Philips ASL volume order

[neurolabusc]

This is consequence of issue 529 where we never trust instance number (0020,0013) for Philips DICOM images (as they are sometimes assigned randomly rather than matching temporal order. We must therefore decide how volumes should be ordered for ASL data.

For this issue, consider the identical Philips data exported as both classic and enhanced DICOM data.

• Classic DICOM
• Enhanced DICOM

For these datasets, 3D volumes can vary by whether they are label/control, phase number (post label delay). In our example, consider series 30x ASL_MultiPhase where we acquire control label (x2) pairs, with 8 phases (x8) , with 30 repeats (x30) for 480 volumes.

For the classic data, the series number seems to match the temporal time that volumes are acquired. If we do not trust the instance number, we can not extract the temporal order from any single tag, and must sort based on a hierarchical order of properties.

MRImageDynamicScanBeginTime (2005,10a0) and TemporalPositionIdentifier (0020,0100) are identical for all Control/Label pairs and all phases, so they distinguishes the repeat.
TriggerTime (0018,1060) distinguishes Control/Label pairs and phases, but is identical for all Repeats
PhaseNumber (2001,1008) distinguishes phase number

Here are the instance numbers for the first slice of each volume (the jump in instance number from (instance numbers 9..48 are for other slices from repeat 1) :

Instance	Trigger	DynTime	TPI	Phase	IsLabel
1	300	0	1	1	0
2	550	0	1	2	0
3	800	0	1	3	0
4	1050	0	1	4	0
5	1300	0	1	5	0
6	1550	0	1	6	0
7	1800	0	1	7	0
8	2050	0	1	8	0
49	300	0	1	1	1
50	550	0	1	2	1
51	800	0	1	3	1
52	1050	0	1	4	1
53	1300	0	1	5	1
54	1550	0	1	6	1
55	1800	0	1	7	1
56	2050	0	1	8	1
97	300	8	2	1	1
98	550	8	2	2	1

In this example, the series number seems to match the temporal order that volumes were acquired. This seems to be a useful way to store the data as NIfTI images, as it allows one to model motion effects across sequential volumes. So the temporal order is S < P < C < R (slices stored next to each other on disk, then volumes of each phase, then the control label, and the repeats are the most distant from each other on disk).

To complicate matters, the way that dcm2niix currently interprets the enhanced DICOMs is different, as we use the values specified by Dimension Index Values (0020,9157).

So slice 6 of repeat 10 of phase 2 of the control (0) scan will report:

(0020,9157) UL 1\6\10\5\1 

Here, the data is stored in the order S < R < P < C. dcm2niix will detect that slice is shifting the fastest and so order volumes such that Repeat 1,2,3.... are stored next to each other on disk with the Control and Label volumes very far apart on disk. This does not match the temporal order at all, but it does seem to be the order explicitly demanded by the DICOM. I suspect this reflects the fact that (unlike other manufacturers) Philips stores the same slice next to each other on disk.

So the question is:
a. Should classic data be stored so volumes match temporal order ( P < C < R) ?
b. Should classic data be stored to be consistent with enhanced data (R < P < C)?

If we vote for a, should be also order enhanced data in temporal order, apparently overriding the order of 0020,9157? I worry about this option, as a general assumption of dcm2niix is to consider the DICOMs as a truthful recipe for the desired outcome. This also seems like an inherently fragile option.

It does not seem like BEP005 gives us much guidance on how to proceed.

[neurolabusc]

@drmclem how can one infer if a sequence starts with a control or label volume? I note that label and control images for a given phase and repeat share identical AcquisitionTime (0008,0018), Trigger Time (0018,1060,) MRImageDynamicScanBeginTime (2005,10a0) and TemporalPositionIdentifier (0020,0100). In the sample dataset, the control image gets a lower instance number, but we know that the DICOM standard does not require sequential instance numbers, and that Philips often chooses random instance numbers. Therefore, on Philips sequences, is a Control volume always acquired before a Label volume, or is the temporal order impossible to determine from the DICOM data?

[captainnova]

I think temporal order is typically preferable for people doing offline corrections for things like head motion or gain drift, especially if some sort of regularization is involved. However, I understand that any reordering would be on a best effort basis. Although BEP005 does not mention BIDS fields for giving the labeling, phase, and repeat order, it probably should. My perspective comes from dMRI, though, where we are used to the 4D .nii usually being in temporal order, but if not, there's always .bval and .bvec to give us the essentials.

[neurolabusc]

@captainnova the latest development commit (v1.0.20210819) attempts to store Philips ASL volumes in temporal order, regardless of whether they are classic or enhanced DICOMs. For classic DICOMs, the instance number is ignored (though for the samples I have seen, instance number was consistent with temporal order).

There are some caveats, as noted above it is unclear if Philips ASL scans always start with a control image. However, I do not think this is a big issue: ASL motion correct tends to handle control and label runs separately.

So dcm2niix will infer that the order S < P < CL < R (S = slices, P = phases/PLDs, CL = control label, R = repeats). This would be equivalent to creating a NIfTI where the first three dimensions are spatial, dim[4] = phase, dim[5] = control/label and dim[6] is repeat. Consider an ASL series with two phases and three repeats, the 12 volumes will be stored:

Volume	1	2	3	4	5	6	7	8	9	10	11	12
Phase	1	2	1	2	1	2	1	2	1	2	1	2
Label	C	C	L	L	C	C	L	L	C	C	L	L
Repeat	1	1	1	1	2	2	2	2	3	3	3	3

This should work well with BASIL.

However, I only have Philips examples of phantoms, which do not show any actual ASL contrast. Therefore, when converting Philips enhanced ASL the software will emit Warning: Guessing temporal order for Philips enhanced DICOM ASL (issue 532)..

I strongly encourage users who see this warning to visually inspect their data to ensure the data is processed correctly. Here is the method I use, demonstrated with Siemens ASL data from dcm_qa_asl.

1. Load the image with MRIcroGL. Make sure all volumes are loaded (the Preferences value Only initial volumes should be unchecked).
2. Choose Draw/Advanced/AutomaticDrawing to create a sphere that covers a lot of voxels in the center of the brain. The goal is to take advantage of signal averaging to improve the signal to noise. When you are happy with your selection Apply the drawing.
3. Open the 4D Graph at the bottom of the window.
4. Choose Show intensity under drawing to create a new line on your plot showing the average signal in your region across volumes.
5. Inspect the drawing to make sure it matches your expectations. For the example here:
   • Note the very first volume is exceptionally bright relative to subsequent volumes. This first volume must be the M0 image demonstrating strong T1 effects.
   • The subsequent images are ordered in pairs, with the first image in the pair slightly darker than the second: the first image of the pair must be the label, followed by a control.
   • Note the pairs show a staircase effect with six steps, these are the 6 post label delay phases.
   • The staircase repeats every 12 volumes: these are our 8 repeats.
   • Therefore, visual inspection suggests that in this example the volumes have been ordered CL < P < R.

I would be grateful if users with Philips data can validate the performance of this latest release.

[matthew-brett]

Sorry to shoot from the hip here, but - is the idea that the user of a Philips converted Nifti image for ASL should be able to assume that the volumes are in temporal order? To what extent is true for other manufacturers and modalities?

[neurolabusc]

@matthew-brett the challenge is the Philips instance numbers are often ordered randomly (presumably reflecting the order images return from a random parallel reconstruction system rather than the order of acquisition). For enhanced DICOMs, one traditionally relies on Dimension Index Values (0020,9157) to sort the volumes, but with Philips the dimension order does not correspond with temporal order (which explains why dcm2niix and dicm2nii have ordered Philips enhanced data volumes differently).

For other manufacturers, the instance numbers are sequential for a given order, and so converters have a well defined, consistent method for ordering data. It is worth noting that for Siemens this order is not temporal. In the figure I show above note that the control-label pair is given sequential instance numbers with an order of CL < P < R, whereas the temporal order was P < CL < R. However, all tools are unambiguous about the order and so users have a consistent experience.

Tools like FSL's BASIL does not require data to be stored temporally, nor does BEP005.

Since Philips instance numbers are often not sequential in any dimension, each tool must decide some method to organize data, even if Philips DICOMs are underspecified to determine true temporal order (e.g. my solution assumes control images are always acquired before labels, even though I am not sure if this is always correct). I think it matters less what order we decide on, as long as all the tools are consistent, that we are consistent for classic and enhanced DICOMs, and that we describe the chosen pattern clearly to users.

[captainnova]

It now passes the test suite here, thanks, which means that the output ordering is again the same as it was with dcm2niix 20180826 and surrounding pipelines should not need to change.

To get a better sense of actual correctness as opposed to just relative correctness I tried the region method you described with MRIcroGL, but the perfusion signal is very weak in the Philips 4 scan I happened to have in our test suite. It seems to be control-label-control-label, but it is not as obvious as in the example you posted, and probably did not have its post-labeling delay well tuned, etc.. A newer scan (Philips 5.7.1) gave much clearer results.

In short, it looks OK, and as far as I can tell it's ready for release!

[neurolabusc]

@captainnova thanks for checking. To be explicit, the current version provides the same results as classic Philips DICOM where instance numbers follow a logical S <P < CL < R slice ordering. The results of the latest version are different than prior versions that were legacy DICOM with jumbled instance numbers and enhanced DICOM. The new version will consistently generate S <P < CL < R slice ordering regardless of these variations.

Thanks for testing this with real data! The whole community has benefited from your access to huge clinical datasets and meticulous attention to detail.

[matthew-brett]

Thanks for the more detailed explanation. What I was getting at is - how do you decide in general, what order to return the images? For example, in this case, I think what you are saying is that it is possible to work out the temporal order, and therefore it is useful to return them in this order. But I guess that the user has to know that is the order, for this sequence, before using the order of the images. And that, if they have a simular set of images from a different manufacturer, they have to know that the images are not ordered by time.

Is there a way to specify the time order, if the volumes are not in time order in the converted image? Or that the images are in time order?

[neurolabusc]

@matthew-brett For other vendors, the order specified by the DICOM instance number (classic DICOM) or Dimension Index Values (for enhanced DICOMs) is used. These seem to always match temporal order, with the possible exception of the multi-PLD Siemens research ASL sequence. For these vendors, I think all conversion tools handle the data consistently, and therefore the community has a consistent experience.

In contrast, Philips can assign instance numbers randomly, and the hierarchical order of Dimension Index Values does not match the temporal order. In addition, for DTI and ASL the Philips DICOMs are ambiguous regarding temporal order (e.g. we do not have accurate time stamps for each slice). Therefore, it might be useful for the community come to a consensus on how to convert these, and we need to communicate our decision carefully with the community.

For DTI, when instance numbers are sensible, the b=0 volume appears to be the first volume in the stack, however GradientOrientationNumber (2005,1413) suggests it is the final direction acquired. Above I document the ambiguities regarding inferring temporal order from Philips ASL.

The frustrating duality of Philips enhanced DICOMs is that they include an almost overwhelming amount of redundant data across slices, simply extracting the meta-data to ASCII text using gdcmdump or dcmdump tends to generate larger files than the image data. On the other hand, these images contain virtually no information regarding what make the slices in the series unique from each other such as true acquisition time. In addition, many details that are crucial in our field are not included, like phase encoding polarity, Fourier fraction, details for total readout time, etc. So on one hand, the Philips headers are overwhelming huge due to redundant information, and on the other hand they contain much less relevant information than other manufacturers.

[neurolabusc]

Closing issue. dcm2niix should now convert Philips ASL data consistently regardless of instance number and classic vs enhanced DICOM format. Conversion is constrained by our limitations of these sequences (e.g. does control always temporally precede label) and the impoverished nature of these DICOMs. This is as far as we can go until these issues are resolved.