Failed to load DICOM SEG series using dicom study json

[marcopus]

Bug Report

Describe the Bug

When loading a study via the Study Dicom Json and the study contains a series and its segmentation (DICOM SEG), the viewer fails to load the segmentation series:

error messages:

• ToolbarRow: Cannot read properties of undefined (reading 'SeriesInstanceUID')
• Referenced series for SEG dataset not present.
• Source data not present

Interestingly, the exact same series load correctly together when using the viewer /local route:

Running OHIF Viewer 4.12.18 from the docker hub. Also just tested in 4.12.19 local dev branch.

What steps can we follow to reproduce the bug?

1. Have a set of a dicom image and a dicom-seg segmentation made using e.g. dcmqi (DICOM for Quantitative Imaging) library
2. Have a dicom json containing two series 1) original dicom image and 2) dicom segmentation
3. Load the dicom json using the route /viewer?url=<json_url>

[marcopus]

I did some debugging, it looks like some metadata are missing for the metadata module to find the referenced display set https://github.com/OHIF/Viewers/blob/383a0ef167e621b7e750997c636009da35b45ed7/platform/core/src/classes/metadata/StudyMetadata.js#L284-L287 This returns the correct referencedSeriesInstanceUIDs when loading the images via the /local route, but not when loding them using dicom json @Punzo do you maybe know off the top of your head, which specific metadata would be needed here to get this to work?

[marcopus]

it's the metadata.ReferencedSeriesSequence missing

[Punzo]

yes, the attribute is 1C https://dicom.innolitics.com/ciods/ct-image/common-instance-reference/00081115. So I would say the data needs to be fixed.

NOTE: at the moment we require it, because for IDC we overlay only segmentations which directly refer to the source data (i.e. the active data series).

However, one could add some UI to force to select manually other segmentations or segmentation missing the reference.

[marcopus]

thank you for your reply. I am gonna try and provide the data as part of the study dicom json. I hope this solves the issue, and then this issue can probably be closed as not a bug

[marcopus]

@Punzo do you know how exactly the ReferencedSeriesSequence metadata should be included in the dicom json? specifically:

• at which nesting level (study/series/instance metadata) should the field appear?
• how should it be formatted? stringified/as a list object?

[Punzo]

you can activate the OHIFDicomTagBrowserExtension https://github.com/OHIF/Viewers/blob/master/platform/viewer/src/index.js#L57 for your local build, and you can explore the DICOM structure. I hope it helps.

[marcopus]

After fixing the ReferencedSeriesSequence, now it's failing because it misses another SQ metadata, PerFrameFunctionalGroupsSequence. I find it inconvenient to having to serialize these data into the dicom json, when the OHIF can actually correctly parse them by itself. Is it possible to let OHIF fetch these missing metadata directly from the dicom files?

[Kayakflo]

Hey @marcopus , I am currently facing the same obstacles (missing documentation for JSON structure) described in your bug report. Since you closed the issue, have you found a satifying solution to achieve the same results when serving DCM files via JSON vs uploading them using the /local endpoint? Any help is highly apprechiated! Cheers

[marcopus]

Hi @Kayakflo

have you found a satifying solution to achieve the same results when serving DCM files via JSON vs uploading them using the /local endpoint?

only partially... I ended up writing an additional OHIF component that imitates the /local endpoint (ViewerLocalFileData.js) but instead of loading files via the dropzone, it fetches them via our data API. So it's a bit of a custom solution, but it avoids the hassle of serializing a bunch of missing metadata, where the OHIF can already figure it out by itself.

For the generation of DICOM SEG from mha I was using a library called dcmqi, with something like:

itkimage2segimage --inputImageList <path_to_mha_file> --inputDICOMDirectory <path_to_dicom_dir> --outputDICOM <path_to_output_file> --inputMetadata <path_to_metainfo_json>

but you are probably familiar with this already

[Kayakflo]

Awesome, thank you for sharing your approach @marcopus ! Looking into both endpoints and setting respective breakpoints also made me wonder why the /viewer endpoint did not utilize the parsing capabilities that already exist in /local. That being said, I wanted to stay as close to the master branch as possible, to avoid conflicts in future versions. My solution is to use pydicom (which I use anyways) to create the JSON containing every single tag there is for each dicom file.

I am highly interested to see how much effort it was for you to add the parsing logic to the /viewer endpoint. If you don't mind sharing your changed, that would be amazing.

Cheers!

[marcopus]

Sure! Here's a snippet of the extra component that I made: https://gist.github.com/marcopus/1a431b0dd56934a8d8573a489a1744fc

Just to clarify, I did not modify the logic of the /viewer endpoint, I simply created this new viewer component and registered it with the router, so that I do not interfere too much with upstream changes.

What's your application and how's your experience so far with OHIF Viewer?

[Kayakflo]

Thank you very much for sharing, it looks clean and makes me wonder even more why it has not been implemented natively.

In my application I basically need a multitenant version of the viewer to limit access by user authenticated by my own authentication layer in front. From what I have seen and tested this is not (easily) possible with the officially supported data sources which led me to the /local and /viewer route. From a usability perspective I am positively surprised about how extensive the viewer is, especially compared to paid alternatives.

[LumiProj]

Dear OHIF Viewer team,

I am currently using the OHIF Viewer in my web application and I am experiencing an issue with playing all frames of a DICOM file when loading studies through my ASP.NET Core API using JSON. While this functionality works fine in local mode, it seems to be malfunctioning when the studies are loaded via my API.

I have followed the official documentation of OHIF Viewer closely and cannot seem to identify the missing segment causing the issue.

I would greatly appreciate your guidance in resolving this matter. Could you please advise me on what I may be missing or what steps I can take to troubleshoot this issue?

Thank you for your assistance.