2012.12.18 18:53 "[Tiff] More problems with libjpeg cross-version differences", by Tom Lane

2012.12.18 19:22 "Re: [Tiff] More problems with libjpeg cross-version differences", by Tom Lane

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.

Is there some clue which could be used to select the JPEG 6 values if libjpeg-turbo is used?

Not sure. If I believed the premise here, I might look harder to find one, but I think we'd just be letting ourselves in for continual future pain in trying to track changes. The only reason that an exact check seemed even vaguely sane is that libjpeg development has been moribund for so long. Which is yours truly's fault no doubt, but that's water over the dam now. With Guido starting to push out new versions again, and the libjpeg-turbo crew doing their own thing, we can expect more slightly-different behaviors to emerge in future.

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.

Yeah. I was intending to take the two known values and allow a couple counts slop on either side of that range. We might have to expand the ranges in future, but it would be a pretty painless thing to do compared to trying to identify the exact expected behavior from the library's available version info.

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.

Dunno, I've not tried to compare the two.

regards, tom lane