Re: jpeg quality factor.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/8/07, gg@xxxxxxxxxxx <gg@xxxxxxxxxxx> wrote:
> On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann <sven@xxxxxxxx> wrote:
>
> > Hi,
> >
> > On Sun, 2007-07-08 at 14:53 +0200, gg@xxxxxxxxxxx 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 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 first JPEG.

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
possibilities are
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.)
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.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux