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

The poor quality problem of decompressing Lossless JPEG2000 bitstream using UIC sample

dexylitol
Beginner
644 Views
Hi, all.
I'm testing unified image codec (UIC) to decompress jpeg 2000 bitstream, containing 12bit CT image data.
However, I've found that the final resultant image decoded by UIC looks degraded, although the image has been encoded lossless.
The following figure shows the decompressed images; the left one is decompressed by Pegasus and OpenJPEG library and the right one is decompressed by UIC (same by picnic.exe)
You can see the difference between the above images easily.
The right image is looking like that it's not fully decompressed.
Attached the JP2 bitstream to this message.
Currently, I'm using 6.1.5 samples.
Any comment will be helpful since I'm so urged.
Thank you in advance.
0 Kudos
16 Replies
Thomas_Jensen1
Beginner
644 Views
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?
0 Kudos
dexylitol
Beginner
644 Views
Thank you, Mr. Jensen, for your reply.
I attached the decoded images in raw file format to this message (The left image in the above).
The image dimension is 512 x 512 and 2 bytes per pixel (little endian).There's no header.
PS. I can't download your attachment.
0 Kudos
Thomas_Jensen1
Beginner
644 Views
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?
0 Kudos
dexylitol
Beginner
644 Views
Thank you for your reply.
The jp2 file was compressed with PICTools (Pegasus) library.
Actually, since we have lots of image files which have been compressed with that tool,
we need to be able to decompress such jp2 bitstream properly.
Any idea?
0 Kudos
dexylitol
Beginner
644 Views
In addition to your test results,
the bitstream was successfully decompressed with the following tools, too.
- LeadTools 14
- Jasper
- OpenJPEG
- PicTools (Actually, the bitstream was compressed with it)
I'm not thinking that the bitstream is bad.
So far, only IPP has a problem with this bitstream.
0 Kudos
Thomas_Jensen1
Beginner
644 Views
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).
0 Kudos
dexylitol
Beginner
644 Views
Dear Jensen,
I multiplied all the pixel values by 16 and compress the image with the PicTools, using lossless compression.
And decompressed the bitstream with both PicTools and IPP. Here are the resulting images.
The right image is decompressed with IPP.
The image looks much better if compared with the above, but it is still degraded.
Please let me know what you need to diagnose it. I can do anything !! ^^
Thanks.
0 Kudos
dexylitol
Beginner
644 Views
And for your information,
I downloaded JHOVE fromhttp://hul.harvard.edu/jhove/using.html#jpeg2000-huland dumped the problematic bitstream.
Jhove (Rel. 1.5, 2009-12-19)
Date: 2010-05-11 15:29:18 KST
RepresentationInformation: CT_Pegasus_6Layers.encoded.jp2
ReportingModule: JPEG2000-hul, Rel. 1.3 (2007-01-08)
LastModified: 2009-08-11 18:18:19 KST
Size: 115714
Format: JPEG 2000
Status: Well-Formed and valid
SignatureMatches:
JPEG2000-hul
MIMEtype: image/jp2
Profile: JP2
JPEG2000Metadata:
Brand: jp2
MinorVersion: 0
Compatibility: jp2
ColorspaceUnknown: false
ColorSpecs:
ColorSpec:
Method: Enumerated Colorspace
Precedence: 0
Approx: 0
EnumCS: Greyscale
UUIDs:
UUIDBox:
UUID: 97, 112, 0, -34, -20, -121, -43, 17, -78, -19, 0, 80, 4, 113, -3, -36
Data: -46, 0, 0, 0, 63, 1, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 40, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
UUIDBox:
UUID: 45, 65, 33, -34, -80, -15, 71, 67, -125, 91, 0, -12, 11, -82, -62, -19
Data: 0, 0, 0, 4
Codestreams:
Codestream:
ImageAndTileSize:
Capabilities: 0
XSize: 512
YSize: 512
XOSize: 0
YOSize: 0
XTSize: 512
YTSize: 512
XTOSize: 0
YTOSize: 0
CSize: 1
SSize: 15
XRSize: 1
YRSize: 1
CodingStyleDefault:
CodingStyle: 0
ProgressionOrder: 0
NumberOfLayers: 6
MultipleComponentTransformation: 0
NumberDecompositionLevels: 6
CodeBlockWidth: 4
CodeBlockHeight: 4
CodeBlockStyle: 1
Transformation: 1
QuantizationDefault:
QuantizationStyle: 64
StepValue: 128, 136, 136, 144, 136, 136, 144, 136, 136, 144, 136, 136, 144, 136, 136, 144, 136, 136, 144
NisoImageMetadata:
MIMEType: image/jp2
ByteOrder: big-endian
CompressionScheme: JPEG 2000
ImageWidth: 512
ImageLength: 512
BitsPerSample: 16
SamplesPerPixel: 1
Tiles:
Tile:
TilePart:
Index: 0
Length: 115426
Comments:
Comment: Pegasus Imaging Corp
I compared it with the dumped one from the good bitstream and found no differences between them except:
- The problematic bitstream has the UUIDs block while the good one doesn't.
- And the CodeBlockStyle value is different. ( 1 and 0 )
I'm not sure if it is helpful for you.
0 Kudos
Thomas_Jensen1
Beginner
644 Views
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 :)
0 Kudos
dexylitol
Beginner
644 Views
Sorry for confusing terminology.

Simply I meant;
- 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.
Thank you.
0 Kudos
Vladimir_Dudnik
Employee
644 Views
Hello,

Just want to inform you that we consider possibility to provide the fix of this issue before end of July.

Regards,
Vladimir
0 Kudos
Aris_Basic
New Contributor I
644 Views
Is this fix going to be an update for base ipp install or just to examples (uic) ?
0 Kudos
Vladimir_Dudnik
Employee
644 Views
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.

Regards,
Vladimir
0 Kudos
Mikhail_Kulikov__Int
New Contributor I
644 Views
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.
0 Kudos
Thomas_Jensen1
Beginner
644 Views
Was this fix in the IPP domain or in the sample domain?
If in the sample domain, then I might apply the fix to my current 6.x code.
0 Kudos
Thomas_Jensen1
Beginner
644 Views
I think I answered my question myself.

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.
0 Kudos
Reply