GNOME Bugzilla – Bug 164087
gimp sometimes fails to write 100% quality JPEG with EXIF + thumbnail
Last modified: 2008-01-15 12:45:27 UTC
Try to save JPEG images with lots of detail, in some cases this would lead to the EXIF + thumbnail data being to large for libjpeg to handle (it gives "Bogus marker length" on stderr). Thumbnails are being saved with the same quality setting as the original image. I'll attach a patch that decreases quality for the thumbnail by 5% until EXIF + thumbnail fits inside this limit.
Created attachment 36018 [details] [review] Patch to make the jpeg plugin not barf on saving high detail images with EXIF and thumbnail at 100% quality
The original bug report can be found at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145100
Created attachment 36020 [details] image that exhibits the problem Saving this image as JPEG, 100% quality, with EXIF and thumbnail and an unpatched JPEG plugin exhibits the problem everytime I tried.
I wonder if it would make sense to use simply quality = 75 for thumbnails regardless of the main image quality? Also, are you aware that, according to the JPEG library documentation: "Quality values above about 95 are NOT recommended for normal use; the compressed file size goes up dramatically for hardly any gain in output image quality." And finally (to be pedantic), note that jpeq quality is not a percentage, it is just a number in the range 1 - 100.
Maybe the EXIF standard has a recommendation on the quality level thumbnails should be saved with? I think forcing a constant quality level would be better, though the code should still guard against exceeding the 65533 jpeg marker limit, so perhaps start and 75 and then pare down if needed. Interestingly, saving your sample image with quality 100 resulted in a 35864 byte thumbnail for me.
Regarding comment #4, I'd say clipping thumbnail quality at 75 would be okay, but you wouldn't save the thumbnail with quality 75 when the image has only say 50 or so ;-). IMO quality values above 95 make sense when you have imaging labs that for whatever reason can't handle TIFF produced by the GIMP and the only other format accepted is JPEG. Regarding comment #5, I'd say clip at 75, use less if less is used, pare down if needed. What I checked was exif_buf_len in the area where I patched, it gave a bit more than 66000 with this image -- this may be thumbnail plus EXIF combined or whatever.
Sounds reasonable. Will you change the patch to implement that behaviour?
I agree that the suggestion in comment #6 is reasonable, but to repeat because this point is so generally misunderstood: quality 100 jpeg files are not any better than quality 95 jpeg files, they are only larger. A quality 100 jpeg file is not equivalent to a tiff file. It's unfortunate that the JPEG group chose to measure "quality" this way, because it's natural for people to want to make the "quality" of their images as high as possible, but in this case it's just a pure waste of resources.
Nils, your patch introduced a bug when saving with quality 0. The exif thumbnail is never generated, but an attempt to write it made regardless. See bug #164158.
Regarding comment #7: Yes, will do. Regarding comment #8: Then why are there quality settings >95 at all? Or what does "in this case" mean? Regarding comment #9: Aftereffect of my misunderstanding quality (0% doesn't make much sense, eh?), will fix that as well.
To quote the full libjpeg docs: -quality 100 will generate a quantization table of all 1's, minimizing loss in the quantization step (but there is still information loss in subsampling, as well as roundoff error). This setting is mainly of interest for experimental purposes. Quality values above about 95 are NOT recommended for normal use; the compressed file size goes up dramatically for hardly any gain in output image quality.
Created attachment 36122 [details] [review] Patch to make the jpeg plugin not barf on saving high detail images with EXIF and thumbnail at 100% quality This one should clip thumbnail quality at 75 and don't barf on images saved with quality == 0.
Created attachment 36217 [details] [review] cleaned up patch This is a cleaned up version of that patch (plus a few minor cleanups in the jpeg code while I was at it). The patch is against gimp-2-2, it won't apply to HEAD because the jpeg plug-in moved to a different place there and has been split up. We will have to manually merge this change to the HEAD branch.
Seems to pass all tests. I tried your image (among others) and saved with quality 0 and 100. Moving the milestone to 2.4 since we still need to apply this to HEAD. 2005-01-18 Sven Neumann <sven@gimp.org> * plug-ins/common/jpeg.c: applied (a slightly modified version of) a patch from Nils Philippsen that makes sure that the EXIF thumbnail doesn't cause the EXIF data block to grow beyond its maximum size. Fixes bug #164087.
Adapted to HEAD: 2005-01-18 Manish Singh <yosh@gimp.org> * plug-ins/jpeg/jpeg-save.[ch]: Adapted the code from the stable branch (based on a patch from Nils Philippsen) that makes sure that the EXIF thumbnail doesn't cause the EXIF data block to grow beyond its maximum size. Fixes bug #164087.