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)!