RSS/Atom feed Twitter
Site is read-only, email is disabled

Annoying behavior of shared settings for file save plug-ins

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

14 of 14 messages available
Toggle history

Please log in to manage your subscriptions.

Annoying behavior of shared settings for file save plug-ins Raphaël Quinet 30 Aug 00:27
  Annoying behavior of shared settings for file save plug-ins gg@catking.net 30 Aug 00:57
   Annoying behavior of shared settings for file save plug-ins Jakub Friedl 30 Aug 08:56
    Annoying behavior of shared settings for file save plug-ins Scott 30 Aug 23:56
     Annoying behavior of shared settings for file save plug-ins gg@catking.net 31 Aug 00:19
      Annoying behavior of shared settings for file save plug-ins Scott 31 Aug 01:10
     Annoying behavior of shared settings for file save plug-ins Raphaël Quinet 31 Aug 17:39
      Annoying behavior of shared settings for file save plug-ins Alexander Rabtchevich 31 Aug 18:04
      Annoying behavior of shared settings for file save plug-ins Robert L Krawitz 31 Aug 18:24
       Annoying behavior of shared settings for file save plug-ins Raphaël Quinet 31 Aug 19:01
   Annoying behavior of shared settings for file save plug-ins Alexander Rabtchevich 30 Aug 09:30
   Annoying behavior of shared settings for file save plug-ins Raphaël Quinet 30 Aug 11:07
    Annoying behavior of shared settings for file save plug-ins gg@catking.net 30 Aug 13:06
Annoying behavior of shared settings for file save plug-ins ??????? ?????? 31 Aug 15:11
Raphaël Quinet
2007-08-30 00:27:06 UTC (about 17 years ago)

Annoying behavior of shared settings for file save plug-ins

Most file-save plug-ins share a behavior inherited from other plug-ins: they save and retrieve their last values so that invoking them again will use the same parameters. As discussed previously, this behavior is fine for image filters but leads to annoying consequences for file plug-ins: if you set some parameters when saving a file, then the same parameters will be re-used if you save another (unrelated) file with the same file format during that GIMP session. These settings will be used instead the default values normally set by the plug-in (which may be user-configurable, as in the PNG and JPEG plug-ins).

Today, Jakub Friedl reported in #gimp that this behavior can lead to surprising results, especially after the changes in the JPEG plug-in that ensure that the initial quality level for the JPEG save dialog is at least as good as the one from the original image. Because all settings from the JPEG plug-in (including the quality level) are re-used from one file to the next, the net result is that the quality level always increases if you load and re-save many files that were originally saved with different quality levels.

Of course I could just add a quick workaround and change the code that sets the initial quality level so that it ignores the value coming from the "jsvals". But wouldn't it be better to remove the call to gimp_get_data (SAVE_PROC, &jsvals) and ignore all these values? Is there still a reason to keep these shared settings, considering that each image that has been saved at least once gets its own "jpeg-save-options" parasite, and the user also has the option to change and save the defaults (which go into a global parasite "jpeg-save-defaults")?

-Raphaël

gg@catking.net
2007-08-30 00:57:44 UTC (about 17 years ago)

Annoying behavior of shared settings for file save plug-ins

On Thu, 30 Aug 2007 00:27:06 +0200, Raphaël Quinet wrote:

Today, Jakub Friedl reported in #gimp that this behavior can lead to surprising results, especially after the changes in the JPEG plug-in that ensure that the initial quality level for the JPEG save dialog is at least as good as the one from the original image. Because all settings from the JPEG plug-in (including the quality level) are re-used from one file to the next, the net result is that the quality level always increases if you load and re-save many files that were originally saved with different quality levels.

Hi,

I said when the new changes were being discussed that the "use image file quality unless defaults are 'better'" was a bad way to go.

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.

This sort of approach will always lead to unexpected results because it is inconsistant.

Stop treating the user like a dumby and trying to make choices behind his back about what is "best" for his files. This would provide a more consistant and predictable behaviour.

A lot of things are now done a lot better w.r.t jpeg but I think this aspect is still fundamentally wrong. Keeping the quality gleaned from the file would solve this problem and provide more predicatable behaviour.

regards, gg/

Jakub Friedl
2007-08-30 08:56:33 UTC (about 17 years ago)

Annoying behavior of shared settings for file save plug-ins

I said when the new changes were being discussed that the "use image file quality unless defaults are 'better'" was a bad way to go.

I think that "use image file quality unless defaults are 'better'" is not thee problem. Problem is inheriting image quality between different images in one GIMP session. I have a default quality of 85. Then I open DSLR image with quality 95. Save it with that quality. Then I open and save low quality cameraphone image. But I am not offered my default nor the original cameraphone quality (which would be both understandable) but the DSLR quality of 95. Huh? These images have nothing in common except they have been opened in the same editor session. Do not mix them up.

Jakub Friedl

Alexander Rabtchevich
2007-08-30 09:30:39 UTC (about 17 years ago)

Annoying behavior of shared settings for file save plug-ins

These are the best words I've heard on UI. A program cannot decide what is better for me because _I_have_not_told_it what _I_need_. This is a principle - it should be up to user, not a program.
In a most common case of saving jpeg files I would like to be able to do via advanced mode:
1. See original file settings as numeric values. That includes quality, subsampling and DCT method .
2. See my current settings (saving and restoring is OK now in RC1). 3. Have some color flag showing which ones are better. This can be done based on the estimation provided in the tread before. And the better way is to show two progress bars one under another - original vs current settings.
3. Decide which one set of settings use for file save: original or adjustable current ones.

gg@catking.net wrote:

Hi,

I said when the new changes were being discussed that the "use image file quality unless defaults are 'better'" was a bad way to go.

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.

This sort of approach will always lead to unexpected results because it is inconsistant.

Stop treating the user like a dumby and trying to make choices behind his back about what is "best" for his files. This would provide a more consistant and predictable behaviour.

A lot of things are now done a lot better w.r.t jpeg but I think this aspect is still fundamentally wrong. Keeping the quality gleaned from the file would solve this problem and provide more predicatable behaviour.

Raphaël Quinet
2007-08-30 11:07:40 UTC (about 17 years ago)

Annoying behavior of shared settings for file save plug-ins

On Thu, 30 Aug 2007 00:57:44 +0200, gg@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

gg@catking.net
2007-08-30 13:06:16 UTC (about 17 years ago)

Annoying behavior of shared settings for file save plug-ins

On Thu, 30 Aug 2007 11:07:40 +0200, Raphaël Quinet wrote:

On Thu, 30 Aug 2007 00:57:44 +0200, gg@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 _________________

Well I dont think I was completely missing the target but I had not realised the broader issue.

The jacking up of "jpeg quality" factor is a result of both the carry over policy and the "use if better" policy.

1) would seem to be by far the better of your two options since the destructive effects in current release are pretty unacceptable. If jpeg and png can work coherently that would be 80% of the problem solved with other plugin formats being brought into line soon after.

It would be a great shame if this long awaited 2.4 release went out with the old destructive behaviour and missed all the fixes you have done recently.

regards, gg.

Scott
2007-08-30 23:56:16 UTC (about 17 years ago)

Annoying behavior of shared settings for file save plug-ins

On Thu, Aug 30, 2007 at 08:56:33AM +0200, Jakub Friedl wrote:

I think that "use image file quality unless defaults are 'better'" is not thee problem. Problem is inheriting image quality between different images in one GIMP session. I have a default quality of 85. Then I open DSLR image with quality 95. Save it with that quality. Then I open and save low quality cameraphone image. But I am not offered my default nor the original cameraphone quality (which would be both understandable) but the DSLR quality of 95. Huh? These images have nothing in common except they have been opened in the same editor session. Do not mix them up.

There are times I definitely *want* to save the settings from a previous save. A common task for me is to edit ten or so images to present at 300x225 pixel size on the web. Of course, I don't want to save exif or thumbnail, so the carrying-over of these choices (and I don't know if this is fixed in 2.4 or not) is appreciated. Not wanting to use *too* much memory on my server, I will usually tweak the jpeg quality factor down to something less than the default 85, and I like having this carry forward from image to image when I am doing this task. If one looks too degraded at the new setting, then I can tweak it upwards, or if one is too big, then I can try lessening the quality, but I certainly wouldn't like to have each new image return to the default, or to some value determined by the image itself. I want to be in control but not have to control too much, if you know what I mean. I want the software to remember what I am doing.

Couldn't there be a button somewhere to "forget previous settings" or "begin new task"? Actually, that would be helpful in many other situations, such as the file-save directory (and this is probably a GTK issue, I suppose). Now, I have to select the directory *every time*, even though I "obviously" want to save all 10 images to the same directory. Sort of like "fifty first dates"....

Actually, the more I think about it, the idea of a "begin task - end task" pair of buttons makes sense to me. Perhaps there could be pre-defined task parameters which the user has set up for different ones. Such as defaults for the resize-image, crop image, save directory, etc, etc. Maybe something like this already exists and I don't know about it. Who knows....

scott swanson just a user.....

gg@catking.net
2007-08-31 00:19:23 UTC (about 17 years ago)

Annoying behavior of shared settings for file save plug-ins

On Thu, 30 Aug 2007 23:56:16 +0200, Scott wrote:

On Thu, Aug 30, 2007 at 08:56:33AM +0200, Jakub Friedl wrote:

I think that "use image file quality unless defaults are 'better'" is not
thee problem. Problem is inheriting image quality between different images
in one GIMP session. I have a default quality of 85. Then I open DSLR image
with quality 95. Save it with that quality. Then I open and save low quality
cameraphone image. But I am not offered my default nor the original cameraphone quality (which would be both understandable) but the DSLR quality of 95. Huh? These images have nothing in common except they have been opened in the same editor session. Do not mix them up.

There are times I definitely *want* to save the settings from a previous save. A common task for me is to edit ten or so images to present at 300x225 pixel size on the web. Of course, I don't want to save exif or thumbnail, so the carrying-over of these choices (and I don't know if this is fixed in 2.4 or not) is appreciated. Not wanting to use *too* much memory on my server, I will usually tweak the jpeg quality factor down to something less than the default 85, and I like having this carry forward from image to image when I am doing this task. If one looks too degraded at the new setting, then I can tweak it upwards, or if one is too big, then I can try lessening the quality, but I certainly wouldn't like to have each new image return to the default, or to some value determined by the image itself. I want to be in control but not have to control too much, if you know what I mean. I want the software to remember what I am doing.

Couldn't there be a button somewhere to "forget previous settings" or "begin new task"? Actually, that would be helpful in many other situations, such as the file-save directory (and this is probably a GTK issue, I suppose). Now, I have to select the directory *every time*, even though I "obviously" want to save all 10 images to the same directory. Sort of like "fifty first dates"....

Actually, the more I think about it, the idea of a "begin task - end task" pair of buttons makes sense to me. Perhaps there could be pre-defined task parameters which the user has set up for different ones. Such as defaults for the resize-image, crop image, save directory, etc, etc. Maybe something like this already exists and I don't know about it. Who knows....

scott swanson just a user.....

Scott
2007-08-31 01:10:01 UTC (about 17 years ago)

Annoying behavior of shared settings for file save plug-ins

On Fri, Aug 31, 2007 at 12:19:23AM +0200, gg@catking.net wrote:

I think what you describe could be put under Save as. It is not Save though.

Probably misusing the "defaults".

You're right, of course. Doh. I always use "save as". And it works fine for my purposes (other than the save-to directory which I mentioned), and I hope it does in 2.4. Sorry to have misunderstood.

Scott Swanson --
(or ss - hey, you've given me ideas, except it looks like something from a notary seal or the nazi era - my middle initial is 'O' - that's probably not a good idea either.....)

??????? ??????
2007-08-31 15:11:58 UTC (about 17 years ago)

Annoying behavior of shared settings for file save plug-ins

On Thu, 30 Aug 2007 11:07:40 +0200, Raphaël Quinet 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

Raphaël Quinet
2007-08-31 17:39:45 UTC (about 17 years ago)

Annoying behavior of shared settings for file save plug-ins

On Thu, 30 Aug 2007 15:56:16 -0600, Scott wrote:

On Thu, Aug 30, 2007 at 08:56:33AM +0200, Jakub Friedl wrote:

I think that "use image file quality unless defaults are 'better'" is not thee problem. Problem is inheriting image quality between different images in one GIMP session. I have a default quality of 85. Then I open DSLR image with quality 95. Save it with that quality. Then I open and save low quality cameraphone image. But I am not offered my default nor the original cameraphone quality (which would be both understandable) but the DSLR quality of 95. Huh? These images have nothing in common except they have been opened in the same editor session. Do not mix them up.

There are times I definitely *want* to save the settings from a previous save. [...]

If you want to save several images with the same settings, you can use the buttons "Save defaults" and "Load defaults". We also have an enhancement request (bug #120829) about providing multiple presets that could be saved and re-loaded when necessary.

I think that it is much better to require an explicit action if you want to re-use some settings from one image to the next, instead of always doing this automatically. Each image should have its own settings and should not be influenced by how you saved unrelated images in the same session. As in the example given by Jakub, it is annoying that the parameters used for saving a high-quality DSLR image are automatically re-used for saving a low-quality cameraphone image.

This should definitely change for 2.6. But my question was about what kind of workaround can be implemented quickly for 2.4. It looks like it might be better to have all plug-ins broken in the same way instead of just fixing the most used ones, so that would be the second option that I described in my previous message: ignore the settings from the original JPEG images and always re-use the parameters from the last saved image. This is bad, but at least this is consistent with other file plug-ins (until they can all be fixed).

-Raphaël

Alexander Rabtchevich
2007-08-31 18:04:51 UTC (about 17 years ago)

Annoying behavior of shared settings for file save plug-ins

Rather strange conclusion from my POV - if something very convenient cannot be provided for each and every case, it shouldn't be provided at all.
I can prove my opinion with a case with healing brush. It saves me a lot of time and efforts during photo retouching despite the fact it doesn't support healing along a path.

Raphaël Quinet wrote:

This should definitely change for 2.6. But my question was about what kind of workaround can be implemented quickly for 2.4. It looks like it might be better to have all plug-ins broken in the same way instead of just fixing the most used ones, so that would be the second option that I described in my previous message: ignore the settings from the original JPEG images and always re-use the parameters from the last saved image. This is bad, but at least this is consistent with other file plug-ins (until they can all be fixed).

-Raphaël

Robert L Krawitz
2007-08-31 18:24:47 UTC (about 17 years ago)

Annoying behavior of shared settings for file save plug-ins

Date: Fri, 31 Aug 2007 17:39:45 +0200 From: =?UTF-8?B?UmFwaGHDq2w=?= Quinet

If you want to save several images with the same settings, you can use the buttons "Save defaults" and "Load defaults". We also have an enhancement request (bug #120829) about providing multiple presets that could be saved and re-loaded when necessary.

I think that it is much better to require an explicit action if you want to re-use some settings from one image to the next, instead of always doing this automatically. Each image should have its own settings and should not be influenced by how you saved unrelated images in the same session. As in the example given by Jakub, it is annoying that the parameters used for saving a high-quality DSLR image are automatically re-used for saving a low-quality cameraphone image.

This should definitely change for 2.6. But my question was about what kind of workaround can be implemented quickly for 2.4. It looks like it might be better to have all plug-ins broken in the same way instead of just fixing the most used ones, so that would be the second option that I described in my previous message: ignore the settings from the original JPEG images and always re-use the parameters from the last saved image. This is bad, but at least this is consistent with other file plug-ins (until they can all be fixed).

It sounds like what's happening is something like this:

1) Current JPEG quality setting is 85 2) User selects "Use quality settings from original image if original image is better"
3) Original image has quality setting of 98 4) User saves image

5) Now the current JPEG quality setting is changed to 98

Is that correct?

If so, then (5) seems wrong to me. The JPEG plugin should remember that the current JPEG quality setting is 85, and that the user has selected Use quality settings from original image. If the user then saves another image that has a quality setting of 60, it shouldn't be saved at 98, but at 85.

My own preference is to err on the side of caution; I'd rather make a mistake of saving at too high of a quality (which loses less information) than too low. If I accidentally save a thumbnail at quality 98 or 100, all I've done is wasted a little disk space; if I save a good image at 85, I've lost a lot of data.

Yes, I know that I shouldn't save a master copy of an image as a JPEG, and I don't intentionally. But I'm human and occasionally make mistakes...

Raphaël Quinet
2007-08-31 19:01:06 UTC (about 17 years ago)

Annoying behavior of shared settings for file save plug-ins

On Fri, 31 Aug 2007 12:24:47 -0400, Robert L Krawitz wrote:

It sounds like what's happening is something like this:

1) Current JPEG quality setting is 85 2) User selects "Use quality settings from original image if original image is better"
3) Original image has quality setting of 98 4) User saves image

5) Now the current JPEG quality setting is changed to 98

Is that correct?

Almost. Step 2 currently happens automatically if the quality of the original image is better than the defaults (because of the complaints that gimp was destroying the quality of some images without warning). But this may change, so step 2 could again require an explicit action from the user.

If so, then (5) seems wrong to me. [...]

Yes, this is exactly what I tried to explain in my previous messages. The problem is that the JPEG plug-in and most other file plug-ins will automatically re-use all settings from the last file that was saved.

My own preference is to err on the side of caution; I'd rather make a mistake of saving at too high of a quality (which loses less information) than too low. If I accidentally save a thumbnail at quality 98 or 100, all I've done is wasted a little disk space; if I save a good image at 85, I've lost a lot of data.

And this is what is currently implemented: if the quality level of the original image is higher than the current default value, then the quality from the original image will be selected automatically. But since the JPEG plug-in shares the same behavior as the other file plug-ins, this new value is automatically remembered for the next time you save an image.

The combination of these two things (using the original quality if it is higher, and the automatic re-use of the last values instead of using the defaults) causes the problem reported by Jakub: if you load and then re-save many images that were saved at different quality levels, you end up with the last image saved at the highest quality level (maximum value from all images), which may be much higher than the default value or than the original quality of that image.

This is a bug that should be fixed. But after discussing this briefly with Simon in #gimp, I think that it would be better to postpone the real fix to GIMP 2.6 because it would not be possible to fix all (or even most) file plug-ins for 2.4. And if only the JPEG plug-in (and maybe PNG) behaves differently than other plug-ins, then some users will probably complain or at least be confused. It may be better to postpone the real fix until all plug-ins support a way to load and save defaults, and maybe support multiple presets.

-Raphaël