OHIF mask export writing invalid dicom segmentation files (jpeg issue)?

[dr.ka...@gmail.com]

We are trying to run some post-processing on the DICOM segmentation files that are generated when a mask is saved with the OHIF plugin (v3.1, in XNAT 1.8.3). When our code tries to load the pixel data from the exported DICOM segmentations, we get errors trying to decode the JPEG data. We've tried with a few different libraries.

With libjpeg, we get this output: 

RuntimeError: libjpeg error code '-1038' returned from Decode(): A misplaced marker segment was found - stream does not contain a JPEG file, SOI marker missing

With GDCM, we get:

Not a JPEG file: starts with 0x00 0x00

AttributeError: Amount of pixel data 2359296 does not match the expected data 18874368

DCMQI's tools also don't seem to be able to work with the files, and give this error:

dcmqi repository URL: https://github.com/QIICR/dcmqi.git revision: ef9e227 tag: v1.2.4

E: Transfer syntax JPEG Lossless, Non-hierarchical, 1st Order Prediction uses lossy compression, not supported for Segmentation objects!

ERROR: Failed to load segmentation dataset! Cannot decompress

Fatal error encountered.

The masks import back into OHIF fine. I'm wondering what libraries are being used to write out the dicom seg files, and why they are being written in the JPEGLossless:Non-hierarchical-1stOrderPrediction transfer syntax? Are there tools outside of the plugin that are successfully loading the segmentations?

Any help/insight would be appreciated.

Thanks,

James

[James Hawkins]

I'm guessing that OHIF is trying to replicate the transfer syntax of the original source DICOM, and is having issues writing out the JPEG Lossless, Non-hierarchical, 1st Order Prediction. Interesting that it correctly loads them back in.

--
You received this message because you are subscribed to a topic in the Google Groups "xnat_discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/xnat_discussion/ObexNIf8GSg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/a6bdccb9-0162-4d38-9c0e-4994a155d88cn%40googlegroups.com.

[Moore, Charlie]

Hi James,

I'm not one of the developers of the OHIF viewer (or plugin), but I've got a guess as to what's happening. For me, when I created a segmentation using the OHIF plugin, it created it with EVLE (Explicit VR Little Endian) transfer syntax. That matches the transfer syntax of the underlying series. What if the data in the segmentation is always written as EVLE, but the transfer syntax is incorrectly encoded in the headers to match the underlying series? That is, what if you can't view your segmentation with a JPEG library because it's not using a JPEG-encoding at all? This would be pretty easy to check. Try explicitly setting the transfer syntax on your segmentation to EVLE and see if it magically becomes viewable. Of course, I could be way off base, but this hypothesis looks consistent with all the data I have available to me 🙂.

Thanks,

Charlie

---

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of James Hawkins <dr.ka...@gmail.com>
Sent: Wednesday, November 17, 2021 2:24 PM
To: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com>
Subject: Re: [XNAT Discussion] OHIF mask export writing invalid dicom segmentation files (jpeg issue)?

 

* External Email - Caution *

You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/CAE%3DXGQvq0MB0Q-L-uHa7j4rOs%3Dphsz5asMpkRhXbuDBfEwv5Gw%40mail.gmail.com.

 

---

The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

[James Hawkins]

It looks like OHIF is trying to match the transfer syntax of the reference series, compressed in this case, and it does try to write out JPEG data (the JPEG just isn't encoded correctly). Manually changing the transfer syntax doesn't create loadable pixel data. If I decompress the session dicoms stored in the XNAT archive, and then create a mask in OHIF, the exported dicom seg file matches the uncompressed transfer syntax and can be read correctly by other dicom tools/libraries. Looks like the fix for us will be to go through the archive and decompress the exams...

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/CH2PR02MB6710E8B39C011724070A4210FE9A9%40CH2PR02MB6710.namprd02.prod.outlook.com.

[James Hawkins]

As a side-effect of decompressing the series, snapshots are now available. Do any additional libraries need to be set up for XNAT 1.8 to handle the snapshots for JPEG compressed images?

[Elina Thibeau-Sutre]

Hello all,

I am also trying to use a segmentation produced by XNAT OHIF and cannot open it (I have exactly the same errors as described in the first message).
Did you find a way to work around this?