First of all, let's differentiate issues related to sample application from issues related to UIC JPEG2000 codec. You have intentionally used MCT (which is basically color convertion step) then why do you expect bitwise parity? Note, MCT is enabled in UIC picnic application because JPEG2000 standard does not put any limitrations on it use regardless of lossy or lossless compression mode.
do you still have this issue with the latest version of IPP 7.0? We still not reproduce this problem on our side.
If you could share your source image for our investigation it may help to understand the root cause of issue (if there are any).
When using 16u images and decoding a JP2, LL file, it decodes without error messages to a faulty image.
Condition = Pixels has high values (values in the upper part of 64K).
Faulty image = bright area has become fully white.
When using 16u images and decoding a JP2, LL file, it decodes without error messages to a proper image.
Condition = Pixels has only low values (values in the lower part of 64K).
Proper image = pixel-for-pixel exact.
IPP 6.1 can decode the JP2 properly.
IPP = w_ipp_220.127.116.11_ia32
Test program = w_ipp-uic_p_7.0.1.046.zip = ipp-samples\image-codecs\uic\bin\ia32\picnic.exe
(used as-is, not recompiled)
1. Run picnic.exe
2. Load 16u_C1 uncompressed tiff with high values (displayed properly).
3. Save to an JP2 LL MCT=off file (file is proper).
4. Load JP2 file (image is faulty).
5. Load JP2 file using IPP 6.1 (image is proper).
You can reproduce using Photoshop:
1. Load any image.
2. Set Mode = Grayscale, 16 bit.
3. Auto-Levels (to ensure image has high pixel values).
4. Save As Tiff.
Use this 16 bit grayscale image with high pixel values when testing.
thanks for reporting that issue, we will check and if possible update UIC JPEG2000 codec in the nearest IPP release (IPP 7.0.2 expected early next year).
the fix is on sample level, you should modify jpeg2k.cpp file in UIC applications (transcoder and picnic) as following (basically change Ipp16s type to Ipp16u type):
line 470:im_err = IppConvert(imagePn.Buffer().DataPtr().p32s, dataOrderPn.LineStep(), (Ipp16u*)ptr, image.Step(),size,1);
line 525:Ipp16u* ptr = image;
line 541:ptr = (Ipp16u*)((Ipp8u*)ptr + image.Step());
However, I see more sample code for jpeg2000 that seems to suffer from 16s types, that possibly should be 16u types:
"im_err = IppThreshold(0, (1 << (image.Precision())) - 1, tmpRow, sz.width*3);"
The function IppThreshold only exists in 16s and 32s overloads, so tmpRow will be 16s, which is wrong, since we are working on 16u image pixels.
The same goes for IppConvert()
IPP 7.0 Update 2 is available now,the issue should be fixed in the vesion. please refer to bleow information to get more information
Version 7.0.2 of the Intel Integrated Performance Primitives (Intel IPP) library is now available. The library is available as astand-alone productor as a component inIntel Parallel Studio 2011,Intel Parallel Studio XE 2011,Intel C++ Studio XE 2011,Intel Composer XE 2011, andIntel C++ Composer XE 2011. Please visit theIntel Software Evaluation Centerto download evaluation versions of these and other Intel software products.
What's New in 7.0.2
- Additional optimizations for the256-bit Intel AVXSIMD instruction set.
- FurtherIntel Atom Processor optimizationshave been incorporated.
- Data compression gains of ~2x via a redesign of the "Inflate for Fixed Huffman" algorithm.
- Cryptography improvements include 1.4x faster "sign verify" and a 2x faster ippsMontForm() function.
- The ipp_zlib library is now based on the zlib 1.2.5 distribution.
- Review a complete listof changes, bug fixes and new features on-line.