Date: Mon, 9 Jul 2007 00:26:21 +0930 From: "David Gowers" <00ai99@xxxxxxxxx> 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 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 first JPEG. 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 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.) 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 degradation. 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 <rlk@xxxxxxxxxxxx> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lpf@xxxxxxxxxxxx Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
