- 2012.12.18 19:08 "Re: [Tiff] More problems with libjpeg cross-version differences", by Bob Friesenhahn
2012.12.18 19:08 "Re: [Tiff] More problems with libjpeg cross-version differences", by Bob Friesenhahn
If you look closely, the actual results are those that raw_decode expects from pre-IJG7 libjpeg versions, but it's thinking it should get the IJG7 results. This is probably because Fedora uses libjpeg-turbo and recently switched over to the libjpeg 8 API --- but evidently, libjpeg-turbo only adopted the API changes and did not change the default decompression/upsampling algorithms.
We could try to hack the "#if JPEG_LIB_VERSION >= 70" test to make this pass in all cases, but I'm thinking that expecting exact pixel values out of libjpeg is a bad idea from the get-go. What I'd recommend instead is allowing a range of acceptable pixel values.
Without checking, I assume that I added the JPEG_LIB_VERSION >= 70 bit.
Depending on the image file, the results from JPEG 7 can be very similar or quite different. Images with subsampling are the worst case.
Is there some clue which could be used to select the JPEG 6 values if libjpeg-turbo is used?
It does seem that updating check_rgb_pixel() and check_rgba_pixel() to allow some slop is a reasonable solution. It also seems reasonable to select the correct set of expected values if possible so that the allowed slop can be as small as possible.
I would guess that libjpeg-turbo's support for the libjpeg 8 API is very poor and only goes as far as the structure binary footprint. Using features from libjpeg 8 (e.g. scaling factors) would produce wrong results since the support for the new scaling factors is not in libjpeg-turbo.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/