# Regression in the DICOM data base

**URL:** <https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913>\
**Category:** Support\
**Created:** [August 16, 2024, 11:24am UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913 "2024-08-16T11:24:56Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![rkikinis](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/rkikinis/32/791_2.png) [@rkikinis](https://discourse.slicer.org/u/rkikinis)\
**Post date:** [August 16, 2024, 11:24am UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/1 "2024-08-16T11:24:56Z")

</div>

Loading the following data set in Slicer nightly 8-15 on Mac OS 14.6.1 fails. The same data set works without problem in the stable release 5.6.2

 ![Screenshot 2024-08-16 at 7.16.05 AM](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/f/0/f0bdd6595326fe7abf2420f74313587e74249526.jpeg)  
The data is from IDC and loads into slicer with the IDC viewer.  
SeriesInstanceUID to download: 1.3.6.1.4.1.14519.5.2.1.2932.1975.255072988367557196694880426160

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [August 16, 2024, 3:47pm UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/2 "2024-08-16T15:47:27Z")

</div>

There is the strange value of _Spacing Between Slices_ (0x0018, 0x0088) `-1`. BTW, there seems to be a bug (or “behavior change”) in recent GDCM IO that may be related, s. [ITK issue 4794](https://github.com/InsightSoftwareConsortium/ITK/issues/4794). **But I am not sure** , just FYI. cc @dzenanz

dciodvfy:  
`Error - Illegal negative value - SpacingBetweenSlices = -1`

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [August 16, 2024, 4:03pm UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/3 "2024-08-16T16:03:15Z")

</div>

I can confirm that _Spacing Between Slices_ `-1` causes the problem. I have changed it to `1` (don’t know what the value should be, but AFAIK it should be taken from IPP/IOP) and the series loads (latest preview, Linux)

 ![Screenshot at 2024-08-16 17-59-44](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/c/f/cfc4ba2ba16b2ac6418d31b4a11dd1afe9214b2b.jpeg)

---

<div class="post-metadata">

**Author:** ![rkikinis](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/rkikinis/32/791_2.png) [@rkikinis](https://discourse.slicer.org/u/rkikinis)\
**Post date:** [August 16, 2024, 7:22pm UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/4 "2024-08-16T19:22:25Z")

</div>

The same data set loads properly in the stable release. Something must have broken as the nightly build has a different version of the dicom module.

---

<div class="post-metadata">

**Author:** ![jamesobutler](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jamesobutler/32/7511_2.png) [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)\
**Post date:** [August 16, 2024, 8:04pm UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/5 "2024-08-16T20:04:20Z")

</div>

Yes Slicer Stable (5.6.x) uses ITK 5.3.0 while Slicer Preview (5.7) is using ITK 5.4.0.

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [August 29, 2024, 8:27pm UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/6 "2024-08-29T20:27:29Z")

</div>

For convenience, to download the series mentioned by @rkikinis, you can do this:

```bash
$ pip install --upgrade idc-index
$ idc download 1.3.6.1.4.1.14519.5.2.1.2932.1975.255072988367557196694880426160

```

Also for convenience, the BigQuery query below will select all series in Imaging Data Commons that have negative `SpacingBetweenSlices`.

```sql
WITH
  temp_table AS (
  SELECT
    SeriesInstanceUID,
    Manufacturer,
    collection_id,
    Modality,
    SpacingBetweenSlices
  FROM
    `bigquery-public-data.idc_current.dicom_all`
  WHERE
    SAFE_CAST(SpacingBetweenSlices AS INT64)<0)
SELECT
  SeriesInstanceUID, any_value(Manufacturer) as Manufacturer, any_value(collection_id) as collection_id, any_value(Modality) as Modality, any_value(SpacingBetweenSlices) as SpacingBetweenSlices
FROM
  temp_table
  group by SeriesInstanceUID
order by Modality

```

For the sake of convenience, the result of running the query is below. You can plug in `SeriesInstanceUID` into the instructions above to download any of those series.

| Row | **SeriesInstanceUID** | **Manufacturer** | **collection\_id** | **Modality** | **SpacingBetweenSlices** | |
| --- | --- | --- | --- | --- | --- | --- |
| 1 | 1.3.6.1.4.1.32722.99.99.25384965558792938714037113526608989475 | Philips | nsclc\_radiomics\_genomics | CT | -4 | |
| 2 | 1.3.6.1.4.1.32722.99.99.100358904385730998553678259325908346054 | Philips | nsclc\_radiomics\_genomics | CT | -4 | |
| 3 | 1.3.6.1.4.1.32722.99.99.149205799948107127590297091243342465514 | Philips | nsclc\_radiomics\_genomics | CT | -4 | |
| 4 | 1.3.6.1.4.1.32722.99.99.28029226020345235950699297480918949957 | Philips | nsclc\_radiomics\_genomics | CT | -4 | |
| 5 | 1.3.6.1.4.1.32722.99.99.227649070570497400491575590741039272857 | Philips | nsclc\_radiomics\_genomics | CT | -4 | |
| 6 | 1.3.6.1.4.1.14519.5.2.1.7009.2401.242751552100019522164450359161 | Philips Medical Systems | acrin\_flt\_breast | CT | -4 | |
| 7 | 1.3.6.1.4.1.32722.99.99.87555546360421578566793618960733881338 | Philips | nsclc\_radiomics\_genomics | CT | -4 | |
| 8 | 1.3.6.1.4.1.14519.5.2.1.7009.2401.133294077881051013352649869844 | Philips Medical Systems | acrin\_flt\_breast | CT | -4 | |
| 9 | 1.3.6.1.4.1.32722.99.99.202497385511333427836173062690695671593 | Philips | nsclc\_radiomics\_genomics | CT | -4 | |
| 10 | 1.3.6.1.4.1.32722.99.99.234042609125631064514013492837366678413 | Philips | nsclc\_radiomics\_genomics | CT | -4 | |
| 11 | 1.3.6.1.4.1.14519.5.2.1.7009.2401.257448054826249901110797391087 | Philips Medical Systems | acrin\_flt\_breast | CT | -4 | |
| 12 | 1.3.6.1.4.1.14519.5.2.1.7009.2401.874419016376926649794615836826 | Philips Medical Systems | acrin\_flt\_breast | CT | -4 | |
| 13 | 1.3.6.1.4.1.14519.5.2.1.2857.3159.256409392788539989062455102657 | Philips | cptac\_cm | CT | -3 | |
| 14 | 1.3.6.1.4.1.32722.99.99.316599411906020923226736902474087731150 | Philips | nsclc\_radiomics\_genomics | CT | -4 | |
| 15 | 1.3.6.1.4.1.32722.99.99.225570660272964280948169301188944152335 | Philips | nsclc\_radiomics\_genomics | CT | -4 | |
| 16 | 1.3.6.1.4.1.14519.5.2.1.7009.2401.158401284359401547777840263080 | Philips Medical Systems | acrin\_flt\_breast | CT | -4 | |
| 17 | 1.3.6.1.4.1.32722.99.99.315391434416455128958547012718014023683 | Philips | nsclc\_radiomics\_genomics | CT | -4 | |
| 18 | 1.3.6.1.4.1.14519.5.2.1.7009.2401.128272705827469658312679193419 | Philips Medical Systems | acrin\_flt\_breast | CT | -4 | |
| 19 | 1.3.6.1.4.1.32722.99.99.154854822987323366648376936102077390994 | Philips | nsclc\_radiomics\_genomics | CT | -4 | |
| 20 | 1.3.6.1.4.1.32722.99.99.53827318715475830435474154358410860035 | Philips | nsclc\_radiomics\_genomics | CT | -4 | |

There is also a recent related issue in OHIF about this: [[Bug] Multiframe DICOM negatiive Spacing Between Slices not handled · Issue #4352 · OHIF/Viewers · GitHub](https://github.com/OHIF/Viewers/issues/4352)

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [August 29, 2024, 8:36pm UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/7 "2024-08-29T20:36:15Z")

</div>

If you would like to see any of the series in the IDC-hosted OHIF v3 instance, you can get series-specific URL using the code below (after installing [`idc-index`](https://github.com/ImagingDataCommons/idc-index) as discussed earlier):

```python
from idc_index import IDCClient

series_uid ="1.3.6.1.4.1.14519.5.2.1.2932.1975.255072988367557196694880426160"

c = IDCClient()

c.get_viewer_URL(seriesInstanceUID=series_uid, viewer_selector="ohif_v3")

```

[https://viewer.imaging.datacommons.cancer.gov/v3/viewer/?StudyInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.2932.1975.277486652714623414151775226101&SeriesInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.2932.1975.255072988367557196694880426160](https://viewer.imaging.datacommons.cancer.gov/v3/viewer/?StudyInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.2932.1975.277486652714623414151775226101&SeriesInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.2932.1975.255072988367557196694880426160)

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [September 25, 2024, 12:32am UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/8 "2024-09-25T00:32:05Z")

</div>

After looking at this in more detail, I’m not convinced that the new GDCM behavior about using the `SpacingBetweenSlices` is actually incorrect. I’ll comment on why in [the ITK issue](https://github.com/InsightSoftwareConsortium/ITK/issues/4794).

For Slicer, the issue has something to do with how non-right-handed direction matrices are handled. If I add this line

```auto
seriesReader->SetForceOrthogonalDirection(false);

```

in `vtkITKArchetypeImageSeriesReader::RequestInformation` then the volume loads correctly. Without it the image loads upside down and the acquisition transform is not able to fix it.

But since that option about orthogonal directions [has been around for six years](https://github.com/InsightSoftwareConsortium/ITK/commit/23436a04c978d176b32775e97d2701d96d6d2dd6) it seems that something else recently has broken the path when this flag is not set, and perhaps that is due to the negative spacing.

I’m not sure when I’ll have a chance to dig into this more so I thought I’d post this note in case @lassoan, @jcfr, @issakomi, or others know more.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [September 25, 2024, 12:43am UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/9 "2024-09-25T00:43:00Z")

</div>

If you suspect that the normalization to right-handed coordinate system causes issues then make sure you use the latest Slicer main version (there were a few versions that did not work correctly) and/or call `vtkMRMLVolumeArchetypeStorageNode.SetForceRightHandedIJKCoordinateSystem(False)` to disable this mechanism completely.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [September 25, 2024, 1:07am UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/10 "2024-09-25T01:07:29Z")

</div>

Yes, I’m testing with the current main branch and I tried removing commenting out the part of the ScalarVolumePlugin that forces the right-handed behavior and it didn’t change anything. I think the issue is in ITK, because when I set `seriesReader->SetForceOrthogonalDirection(false);` I get an identity direction matrix which is correct for this LPS axial IS scan, but without it (the default `true` value) I get a minus one in the lower left.

---

<div class="post-metadata">

**Author:** ![MikhayEeer](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/mikhayeeer/32/18486_2.png) [@MikhayEeer](https://discourse.slicer.org/u/MikhayEeer)\
**Post date:** [October 4, 2024, 6:08am UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/11 "2024-10-04T06:08:00Z")

</div>

I have also meet this problem.  
There is no problem using version 5.6.2. I built version 5.7.0 from the source code. This problem occurs after some DICOM files are imported.  
When I change the -1 of the direction matrix, the DICOM display will be normal, but after using the AI ​​generated model of lungCTsegmenter, the generated segmentation position is misplaced.  
I want to know which part of the source code should be modified to correct the problem when importing DICOM.

---

<div class="post-metadata">

**Author:** ![MikhayEeer](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/mikhayeeer/32/18486_2.png) [@MikhayEeer](https://discourse.slicer.org/u/MikhayEeer)\
**Post date:** [October 4, 2024, 6:09am UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/12 "2024-10-04T06:09:30Z")

</div>

I don’t dare to roll back the code version directly to 5.6.2, because I want to use the py translation fixed in 5.7.0.  
If I roll back the itk version in superbuild to 5.3.0, there are still many related errors.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [October 4, 2024, 1:29pm UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/13 "2024-10-04T13:29:09Z")

</div>

@MikhayEeer I added

```auto
seriesReader->SetForceOrthogonalDirection(false);

```

right after this line:

> <https://github.com/Slicer/Slicer/blob/9c0754c6741e8127c38691895d452d389ee3cd03/Libs/vtkITK/vtkITKArchetypeImageSeriesReader.cxx#L684>

It would be great if you could test it with your data and report back. So far in limited testing it’s been working for me.

---

<div class="post-metadata">

**Author:** ![MikhayEeer](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/mikhayeeer/32/18486_2.png) [@MikhayEeer](https://discourse.slicer.org/u/MikhayEeer)\
**Post date:** [October 4, 2024, 3:14pm UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/14 "2024-10-04T15:14:40Z")

</div>

Thank you very much for your specific solution. I will test this method in the next few days and give you feedback later.

---

<div class="post-metadata">

**Author:** ![MikhayEeer](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/mikhayeeer/32/18486_2.png) [@MikhayEeer](https://discourse.slicer.org/u/MikhayEeer)\
**Post date:** [October 8, 2024, 7:46am UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/15 "2024-10-08T07:46:21Z")

</div>

Thanks for your solution, I have solved the problem successfully.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [October 8, 2024, 12:15pm UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/16 "2024-10-08T12:15:13Z")

</div>

Thanks for reporting @MikhayEeer . @lassoan let’s discuss in the dev meeting but I suggest we go ahead and make this change in the preview version of Slicer and see if we hear of other regressions.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [October 8, 2024, 8:26pm UTC](https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913/17 "2024-10-08T20:26:31Z")

</div>

After some more testing and discussion during today’s dev meeting I’m convinced adding this flag is a good way forward. If anybody notices regressions in the preview builds please speak up since this fix will in the 5.8 release coming the the next few weeks.

> <https://github.com/Slicer/Slicer/pull/7987>
>
> Fixes #7937
> 
> See original report here about a dataset being scrambled that loa…ded well in the 5.6.2 release:
> 
> https://discourse.slicer.org/t/regression-in-the-dicom-data-base/37913
> 
> This corresponds to the change in behavior described here, where spacing from ITK that used to be 1 is now, for example 5 or -1:
> 
> https://github.com/InsightSoftwareConsortium/ITK/issues/4794
> 
> Which is believed to be due to the changes here, which was added so that for Secondary Capture files the spacing would be respected if present:
> 
> https://github.com/InsightSoftwareConsortium/ITK/pull/4521
> 
> However adding this code in GDCM meant that if the SpacingBetweenSlices tag is present, even in a CT, it is being used by ITK to calculate spacing, and also ITKToRAS transforms when trying to orthogonalize the transform.
> 
> Since Slicer doesn't rely on orthogonal IJKToRAS transforms, this change tells ITK to skip that step and instead it relies on the positions and orientations of the slices to calculate the IJKToRAS transform, which is compatible with what Slicer expects.
> 
> This code was tested on both the CT scan with the negative spacing that was reported in the original issue, and on other CT cans without that tag and the geometry matches what was obtained in 5.6.2.
> 
> This change was discussed in the Slicer developer meeting 2024-10-08 and determined to be the best course of action. Further fixes in GDCM or ITK were not pursued because it was unclear whta the correct behavior should be at the library level considering that a negative spacing between slices is technically invalid for CT scans according to the DICOM standard.