[Import] data with irregular slice spaces can't be opened

[mathildemerle]

MUSIC n’arrive pas à ouvrir les données de UMich 152 (CT et MR). Osirix y arrive.

Note : quand on essaie de reslicer avec Osirix, on a ce warning:

[fcollot]

To be more precise: MUSIC opens the data but the result is incoherent.

[fcollot]

After checking this out I found that ITK does not implement images with irregular spacing. This was supposed to be added to ITK4 (https://itk.org/Wiki/ITK_Release_4/Image_Class_Hierarchy_Refactoring) but didn't make it. Since MUSIC uses ITK for its internal image format, we can't work around this easily.

[msermesant]

I think .01 mm differences are probably negligible, we could force the constant spacing, and eventually later add this to the reformat workspace so that we can also compute a proper interpolation on a regular grid when the input is like this.

[fcollot]

I was about to suggest transforming the input data to a regular-spaced image (which will probably require a bit of work) but if you think we can just ignore it for now, then the solution would be to fix the NRRD reader so that it finds the correct slice boundaries. I'll work on it.

[fcollot]

(and we can add the interpolation later as you suggest)

[fcollot]

@msermesant It seems ignoring the variable spacing means removing the use of ITK's NRRD reader and writing our own. This is going to be too much work to do now. We found a solution with Hubert by converting the image from RGB to grayscale in Osirix, which then allows reslicing it and exporting it. The resulting image can be loaded into MUSIC but the values are not in the usual CT range, resulting in some problems in the pipeline (in places where it supposes the lowest value is -1024). To fix this I am changing the script.

[msermesant]

I don't see how the NRRD reader is involved, as we are supposed to receive DICOMs? My understanding was that in the DICOM import we were detecting when multiple slices had the same origin, with a translation along one axis, in order to reconstruct a 3D volume. There should be a check somewhere to see if the spacing is regular, this check probably fails so the 3D reconstruction fails?

[msermesant]

Actually it seems that in itkDCMTKImageIO.cpp there are already loops to try to correct for such small changes, with sometimes a 10% error bound:

//Forcing sliceLocation to follow affine fucntion a*x+b, where a is the z-spacing // b is the position of the first slice // x is slice index (not used, just for explanation) //Prevents from some sorting issues (sequences not being recognized because of tiny sliceLocation difference)

   Z-spacing is determined by the ImagePositionPatient flag. Compute the distance between
   2 consecutive slices and project it onto the acquisition axis (normal of the ImageOrientation).
   Average it over all slices, use a 10% margin to distinguish between volumes in case of 4D images.

[fcollot]

The imported file is stored as an NRRD file. I was supposing the import succeeds in writing a proper file, and that it is the loading of this file in MUSIC that fails reading the data properly.

[fcollot]

(I forget why I came to that conclusion) Anyways I'll look into the code you mentioned.

[fcollot]

@msermesant After further testing it seems it's not the spacing that poses a problem but the RGB mode of the image. I converted the image to grayscale in Osirix, but keeping the irregular slice spacing, and it loads fine in MUSIC.

[msermesant]

OK, I did not know CT and MR could come as RGB DICOMs... we should investigate why. It should be noted that the MUSIC volume does not preserve the irregular spacing, as we construct a 3D array with only one z-spacing. We should probably have a warning like Osirix to warn the user of this.

[fcollot]

https://github.com/Inria-Asclepios/medInria-public/pull/320 fixes the loading of RGB images. Now there are two more issues to address:

• Warning the user of irregular spacing
• Handling of RGB in MUSIC

For the second issue, there are two solutions if we want to be able to use the RGB images in MUSIC:

• Extend our processes (filters etc.) to accept RGB images
• Add functionality to convert RGB to grayscale

[fcollot]

I found that MUSIC calculates slice spacing differently than Osirix. Both of them calculate the difference between the position vectors of two consecutive slices. Osirix then takes the magnitude of this vector as the spacing, whereas MUSIC projects this vector onto the slice normal first. When two consecutive slices are slightly offset on the X and Y axes, this gives a different value in the Osirix calculation, but the MUSIC spacing stays the same.

I made a beautiful diagram to illustrate this:

[fcollot]

So the result is that MUSIC doesn't even detect a different spacing as does Osirix simply because it calculates it differently (and in my opinion it is more correct).

[msermesant]

OK. thanks for looking into this, the medInria DICOM importer has several heuristics that we should revisit at some point to validate them or see if they are still necessary by looking at the different DICOM importers freely available.

[fcollot]

(I'm only guessing that this is what Osirix does but when I calculate the spacing this way I get the same values as Osirix displays in the error)

[fcollot]

@msermesant The clinicians received another RGB image yesterday from a different center, so to avoid having them using Osirix each time they receive such an image I'm adding a filter to MUSIC to convert RGB images to grayscale. In the pipelines we can easily detect RGB images and apply the filter so that it's transparent for them.

[msermesant]

great. I really don't understand why it is stored as RGB, we need to see this at some point. the conversion is not trivial because not unique so we need to check we don't loose information.

[mathildemerle]

The issue seems to be solved. If a problem appears concerning this topic, we could create an issue on medInria side