Re: [Gimp-developer] Save/export, option to go back to old behaviour

[Graeme Gill <graeme2 argyllcms com>]

Alexia Death wrote:
> Even the act of loading a file into memory as pixel data and then
> recompressing on save is lossy for lossy formats and grayscale formats
> outright destroy information if the original is color. It is not

This type of argument simply doesn't hold water. A file that
holds the image data in a lossily compressed format positively
indicates that this is what the user intends. They have chosen
a certain image quality vs. file size tradeoff, and not maintaining
this choice is discarding the users preferences.

To load a compressed image, and then simply invent 90% of the
bits out of thin air, add the invented bits back into the
image and then carefully preserve every one of them is just nonsense.

Honouring the idea of loss prevention when dealing with
lossily compressed sources simply means (by default)
maintaining the same level of quality/size traedoff.
[ Of course the user should have the option of changing this
tradeoff if they so desire. ]

> realistic to keep track for each format feature by feature, if the
> image is now restorably exported or not, it would make maintaining
> gimp code and adding features a horror... Each change anywhere would
> recquire going over all export plugins making sure their supported
> feature lists are up to date... This separation makes it clear cut.

That's an implementation limitation, not a fundamental logical constraint.
The internal storage just has to keep track of what image feature
is being used (trivial to automatic), and for the various file format code
to check whether they can save all the features used. There is nothing fundamentally
hard about creating or maintaining such an approach, although I can well
believe and accept that development history may prevent such an approach
in Gimp with any ease. But if that is the case, the honest thing is
to accept this and work towards overcoming it, rather than pointing
to talk of "loss prevention".

> The project file, the one that keeps ervery feature of gimp intact is
> the xcf and you save to it. Any rendering you export to. And this
> distinction will get even more important when we get to gegl backend
> in full.

So what ? You certainly don't want to create a superset storage file
unless it contains more than the original file contains. To do so
is simply wasteful and a burden on the user.

> In short, options were considered, arguments have been had. We didn't
> do this to anoy anybody, we did this based on alot of consideration
> and a future of GIMP as a nondestructive image editor.

Not thought through with enough imagination or consideration of the
users perspective, in my opinion.

Graeme Gill.