Lossy unsigned int test fails

[jpambrun]

Test jp2_U16bit_test fails with

jp2_U16bit_test.js
✔ file_860AE501
✖ file_lossyhdr

Assertion Message: 1994381 / 1998132 degraded pixels, MSE=46125280.03677685 Max err= 65535

When compared with Matlab's JPEG 2000 decoder, almost every pixels appears incorrectly reconstructed. This is illustrated in the attached figure where black represents perfect reconstruction and white represents a difference of 1000. Pixel close to 0 and 65,535 can roll over resulting in very obvious distortions.

[jpambrun]

It seems to be two separate problems:

1. a type conversion bug error that causes the very large and visible distortions and
2. a precision issue that produce a different result than the decoder from Matlab.

I have narrowed the first issue to line 1491 from jpx.js

out[pos] = val + offset

Where 'out' is a Uint16 and 'val + offset' are float32. When 'val + offset' is 65535.5, it is casted to 0 . When it is -0.5 is is casted to 65535.

Replacing the offending line with for testing:

out[pos] = Math.max(Math.min((val + offset),65535),0);

yields :

But, I am still not sure how to properly resolve this for all data types.

However, the second issue is still present as evidenced by the difference image:

[jpambrun]

The type conversion issue was fixed in commit c6a2c34. However, the difference with Matlab's codec is still abnormally large.

[chafey]

Is the matlab codec known to be correct? Are we sure the issue is on our side and not matlabs?

[jpambrun]

I don't know which implementation is correct. However, Matlab is widely
used while this codec was never tested with anything other than 8 bit
unsigned RGB images before our efforts.

On Tue, Jul 7, 2015, 12:38 AM Chris Hafey notifications@github.com wrote:

Is the matlab codec known to be correct? Are we sure the issue is on our
side and not matlabs?

—
Reply to this email directly or view it on GitHub
#5 (comment).