Date: Mon, 9 Jul 2007 00:26:21 +0930
From: "David Gowers" <[EMAIL PROTECTED]>
On 7/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote:
> > Hi,
> > On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote:
> >> Does your reply indicate you take a "this feature not a bug" approach
> >> here
> >> and you think is the best way gimp should deal with this situation?
> > Indeed. When you open a JPEG file, then you have a decoded image. The
> > settings that were used to encode it are irrelevant since encoding it
> > again as a JPEG file would not yield the same image anyway.
> I'm sorry I find that a rather forced logic. As we have seen the image
> will not be _identical_ due rounding errors and such , that does not make
The image may well be quite unlike the input due to lossy compression
-- see below.
The question to my mind is what's going to be closest to the user's
expectations in terms of quality and size, not what's going to be
pixel for pixel identical. When saving (or, I'd argue, exporting) an
image from a lossless format (png, or even more so xcf) to a lossy
format, we can really only guess, and in that case having a settable
default is good. However, when we're working with JPEG files, we have
a bit more information about what the user likely wants, based on the
quality setting and perhaps the file size.
> the existing choice of jpeg_quality "irrelevant". It represents
> the users choice of size/quality trade-off.
> I see no justification to discard that choice as irrelevant.
AFAICS, Sven is saying that it is irrelevant, because it is
*impossible* to numerically represent the overall quality of the
image to be saved. The quality setting of the input file, assuming
that it is correctly calibrated to the IJG scale, would be
multiplicative: when you save a jpeg file with quality 75, you are
saying 'throw away a certain amount of the image data' -- and
saving it again with quality 75, you are saying 'discard that much
again'. You can't save with the same quality, because you've
already thrown away much of the data that was used to create the
Sure, but if the image was originally saved at quality 98, and then
you resave it at 75, you're going to wind up with a lot more
artifacts, which would be a surprising result if you don't understand
how JPEG works. If the original image was saved at 60, and you resave
it at 98, you might wind up with a much bigger image (I'm less certain
of that), which is also not what I think would be expected.
The issue at hand is a special, but IMHO important, case -- a very
high quality JPEG gets minor edits (perhaps to remove redeye or the
like) and resaved; the result is *markedly* lower quality because the
default of 85 is much less than the original.
Actually getting a quality that is notionally '75% of full detail'
when saving a jpeg output from a jpeg input, is trial and error --
so really, presenting a preview would improve the situation.
As for the practice of saving jpg outputs from jpg inputs, my personal
experience has been that it's a BAAAAD thing; basically the only two
a) Image mutilation
b) filesize inflation (ie. you can preserve quality.. by choosing
something that effectively renders JPEG's compression ineffective
(quality = 96 or above, IME)
-- this often inflates the filesize beyond that of lossless image
formats like PNG.)
What about the case where the original quality was 96 or 98, and it's
resaved at the same quality level? My quick test showed a slight
decrease in file size, but probably very little in the way of image
About the only thing GIMP could do to help here, is to warn the
user if they are saving a jpeg file and the image was originally
loaded from a jpeg file.
That would be a good idea, but I believe that there are at least some
common cases where it's possible to do a bit better.
Robert Krawitz <[EMAIL PROTECTED]>
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
Gimp-developer mailing list