dcm2niix reverses Philips PET time series

[elijahrockers]

The order of frames of dynamic scans acquired on Philips PET Gemini TOF is reversed by dcm2niix. Most likely it is due to "creative" use of the headers on their part..

[neurolabusc]

Thanks for this example. There are two issues here:

1. The order of the image instance number (0020,0013) is reverse of the AcquisitionTime (0008,0032). I have never seen this before, and this means the images appear in the reverse order in most DICOM viewing software (not just dcm2niix). When you can't rely on the instance number, you have to question what other parameters are borked. While this may technically be legal in DICOM, it is at the very least obfuscation. From my perspective, this is not a problem with my software (and the plethora of other DICOM viewers), but a problem with the source data. Hopefully the vendor can fix this on their end.

2. The time between volumes is not consistent. That makes perfect sense for PET scans, but the images can not be saved as a 4D NIfTI, as NIfTI requires equidistant samples. This could be saved as a series of 3D NIfTI images, but you will have to do some leg work to work out the volume timing. These images also will not work with off-the-shelf NIfTI tools like SPM. I assume you will work out your own scripts to compute the mean signal and temporal dynamics. But these are atypical for the NIfTI format. If your goal is to generate a mean signal for all the volumes in a session, preserving the slice order is not important (e.g. you can use a script like nii_mean_stdev), though you may want to weight by time between these.

For the moment, I have added a basic detection system, which will alert the user to these anomalous images: Warning: Images sorted by instance number [0020,0013](1..2430), but AcquisitionTime [0008,0032] suggests a different order (141600..125100)

[neurolabusc]

Paul Morgan for noted that PET scans can describe image number with 0054,1330. In the example dataset 0054,1330 provides the correct slice order while 0008,0032 does not. My sense is that your example is technically legal: 0020,0013 is unique for each image, even though it is not meaningful. However, I would strongly encourage you contact Philips and ask them to use a sensible 0020,0013 as many tools display images using these values. I have uploaded a patch that sorts based on 0054,1330 if this tag exists and the modality is PET.

I have also added some logic that detect variable time intervals between volumes. In the case where timing is not consistent, it will save one volume for each time point (as NIfTI assumes regular timing between volumes) and provide a warning message that provides the onset time. For the sample data you will see:

Warning: Creating independent volumes as time between volumes varies
 OnsetTime = [ 0 30 100 130 200 230 300 400 500 600 800 5000 5500 6000 6500 7000 7500 8000 8500 9000 9500 10000 10500 15000 15500 16000 16500 ]

I think this patch will close this issue, but please test carefully for unintended consequences. Dealing with these variations makes the code more complicated and harder to maintain. The vendor should be admonished.

[elijahrockers]

Generally most PET processing software that I've worked with acknowledges that the .nii file doesn't have timing information and allows us to specify the time intervals, so splitting them into individual files isn't really necessary. It would actually create an extra step re-merging the frames.. maybe we can just leave them together?

This is not the first time we've had problems with Philips, sometimes catastrophic. Our institution is replacing our scanners with Siemens in the near future, in part due to frustrations with critical elements of their system

[drmclem]

Hi
It should also be noted that (0020,0013) has changed definition - it used to be "image number" and is now "instance number" see for example dicom standard and is also type 2 so can be empty.

Instance numbers do not require mapping to any spatial or temporal order and that should obtained from other values - see for example stack overflow and this one - it's not even guaranteed to be unique.

Matthew

[neurolabusc]

Matthew,
I believe you are technically correct, and dcm2niix does attempt to use other means when available (e.g. Dimension Index Values, 0020,9157). However, given the number of tools the do sort based on 0020,0013, its historical meaning, and the lack of clarity on any explicit method to display DICOM data, a vendor that does not provide this tag in the order they expect the slices to be viewed is risking profound consequences.

One worries about using such a complex, evolved format that different vendors interpret differently for important health data. Given the ubiquity of DICOM, we are stuck with it. However, I do think everyone would be better off if the top vendors could agree on a core set of features to allow simpler images. A similar thing happened to OpenGL, where features kept on getting added on top of old ones. They then developed a "core" specification, where old features are provided for compatibility but modern developers can use just the streamlined core subset.

[drmclem]

Obviously I agree - part of the problem was that it was never intended as a stand alone file format - it was designed as a communication protocol between servers which is why the disk files were always opaquely named. If you have server you can negotiate your facilities up front before data storage and get the data you expect - whereas file export requires us to store everything that any software might support.

It would be possible to only store the mandatory fields, no private tags and strip out much of the variable items, however then this would not serve the research (who are bascically the users of DICOM files) as we keep getting requests to add more. This in conjunction with the fact that most research tooling is written as a means to an end and often doesn't attempt to implement the standard as whole which leads to, entirely reasonable, short cuts.

[neurolabusc]

I think the vendors could come up with a core specification that would allow them to store private data and yet make it far easier (and faster) for typical tools to parse the datasets. For example, providing nested dataset SQs with explicit lengths at the start would allow tools that are not interested in those block to skip them entirely rather than having to parse them to work out each element length. Well designed, such a core specification could allow vendors to continue to store verbose data but allow tools to rapidly parse the relevant data.