[Bug] Multiframe DICOM negative Spacing Between Slices not handled

salimkanoun commented 2 months ago

Describe the Bug

In multiframe DICOM, some of theme has a negative 0018,0088 Spacing Between Slices exemple 0018,0088 Spacing Between Slices: -4.41806

According to the dicom standard in the case of NM images "The normal is determined by the cross product of the direction cosines of the first row and first column of the first frame, such that a positive spacing indicates slices are stacked behind the first slice and a negative spacing indicates slices are stacked in front of the first slice"

In the current version, Cornerstone only take in consideration 0018,0050 Slice Thickness resulting that DICOM with negative spacing between slices are upside down.

Here are two samples with this issue: Bone scitigraphy https://nc-6563074006263353659.nextcloud-ionos.com/index.php/s/yYjXZxapM77WMYF Datscan https://nc-6563074006263353659.nextcloud-ionos.com/index.php/s/Nt8qkxEw2NMNM6A

Steps to Reproduce

Open OHIF with config strictZSpacingForVolumeViewport: false Open the Datscan image with basic mode, go to MPR The brain is upside down (see vertex being down)

Open the bone scintigraphie in basic and go to MPR, see the bladder uptake in upper part of the viewport

Modify the TMTV mode to try to fuse the NM (here labeled OT has reconstruction in NM is not native) with CT

An error occur
We can see the mismatch of the two series

The current behavior

upside down image

The expected behavior

image stack should be done in reverse order if Spacing Between Slices is negative

OS

Linux

Node version

20+

Browser

Chrome 100+

salimkanoun commented 2 months ago

updatetmtvmode.zip

Here the source file to update to make TMTV mode compliant with the bone scintigraphy spect ct

The config file with strictZSpacingForVolumeViewport: false,

GetHpModule of TMTV extension with protocolMatchingRules: [ { attribute: 'ModalitiesInStudy', constraint: { includes: ['CT', 'PT', 'NM', 'OT'], }, },

ptDisplaySet: {
  seriesMatchingRules: [
    {
      attribute: 'Modality',
      constraint: {
        includes: ['PT', 'NM', 'OT'],
      },
      required: true,
    },

and index of the mode of tmtv mode with a change to enable it for NM / OT series

[modalities_list.includes('PT') || modalities_list.includes('NM') || modalities_list.includes('OT')] &&

salimkanoun commented 2 months ago

Also in cornerstone there is this comment

  // We implemented these lines for multiframe dicom files that does not have
  // position for each frame, leading to incorrect calculation of zSpacing = 0
  // If possible, we use the sliceThickness, but we warn about this dicom file
  // weirdness. If sliceThickness is not available, we set to 1 just to render
  if (zSpacing === 0 && !strictZSpacingForVolumeViewport) {

I'm not sure about this algorithm when reading multiframe image, using metadata we can determine if it is reconstructable and it is possible to compute the position of each slice if needed by adding framespacing * frame number to the origin and then have each slice position if needed

However the strictZSpacingForVolumeViewport sounds like a special option to support multiframe while multiframe should be supported out of the box in my opinion

salimkanoun commented 2 months ago

This thread is for @sedghi as we discussed this issue

fedorov commented 2 months ago

This unfortunately is observed in CT as well sometimes, see related discussion in Slicer forum: https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913.

salimkanoun commented 2 months ago

Agree it is not specific to NM, should be handled for all modalities

pieper commented 2 months ago

Thanks for pointing this out - we should figure out the correct interpretation of these negative SpacingBetweenSlices values and do the correct thing on all the platforms where this community has influence (perhaps with the options for the user to override the selection).

From my understanding we should:

check the SOPClass and if it's an NM then we should accept the negative spacing and interpret it in the first post in this thread
If it's not NM, then we should use the absolute value of the SpacingBetweenSlices (on the basis that the negative value is invalid DICOM).

Note that in older versions of ITK (and 3D Slicer) this value was ignored and, I believe, always came back as 1. Now that it can be returned as negative it's created a backwards incompatibility.

OHIF / Viewers