While I have been working for days on the animation software for ZeMarmot, I wanted to “rest” my brain a little and came back to an old project of mine, which I should have implemented months ago.
So let’s get the troll out straight away: yes, this is about the split between save and export on GIMP. Now I was not there when the decision was taken, but I think it makes sense anyway. Saving is about “your work”, your process. XCF is — in such a view — not an image format, but a project format. It contains much more than the final visual image. Same as you would not save a “.mpeg“, “.avi” or “.mov” in blender, but a “.blend“, you don’t save a “.jpeg” or “.png” either, but a “.xcf” (another analogy for developers out there: “.blend” or “.xcf” can be compared to your source files — which is definitely what they are in a multimedia project — and the image or video formats as the compiled binary).
Yet I understand that some users have a hard time understanding this since there are nearly no difference in our GUI between saving and exporting.
What’s the difference, you’d ask? And you’d be right.
In the last 2 days, I refactored the whole GimpFileDialog code, which was completely mixing every concepts with hard-to-read if {} else {} statements inside a single class. GimpFileDialog became a generic parent class, containing only logics common to all file dialogs, and I added 3 specific children: GimpOpenDialog, GimpSaveDialog and GimpExportDialog.
This will allow us to do easily much more interesting graphical interfaces specific to each process.
As a proof of concept, I tested a “Scale at export” feature, which would allow to rescale images at export time, without touching the original. Who indeed never worked on some high resolution image, then needed to export it in lower resolution (to upload on some website, send through email or whatever…)? The current GUI would force to scale the original image, export it, then not forget to cancel the scale afterwards (if you forget, save and quit — for instance by habits — you are doomed: you just completely lost data and hours of high res work!).
Here for a UI test:
Now before you tell anything: I know that the above screenshot does not look so nice, with a lot of wasted space on the right. I reused an existing widget (the same used in the “Scale Image” dialog, if you know GIMP well) and have not been trying to customize for this first version. The goal was mostly to test the new refactored code and we have some more thinking and discussion before actually adding these features (there are many more things that could be rethought to improve export, at deeper levels too).
The refactoring is now merged to master; the “Scale at export” isn’t yet though (feel free to test it on its git feature branch though, it’s functional).
Of course this is only the start of greater things. One may want to crop an image, change the color space (particularly if you were working in non sRGB), or even apply any GEGL operation before export (like “sharpen” after downscaling).
This should all be possible soon. Of course we’d have to work on the ideal UI to not clutter the export dialog. I will keep readers updated for when the next steps will occur.
I believe this is partially what some people would call a “Save for Web” feature, though I personally don’t like this naming since it is far too restrictive. You may want to change your exported image for far many more reasons that just “the web”.
Now I’ll be back to ZeMarmot (and I remind everyone who wants to support me to improve GIMP they can still support our Open Animation Film)!
It seems logical then to merge the “Save for Web” dialog with “Export”. Save for Web should be deprecated since it actually exports and that terminology miss then messes with the user. The features from Save for Web could then be merged with the new export dialog since their functionality relates to each other.
It looks like you are saying the “Save for Web” plugin is an official plugin. But as far as I know, it has been made by a third party and is not shipped with official GIMP.
This said, you are right that at term, the most important features of a “Save for Web” could definitely have their place in the export dialog. Even preview: I could definitely imagine that we could get an in-canvas (rather that in a separate window) preview of the export in order to evaluate quality before export, same as we have in-canvas preview of GEGL filters in our current dev version.
Yet it is possible also that some very specific options (ones not used often enough to be on the main dialog, maybe the Save for Web plugin has some like this?) could still have their place in a separate plugin.
In any case, this is all in early design, and we have to think about what should be there or not, and how. An important part of the job is to not bother users who don’t care about these options and just want to use defaults (thus not to clutter the UI in an obtrusive way).
As for the “Save for Web” plugin, we don’t manage it.
Niklas, the Save for Web plugin has already been renamed to Export for Web anyway.
This looks like decent progress but how would this hold up with the GTK+3 migration in the future. Their dialogs have quite a different design so are you taking that into accound now or is the plan to leave it until the migration is at a further point?
I have not tested these changes in our GTK+3 branch yet. Obviously we will, but even if different, I don’t doubt a second we will be able to make a good transition for this feature (and others).
Why not renaming “save” to “save project” and “export” to “save image”?
I don’t understand how this would solve anything. We don’t “save” images. We export them, or render them… all but “save” them, since we rather “lose” than “save” data. Which bitmap image format has support for layers, alpha channels, masks, vectors/paths, selection (itself with some kind of opacity), color channels up to 64 bit floating point precision, and so on? No raster format has *all* of these (some have a few of the features).
I really don’t understand all the fuss about this save/export split. Now don’t get me wrong, I understand some people got used to before, and I could have perfectly lived with and hacked GIMP if it had not done such a split. But now that it has, I think it makes sense, and this split may be after all what sparkled these ideas in me that “export” should be so much more than what it is now. So I think it was a worthwhile split. And renaming it “Save image” would just bring back more confusions to users (“Why are there 2 saves? What’s the difference?” Etc.).
the problem is that there are many gimp users who never used XCF of their life. They use gimp for things which don’t require layers or things like that (let’s say crop, curves, selections, clone… plenty of stuff like that that you can do without needing XCF). Or if they use layers and features like that they use them only temporarily and never save them. They don’t keep the “raw” “original” data like that. And those users know word, excel, and so on, but not photoshop and other tools.
These users exist. They are not used to the old gimp behaviour. They are used to the behaviour of most all applications except professional applications like photoshop that they don’t know and will likely never use.
For these users I think the distinction “project” or “image” makes plenty of sense.
I don’t have a video editor in front of me but I would expect video editors to also use “save video” and “save project” or maybe “export video” and “save project”.
Not simply “save” and “export”.
But yes anyway just adding a word won’t solve the problem, that people who are confused today will still be confused when pressing ctrl-s and so on.
Openshot: Save project / Export video
Pitivi: Save / Render
Blender: Save / Animation
Kdenlive: Save / Render
I can’t check directly at proprietary software, but from screenshots (which may be outdated of course), it looks like both Adobe Premiere and Afters Effects would be: Save / Export (funnily they have the “Project” concept only for “Open Project”, not on the “Save” item).
Anyway, as you say yourself, I seriously don’t think it would solve any of the confusion.
“I don’t have a video editor in front of me” — well, you should have 🙂 Then you could check it for yourself and see that your assumption is far from being correct 🙂
You may probably be shocked to learn that “professional applications like photoshop” use the Save As dialog to produce formats as JPEG, PNG or TIFF (a simple Save will keep the current format, not force a .PSD.
Great idea, I really like the variant: “save project” and “export image”.
To anyone understanding good english – this conveys the difference final file format that will be created by the dialog.
I second this!
“Why not renaming “save” to “save project” and “export” to “save image”?”
Iirc changes to the graph in gegl are persistent and so having a save button in the first place seems a bit redundant.
If I’m wrong and it isn’t persistent then making it persistent should definitely be a goal.
Export seems like the logical term to be using tbh.
Conveying what export actually does could be done more effectively if gnome had something like intents for passing a project from gimp to another application in a format the other application supports.
e.g. To elaborate on what I mean about using something like intents.
export-> gnome_mail -> contact || group -> supported formats for gnome mail
Now lets say the users workflow involves sending the image/project’s they work on to the same contact(s)/group.
Gimp should try and be smart about guessing the default properties you would like to use when exporting to said contact/group by setting up policies for different groups/contacts based on the most frequent/last used properties the user chose for that specific group/contact.
Hi,
Managing file exchange over networks could be a cool plugin (actually we used to have a “send by email” plugin, but it was very rough and it has been disabled in our tree for some time now. It could be revived if there are some will from contributors), but should not be implemented as a core feature, in my opinion.
Also you seem to assume that GIMP is a GNOME software. This is not the case, it is a friend of GNOME, and under its protective umbrella, but it is not in the core project. I am personally against GIMP to depend deeply on GNOME (or any other desktop, for that matter). Processes I am in favor, however, are using desktop standards (freedesktop and co.) for information exchange so that we could work with any other software understanding the same desktop standards (so if the goal is to send an email, we should be able to interact with any email client, and not just GNOME mail). This was maybe not what you meant when speaking of GNOME intents or GNOME mail, but I just wanted to make this point clear.
Also I have a hard time understanding how this relates to export, or even if how this would really improve a workflow that much. Firing your web client and attaching a file yourself is not that terrible, especially that you would not do it every 5 minutes (well if you have to, more things are wrong in your workflow and even a “Send by email” feature in GIMP won’t be the solution).
I was aware of that. There was a proposal a while back on freedesktop.org to implement intents -> http://lists.freedesktop.org/archives/xdg/2014-January/013068.html
For a better understanding of what I mean -> http://developer.android.com/training/sharing/send.html
Right now when you export something in gimp you are exporting it to a location in the filesystem.
I think that what is creating the disconnect with the term export.
What I had in mind was having a more general system where different applications would advertise support for gimp along with application level policies with even more fine grained policies(like what I mentioned with contacts/groups with gnome mail).
gwibber might advertise to gimp that it is a supported destination for export and tell gimp what formats and resolutions are supported/recommended,
and/or polari etc.
In other words it doesn’t have to be export to mail.
Would be interesting to see integration with a webserver working through a system like intents(having the webserver advertise the optimal resolution and format based on the markup and stylesheet of a page).
Doesn’t have to export over network, could be export->nautilus->this-directory(nautilus tells gimp there are 6 jpg files in this directory at 800×600) and gimp defaults the properties of export to jpg @800×600
Sorry for the long winded post but the reason why I think this helps remove the mental disconnect with the term export is because you have that link between the conversion to a lossy format attached to the reason you are converting to lossy format. You also have more guidance through the process because gimp is provided with a better context of what you want to do and what options are supported for getting that task done(don’t show user options that aren’t relevant to the task at hand/if its not supported for their task then don’t display it).
Everything you can currently do with export dialog would be possible with one based on intents, the main difference is that it would be a more straight forward process.
Sorry, I’m pretty terrible at explaining and its probably a bad idea anyway.
could probably be summarized as exporting to location on filesystem in order to import into an application is more hassle for the user and less powerful than having the application communicate the context of what it will accept to gimp(hopefully using freedesktop.org standard).
Great Work on the Open/Save/Export Dialog Box – it sounds like the clarity between the three has been improved in the codebase – always glad to read a GIMP post 🙂 GTK3 branch is amazing – especially the dark variant on arch from GIT.
I am one of those who *hates* with a passion the Save/Export dialog split. I use GIMP a lot for photography work, where I start with JPEGs or RAWs (depending of the project, type of work and such) and *never* in this type of workflow save as XCF, but only as JPEG
Sure, sometime I do design work and then keep the XCF around for further iterations of the project,, but then the project started as an XCF so it make sense to save as XCF, which is not the case when the project started as a JPEG.
Regarding the editing (scale) from the export dialog, indeed there are cases when you want a copy for a different medium (for web display, preview for your client or such) and you probably want that copy optimized (sharpness and maybe more). Then you don’t want that optimization done blindly, you want to *see* the result, which would bring some kind of a full editing app inside the export dialog.
> Then you don’t want that optimization done blindly, you want to *see* the result, which would bring some kind of a full editing app inside the export dialog.
I agree. As I said in another comment, I would imagine an in-canvas preview for the result of what is going to be exported. No need to add this kind of preview inside the export dialog, where it would likely end small and barely usable, whereas in-canvas, you could still zoom in and out, flip or do whatever you want to check out the preview properly before actually exporting (yet not touching the original image).
Just the same as we have live preview of filters (GEGL operations) directly on canvas, currently (in the dev version).