Volume order for Enhanced Philips ASL

[neurolabusc]

This issue regards Philips enhanced ASL datasets, for example series 302 from this repository. I discuss this in dcm2niix issue 533.

I think dicm2nii and dcm2niix should behave consistently. For Philips Enhanced DICOM with multiple volume dimensions, dcm2niix and dicm2nii currently use reverse order.

The dataset differs in three non-spatial dimensions: Phase (8 post-label delays), Contrast (control or label) and Repeats (averages with the same phase and contrast). I believe this data is acquired in the order P < C < R (so that the first volume is the first phase, control, first repeat, and the second volume acquired was the second phase, control, first repeat). At the moment, based on Dimension Index Values (0020,9157), dcm2niix stores the volumes as R < P < C, and dicm2nii stores the data as C < P < R.

I am not sure that Philips consistently uses a specific order for 0020,9157, but as long as the number of phases (2001,1017) and repeats (2001,1081) do not equal each other (and do not equal two, as there are two possible values for 2005,1429), we could identify these:

(2001,1017) SL 8 # NumberOfPhasesMR
(2001,1018) SL 6 # NumberOfSlicesMR
(2001,1081) IS [30] # NumberOfDynamicScans
(2005,1429) CS [CONTROL] # MRImageLabelType
and
(2005,1429) CS [LABEL] # MRImageLabelType

On the other hand, because of these limitations, I am not sure that the Philips enhanced ASL DICOM is sufficiently specified for us to ensure 100% accuracy in correctly determining temporal order of volumes. Therefore, I can understand if you do not want to change this.

I do think it is important for dcm2niix and dicm2nii to behave consistently. If you do not think that we should reorder temporally, can you justify why you prefer the method of sorting (0020,9157) versus that used by dcm2niix?

The method used by dcm2niix is to sort dimensions such that spatial slices from volume must be kept together, and with this dataset the dimensions are:
Unused \ Slice \ Row \ Phase \ Contrast

(0020,9157) UL 1\1\1\1\0                                #  20, 5 DimensionIndexValues

So dcm2niix sorts as S < R < P < C. On the other hand, if the DimensionIndexValues listed the dimensions as
Row \ Phase \ Contrast \ Slice \ Unused

(0020,9157) UL 0\1\1\1\1                                #  20, 5 DimensionIndexValues

dcm2niix would sort as R > P > C > S. In other words, since all slices in a volume are temporally acquired sequentially for a given set of non-spatial dimensions, we always sort so the slices stay together. Of course, the logic of dcm2niix does not fit the reality of how Philips uses these dimensions any better than dicm2nii.

[xiangruili]

@neurolabusc
I just had a chance to look into the issue, but I started with the classic images first. I did a quick fix (I believe it is more general for the annoying Philips order issue), and dicm2nii gives different result from those in dcm_qa_philips_asl/Ref folder.

series302_after_sorted.xlsx

Attached shows the 4 identifiers, besides InstanceNumber after dicoms are sorted for series 302. It looks right to me, but I am not very confident.

[Edit:] It was series 302, and I added original InstanceNumber to the table. Also there was a typo in last commit and it is corrected now.

[neurolabusc]

Here is a tab delimited text for how dcm2niix should sort this series:

notes.txt

InstanceNumber	Position	Volume	Repeat	ASLlabel	Phase
1	0	1	1	0	1
2	0	2	1	0	2

The data will be sorted so Volume will be dim[3] and ordered position will reflect dim[2]

I do wonder if you dowloaded my repository prior to it being upgraded to the next version, or your last commit changed behavior. It seems to me that the latest versions of dcm2niix and dicm2nii agree on how to convert this data.

[xiangruili]

@neurolabusc You are right. I downloaded an early version. Now the result from both converters agree.
I will look into the enhanced images. Thanks.

[xiangruili]

@neurolabusc
By dicom standard, Dimension Index Sequence (0020,9222) stores the tags and description of meaning in Dimension Index Values. For example, series 302 of the enhanced data has these description for the 5 dimension:
Stack ID
In-Stack Position Number
Temporal Position Index
Trigger Delay Time
Private Label Type
These are clear for human, but may not be ideal for code to infer the correspondence.

I am thinking to ignore Dimension Index Values and use the same identifiers as classic images to sort the frames. How do you think about this approach?

[neurolabusc]

@xiangruili yes there are a couple of solutions that should provide identical results.

Like you suggest, I have chosen to use the same identifiers as classic DICOM for the enhanced DICOM, in the hopes of providing consistent conversion. My own solution for Philips Enahanced ASL sequences is here. Specifically, I rewrite the Dimension Index Values with the same identifiers used for classic images:

dimensionIndexValues[0] = 0020,9057; //dim[3] slice changes fastest
dimensionIndexValues[1] = 2001,1008; //dim[4] successive volumes are phase
dimensionIndexValues[2] = 2005,1429; //dim[5] Control/Label
dimensionIndexValues[3] = 0020,9128; //dim[6] Repeat changes slowest

Since we have very few examples of Philips Enhanced DICOM ASL, it is hard to choose what the most robust solution is for different versions of Philips software.

[xiangruili]

@neurolabusc:
dicm2nii before 2021.10.17 has problem for some enhanced dicom, like the new Canon data. I just updated it, and hopefully it is more reliable now. Here is the idea and current solution:

Different scanner vendors use DimensionIndexValues in different order, even for the common ones like InStackPositionNumber and TemporalPositionIndex. Luckily, DimensionIndexSequence seems always there to indicate the meaning of those indices in DimensionIndexValues. So I am now using DimensionIndexSequence to find out the slice dimension, and leave others as higher dimensions (they all stay in 4th dim in NIfTI for now, since many NIfTI tools, like FSL, don't support 4+ dim).

Due to the NIfTI 4+ dim issue, the practical way is to split 4+ dim into multiple NIfTI file. I am currently following dcm2niix to split echoes and mag/phase/real/imag for regular dicom, but not enhanced dicom yet.