GNOME Bugzilla – Bug 759363
Explicit exports functionality with more options
Last modified: 2016-01-20 07:31:56 UTC
Now that Photos has editing, it needs export. Currently, any edited photo is automatically exported to a predefined Exports folder. There are a few problems with this approach: * It makes it hard to share an album, where only a subset of the album has been edited. * If you shoot in raw, there's no way to share photos that haven't been edited. * It needlessly eats disk space. * It means that the user can't change the size of the images, in order to have smaller files. * Once we get sharing/upload functionality, export via a local file won't always be necessary in order to share. Automatically exported photos will often be redundant. It would probably be better to have an explicit export function, which can be accessed from selection mode. Initial mockups for this: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/photos/wires-export.png
I wonder if we should have a cut-off for the "reduced" exports. eg., Facebook supports a maximum width of 2048px these days: https://www.facebook.com/help/266520536764594/ The threshold could be smart. eg., if the picture is already below 2048, then "reduced" can be the next lower step.
(In reply to Debarshi Ray from comment #1) > I wonder if we should have a cut-off for the "reduced" exports. eg., > Facebook supports a maximum width of 2048px these days: > https://www.facebook.com/help/266520536764594/ > > The threshold could be smart. eg., if the picture is already below 2048, > then "reduced" can be the next lower step. In order to achieve the desired effect, it might make sense to decide on an image size that is big enough, but not needlessly big. You could go for something like 1000px on the short edge, for example.
Created attachment 317421 [details] [review] application, utils: Define a macro for the export sub-path
Created attachment 317422 [details] [review] query-builder: Skip exported URIs
I have some doubts about this string: "Photos are exported to the Pictures > Exports folder" Even though XDG_PICTURES_DIR is often set to ~/Pictures, there is no guarantee that it will always be so. It can point to ~/<localized("Pictures")>, ~/foo, or the user's home directory itself. I wonder if "... foo > Exports ..." will be easily understood by the user. I see that Files always uses the base name to name the bookmarks for these folders. eg., "foo". In Photos' properties dialog we hyperlink the full path for local items.
An initial implementation is now available in gnome-photos:wip/rishi/misc-fixes It lets you export an image from the hamburger menu. Missing items: * Not accessible from the selection toolbar * Doesn't downscale * Cannot export albums
(In reply to Debarshi Ray from comment #5) > I have some doubts about this string: > "Photos are exported to the Pictures > Exports folder" > > Even though XDG_PICTURES_DIR is often set to ~/Pictures, there is no > guarantee that it will always be so. It can point to > ~/<localized("Pictures")>, ~/foo, or the user's home directory itself. I > wonder if "... foo > Exports ..." will be easily understood by the user. > > I see that Files always uses the base name to name the bookmarks for these > folders. eg., "foo". In Photos' properties dialog we hyperlink the full path > for local items. I'm not sure it would make sense to show a hyperlink here - it will be gone by the time the user needs it. One thing we could possibly do is show an in-app notification after the export has completed, and that could include a link to the export location. As for the description in the dialog, we could change the string: "Photos are exported to the <folder name> folder (you can find this in <xdg pictures folder name>)." Or we could drop it altogether, if we decide to use an in-app notification?
(In reply to Allan Day from comment #7) > I'm not sure it would make sense to show a hyperlink here - it will be gone > by the time the user needs it. That's a good point. > One thing we could possibly do is show an > in-app notification after the export has completed, and that could include a > link to the export location. > > As for the description in the dialog, we could change the string: > > "Photos are exported to the <folder name> folder (you can find this in <xdg > pictures folder name>)." > > Or we could drop it altogether, if we decide to use an in-app notification? I am leaning towards using an in-app notification and dropping the description in the dialog. Enabling the user to click a hyperlink to open Files is more straightforward than using a textual explanation.
Created attachment 317825 [details] [review] utils: Change PHOTOS_EXPORT_SUBPATH to be "Exports"
(In reply to Allan Day from comment #2) > (In reply to Debarshi Ray from comment #1) > > I wonder if we should have a cut-off for the "reduced" exports. eg., > > Facebook supports a maximum width of 2048px these days: > > https://www.facebook.com/help/266520536764594/ Flickr allows a maximum size of 200MB and resizes the image into 2048px, 1600px, 1024px, 800px, etc. versions: https://www.flickr.com/help/photos/ > In order to achieve the desired effect, it might make sense to decide on an > image size that is big enough, but not needlessly big. You could go for > something like 1000px on the short edge, for example. It can be tricky to define it in terms of the short edge. Think of panoramas, for example. The longer edge is probably a better option and that is also what Flickr is using. I guess we won't be showing the radio buttons if the original image is already small enough. Right? By the way, are you happy to have only 2 levels? Apple Photos on Mac OSX has more: https://discussions.apple.com/servlet/JiveServlet/showImage/2-28031167-554861/Screen+Shot+2015-04-09+at+03.42.56CEST.png
Created attachment 317972 [details] [review] Save the pipeline on "Done", instead of exporting the image
Created attachment 318026 [details] [review] application, preview-menu: Add "Export"
Created attachment 318027 [details] [review] application, base-item: Rework photos_base_item_save_async
Created attachment 318029 [details] [review] Add a sink to guess the size of a GeglBuffer after JPEG compression
Created attachment 318030 [details] [review] base-item: Add photos_base_item_save_guess_sizes_async
Created attachment 318041 [details] [review] utils: Add photos_utils_buffer_zoom_async
Created attachment 318052 [details] [review] Add a zoom parameter to photos_base_item_save_async
Created attachment 318053 [details] [review] base-item: Add photos_base_item_get_bbox_edited
Created attachment 318054 [details] [review] Add PhotosExportDialog
Created attachment 318055 [details] [review] application: Rewrite app.save-current to match the design
The code in master lets you export an image, and optionally downscale it, from the hamburger menu. I have left out the description for the time being, and there is no in-app notification either. Other missing items: * Not accessible from the selection toolbar * Cannot export albums How do you want to place it in the selection toolbar? Do you want to use an icon or a label? Exporting albums will take more effort. Given the other items on the roadmap [1], I think it might be better to do it during the 3.22 cycle. [1] https://wiki.gnome.org/Apps/Photos/Roadmap
Created attachment 318193 [details] [review] base-item: Fix typo
Created attachment 318194 [details] [review] base-item: Fix typo
(In reply to Debarshi Ray from comment #10) > > > I wonder if we should have a cut-off for the "reduced" exports. eg., > > > Facebook supports a maximum width of 2048px these days: > > > https://www.facebook.com/help/266520536764594/ > > Flickr allows a maximum size of 200MB and resizes the image into 2048px, > 1600px, 1024px, 800px, etc. versions: https://www.flickr.com/help/photos/ Sounds reasonable. > > In order to achieve the desired effect, it might make sense to decide on an > > image size that is big enough, but not needlessly big. You could go for > > something like 1000px on the short edge, for example. > > It can be tricky to define it in terms of the short edge. Think of > panoramas, for example. The longer edge is probably a better option and that > is also what Flickr is using. Sure, makes sense. > I guess we won't be showing the radio buttons if the original image is > already small enough. Right? Right. > By the way, are you happy to have only 2 levels? Apple Photos on Mac OSX has > more: > https://discussions.apple.com/servlet/JiveServlet/showImage/2-28031167- > 554861/Screen+Shot+2015-04-09+at+03.42.56CEST.png I thought about it, but couldn't think why more levels would be needed.
(In reply to Allan Day from comment #24) > (In reply to Debarshi Ray from comment #10) > > > > I wonder if we should have a cut-off for the "reduced" exports. eg., > > > > Facebook supports a maximum width of 2048px these days: > > > > https://www.facebook.com/help/266520536764594/ > > > > Flickr allows a maximum size of 200MB and resizes the image into 2048px, > > 1600px, 1024px, 800px, etc. versions: https://www.flickr.com/help/photos/ > > Sounds reasonable. Right now, it uses two steps: 2048 and 1024. If an image is bigger than 2048, then the reduced version is downscaled to be 2048 on the longer edge. If the image is between 2048 and 1024, then it is downscaled to 1024. Anything smaller is not downscaled. 2048 seemed like a good choice for HiDpi displays. > > I guess we won't be showing the radio buttons if the original image is > > already small enough. Right? > > Right. I wonder if we should have a couple of spinners though. It takes a second for the size estimates to show up.
Created attachment 318215 [details] selection mode mockup (In reply to Debarshi Ray from comment #21) ... > How do you want to place it in the selection toolbar? Do you want to use an > icon or a label? See the attached mockup for how we could do selection mode. Also, with selection mode the dialog will need to adapt for multiple selections. I've updated the wireframes for that: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/photos/wires-export.png
Created attachment 318425 [details] [review] Add a sink to guess the size of a GeglBuffer after PNG compression
Created attachment 318427 [details] [review] base-item: Rework PhotosBaseItemSaveData to be more flexible
Created attachment 318428 [details] [review] base-item: Use photos:png-guess-sizes for guessing PNG sizes
Created attachment 319334 [details] [review] export-dialog: Make the formatted size text smaller
Created attachment 319335 [details] [review] export-dialog: Show a progress message while we are guessing the size
Created attachment 319341 [details] [review] export-dialog: Add the pixel dimensions to the size text
Created attachment 319344 [details] Screenshot of export dialog without any downscaling options
Created attachment 319345 [details] Screenshot of export dialog while it is calculating the sizes
Created attachment 319346 [details] Screenshot of export dialog with downscaling options
I would like to close this now. I filed gnome-love bugs for the remaining items: (i) Support exporting from selection mode (bug 760838) (ii) Manual export of albums and multiple images (bug 760839) Please feel free to open new bugs about further polish and changes.