libjpeg incorrect image read inconsistency

[saurabheights]

Hi Tokenrove,
I have recently ported the C code to C++ with using only IIR filter for local metrics computation. I tested the whole code in parallel with the C code.

I noticed an issue and to further identify it, I used below image which has 4 blocks of 64x64 size. These blocks have R=G=B and block have intensity 0, 1, 16, 17(out of 255). [This was a image cropped from a larger image having intensities 0-255 blocks.]

For second block(top-right), this is the output I got(added these lines while HSI calculation)
i = 0 j = 41 R = 0 G = 0 B = 0 [should be 1,1,1]
i = 0 j = 42 R = 0 G = 0 B = 1 [should be 1,1,1]
i = 0 j = 43 R = 1 G = 1 B = 1

This is the output for all rows of second block. Till around 41st pixel of the row, libjpeg always gives me value of 0 instead of 1.

When the image is read from Opencv, I found pixels to be of consistent intensities within a block. I even used minMaxLoc function to verify over each local block.

Please can you share any thoughts you may have on this.

[tokenrove]

Thanks for the report! Just letting you know I probably won't get a chance to look at this until Friday. I apologize for the delay.

[tokenrove]

Just looking at this now; you're right, of course, what we get in image.c is erroneous -- specifically, the x offset needs to be multiplied by the number of components. I'm going to push the fix for this and #4 to a branch, fixes-before-tests so that the fixes are available immediately, but I'm going to try to get the time to implement the test suite shortly so they can go in with tests.

On a broader note, this reminds me that I wanted to rewrite these programs to work on a stream of image data (at least a stream of blocks) rather than having to allocate everything up front.

[saurabheights]

Cool, thanks for finding the bug.