[Gimp-developer] Annoying behavior of shared settings for file save plug-ins

[Могучий Сергей]

> On Thu, 30 Aug 2007 11:07:40 +0200, Raphaël Quinet <raphael at gimp.org>  
> wrote:

> On Thu, 30 Aug 2007 00:57:44 +0200, gg at catking.net wrote:
>> Gimp should not decide what is "better" because it cannot know what is
>> required so cannot make that choice.
>>
>> This sort of "surprise" behaviour is precisely the kind of thing I was
>> warning against in making covert changes to user data.
>
> I think that you are trying to shoot the wrong target.  The main
> problem that I described in my previous message is not the fact that
> GIMP tries to preserve the quality of the original image or decide
> what is "better".  The problem is that some changes that you make when
> saving one file are propagated to all other files that you save later.
> The recent updates to the JPEG plug-in make this problem more obvious,
> but it also affects all other file plug-ins.
>
> Before jumping to conclusions about where the problem comes from, please
> try the following exercise:
> - Load or create a GIF animation (2-3 layers should be enough).
> - Save it as A.gif and let's pretend that you don't like the speed at
>   which that animation runs so you set the delay to 333ms and check
>   the box "Use delay entered above for all frames".
> - Close that image.
> - Open or create a new, totally unrelated GIF animation.
> - Save that image as B.gif.  Although you probably wanted to keep its
>   settings or at least save it with the default values, you see that
>   "Use delay entered above for all frames" is now checked.  The
>   settings from an unrelated image that is now closed are used for
>   saving your new image.  If you do not want to destroy the timing of
>   your animation, you have to pay attention and uncheck that box
>   before you save the file.
>
> Does it make sense that two unrelated images influence each other?
>
> But things are even more confusing if you keep some images open.  Try
> the following exercise, with PNG this time:
> - Load or create a new image.
> - Save it as A.png but set its compression level to 0 because you want
>   to waste some disk space and disable all other options because you
>   do not want to save the image comment, creation date, etc.
> - Keep A.png open and load or create another image.
> - Save the second image as B.png.  Although you probably wanted to use
>   your default settings (which can be customized with the buttons
>   "Load/Save defaults"), you see that the same parameters as A.png are
>   now used when saving this image.  You do not like this, so you set
>   the compression level back to 9 (you can also check or uncheck some
>   of the other boxes) and save the image.
> - With both A.png and B.png still open, load or create a third image.
> - Save that image as C.png.  Now you see that C.png inherited the
>   settings from B.png, the last image that was saved.
> - Make some small changes to A.png and save it again using a new name
>   such as D.png.  By now, maybe you expect that saving D.png would use
>   the same settings as C.png, the last image that was saved?  But no,
>   this time you see that D.png keeps the settigns from A.png because
>   it was still open.
> - Now if you make some changes to B.png and give it a new name E.png,
>   then that file will use the settings from B.png.  But if you had
>   closed and re-opened B.png, then you would see that E.png is saved
>   with the parameters from D.png, not B.png.  Are you confused yet?
>
> If you work on two files in parallel (A.png and B.png) and save them
> alternatively as your work progresses, then any new file that you open
> and save will inherit the settings from A.png or B.png, depending on
> which one was saved last.
>
> And if you are still convinced that all of this makes sense, try to
> play with some settings that are enabled or disabled depending on the
> contents of the original image.  For example, if the original PNG
> image has transparency (alpha channel), then you will be able to check
> or uncheck the box "Save color values from transparent pixels".  This
> setting may be propagated to other PNG images that also have an alpha
> channel.  But if you load a PNG image without alpha channel, then this
> option will not be available.  After saving that last file, can you
> correctly guess if that box will be automatically checked or not when
> you load another PNG image with transparency and then try to save it?
>
> I consider the current situation to be broken for all file plug-ins.
> Instead of re-using the settings from whatever image was saved
> recently, each image should keep its own settings and should not be
> influenced by what you do with the other images.  The save settings
> should come from the original image or from the user defaults if the
> image has never been saved yet.  It should of course be possible for
> the user to customize these defaults (currently, this can only be done
> for JPEG and PNG, but the old bug #63610 is about extending this to
> other plug-ins).
>
> I hope that you are convinced that something is wrong with the
> behavior of the file plug-ins.
>
> Now, regarding the JPEG plug-in, I see two ways forward:
>
> 1) Do not re-use the values from previous (unrelated) invocations of
>    the plug-in.  This ensures that each file keeps its own settings,
>    as described above.  The same fix can also be applied to the PNG
>    plug-in because it uses similar parasites for saving image settings
>    and it also has the "Load/Save defaults" buttons.  But other
>    plug-ins will still have the wrong behavior because it is too late
>    to fix all of them before 2.4.
>
> 2) Instead of trying to fix the plug-ins for 2.4, make sure that they
>    are all broken in the same way.  This would mean that the JPEG
>    plug-in in 2.4 will not try to use the quality settings from the
>    original image even if they are better than the defaults.  We would
>    go back to the previous behavior and postpone the real fix
>    explained above until the next development cycle.  Those who
>    complained that GIMP was "destroying" their images by saving them
>    at a lower quality than expected will just have to wait for 2.6.
>
> I don't care about which way we go.  Both of them have good and bad
> sides and both of them will leave some users frustrated or confused.
>
> -Raphaël
> _________________

May be we need switch (radio or combo):
- Use default settings
- Use previous settings
- Use settings from the original image