After converting Philips DICOM with the october 2016 version of dcm2niix, voxel values in scans have increased by approximately 500 times. This does not happen when using the June 2015 version. This happens for both anatomical scans and EPI's.

Unfortunately I cannot find a download for the compiled 2015 linux version, so I'm now stuck with greatly inflated values; what is causing this? Or are previous versions available to download somewhere?

EDIT: I've discovered a change in the information displayed using spm_vol for the 2015 and 2016 converted images. For the June 2015 version the v_b.pinfo information is as follows:

5.46715497970581
0
352

However, for the 2016 version the following is displayed for a nifti converted from the same DICOM source:

2316.35791015625
0
352

Where:
V.pinfo - plane info for each plane of the volume.
% V.pinfo(1,:) - scale for each plane
% V.pinfo(2,:) - offset for each plane
% The true voxel intensities of the jth image are given
% by: val*V.pinfo(1,j) + V.pinfo(2,j)
% V.pinfo(3,:) - offset into image (in bytes).
% If the size of pinfo is 3x1, then the volume is assumed
% to be contiguous and each plane has the same scalefactor
% and offset.

So the scaling seems to be indeed off by a factor of (2316/5.5) 421.

I am not familiar with the viewer you are using, do you see different values in MRIcroGL and SPM? I wonder if your viewer is not taking the rescale slope and intercept into account. I suspect that the issue here is that your data exceeds what can be stored in a signed 16-bit integer (e.g. the DICOM data is UNSIGNED 16-bit, but this is not a common NIfTI format). In this case, there are different strategies to preserve precision. Feel free to send me a sample dataset by personal email (e.g. send link to dropbox). A full report from fslhd would also be useful. By the way, there may also be differences in PAR/REC conversion as my software tries to convert the float value to NIfTI rather than the display value (as described here http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3998685/).

I used Mango to give a quick impression of the inflated values; but these also appear when viewing the images with SPM. The same DICOM file converted using the june2015 version shows identical values as the raw DICOM (with intensity in SPM expressed as Y = 1X), whereas a conversion using the oct2016 version yields inflated values (for instance; intensity Y = 35 X, where this number can go up to 500). This intensity factor is revealed also when using spm_vol to get v_b.pinfo, where the first value is the 'scaling' factor.

For some scans (like EPI series) the values are interpreted to go up to three million, where we used to have them around 1000/2000. For anatomies values rise to the hundreds of thousands. Of course these are relative values, and the data and unique number of integers remains the same. But we do wonder why suddenly this 'intensity scaling factor' is different between releases. We've used DICOM from two Philips scanners (releases 3.3 and 5.3), and both give us similar results. 

I will prepare an anonymous sample-DICOM with two converted nifti files to share.

I've uploaded a simple anatomical scan from a Philips release 3.2 scanner.

https://dl.dropboxusercontent.com/u/2777...

Also included two nifti files, one converted with the june 2015 version and one with october 2016. When looking at the two files with spm_vol, the data is as follows:

June 2015:
v_b.pinfo

• 1
• 0
• 352

Maximum value (max(max((max(y_b))))): 535

October 2016:
v_b.pinfo

• 93.9043
• 0
• 352.0000

Maximum value (max(max((max(y_b))))): 50238.7907

So the scaling factor is altered in the newer version, resulting in much higher values; my question is why this is different between versions of dcm2niix.

Hi-

Thanks for the example. This demonstrates that the recent version is correctly scaling the image intensity use=ing the formula provided by Philips. For most MR modalities (T1, T2, T2*) the image brightness is relative, and there is no need for precise scaling. However, this can be important for some other modalities (ASL, DWI). Therefore, recent versions of my software preserve this information. 

When you run recent versions of my software with your sample you will see this:
  Philips Precise RS:RI:SS = 4.73675:0:0.0106491 (see PMC3998685)
And if you view the DICOM header with a tool like Osirix you can see the values:
 0040,9224 RealWorldValueIntercept 0
 0040,9225 RealWorldValueSlope 4.736752136752137
 2005,100E ScaleSlope 0.01064914

If you open a PAR/REC header you will see the Phiips description of these values
 //# === PIXEL VALUES =============================================================
 //# PV = pixel value in REC file, FP = floating point value, DV = displayed value on console
 //# RS = rescale slope, RI = rescale intercept, SS = scale slope
 //# DV = PV * RS + RI FP = DV / (RS * SS)

So to convert your pixel values to floating point values you need to multiply them by 93.9043. That explains why the NIFTI header now reports a rescale slope of 93.9043.

Dear Chris, 

Using your tool to convert a Philips ADC map from dicom to nifti (Chris Rorden's dcm2niiX version 10oct2016 (32-bit Windows))  I get this:

Philips Precise RS:RI:SS = 3.01783:0:0.0042949 (see PMC3998685)

Looking into PMC3998685 I can find that the final equation used to transform stored values (PV) into the final values (FP) is:

FP = PV ·(1/SS) + RI/(RS·SS) = PV · scl_slope + scl_intercept.

The scl_slope (1/SS) and the scl_intercept  (RI/(RS·SS)) values written in the nifti file by your tool agree with that definition, but if I get the FP values using the PV values written in the raster I don't get the FP values obtained with other tools (DWIConvert and mcverter, which perform this operation and save a nifti file with scl_slope=1, scl_intercept = 0 and FP values in the raster). In order to make your nifti agree with the other two I need to use FP = PV · 1/scl_slope.

I'm pretty sure that the correct values are the other two because I'm working with an ADC map and those are which make sense.

Am I missing something?

Thanks for sharing your tool.

I don't have a Philips system, and the equations were provided by others. If you want to send me a sample dataset (send dropbox link via private email) I would be happy to examine it. Otherwise, you can make the required modifications yourself to the function PhilipsPreciseVal() in nii_dicom.cpp and submit a github pull request. It sounds like you are suggesting that the line "d.intenScale = l1-l0;" needs to be re-written as the reciprocal, e.g. reading "d.intenScale = 1.0f/l1-l0;". You would want to check that.

I've sent you an anonymized DICOM slice.

To be clear, this is a problem with your vendor (Philips), not my software. They list the formula for precise scaling in the header of every PAR/REC file. Further, this precise "Float" value is often recommended over the "Display" value (see PMC3998685). Since Philips created this anomaly from the DICOM standard, they need to be consistent in how they support it. It clearly creates confusion is a user needs the display values for some situations and the precise float values for others. If Philips believes that the display value is the best solution, they only need to store SS as equal to RS. In cases where this is not happening, they are explicitly stating that the FP is a more precise answer than the DV. Having said this, I think in the real world this will matter very little. The raw data is identical, regardless of the scl_inter and scl_slope saved in the NIfTI header. Further, the raw MRI signal is relative, so the difference in scaling factors will not influence the results you get when deriving values from the raw data. I believe you will get much better derived values (FA, MD, ADC, etc) after pre-processing your raw data using TOPUP/EDDY rather than relying on the derived values generated by the scanner.

Regardless, to help users out, Github includes a new version of my software that allows the user to demand the DV scaling instead of the scaling FP. To do this, add the parameter "-p n" to disable precise scaling.
 ./dcm2niix -p n ~/tst_parrec
Further, I have updated the BIDS text file to report the Philips scaling parameters (SS, RS, RI) as well as whether the precise or display value was stored in the image. 

I really hate adding this option to my software, as I am sure many users will wonder when they should use this option. Again, for people processing their own data, this choice should not matter. Further, I wish to emphasize that the vendor really needs to clarify this, we are at the mercy of the images they generate.