Questions about warnings

[jbourgin]

Hi,

I have downloaded fMRI data from the ADNI database (http://adni.loni.usc.edu/) and converted DICOM files into nifti format using dcm2niix v1.0.20180622.

Yet, after the conversion, I get some messages I don’t totally understand:

• The first one is: Warning: Assuming 7FE0,0010 to an icon not the main image. I noticed that the files for which these messages occur were not successfully converted by an older version of dcm2niix (the message I got then was “No valid dicom files”). With the last version, the files are converted and seem normal. Yet, I don’t know what to do with this message.

• The second one is: slices not stacked: Study Date/Time (0008,0020 / 0008,0030) varies and Slices not stacked: dimensions or bit-depth varies. I noticed that these messages occur when I process simultaneously the folders of several subjects, but not when I process them one by one. So I suppose that they only indicate that the software realizes that the folders belong to different acquisitions, and splits the slices accordingly. Yet, I wondered if processing several subjects simultaneously may have any harmful effect on the conversion?

• The third one is: slices stacked despite varying acquisition numbers (if this is not desired please recompile). Can you tell me what “acquisition numbers” refers to?

• The last one is: Warning: Weird CSA 'ProtocolSliceNumber' (System/Miscellaneous/ImageNumbering reversed): VALIDATE SLICETIMING AND BVECS. I suppose that this message refers to slice order. Yet, I am analyzing resting state data, thus I do not need to perform slice timing. In these conditions, is this message still relevant?

You will find attached a message (with verbose activated) I obtained for one acquisition and in which the first, third and last messages occurred (Example). I use dcm2niix through MicroGL on Windows 10.

Please let me know if you need further information.

Thanks for your help!

Jessica

[neurolabusc]

• The 7FE0,0010 warning is typically generated by images touched by a GE GEIIS PACS system. For about a decade the GEIIS software would add an icon to the DICOM that actually violated the DICOM standard. Despite being patched, these systems still exist and these borked DICOMs remain common in archival datasets. Hopefully dcm2niix detects and converts these images correctly. However, these images are likely to disrupt other tools. Therefore, this warning is useful to remind users to upgrade their PACS and to give them a idea of the problem if other tools fail.

• Yes, dcm2niix should discriminate datasets from different individuals. dcm2niix will correctly convert a parent folder subfolders that contain each individual (as long as the DICOMs are well behaved). However, if your data is already segmented by participant it will be faster to segment the data one person at a time (so the data is explicitly segmented). When you run huge parent folders that require dcm2niix to sort and segment the contents of the sub-folders both the time required and memory requirements increase.

• You can think of DICOM data from a session as being saved in hierarchical folders: series number (0020,0011), acquisition number (0020,0012) instance number (0020,0013). Consider a typical MRI session: the series might be your T1, fieldmap and fMRI runs, your acquisition number might distinguish the different echoes and reconstruction (e.g.magnitude/phase) images of the fieldmap, and the instance number distinguishes different slices or volumes. In the typical MRI case we want to combine all images from a same series together into the same NIfTI, regardless of acquisition or instance number. Unfortunately, the DICOM standard does not specify how the vendor uses these tags, and some vendors do use the acquisition number for a meaningful distinction (as I recall, this is seen in some GE CT images). Therefore, if you are unhappy with how dcm2niix clumps acquisitions together you can change its behavior.

• The CSA headers are proprietary Siemens DICOM groups that scientists have decoded to infer useful properties about your scan, like the slice order and precise slice acquisition time. However, these headers can sometimes contain information that does not make sense. The two examples I am aware of is if you create derived data (e.g. FA maps) the CSA header does not contain the information expected from the raw data. In this case, you can ignore the warning (as you will always generate better derived images after processing your raw images). The other case is the fantastic CMRR multi-band sequences: in some cases the first volume of a multi-volume sequence contains bogus CSA data. In this case, dcm2niix should get the correct data from later volumes. So this warning provides a starting point if dcm2niix fails to process data.

[jbourgin]

Thanks a lot for your exhaustive response! It's all clear for me now.