After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 75398 - file_jpeg_load should not attach a default parasite
file_jpeg_load should not attach a default parasite
Status: VERIFIED FIXED
Product: GIMP
Classification: Other
Component: Plugins
1.x
Other All
: Normal normal
: 1.2
Assigned To: GIMP Bugs
Daniel Egger
: 101844 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-03-19 08:18 UTC by T.Wirschell
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch for jpeg.c: do not attach jpeg-save-options parasite when loading (2.18 KB, patch)
2002-12-17 15:53 UTC, Raphaël Quinet
none Details | Review

Description T.Wirschell 2002-03-19 08:18:34 UTC
When you store an image as a JPG, and change the settings used, these
settings are remembered for the rest of Gimp's lifetime. One of the good
things about this is that when you hit CTRL-S to quicksave, you resave with
the same settings.
The problem arises when you change a setting like quality. I normally use
90 instead of the default of 75. Save a given file like this, and close the
image. Take note of the size of the now created file.
Still within this same Gimp session, reopen the image and hit CTRL-S to
quicksave the image.
Again take note of the file size. It's considerably smaller than before.
The reason for this is obvious when you try to save the file again with
File->Save As since the Quality option will have jumped back to 75.
The main reason this is a bug is because at no point are you being prompted
that you might not be using the same quality setting as you had previously
set, and on top of that that this new quality setting has become the
default for your future saves. It has on more than one occasion forced me
to redo an image because the quality was sub-standard for my purposes.
Comment 1 Raphaël Quinet 2002-03-19 09:49:09 UTC
The problem does not come from the quicksave feature.  Instead, it
comes from the fact that the defaults in the JPEG save dialog (and
other plug-ins) are remembered separately for each file and they are
lost when a file is closed and re-opened.

You can test the fact that the settings are remembered on a per-file
basis by duplicating an image (Ctrl-D) and saving the two copies at
different quality settings.  If you try to save them a second time
with Save As, you will see that each one will have remembered the
previous settings separately.

Now, considering the fact that the settings are remembered only on a
per-file basis and are not saved globally, then there is the problem
that closing and re-opening a file discards all previous settings.
It is not possible to recover the original quality settings from a
JPEG file (the same is also true for several other file formats), so
all settings are reset to their default values.

One way to solve this problem would be to allow the user to save the
current settings for any file_save plug-in as the new defaults, so
that when you reload an image (or create a new one), it would get
these new default values instead of the hardcoded ones (such as 75%
quality for JPEG).  This suggestion is already described in bug #63610
so I am marking this as a duplicate.


*** This bug has been marked as a duplicate of 63610 ***
Comment 2 T.Wirschell 2002-03-19 10:26:23 UTC
I don't consider this a duplicate of 63610 even though its resolution
would be a possible workaround (but not a good fix).

When you work on a file and save with a certain setting, each
subsequent save will use these same settings. The problem is that when
you open an existing image and hit save, the defaults are _reset_ even
though you're not notified of this. I think the correct behaviour
should be that the resave of this existing image use the _current_
settings, rather than the defaults, and it most certainly should not
_reset_ the current settings to the program's defaults.

After all, why is it that when I get an image off of my scanner, it
saves using the current settings, however when I use an image off of
my harddisk it does not. In both cases it cannot be determined what
the quality of the retrieved image was.
Comment 3 Raphaël Quinet 2002-03-19 12:18:56 UTC
Hmmm...  I have investigated this a bit further, and now I understand
the cause of this problem.

There are two kinds of "current settings":
- All plug-ins can save their current settings and tell the GIMP to
  associate these values with their name ("file_jpeg_save") so that
  they can re-use the same values if they are called again with
  RUN_WITH_LAST_VALS.  That's what happens when you hit Ctrl-S.  These
  settings are global.
- In addition, the JPEG plug-in saves its current settings in a
  parasite "jpeg-save-options" that is attached to each image.  These
  settings have precedence.  So if a "jpeg-save-options" parasite is
  attached to an image, these values will be used when you attempt to
  save it (and these values will also be stored as the current plug-in
  settings, globally).

The problem:
- If you create new images (with File->New or from the scanner) and
  save them as JPEG, the global settings for "file_jpeg_save" are
  used every time because there is no parasite until the image is
  saved.  So you might believe that these are the "current settings".
- If you load a JPEG image, a parasite "jpeg-save-options" is attached
  to this image.  It only contains default values (quality 75%, among
  others) because it is generally not possible to recover all settings
  from a saved file.
- The problem occurs when you save that image that JPEG image, because
  the values in the parasite (in this case, the hardcoded defaults)
  take precedence over whatever was in the global "file_jpeg_save"
  values.  These values are used for saving the image and then they
  are saved in "file_jpeg_save".
- After that, saving an image that has no parasite attached to it will
  cause these settings to be used (reset to the defaults, which is not
  what you want).  If you save another image that had already been
  saved earlier (and has a "jpeg-save-options" parasite attached to
  it), then the values from that parasite would be used for saving
  the file and they would also become the new "current settings" for
  all images that have no parasite.

Having two kinds of "current settings" does not help in this case and
leads to a schizophrenic behavior (and some confusion for the user).

One way to solve this problem for the JPEG plug-in would be to ensure
that it does not attach a parasite to the images loaded from disk.
The "gimp-comment" parasite can be attached (because its value is
really taken from the file), but not the "jpeg-save-options" (because
using the hardcoded defaults causes the problems described here).
I have changed the summary of this bug report accordingly.  The
solution is simple and consists in removing the 20 lines that create
the default parasite in step 3 of the file_load function in
plug-ins/common/jpeg.c.

The more general problem (defining what are the "current settings" and
what are the "defaults") will probsbly be handled in bug #63610.
Comment 4 Raphaël Quinet 2002-12-17 15:53:05 UTC
Created attachment 13073 [details] [review]
patch for jpeg.c: do not attach jpeg-save-options parasite when loading
Comment 5 Sven Neumann 2002-12-17 16:07:20 UTC
*** Bug 64149 has been marked as a duplicate of this bug. ***
Comment 6 Sven Neumann 2002-12-17 16:09:33 UTC
Sorry, pasted into the wrong field.
Comment 7 Sven Neumann 2002-12-17 16:24:45 UTC
Applied to both branches:

2002-12-17  Sven Neumann  <sven@gimp.org>

	* plug-ins/common/jpeg.c: do not store a parasite with default
	save settings when loading a JPEG image (fixed bug #75398).
Comment 8 Sven Neumann 2003-01-02 13:09:30 UTC
*** Bug 101844 has been marked as a duplicate of this bug. ***
Comment 9 Raphaël Quinet 2003-06-20 16:44:52 UTC
The fix is part of the stable release 1.2.4.  Closing this bug.