Peck: New GIMP Save/Export plug-in: Saver [LWN.net]

At her blog, Akkana Peck has announced a new GIMP plugin called "Saver" that is intended to replace the default Save/Export functionality introduced with the GIMP 2.8 release. GIMP 2.8 famously separated "Save"and "Export" into two separate functions, with "Save" only able to write out images to GIMP's native, multi-layer XCF format. As Peck notes, that change "has been a matter of much controversy. It's been over two years now, and people are still complaining on the gimp-users list." The new plugin is an attempt to perform the "expected" action in each circumstance. "I've been using Saver for nearly all my saving for the past year. If I'm just making a quick edit of a JPEG camera image, Ctrl-S overwrites it without questioning me. If I'm editing an elaborate multi-layer GIMP project, Ctrl-S overwrites the .xcf.gz. If I'm planning to export that image for the web, I Ctrl-Shift-S to bring up the Saver As... dialog, make sure the main filename is .xcf.gz, set a name (ending in .jpg) for the exported copy; and from then on, Ctrl-S will save both the XCF and the JPG copy.

to post comments

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 7, 2014 20:26 UTC (Fri) by dfsmith (guest, #20302) [Link] (9 responses)

I know this is the wrong forum but...

I wish these editing programs would do "automatic export". Often I find myself making a minor edit in an Inkscape/GIMP/Xara master document and then have to do a tedious chain of exports for the different formats sizes for production. (E.g., .raw -> large jpeg, small jpeg, plus update the raw.)

I realize that make + ImageMagick's "convert" will do this if I don't mind dropping down to the command line; but it's tedious, and means more aux files!

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 7, 2014 20:32 UTC (Fri) by halla (subscriber, #14185) [Link] (1 responses)

Hm, this is an interesting idea. I can definitely see how it would speed up people's workflow. Making a nice ui for it could be tricky, and one would have to decide how to store the patterns -- naming convention, sizes, formats, scaling algorithms -- as presets. I guess we could even share that kind of preset definition between krita, gimp and other apps.

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 7, 2014 21:23 UTC (Fri) by dfsmith (guest, #20302) [Link]

On the export dialog, add an "Export this when saving document" check box, and watch the time-stamps like a hawk!

Another (sub)dialog under document properties would have to be made to remove the auto exports.

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 7, 2014 22:03 UTC (Fri) by ballombe (subscriber, #9523) [Link] (2 responses)

You can create a GIMP plugin that does that for you.

Re: You can create a GIMP plugin that does that for you.

Posted Nov 9, 2014 20:52 UTC (Sun) by ldo (guest, #40946) [Link] (1 responses)

For some reason that doesn’t go down well. I think when people hear “GIMP plugin”, they think of something similar to “Photoshop plugin” and some massive, complicated C++ programming job.

They don’t realize that a GIMP plugin can be written in just a few lines of Python. Think “Photoshop automation” but more advanced. Though you can go all the way to “Photoshop plugin” if you really want.

Re: You can create a GIMP plugin that does that for you.

Posted Nov 10, 2014 13:24 UTC (Mon) by Tjebbe (guest, #34055) [Link]

I think that is why Firefox makes a very explicit distinction between plug-in and add-on.

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 8, 2014 8:06 UTC (Sat) by peter-b (guest, #66996) [Link]

When I've had to do this in the past I've used a Makefile (including rules for cleaning up the droppings).

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 8, 2014 13:49 UTC (Sat) by rsidd (guest, #2582) [Link]

From TFA, the saver plugin does automatically export to one format if you set it to do so. It may not be hard to modify it to do what you need (though "large jpeg" + "small jpeg" may be more complicated).

The plugin looks very well thought out and I hope the GIMP upstream takes note!

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 9, 2014 22:12 UTC (Sun) by debacle (subscriber, #7114) [Link]

This sounds like a good idea. Why not enter it in the Gimp bug tracker as enhancement idea? Maybe link to this LWN discussion and the positive feedback you received.

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 14, 2014 3:55 UTC (Fri) by jzbiciak (guest, #5246) [Link]

I know what you mean. When I'm in a situation where I want to publish multiple versions of an image, I find myself wishing I had a facility like I have already for circuit boards. Allow me to explain.

From time to time I design circuit boards in a program called Eagle. It has a feature called CAM Jobs. It's like scripting, only a bit more rigid in structure. (CAM == Computer Aided Manufacturing.)

The purpose of a CAM Job is to generate various files from the board I've designed. (For CAM files, it's usually separate files for each layer, plus some metadata files for drills and such.) My schematic and board stay in their native .sch and .brd formats. The CAM Job walks through the design and, according to my specification, extracts a number of files with different properties. The CAM Job is configured through the GUI, mostly by checking boxes on a form and selecting / configuring a few other parameters.

It sounds like you want something similar for exporting images. You want to keep your source image in native format and size, and then when you push a button, it generates a set of derived image files that differ in format, size and other characteristics. And, given that it's all based around exporting, it's a bit more rigid than you'd normally encounter with full scripting, so it perhaps lends itself to a GUI presentation more easily.

(There's a parallel to Eagle here as well: Eagle allows fairly complex scripting, but CAM jobs can be set up with far less effort (at least for me) from the GUI, and still be fairly complex.)

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 8, 2014 0:13 UTC (Sat) by gvy (guest, #11981) [Link]

Sounds reasonable.

Lossless JPEG transformations

Posted Nov 8, 2014 8:14 UTC (Sat) by epa (subscriber, #39769) [Link] (11 responses)

I can understand the reasons for not quietly 'saving' in a lossy format like JPEG, particularly not when overwriting the original file. The more times you save and reload, the more opportunities there are for quality to be lost.

Now there are some operations which can be done losslessly on JPEG files. They include rotation by 90 degrees and cropping. But what else? If you load a JPEG and touch up just a small area, can the editor guarantee no loss of data in the rest of the image? What about if you adjust tone curves to boost contrast - is there some way to hook that into the lossy compression so that you can make limited adjustments while keeping the same data?

For better or worse the master copy of many images is in JPEG format (not all digital cameras output the raw) so a safe way to edit them would help a lot.

Lossless JPEG transformations

Posted Nov 9, 2014 3:09 UTC (Sun) by k8to (guest, #15413) [Link] (10 responses)

I think this is more about how gimp puts up a roadblock when you load in a PNG and do edits and try to save as another PNG. It's worrying that you might have wanted to take advantage of all its more sophisticated functions with documents and layers and etc. However, the user is just trying to edit an image.

Lossless JPEG transformations

Posted Nov 9, 2014 6:44 UTC (Sun) by riking (subscriber, #95706) [Link] (1 responses)

Precisely this. Roadblocks may be justified for lossy formats like JPEG, but I've resorted to installing a paint program just so that I can perform my simple edits like cropping without having to go through the motions of "Export, Png, filename, done, close, yes I want to discard (I JUST SAVED IT), oh wait it only closed the image, close GIMP".

Lossless JPEG transformations

Posted Nov 15, 2014 12:43 UTC (Sat) by drothlis (guest, #89727) [Link]

Your first 4 steps, at least, can be abbreviated to "File > Overwrite xxx.png".

How we got here

Posted Nov 9, 2014 9:22 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (7 responses)

For a LONG time the software tried to be smart about this, to prompt you only when you were about to do something obviously dumb. For example if you tried to save a layered image in a non-layered format. But that wasn't enough, because people would do things that seemed fine, but then _still_ be angry that GIMP didn't do what they had expected, which as usual for any software was "read my mind".

So we (they by this point, it has been years since I contributed though I always mean to go back) gave up, the Save - Export split is the result. This Save/Export plugin seems to shift back towards the previous status quo. So long as it remains optional I expect most people to keep saying it's great and should be the default. As soon as it's the default, I expect the "I lost everything, you idiots!" emails to begin again.

It is telling that Peck begins by describing a simpler "solution" she wrote that has also been popular but which she herself stopped using because it wasn't actually lining up with her usage.

The thing GIMP doesn't (and can't) see is whether in your head you're thinking "So I'll come back to this tomorrow and fix the text in that middle layer" or "Phew, done, let's get that JPEG in an email and go home". Because in the former case we absolutely need to save the metadata to re-construct that middle layer from text, for when you change it, and in the latter case we absolutely need to just write the JPEG and shut up. Maybe Save/Export will _reduce_ the number of occasions where GIMP guesses wrong, but the Save - Export split ensured that the human is obliged to make their intention explicit, which in my experience is the only reliable resolution when two humans do the same thing but expect different outcomes.

How we got here

Posted Nov 9, 2014 10:16 UTC (Sun) by magnus (subscriber, #34778) [Link]

Perhaps at the time of save when the user thinks it has finished is not the optimal time to ask for an intelligent decision?

For example, if you open a jpeg, you could ask the first time the user tries to modify that file if they want to edit it "in place" or import it into the native format. And you then refuse (in a helpful way) to provide any feature that can not be saved in that format until they import it.

Automatically backing up overwritten non-native files by default could perhaps also be a way to reduce data loss for newbies.

How we got here

Posted Nov 9, 2014 11:33 UTC (Sun) by DOT (subscriber, #58786) [Link] (1 responses)

Another way to bridge the Save-Export gap would be to always dump an XCF file, even if you are saving in a lossy format. So when you edit an XCF you get the expected XCF file, and when you edit a JPEG you also get the expected behaviour (a JPEG file), but as a special backup there is also the XCF. GIMP could even try to find a matching XCF file whenever you open a PNG or JPG file and open that instead.

How we got here

Posted Nov 10, 2014 22:15 UTC (Mon) by HenrikH (subscriber, #31152) [Link]

Wouldn't that lead to the situation where lots of people find flaws with the png/jpg unless they open it in GIMP which makes them go round in circles to why GIMP makes the image look ok but Firefox/Chrome/Whatever displays the image wrongly?

How we got here

Posted Nov 9, 2014 15:02 UTC (Sun) by mattdm (subscriber, #18) [Link] (3 responses)

One of the things that frustrates me is that I tend to load a dozen or so images, work on them, export, and then close. Previously, the warning "you haven't saved!" was useful, because it actually kept me from losing work by accident.

Now, that dialog comes up for both saved and unsaved work ("exported and unexported"), making it valueless. Newer versions at least give text saying if the image was exported, but I still have to check the words rather than just relying on the software to tell me when there's unsaved work and not bother me otherwise.

How we got here

Posted Nov 9, 2014 21:26 UTC (Sun) by luya (subscriber, #50741) [Link]

It sounds like a bug or a request of enhancement.

How we got here

Posted Nov 9, 2014 23:09 UTC (Sun) by nybble41 (subscriber, #55106) [Link] (1 responses)

> Previously, the warning "you haven't saved!" was useful, because it actually kept me from losing work by accident.

Except that it didn't, really, because not all of your work was saved when you exported to a non-native image format. Particularly if that format used lossy compression, like JPEG. It makes perfect sense that the program would ask whether you really intended to throw away the rest of the information which wasn't included in the export.

Perhaps the best solution would be to base64-encode the XCF file and stick it in a JPEG comment field. ;)

How we got here

Posted Nov 10, 2014 0:00 UTC (Mon) by mattdm (subscriber, #18) [Link]

> Except that it didn't, really, because not all of your work was saved when you exported to a non-native image format.

Except that it did, really, because I have an archived copy of the original somewhere else, and there's nothing in the xcf format that represents anything extra and useful for me.

If Gimp were a non-destructive adjustment-based editor it might be different, but it's not anyway. (And even if it were, the intermediate adjustments aren't usually important to store anyway.)

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 8, 2014 14:34 UTC (Sat) by zuki (subscriber, #41808) [Link]

I don't like the save/export split, so I went off to install this plugin...
... and learned about the dynamic keybindings functionality. It is simply amazing.

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 9, 2014 21:32 UTC (Sun) by luya (subscriber, #50741) [Link]

From my view, that plugin encourages bad practice especially when trying to save from a non-destructive file like xcf to destructive file like jpeg. It is a matter of incoming disasters.
Although that plugin is useful for some people, that compromise is detriment to other images editors using different software notably Adobe Photoshop. For that reason, that plugin should remain optional and bad practice should be discouraged.

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 10, 2014 21:08 UTC (Mon) by Harland (guest, #52209) [Link] (12 responses)

Had to chime in ;) , as it is suprising this 'arguement' still does not have a standand solution.

First, why is there a 'save' button at all? There is certainly enough space available on most machines; most of the time there is all ready a working directory; and undo lists and working backups are necessary. --> Opening creates an original 'backup', and saves are auto and native - lossless, and then you may want checkpoints/releases/exports. Honestly, get rid of the brain drain of organizing this, and let the machine just do it, and let the ones that have to do something else, have custom options (no backup, no auto, etc)

In audio and video work, exports are also known as rendering profiles - which can be batched (and seems to me jpeg is a render, not an edit master).

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 11, 2014 13:21 UTC (Tue) by ggiunta (guest, #30983) [Link] (11 responses)

One has to wonder why no-one has implemented this as fully working solution yet... There have been attempt, though, with recent versions of OSX going that direction.

In short: if a user can not be bothered to figure out how to use 'saving', he will also be lost when told to
- pick from rev. 93256745 or 93256746
- pick from rev. 9.15am or 9.17am
- checkpoint the current revision as 'specific tag here' to later retrieve it

In other words: its not a technology problem, it is a business logic one

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 12, 2014 3:33 UTC (Wed) by Harland (guest, #52209) [Link] (10 responses)

I guess part of my reasoning, is I should not have to think about saving; only, hey, I need to export/render this in another format, and my work is never at 'risk' (barring of course non app related data loss). And I feel Im a well versed and intelligent user, and I dont want to think about saving (or when I did).

And I dont see the 'business logic' problem. I expect to see the last version/edit I made, and optionally I can revert to when I opened if my session goes 'off the rails'. The app should give me an undo mechanism (hopefully) while in session, all the while saving (no button pushes). As a sophisticated user I might want a checkpoint(etc). And the app never has to get me to pick a rev unless (fairly rare) I see a "oh sh** when did I do that mess up" and try to go back.

We're not (mostly) saving to floppy anymore, where it might take a coffee break to wait it out. The save button is a technological hold over from I/O bound wait tasks. It should be deprecated.

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 12, 2014 8:18 UTC (Wed) by halla (subscriber, #14185) [Link] (9 responses)

Actually, saving an image of the size currently normal, with the number of layers currently normal still takes quite a bit of time. You're going to have to compress and save several gigabytes of pixels.

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 12, 2014 21:22 UTC (Wed) by Harland (guest, #52209) [Link] (8 responses)

Gigabytes of image data? if 25 megapixel * 16 bit colour (=2Bytes per pixel) => 50MBytes total image bitmap, that is about a 1sec transfer on PATA for the _whole_ image and 25Mpx is way above normal (most pro are ~13Mpx). Layer data may multiply this, but certainly not several gigabytes.

I still dont see why we need a save button to tell the app to flush/serialize memory to disk.

The only functionality that may remain for this button is when I create a _new_ file/project and want to name the file on disk (even this should only be a rename, as it should be saving for me already in some default location)

I realize this may not be the correct forum for all this, but hope it sparks something.
As I get older I learn I dont want to control all the things, and pushing save is tedious, especial for quick edits -- I want: open, edit/render, close/done.

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 12, 2014 21:59 UTC (Wed) by raven667 (subscriber, #5198) [Link]

Oh I don't know, the Krita developer you are speaking with is talking about clients at the high end with 64Mpx images and many layers (say 10+) with undo buffers and whatnot that can add up really fast.

So I think you are right for the general case, just have saving be automatic and don't require explicit action, but that doesn't cover all use cases, sometimes explicit is best.

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 12, 2014 22:25 UTC (Wed) by halla (subscriber, #14185) [Link] (2 responses)

16 bit per channel is two bytes per channel is 8 bytes per pixel. "16 bit colour" does not exist in any practical way these days. The minimum is 8 bits per channel, which is four bytes per pixel. The current maximum in Krita 32 is bits per channel, though people are asking for 64 and 128 bits floating point per channel.

Grayscale images are two channels, rgb images 4 channels, cmyk images five channels: you need to count for an alpha channel as well.

I regularly get complaints from users who have images of 25,000 times 12,000 pixels. At 16 bits per channel, with a dozen layers.

That is:

25,000 * 12,000 * 8 = 2,2351742 gb per layer.

Times a dozen layers, plus the final rendered result. That is, give or take, 30 gb of image data. Which all needs to be accessed to to compute that final rendered result at the highest possible fidelity.

Now, I'm not going to tell my users they are wrong or that their demands are unrealistic; I'm not in the business of educating my users, it's up to me to try to make it possible for them to do what they want to do. The only real problems are things like memory bandwidth and cache sizes.

Heck, right now, a 300 dpi A4 16 bit floating point RGBA image with two dozen layers is a problem already. And that sort of image even makes _sense_.

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 13, 2014 21:51 UTC (Thu) by Harland (guest, #52209) [Link] (1 responses)

Thank you for the correction on the gigabyte data, and I baulked on the colour bits/channels.
I was thinking on the lines of (most) camera image data, but makes proper sense for hand/machine painted pixel data, amazing.

I still think it is feasible to remove the save button ;). Why is an app waiting for the user to hit it explicitly (Id rather commit an edit/change and revert, then not)?
It may be awhile coming, to break this UX paradigm, but I think it is a needed change.

Cheers, H.

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 17, 2014 22:45 UTC (Mon) by n8willis (subscriber, #43041) [Link]

As an aside, I would point out here that "automatically saving" in the background is, in a manner of speaking, the approach taken by most if not all raw-photo editors. Rawstudio, etc. In those cases, the app-specific "edited" version is usually hidden from the file-browsing UI in some way (.filename, hiden dir, etc), just like matching raw+JPEG files are rarely listed separately.

Then again, raw photo editing is almost always lossless, since it consists of a series of filter operations.

GIMP and Krita might could get away with always saving an edit-able format, depending on how fast disk storage increases in capacity. But more interesting to note is that in future (post-3.0) releases, GIMP's native format will also be lossless, since it will be a graph of GEGL operations. So the always-save approach might just automatically make sense in some future release.

But that's still a ways away. And always-save-in-background has other problems, as has been pointed out.

Nate

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 22, 2014 23:19 UTC (Sat) by Wol (subscriber, #4433) [Link] (3 responses)

> most pro are ~13Mpx

Pretty much *ALL* DSLRs on sale nowadays are twice that. Pro-grade cameras probably three times that.

You may be right that the average is ~13Mpx - many pros hang on to their old cameras that are maybe 6Mp or 10Mp because the sensors are such good quality, but actually getting a new camera with such a low pixel-count is well nigh impossible.

Cheers,
Wol

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 23, 2014 2:11 UTC (Sun) by tao (subscriber, #17563) [Link]

Nikon D4S is "only" 16Mpx and is the flagship pro model. They have plenty of cameras with higher Mpx than that, but the pro models tend to be lower Mpx, higher framerate,

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 23, 2014 4:46 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

Pro cameras are in the 16-25Mp range, the big difference in the pro cameras isn't in the number of pixels, but rather in the size of the pixels (which equates to better low-light and high speed capabilities) and in the quality of the lenses

Peck: New GIMP Save/Export plug-in: Saver

Posted Nov 23, 2014 22:48 UTC (Sun) by anselm (subscriber, #2796) [Link]

There are “pros” and then there are “pros”. If you are a professional sports photographer your camera requirements will be considerably different from those of a professional landscape, travel, or fashion photographer. Many “professional” photographers these days even move away from DSLRs towards mirrorless systems which are a lot less bulky but in many cases produce comparable image quality.

Also, megapixels in general are greatly overrated as a quality measure for cameras. For most purposes, high megapixels will improve your photography in the same way that flames painted on the side of your car will improve your driving. There are a few very restricted areas of photography where high megapixels do make sense but that does not even apply to all “professional” photography. The people who are into that sort of photography typically don't bother with DSLRs – they use medium-format bodies with digital backs which are very expensive indeed but can produce way better results.