Variation in file organization and sidecar between classic and enhanced DICOM (Philips)

[parekhpravesh]

Hello,
We are acquiring data using Philips 3T Ingenia and have saved both classic DICOM and enhanced DICOM for the same subjects. Specifically for fieldmap data, we are saving the phase and magnitude images (two different echo times). On using the 20171215 build to convert to NIfTI, we noticed the following:

1. For classic DICOM

• Resulted in two 4D nii files corresponding to each echo
• The first volume is the magnitude image and the second volume is the phase image
• Two JSON sidecar files are created (one for each echo time)
• The sidecar entry ImageType shows: ["Original", "Primary", "M", "FFE", "M", "FFE"]
• For the first echo, there is no sidecar entry for EchoNumber

2. For enhanced DICOM

• Resulted in four 3D nii files all marked as echo2 and suffixed with _ph_x where x = 1:4
• A single JSON sidecar file is created (marked as echo2)
• The sidecar entry ImageType shows: ["Original", "Primary", "PHASE", "MAP", "P", "FFE"]
• The PhilipsRescaleSlope and PhilipsRescaleIntercept values, and the PhilipsScaleSlope values are different between classic and enhanced DICOM
• There is a minor difference in the PixelBandwidth: enhanced results in 1009.29 and classic results in 1009.
• The sidecar entry AcquisitionTime is different between the two: 17:25:22.270000 (enhanced) and 17:25:35.075000 (classic)

I have also noticed this variation AcquisitionTime and PixelBandwidth for other modalities (like T1w images). What could be going on? Is this a Philips specific problem?

Look forward to your thoughts on this.

Thanks and Regards
Pravesh

[neurolabusc]

Hello-
I suspect these issues are related to 165 and 168. I do not have access to a Philips system, so either you can create a patch and submit a pull request or share a sample dataset with me (e.g. send a personal email to me with a link to a zip archive on dropbox). The Philips enhanced mode is very complex, and Philips stores contradictory values in standard DICOM tags. I think this is technically legal - as the private use of public tags is encapsulated in private SQs. However, detecting that a tag indicates a private SQ is difficult, in particular if the DICOM has been saved as implicit VR. The problem is solvable, but we need a good sample of datasets, some solid development time and a thorough amount of validation. Many of the minor differences you report are probably just rounding errors or internal vendor changes. You can always open the DICOM headers up with a tool like Horos and determine how Philips is specifying the same values in different storage formats.

[parekhpravesh]

Thank you for your reply.
I will email you links to two zip files having classic and enhanced DICOM acquisitions for the same subject. We have a Philips scanner at hand with a reasonable degree of flexibility. I would be more than happy to provide various kinds of files that might be needed and to test out any fixes. I will check up on the rounding errors and report back! Thank you!

[parekhpravesh]

Hello,
Another thing that I just observed: when using enhanced DICOM, the magnitude images (of fieldmap) have all got negative voxel intensities. This behaviour persists irrespective of using Philips precise or display value.

[drmclem]

Hi
Not sure of your source data but if this is a phase map you are referring to the values may well be natively scaled to from -pi to +pi and so negative values can be expected.

If it is fieldmap however from the the product B0 mapping sequence then this will be deviations in Hz agan, could be -ve.

Matthew

[parekhpravesh]

Hi @drmclem,
I was referring to the magnitude image of the fieldmap (we are saving both phase and magnitude images); the phase images are the ones that are scaled between -pi and +pi (note that phase images are only scaled between +/- pi when using Philips precise values and not the display values). I agree that negative values are expected in the magnitude images. However, in the present case, the entire image (apart from five voxels) have negative values which seems a little strange. I do not see such behaviour when I am using classic DICOM though (none of the voxels have negative intensity in this case).

[neurolabusc]

Should be fixed in v1.0.20180325.

@parekhpravesh please test this. Note that your DICOM images were heavily modified, apparently by a Matlab anonymization script. These modifications obscure several Philips features. For example, there are no public records for slice positions, so there are probably small errors in the origin estimates. I assume these will be ~0.5 voxels and so have no impact. However, for archival work I would check the providence of your images and make sure you store data as generated by Philips.

[parekhpravesh]

Thank you! I will test the release and report back.
I had used the dicomanon function of MATLAB to anonymize the DICOM files before sending them over...we have all the raw DICOM files so it shouldn't be a problem. I will be happy to share non-anonymized DICOM files if they are needed.

[parekhpravesh]

The Windows version is not working correctly; it crashes after detecting the number of DICOM files. However, the Linux version is working. Here are some observations:

• File names are prefixed with classic/enhanced
• For survey scans (not that they are of particular interest):
  • Classic DICOM results in three files each having multiple slices belonging to one orthogonal view
  • Enhanced DICOM results in one 4D file with each volume having one slice in all three views
• For diffusion images:
  • The b=0 image is placed as the first volume in classic DICOM while the same image is placed as the last volume in enhanced DICOM (the bvec file correctly marks first and last entry as zero respectively)
  • For this test dataset, there were three kinds of diffusion files: acq-fwd_dwi, acq-rev_dwi, both having 8 volumes, and one full acquisition
    • classic DICOM NIfTI are named as classic_acq-fwd_dwi and classic_rev_dwi_e1
    • enhanced DICOM NIfTI are named as enhanced_acq-fwd_dwi and enhanced_acq-rev_dwi
• For fieldmap images:
  • Classic DICOM results in two 4D files with the first volume being magnitude and second being phase image
  • Enhanced DICOM results in four 3D files with e1 and e2 added to file names (_ph added to phase images)
  • Magnitude images
    • The intensities of magnitude images are different between classic and enhanced DICOM
    • The origin of classic is set to (-2,1,-1) while enhanced is set to (0,-1,1) (origin seem to be consistent for other image types between classic and enhanced)
  • Phase images
    • The intensities of phase images are very different between classic and enhanced DICOM
    • The origin shift is the same as above
    • For classic DICOM, the phase image is wrongly scaled with extremely high intensity values (min = -1.7850e+07, max = 1.7850e+07)
    • For enhanced DICOM, the phase image seems to be correctly scaled (min = -3.1416, max = 3.1405)
• For T1w scans:
  • No differences between classic and enhanced DICOM
• For functional images:
  • No differences between classic and enhanced DICOM

Observations on reviewing the fieldmap JSON sidecar

• The ImageType field (for classic DICOM) reports ["ORIGINAL", "PRIMARY", "M", "FFE", "M", "FFE"] for classic DICOM; however, this entry should (most likely) be ["ORIGINAL", "PRIMARY", "M", "FFE", "PHASE", "FFE"] corresponding to the 4D volume file having first volume as magnitude and second volume as phase image
• The ImageType field (for enhanced DICOM) reports ["ORIGINAL", "PRIMARY", "PHASE", "MAP", "P", "FFE"] for both the phase and magnitude images

[neurolabusc]

@parekhpravesh thank for your thorough testing. It has led to two improvements:

• @ningfei increased stack reserve size to restore Windows compatibility.
• I now detect "Phase" in the image type to separate out Phase and Magnitude images for classic Philips (similar to how these images are separated for Siemens and Philips Enhanced).

As far as I can tell, the other variations you describe seem to be inherent to the source images. Philips simply stores slightly different information in the enhanced and classic images. Thanks again for providing these images, they were instrumental in developing this release.