[Bug] Multiframe DICOM negative Spacing Between Slices not handled

[salimkanoun]

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]

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]

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]

This thread is for @sedghi as we discussed this issue

[fedorov]

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]

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

[pieper]

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.

[salimkanoun]

I agree with you @pieper, thank you !

[pieper]

There's more information about how we addressed this in 3D Slicer here: https://github.com/Slicer/Slicer/pull/7987

The details are very different in ITK/Sllicer but I hope we can achieve a consistent interpretation across projects. I understand that in general using the ImagePositionPatient and ImageOrientationPatient should be reliable and that SpacingBetweenSlices shouldn't be used.

[fedorov]

I understand that in general using the ImagePositionPatient and ImageOrientationPatient should be reliable and that SpacingBetweenSlices shouldn't be used.

Except when it comes to irregularly sampled modalities, such as DICOM Segmentations, where the opposite is true - ImagePositionPatient + ImageOrientationPatient in the general case be sufficient to calculate spacing, and SpacingBetweenSlices should be used. There is a related discussion in https://github.com/QIICR/dcmqi/pull/89.

[pieper]

Yes, this is clearly a complex situation, as evidenced by the 8+ years of discussion!

irregularly sampled modalities, such as DICOM Segmentations

I think in this case it's particularly important to look at the per-frame ImagePositionPatient in order to determine how best to handle the data. Segmentations have several edge cases as discussed in the referenced thread. I hope producers of segmentations work to encode them in unambiguous ways.

A situation seen commonly in clinical data is variable slice spacing (i.e. a CT where the slices are close together in the hip, knee, and ankle, but further apart through the femur and shin). There's clearly no uniform SpacingBetweenSlices here, so it can't be represented as an ordinary volume and per-frame positions/orientations are needed. Slicer deals with this using a nonlinear transform.

[sedghi]

I have a solution for this: our multiframe setup for NM wasn't correctly accounting for the frame number in ImagePositionPatient.

Regarding the DICOM SEG and its dependence on SpacingBetweenSlices instead of IPP and IOP, weird ...