Philips Enhanced with varying rescale slope and intercept

[neurolabusc]

I have been alerted that new Philips research DWI sequences can save different rescale intercept (0028,1052) and rescale slope (0028,1053) values for different slices in a 4D enhanced DICOM dataset. This is legal in DICOM, and in fact provides an elegant method to maximize precision for the INT16 storage. However, these datasets can not be directly saved to NIfTI, as a single scl_slope/scl_inter is used for the entire 3D/4D file. At the moment, dcm2niix detects this variability and saves each slice as a separate NIfTI image. This is technically correct but not useful. These images should be converted too FLOAT32. This will require twice the disk storage, but will preserve the image scaling information.

[drmclem]

Hi

For information - this option has been available on the Philips systems for quite a few releases (and not just for DWI) but is a hidden option for research only and needs to be manually set by the user for any scan where it is required. Users should be aware that this will cause problems with certain tooling (for example the help text states that MPR will not be possible with this option on).

Matthew

[neurolabusc]

@baxpr has provided a sample Philips Enhanced DICOM format where image intensity is scaled differently for each 2D slice. The image below shows the issue: the bottom row shows an in-plane slice, while the top row shows an orthogonal slice. The left row shows the image if the slice-by-slice scaling is ignored, while the right image adjusts intensity for each slice. Notice the top and bottom slices (where there is poor SNR) show bright signal in the uncorrected image, whereas the right panel shows that these slices are relatively dark.

I am submitting a development build of dcm2niix that handles these images. However, the opportunity for regressions is large and I do not have access to many Philips datasets. I would be grateful if Philips users could test this out (@captainnova has helped in the past).

The big issue is that Philips DICOMs can store slices in random order (presumably when they come from a parallel reconstructor). dcm2niix needs to segment series with different properties (trigger time, echo time, phase/real/imaginary/magnitude, etc) while sorting fMRI and DWI data into the correct volumes. Often different properties have different scaling factors (e.g. phase map will be -pi..pi, while magnitude image will be different). dcm2niix tries to losslessly preserve 16-bit integer data if the intensity scaling is consistent within an output image, and only resort to 32-bit float conversion if the intensity scaling varies within an image.

I have tried to make both PAR/REC and DICOM conversion handle this gracefully. However, many aspects of this are untested.

I have also created a regression testing repository dcm_qa_enh checks enhanced conversion, though it does not include any with in-slice intensity variation (the example I have requires too much disk space for GitHub).

[drmclem]

Hi
I think this is one to think about carefully - this is not standard behaviour and has been specifically overridden by the users of the system and acutually is not a well known hack (and will break for example some of the on scanner processing) so not sure how much of an issue it is in real life and whether other users would be able to reproduce it (it requires privilegde access to enable). For users where cross scan scaling is required to be consistent be recommend converstion to float and to process the scaling at load time. I might be tempted to suggest that if you detect that scaling is different within an image type that you just force float.

The alternative would be to "undo" the variant scaling and scale everything to the worst case.

Matthew

[neurolabusc]

I am closing this issue. Hopefully my kludge does not have unintended consequences. I would caution users to heed @drmclem's advice to carefully consider enabling this option for sequences.