Compression Issue when BitsStored(8) is less than BitsAllocated(16)

[Rahul Gulati]

Hi,

We are facing issue with compression/decompression of DICOM images of storage SOP Class 'SecondaryCaptureImageStorage' having transfer syntax 'LittleEndianImplicit'. The images in question(see attached "compression_issue.dcm") have single frame with 'BitsAllocated' as 16 and 'BitsStored' as 8 respectively. And has the pixel data size as 2621440(1024 * 1280 * 1 * (16/8)) bytes.

We are using legacy compression/decompression classes org.dcm4che3.imageio.codec.Compressor/org.dcm4che3.imageio.codec.Decompressor.

What we are doing is first we are compressing the dataSet and then we are verfiying the compression by decompressing it and then comparing the pixel data Md5 with the original.So, in this case we are failing the compression verification check. And also when we are opening the compressed image in a DICOM viewer, we are seeing distorted image.

Also we didn't face any issue when we tested the compression/decompression by changing the 'BitsStored' as 16 i.e. same as 'BitsAllocated' i.e. we were able to pass the compression verification check as well as compressed image in DICOM viewer was same as the original one.

So, the issue seems to be the handling of condition when bitsStored is less than bitsAllocated. Also, the existing issue https://github.com/dcm4che/dcm4che/issues/741 was fixed for Transcoder only and not for legacy Compressor/Decompressor.

Please let me know if You need more info.

Regards,

Rahul Gulati

[Rahul Gulati]

Please also find additional info below:

We are trying the compression to JPEGLossless(1.2.840.10008.1.2.4.70). And using the dcm4che version '5.22.4'

[Rahul Gulati]

Hi,

I would really appreciate if anyone has any update on this. 

Is anyone currently looking into it?

Regards,

Rahul Gulati.

[Gunter Zeilinger]

You may provide a fix in a pull request. We actually do not longer make use of legacy Compressor/Decompressor, so fixing them has rather low priority for us.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

--
You received this message because you are subscribed to the Google Groups "dcm4che" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dcm4che+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dcm4che/203d5d20-f913-45b2-b728-1d8b33c83056n%40googlegroups.com.

[Rahul Gulati]

Thank You for replying. But the issue exists on org.dcm4che3.imageio.codec.Transcoder as well i.e. from Transcoder as well when the bitsStored(8) is less than bitsAllocated(16), the attached image in question is badly compressed.

[Gunter Zeilinger]

Opened https://github.com/dcm4che/dcm4che/issues/813

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

To view this discussion on the web visit https://groups.google.com/d/msgid/dcm4che/8808ff6b-cb8f-4e43-81f4-92ea8d4bfbe6n%40googlegroups.com.

[Rahul Gulati]

Hi,

Thank You for fixing the issue. As suggested I have created a pull request https://github.com/dcm4che/dcm4che/pull/826 on legacy Compressor/Decompressor having similar changes as done for issues #813 & #741 for Transcoder.

Regards,

Rahul Gulati.

[Rahul Gulati]

Hi,

Can anyone please review the pull request https://github.com/dcm4che/dcm4che/pull/826 on legacy Compressor/Decompressor having similar changes as done for issues #813 & #741 for Transcoder. 

Regards,

Rahul Gulati.

[Gulati, Rahul11]

We are getting similar issue with compression even when BitsStored value is 10/12/15 and BitsAllocated is 16 i.e. when BitsStored is less than BitsAllocated. And I checked that the issue is with Transcoder as well.

 

Please find DICOM instances in attached zip file for analysis. And also for attached instances with BitsStored as 10 and 15, we are getting below coredump from "libopencv_java.so"

 

# A fatal error has been detected by the Java Runtime Environment:

 #

 #  SIGSEGV (0xb) at pc=0x00007f864d4a9f10, pid=474633, tid=474847

 #

 # JRE version: OpenJDK Runtime Environment (14.0.2+12) (build 14.0.2+12-Ubuntu-120>

 # Java VM: OpenJDK 64-Bit Server VM (14.0.2+12-Ubuntu-120.04, mixed mode, sharing,>

 # Problematic frame:

 # C  [libopencv_java.so+0xb75f10]  grayscale_convert+0x40

 #

 # Core dump will be written. Default location: Core dumps may be processed with "/>

 #

 # An error report file with more information is saved as:

 # 

 #

 # If you would like to submit a bug report, please visit:

 #   Unknown

 # The crash happened outside the Java Virtual Machine in native code.

 # See problematic frame for where to report the bug.

 

Regards,

Rahul Gulati.

To view this discussion on the web visit https://groups.google.com/d/msgid/dcm4che/d0329198-1c21-4b2c-8a88-5331a6e394c6n%40googlegroups.com.

Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

[Nicolas Roduit]

Please give which types of conversion crashes the application. I didn't manage to make a crash.

I've checked the images and they are all corrupted. BitsStored does not match with the pixel values. Which software has generated those images?

Here are the max pixel value found in the image:

10-bit image: value 2440 in pixel (1570, 1975) => max value in 10-bit is 1023

12-bit image: value 4096 in pixel (394, 138) => max value in 12-bit is 4095

12-bit image: value 54894 in pixel (1835, 1954) => max value in 15-bit is 32767

[Rahul Gulati]

Thank You so much for analysis of images in question. We are doing conversion to JPEGLossless (1.2.840.10008.1.2.4.70) but after your input I retested the conversion after cleaning up my system and didn't face any crash

[Nicolas Roduit]

An improvement could be to check the max value in the image when bits stored and bits allocated are different but it will have a performance cost.