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

2012.12.18 21:27 "Re: [Tiff] More problems with libjpeg cross-version differences", by Ryan Wong

> Subject: Re: [Tiff] More problems with libjpeg cross-version differences

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.

The sloppy approach is fine with me. The main intent is to be a sanity check rather than to assert absolute conformity.

A typical approach (though not necessary scientific nor psycho-visually valid) for comparing the outputs of two image decoders from the same input image is histogram of pixel differences.

This is how histogram of pixel differences works:

For each row of pixels    For each pixel in the row        Compare RGB values from first decoder with the second decoder        Take the absolute value of difference (scaled between 0 and 255)        Increment the corresponding bin in a 256-bin histogram

After obtaining the histogram, a performance curve can be obtained for each RGB difference bound. Namely, y = f(x) is the fraction of pixels that have RGB difference exceeding x quantization steps (x = from 0 to 255). The test code can then pick a few test points on the curve and compare against hard-coded tolerance thresholds.

This simpler approach would be sufficient if the only source of RGB difference comes from rounding errors between two independent implementations of decoders.