Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.

j2k compression bug

Aris_Basic
New Contributor I
443 Views
im decompressing this image compressed with ipp to a bad looking image im guessing it could be a compression issue.
here is original annonimized dicom aswell as compressed version of the same (j2k lossless compression using UIC)
i do compress a lots of images with IPP j2k and havnt seen this issue before (DICOM parsing is done by a 3rd party library)
you will notice that compressed image once decompressed has some weird white bands on the side and dark vertical lines. i can compress this image fine with another j2k compression library (i could do that too and send you that version aswell)
0 Kudos
9 Replies
Thomas_Jensen1
Beginner
443 Views
You forgot to indicate which IPP version you are using.
I know for a fact that only the very latest IPP 7.0.4 with samples version 7.0.4.054 is able to handle 16 bpp jpeg2000 correctly.

Issues involved are: using 16 or 32 bit mode in the codec, and having pixel values in the high part in the 16-bit word (your Dicom has values in the highest part of 16 bit).

0 Kudos
Thomas_Jensen1
Beginner
443 Views
I took a look at your orig.dcm file.
It is odd that Dicom says Bits Stored = 12, High Bit = 11, but when I load it with different programs, I do get pixels larger than 12 bits:

- Photoshop: OK
- LeadTools 16.5: very strange, and vertical bars left and right of image.
- Picnic 7.0.4: unable to load Dicom file.
- My IPP with DicomLib: normal image, but with vertical bars left and right of image.

It appears that Hitatchi generates an 12 bit image in 16 bit word, where there are pixels with value 0xffff.

It also appears that my code that reads Dicom image files maybe should clip the image at the stated High Bits.

Going back to the previous IPP version, if you give it an image with only low bits (values 0..4095), it would work fine, but with high bit values (close to 0xffff), IPP would not work properly. Maybe your Hitatchi device has started outputting "illegal" Dicom files with values close to 0xffff, while it says High Bit = 11. I'm sure that if you clip the image so it only has values 0..4095, IPP will work fine.
0 Kudos
Aris_Basic
New Contributor I
443 Views
sorry it was with 7.04 of IPP
thx for reasearching image deeper, i was getting ready to do tha this morning.
so maybe just clamp all the pixels to 12bit to avoid IPP picking up that noise.
BTW shouldnt IPP codec automatically discard higher bits in this case ?
what would be good ipp function to do in place clamping ?
0 Kudos
Aris_Basic
New Contributor I
443 Views
found ippiThreshold hopefully that will help
that did not work but AndC did :)
almost clean image (some white lines on a side but im ok with that)
0 Kudos
Thomas_Jensen1
Beginner
443 Views
I'm thought that 7.0.4 should have fixed the bug with Jpeg2000 blurry white when high bit pixel values are present.

I'm a bit too busy right now to retest...

I also know that there are a few source code patches for jpeg2000 right here in this forum.
I have been picking up those fixes to correct the error you have. The fixes are in the jpeg2000 samples, not in the IPP libraries.
0 Kudos
Thomas_Jensen1
Beginner
443 Views
No, and also for Jpeg, above 8 bits (extended, 12bits), you are required to clip yourself.
I learned this the hard way.
0 Kudos
Aris_Basic
New Contributor I
443 Views
any ETA when new IPP version will be out with all those fixes/changes ?
0 Kudos
Aris_Basic
New Contributor I
443 Views
BTW i think i noticed another weird issue.
15bit signed dicom if i compress it as signed image decompressed image looks bad (im assuming ipp asssume highest bit to be a sign bit and not bit 14 (when counting from 0). is that correct assumption ?
EDIT:
actualy i just noticed that current UIC jp2 codec will not even allow compression of signed images.
is there a plan to change that ?
0 Kudos
Thomas_Jensen1
Beginner
443 Views
For my part, I really cannot understand why one would want to keep a grayscale image in signed format. I mean, after all, black is zero, white is (MAX_VAL).

I do understand using signed image pixels when working with (DFT/FFT) filters.

I often got stuck on a feature in older IPP versions supporting only the 16s format, when I needed 16u format. Luckily, Intel later added support for 16u to many old functions.

Anyway, you should not think IPP can work with anything else than 8/16/32 bits.
Surely, Dicom has the Stored Bits property, but if you use IPP, you use 16 bits for processing. Only when sending an IPP image to a codec, such as Jpeg Extended mode (12bit), you scale down the 16 bits to 12 bits before sending to the codec. Then you put the compressed data into Dicom. Likewise, when decoding (decompressing) a 12bit image, you would then upscale it to 16 bit in IPP for further processing. You'd do this because for a 12bit image, you still want 0xffff to be full white. This way, your app only have to deal with 16 bit for processing (possible also 8u_C3).
0 Kudos
Reply