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
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. But I am not sure, just FYI. cc @dzenanz
dciodvfy:
Error - Illegal negative value - SpacingBetweenSlices = -1
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)
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.
Yes Slicer Stable (5.6.x) uses ITK 5.3.0 while Slicer Preview (5.7) is using ITK 5.4.0.
For convenience, to download the series mentioned by @rkikinis, you can do this:
$ 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.
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
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 as discussed earlier):
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")
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.
For Slicer, the issue has something to do with how non-right-handed direction matrices are handled. If I add this line
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 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.
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.
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.
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.
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.
@MikhayEeer I added
seriesReader->SetForceOrthogonalDirection(false);
right after this line:
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.
Thank you very much for your specific solution. I will test this method in the next few days and give you feedback later.
Thanks for your solution, I have solved the problem successfully.
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.
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.