adapters/Cornerstone/Segmentation: generateToolState sets incorrect segmentsOnFrame for 4D Volumes (worked correctly in previous versions!)

[Christian-e-S]

Please note: We saw this issue appear in the latest version of the OHIF viewer which relies on a newer version of dcmjs. The issue was not present in previous versions of dcmjs (e.g., 0.18.8).

Description of the issue:

Background Information We have 4D datasets in our PACS (e.g. Diffusion Weighted Imaging). A single series contains contains a sequence of the same 3D volume captured at different point in times or with different modality parameters. Let's say, the 3D volume (e.g., from a brain scan) is made up of 20 images and the 4D series contains 10 of these 3D image sets, than the entire series would contain 200 images. In the DICOM viewer you can scan through these 200 images, which means you scan 10 times through the brain. Since it is always the same 3D volume, the geometry information is exactly the same for each volume (e.g., image 01, 21, 41, 61, 81, 101, 121 ... share the same geometry as well as the images 02, 22, 42, 62, 82, 102, 122 ... and so on). Of course each image has a distinct SOPInstanceUID.

We use 3D slicer to do segmentation on the 4D dataset, which allows us to draw segments on the images of an individual 3D volume in the 4D data set. Let's say we draw a segment on some images of the 5th volume (e.g image 83, 84 and 85). When we inspect the resulting DICOM SEG file, ReferencedSOPInstanceUID is set correctly for these images.

In a previous version of the OHIF viewer (which used dcmjs version 0.18.8), the segments where shown on the correct images.

Issue: Using the latest version of the OHIF viewer (using dcmjs 0.19.7), the segments are always shown on the images of the very first 3D volume in the series (in our example that would be image 3, 4 and 5).

My suspicion: The function generateToolState in adapters/Cornerstone/Segmentation_4X.js sets the return value segmentsOnFrame[imageIdIndex] for each imageIdIndex where the segmentIndex should be shown.

What I can see, is that the newer version of dcmjs tries first to determine the imageId by comparing the geometry of the images in the series (getImageIdOfSourceImagebyGeometry). Only if this doesn't work, it tries to get the imageId by comparing to the SourceImageSequence (getImageIdOfSourceImagebySourceImageSequence).

Since the geometry is always the same for all 3D volumes is the 4D series, the first matching volume is always the first volume in the series.

Question: What is the rational that this approach has been chosen? Would it be possible to reverse this order (So first try via SourceImageSequence and then via geometry)? If the geometry matching is used, would it make sense to include all geometry matching images in "segmentsOnFrame"? Showing the segment in all 3D volumes of the series is at least a "more correct" approach than showing it only on the wrong 3D volume.

Looking forward to your response!

Best Regards

[pieper]

Also see #253

[pieper]

@Christian-e-S thanks for the report 👍

@Punzo knows what to do.

[Punzo]

@Christian-e-S yeap, thanks for testing and reporting the issue. The issue is because of https://github.com/dcmjs-org/dcmjs/pull/253. After talking with David and in the light of this issue, make sense to first use ReferencedSOPInstanceUID and then other logic to find the Ids in case of issues with the data. I will have a PR in few minutes

[Punzo]

pinging also @fedorov since this change was related to some IDC data with issues with wrong ReferencedSOPInstanceUID

[Punzo]

fixed in https://github.com/dcmjs-org/dcmjs/pull/256

[Christian-e-S]

Great! Thank you very much for the fast reaction!!