I downloaded your jp2 and decoded it, using my own implementation of IPP 6.1.5. It looks different than both your images. Your left image looks best, but your IPP, and my IPP is very bad, with details not visible (see jpeg in attachment). Can you also supply your image as uncompressed tiff?
I'm not sure why my attachtments cannot be opened. I uplaoded them into my "Files", but gtheir thumbnails are also bad. Maybe Vladimir can help?
I downloaded your RAW and see that it is indeed the same as your left image. I also loaded it into Picnic.exe 6.1.5 (after having converted into PNG) and had Picnic.exe save it as Jpeg2000 lossless with (default settings). That lossless jp2 file, I opened with Picnic.exe and with other tools, and that was all properly decoded, with the excact same as the input.
Then I tried to load your jp2 file into various tools without success: - LeadTools 13: load OK, but bad crazy pixels. - LeadTools 16.5: OK. - Acdsee: OK.
I think your jp2 file is slightly bad, although I don't know how. Bad decode in IPP 6.1.5 and LT13, good decode in recent tools.
May I ask, with what tool was your jp2 file saved?
I see that the pixels in your RAW image has its 12 bits in the lower part of the WORD. To help Intel, you could try to upscale your image, so the 12 bits are in the upper part of the WORD, and then compress again with Pictools, to see if IPP can handle that structure ("real" 16 bit pixels).
You talk about good bitstream and bad bitstream, I do not understand that. I understand that you have a jp2 file created by Pictools, that IPP cannot properly decode, right?
I notice that Jhove does not indicate lossy/lossless, or wavelet bank WT53/WT97 in the dump. Since your Pictools image is lossless, I'm not sure there should be "6" composition levels, but I'm not an expert.
Anyway, this is really an issue for Intel. A seemingly valid, and rather simple (lossless 12bit grayscale) jp2 file created by Pictools, cannot be decoded properly by UIC 6.1.5 (w_ipp-samples_p_6.1.5.060).
Maybe you should also add this as an issue in Premier Support. Since this issue is readily reproducable, Intel should be able to fix it quickly :)
- bad bitstream: compressed by Pictools and poorly decoded with IPP.
- good bitstream: compressed by other tools (such as jasper) andsuccessfullydecoded with IPP.
In my knowledge, the bad bitstream was compressed by pictools, with WT53/lossless, 6 layers and 6 decomposition levels.
I generated another bitstream using pictools, with single layer and 5 decomposition levels (those were same settings in the 'good' bitstream mentioned above), but it was not successfully decoded with IPP, either.
Thus, I guess it's not related with the "6" levels.
We did not finished investigation yet, but usually we can provide fix on sample level. IPP functions level is much simplier comparing with codec level and well tested. Although we do test codec level too, but there much more variance in parameters and modes ond so on.
Please update libraries to 7.0.2, it was fixed there. Non-standardtermination of raw coding passes by OpenJPEG was detected as damage and itblocked further decoding. New version of functions are tolerant for such kind ofstreams and read data safely till it's possible.
I had the problem, that when rebuilding the latest samples, I still got the problem of this topic. However, using the prebuilt sample binaries, the problem was not there.
I then found out that I forgot to upgrade my IPP 7.x to the latest version, although I had already downloaded it... With the latest version of IPP itself, then the problem was gone, thus it appears the fix is in the IPP domain. That makes it impossible to use Jpeg2000 properly in IPP 6 though.