dcm2niix fails to convert Philips resting-state and diffusion DICOM files

[DimitriPapadopoulos]

We have DICOM files acquired on a Philips Ingenia MRi scanner. The resting-state fMRI and the DWI sequences are not properly converted by dcm2niix, although dcm2nii does succeed. The exit status of dcm2niix is 0 and it does not print any error message while converting these sequences. However they look bad visually, see screen captures below.

Fig. 1 - resting-state fMRI DICOM files converted with dcm2niix

Fig. 2 - resting-state fMRI DICOM files converted with dcm2nii

When visualizing the resting-state and DWI data converted with dcm2niix, FSLView complains:

ERROR: Illegal NIfTI file - /volatile/xxxxxxxxxxxx/rest_RESTING_STATE_20111222000000_401
       Zero determinant stored in sform and/or qform that is marked as valid

Any clue?

Please note that these DICOM files files have been anonymized, in theory using this DicomEditor script: dicom-anonymizer.script. However a different anonymization method might have been applied without my knowledge. Indeed I see that the Manufacturer and ManufacturerModelName DICOM tags are missing from these DICOM files, although dicom-anonymizer.script is supposed to keep them. Could that be a problem?

If needed I can provide sample DICOM files.

[neurolabusc]

Yes, please provide an example. You can send it to me directly. I would also suggest you archive and use the raw data from your scanner. Philips DICOM data (and their enhanced format in particular) often confound popular DICOM tools such as anonymization.

[DimitriPapadopoulos]

The raw DICOM data are stored in the PACS of the acquisition centre, but they have to be anonymized before they leave the acquisition centre. In theory they have been properly anonymized (see dicom-anonymizer.script), specifically private tags are not removed. I'll send you the resting-state and diffusion privately.

[DimitriPapadopoulos]

Meanwhile I checked that the DICOM files that are properly converted by dcm2niix are anonymized differently from the DICOM files that cannot be anonymized by dcm2niix, one of the differences being the absence of Manufacturer, ManufacturerModelName and SoftwareVersion among other DICOM tags.

[neurolabusc]

If you can provide a sample of the troublesome dataset I can provide feedback. My email is in my profile picture - it is usually easiest to send a box/dropbox link to the dataset. It sounds like an issue with your anonymization. Please make absolutely sure that the anonymizer is not converting Explicit VRs to Implicit VRs. Be aware that Philips uses a lot of private SQs, and since these are not public (and therefore not part of most DICOM dictionaries), many tools do not convert these correctly. This is one of the reasons Philips DICOM tends to be pretty fragile for conversion.

[DimitriPapadopoulos]

You obviously didn't get my mail. Sending it again.

[DimitriPapadopoulos]

By the way, as far as I know our anonymizer just removes/blanks DICOM tags - it doesn't remove whole private blocks.

[neurolabusc]

I still have not received any message from you. My institution rejects emails with many types of attachments. Therefore, either send a box/dropbox link or consider sending a message to me via gmail (crorden6).

If your anonymizer removes 'blank' SQs, or if it converts an explicit VR private SQ to an implicit VR without the appropriate delimiters you can destroy the context for interpreting the DICOM header. In my experience, many tools preserve the data inside Philips private blocks, but they remove the ability to determine whether public tags in these private blocks refer to public information or are specific to private information. I have not seen your data, but one thing that might explain your data is the fact that Philips uses the public tag Image Position Patient (0020,0032) differently depending on its context (e.g. it has a public definition, but in a private SQ it is used differently).

[DimitriPapadopoulos]

I did send an email (without attachments but instead with a link to an FTP server) to your email address. I'll try again.

[neurolabusc]

The issue is with your anonymization script that removes the manufacturer name. This is a flaw in your data, not with dcm2niix. Different manufacturers interpret some DICOM tags differently. It is important to know the manufacturer to extract this data. I strongly suggest you reinsert this tag if you want your DICOM data to be of archival quality.

As a hack, you can change one line of code in dcm2niix that will allow it to handle your files. Change the line in nii_dicom.cpp from
if (lByteLength < 2) return kMANUFACTURER_UNKNOWN;
to read
if (lByteLength < 2) return kMANUFACTURER_PHILIPS;
and recompile.

This change will have unintended consequences if you remove the manufacturer name from DICOM files created by other vendors.

[DimitriPapadopoulos]

Indeed I was expecting an issue with Manufacturer or ManufacturerModelName. It's just that it used to work with dcm2nii, but I can fully appreciate that the logic in dcm2niix may be different and actually more robust - provided the DICOM files are properly anonymized.

Thank you so much for your help.

[neurolabusc]

The developmental commit will identify the manufacturer as Philips if:

1. Manufacturer tag (0008,0070) is missing or unknown
2. Either tag (0018,9087) is detected (DWI) or the private creator tag (2001,0010) reports Philips.

This is a great and desperate kludge. In my mind, DICOM data that removes the manufacturer tag is not archival quality. Knowing the manufacturer provides crucial context for interpreting data. Different vendors interpret DICOM tags differently. While my older dcm2nii tended to assume data was Philips (since I worked at a center with Philips equipment), the more modern dcm2niix provides much richer meta data by recognizing vendor specific issues. A simple concrete example of the issue is how each vendor uses specific acronyms.

I would urge you to write a script to re-insert the manufacturer tag into your data. The example below provides a template:
gdcmanon --dumb --replace 0008,0070,"Philips Healthcare" IM_2044-no-phi IM_2044.dcm

Be aware that 0008,0070 is a Type 1 DICOM attribute. One could argue that this is no longer valid raw DICOM data.

[DimitriPapadopoulos]

I totally agree with you, we should either retrieve our DICOM data from the PACS and re-anonymize with the updated anonymization script, or modify the existing files by adding back the Manufacturer tag - as well as the ManufacturerModelName and SoftwareVersion tags.

Thank you for the tip with gdcmanon.

The missing Manufacturer can be explained though. The person who wrote the initial anonymization script started with the dicom-anonymizer.script bundled with DicomEditor, which implements the Basic Profile defined in DICOM PS3.15 as far as I can understand.