Saving DICOMsegmentations - Interoperability with OHIF

Support
1

I am using 3Dslicer with the Monailabel plugin to run some segmentation models. The result is then exported as DICOMSegmentation and saved to an Orthanc PACS. Up to this point we were using OHIF v2 to visualise the images along with the segmentations. However we have noticed that this is not working for OHIF v3.3. It throws some error about missing SpacingBetweenSlices tag. Anyway, my question is the following do we know whether OHIF v3.3 is capable to read DICOMSegmentations stored using 3DSlicer? Is there a way to tweak the way the segmentations are stored so they will be read by OHIF v3.3?

Thank you.

2

I saw your issue on OHIF github about this. It would be great if you could provide some example data (no PHI, just phantom or dummy data) to illustrate the issue and we can get to the bottom of this.

3

Right after posting this, I had a closer look into the console errors while reading the images with OHIF and tried this “Hail Mary” solution which worked. For my tests I am using this open access dataset, the latest version of 3DSlicer for windows and macOS, and the latest stable release of monai label. I hope that helps.

4

Interesting - thanks for the info. But are you saying the issue is with the segmentations on TCIA? I thought you were saying that SEGs from the current version of Slicer weren’t working. Can you post an example of the specific file that requires the change in OHIF?

5

Also @ksidis is the SEG generated by MONAI Label or exported from Slicer?

6

Apologies for not being clear.

I meant I am simply using open access dicom images and segment them using 3Dslicer with monai label.
The result of the segmentation causes OHIF v3.3 to crash. Please find an example image exported from my pacs here

My understanding is that monai label simply provides the segmentation mask and 3DSlicer exports that to a DICOMSeg object.

7

Thanks for sharing this. I can see with dcmdump that the seg says it’s made with dcmqi from QIICR:

(0008,0060) CS [SEG]                                    #   4, 1 Modality
(0008,0070) LO [QIICR]                                  #   6, 1 Manufacturer

It appears to have valid SpacingBetweenSlices, so it’s not clear why you needed to patch OHIF.

      (fffe,e000) na (Item with undefined length #=3)         # u/l, 1 Item
        (0018,0050) DS [5.000000e+00]                           #  12, 1 SliceThickness
        (0018,0088) DS [5.000000e+00]                           #  12, 1 SpacingBetweenSlices
        (0028,0030) DS [6.132812e-01\6.132812e-01]              #  26, 2 PixelSpacing
      (fffe,e00d) na (ItemDelimitationItem)                   #   0, 0 ItemDelimitationItem

I wonder if it’s related to this bug: Fix: reading sequences with undefined length items - length value of item delimitation tag and new item tag will be used to detect the length of the sequence more precise by kursawero · Pull Request #346 · dcmjs-org/dcmjs · GitHub

Would you be able to test OHIF using the latest dcmjs?

8

Hey @pieper, thx for looking into this. Yes I can confirm that the tag is there, so there might be some issue with their DICOM library because the property inside OHIF is null. I’ll try and find some time to test your suggestion.

9

Thanks for looking into it. I’m pretty sure the OHIF v3 code uses dcmjs before that fix was release so there’s a good chance updating the dependency will work. Let us know how it goes.

10

@ksidis @pieper turns out that the problem was not in dcmjs but OHIF.
The logic was getting the tag value from the first image metadata.

I opened a PR to extract it from the SEG’s shared group seq / pixel measures seq.

11

Thanks @igoroctaviano !