Page MenuHomePhabricator

DICOM Seg loading error
Open, HighPublic

Description

I tried loading the following DICOM Seg files in MITK:

I used the current MITK Windows installer: https://www.mitk.org/download/releases/MITK-2018.04.2/Windows/MITK-v2018.04.2-windows-x86_64.exe

Origin of the files is Mevis Satori

Project context is RACOON where we should be interoperable with the other components, e.g. Satori. And we potentially want to do radiomics with these segmentations. So an important first information is if it is our (MITKs) fault or theirs.

Event Timeline

neher triaged this task as High priority.Nov 30 2020, 1:30 PM
neher created this task.

Forgot the error message :)
Error occurs directly when loading the file.

Info Reader 0 (Instance Number, consecutive) suggests 1 3D blocks  
Info loading C:/Users/neher/Downloads/structureExport_2020-11-10T08_47_51.618911/Lungs_seg_Left lung_1.dcm  
Error An error occurred while reading the DICOM Seg file: JSON Exception: file could not be read.  
Error Unknown read error occurred reading C:/Users/neher/Downloads/structureExport_2020-11-10T08_47_51.618911/Lungs_seg_Left lung_1.dcm

I tested with the latest develop:

WARNING: SliceThickness is present and is 1. using it!
ERROR: JSON parameter file could not be parsed!
You can validate the JSON file here: http://qiicr.org/dcmqi/#/validators
Exception details (probably not very useful): LargestUInt out of Int range
#11.518# ERROR: An error occurred while reading the DICOM Seg file: JSON Exception: file could not be read.
#11.520# ERROR: Unknown read error occurred reading /home/nolden/Downloads/Lungs_seg_Left lung_1.dcm

Hi,
we tried to import our DICOM Seg in the MITK WB and this did not work. I think it makes sense if we schedule a short meeting. What do you think?

It looks like DCMQI CIE color code produces invalid values for attribute
(0062,000d) US 0\32768\32768 # 6, 3 RecommendedDisplayCIELabValue

results in RGB 4294967294/0/1

This happens in ImageSEGConverter::dcmSegmentation2itkimage line ~ 603-626. This value is also included in the JSON produced by that function. The JSON parsing code interprets this as uint but tries to convert it to int and checks the bounds which fails and causes the exception.
Best guess is that the CIE color conversion code is somewhat incorrect in dcmqi.

In T28039#215328, @kast wrote:

Hi,
we tried to import our DICOM Seg in the MITK WB and this did not work. I think it makes sense if we schedule a short meeting. What do you think?

Sure. I reported the bug and I am a stakeholder but I am most likely not the best person to discuss technicalities. Maybe you send an email, @kast ?

@kast @weihs do you assume it's the same problem you have with your data? Could you share your DICOM seg?

@neher I tried OHIF within kaapana with your data, but it refuses to show it without the reference CT, possible to share that here?

If it's a dcmqi problem it should also show up using their command line tools. if we could reproduce it like that (or within 3D Slicer) I think it would also work to contact @fedorov
and ask for suggestions

@nolden, Jonas already tried it with the reference CT. Does not work since some tag that Ohif uses to link the seg to the ct is missing.

Here you go with the CT. Actually the archive contains two CT images, not sure which one is the matching one :)
https://hub.dkfz.de/s/MDWwGHQxJcWgrzN

we tried it with the attached data and also with our own
(0062,000d) US 0\32768\32768 # 6, 3 RecommendedDisplayCIELabValue is the value in both datasets
we have different values but the issue is the same

removing the tag or changing its value to 43803\26565\37722 which is the fallback in dcmqi works, then also the workbench loads the files

since the log message clearly locates the issue somewhere in the dcmqi code we debugged only the dcmqi code portion of mitk::DICOMSegmentationIO
dcmqi::JSONSegmentationMetaInformationHandler::read throws the exception, debugging through it shows the issue with the attribute above

I contacted dcmqi upstream, thanks @fedorov for the quick reply.

"You guys correctly identified the location in dcmqi where this is
happening: https://github.com/QIICR/dcmqi/blob/master/libsrc/Helper.cpp

Something in this path is likely incorrect:
getIntegerScaledCIELabFromCIELab -> getCIEXYZFromCIELab -> getRGBFromCIEXYZ
"

I understand for a timely solution we should probably look for a workaround or try to fix it in dcmqi.

Another idea is to look at how OHIF is doing CIELab to RGB conversion, since they do this independently from dcmqi.

Did you guys solve it for your purposes?

The developer who contributed the conversion code in dcmqi is not around, and I do not know all the background why it was implemented the way it was. There are util functions in DCMTK which implement the conversion: https://github.com/DCMTK/dcmtk/blob/master/dcmiod/libsrc/cielabutil.cc (this is what is re-implemented in OHIF/dcmjs: https://github.com/dcmjs-org/dcmjs/blob/master/src/colors.js). I have a PR to switch to using DCMTK: https://github.com/QIICR/dcmqi/pull/413. The issue however is that RGB<->CIELab conversion is not round-trip consistent, due to dcmqi using int8 for RGB, so I have not finalized the PR yet.

dcmqi issue here: https://github.com/QIICR/dcmqi/issues/412.

Would be great to have your thoughts on this.

Also, I forgot to mention - the RGB for the CIELab color value in question (0\32768\32768) is almost black. You may want to communicate this to the producer of the segmentation to confirm that is indeed the intended color for that segmentation.

dcmqi issue should be fixed in the latest release: https://github.com/QIICR/dcmqi/releases/tag/v1.2.3 (you can see details in the issue referenced earlier).

@fedorov Happy new year and thanks for keeping us up to date!

We should check if the 3rd party update realy solves the issue and according to that plan the release todos.

I set the GIT_TAG of DCMQI locally to v1.2.3 and I can confirm that the data from above can be loaded.

I set the GIT_TAG of DCMQI locally to v1.2.3 and I can confirm that the data from above can be loaded.

OK, then increasing the DCMQI version to 1.2.3 before our next release seems to be the most sensible fix, doen't it?

Just submitted a Differential

Changes have landed . @neher could you test again using a nightly build?

Sure. Could you point me to the nightly installers again? @nolden