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)
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.
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.
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 ?
actualy i just noticed that current UIC jp2 codec will not even allow compression of signed images.
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).