Jpeg2000 decoder fails using Arithmetic = 16-bit

[Thomas_Jensen1]

Using IPP 7.0.5 with latest samples.
I found an error where the Jpeg2000 decoder fails using Arithmetic = 16-bit when decoding an 8_u grayscale image.

The Arithmetic option is used to select faster code when the pixel precision allows for at, namely when precision is <= 14.

Testing with Picnic does not indicate the error because Picnic always passes Arithmetic = 32-bit to the decoder, even if you select 16-bit in the Jpeg2000 options. This is also a bug.

The failed decode results in an image where it sems that only a few wavelets has been summed.

Has anyone out there used Arithmetic = 16-bit when decoding 8_u images?

I added files reproducing this bug.

[Thomas_Jensen1]

No reaction yet?

[levicki]

You should know better than to expect any kind of answer from IPP team unless you file a Premier Support issue especially if it is an issue with samples.

[Thomas_Jensen1]

I have already, before this forum, placed an Intel IPP Premier Support Issue.

Now, it is in the Premier Support, and in the IPP Forum.

I'm waiting for answer.

In the IPP forum, I recently added file attachments; these are files that makes it possible to reproduce the bug.
1. Using the current Picnic.exe; no bugs are seen.
2. Debugging Picnic; you see that it has a bug, not passing arithmetic 16-bit selection to the J2K decoder.
3. Fixing Picnic, to pass the proper arithmetic 16-bit selection to the decoder, you'll see the actual bug; the decoder decodes the image incorrectly.

[Sergey_K_Intel]

Hi Thomas,

Is the attached DICOM file ok? I cannot decode it with any of DICOM viewers.

Regards,

Sergey

[Thomas_Jensen1]

You can load the attached dcm file with the current Intel IPP 7 update 5 samples precompiled Picnic.exe.

I just did a retest by redownloading my attached file, and it loads fine on my precompiled Picnic.exe, however, as I wrote above, the precompiled Picnic.exe has a bug that cause the Jpeg2000 decoder to always use 32-bit arithmetic (and with 32-bit it decodes fine, except it is slower), even if you set it to 16-bit in Picnic's user interface, therefore you must first fix the bug in Picnic and then rebuild it to properly reproduce the error. I did this by simply hardcoding arithmetic to 16-bit, and then when loading this Dicom file with an 8u_C1 image encoded with lossy Jpeg2000, you will directly see that the IPP Jpeg2000 decoder fails. It decodes to a faulty image, as you can see in the attached bmp file.

Of course, you don't need to use Picnic to reproduce the error, any code that use the IPP sample Jpeg2000 decoder, just set jpeg2000 param arithmetic to 16-bit and the decode an 8 bpp lossy jpeg2000 image.

[Bell]

I guest thebug was inside thefile "dquant.h". The calculation of inline function

inline void QuantInv(const ImageCoreC &img, const IppiSize &size, QuantValue quant, unsigned int sbDynRange)

might out of range.

[Thomas_Jensen1]

I do see some clipping danger in dquant.h, but it is over my head to determine if that is actually so.

For 16u pixels and 32-bit arithmetic, the Ipp32s type is used.
So for 8u pixels and 16-bit arithmetic, the used Ipp16s type appears to be usable...

I just don't know how dig further into this problem.

Intel, how far are you with your investigation?

[Bell]

I investigate it and I'm wrong. The bug was somewhere else. Be patients, I had had submit a multi-layer bug to Intel via Premier Support long time ago. They did take over one year to solve the problem. I only could use OpengJPEG as alternative workarround during this time. If memory usage is really critical for your application, go for Kakadu Software (http://www.kakadusoftware.com/). It use line-based wavelet transformation to decode image. Really save memory and better performance than IPP.