SimpleITK doesn't seem to apply rescale intercept/slop

I’m using the SimpleITK API for python to load medical images in DICOM format (PET and CT). However, it appears that SimpleITK doesn’t apply the rescale slope and rescale intercept. My code right now is:

import SimpleITK as sitk

root_pet = 'path_dicom_files'

reader = sitk.ImageSeriesReader()
dicom_names = reader.GetGDCMSeriesFileNames(root_pet)


imagePET = reader.Execute()
pet_array = sitk.GetArrayFromImage(imagePET) 

However, the range is: [-31796.78, 31074.89], but it should be [0, 4883997.44]. Can anyone help as to why the PET image is not rescaled? It seems like it’s still in the int32 format right now.

Hello @malteekj,

I don’t think that is the problem (not applying slope intercept), as we have used SimpleITK in the past to read PET images. Can you possibly share the data so that we look into it? Otherwise we have no way of pinpointing the problem.

Finally, given the range of values you provided the image pixel type is likely float32, but not int32.

Hi @zivy,

Thanks for the answer. I have uploaded a sample PET image (159 slices):

The file is a PET image of a 2 mice with subcutaneous tumors.

Hello @malteekj,

I just tried the following minimal example (not recommended as assumes a single series in the current working directory) and it reports a range of [0, 4883997.44304984] for your volume:

import SimpleITK as sitk


image = sitk.ReadImage(sitk.ImageSeriesReader_GetGDCMSeriesFileNames('.'))

Which version of SimpleITK are you using? Possibly there is a bug in your code reporting the min/max of the data? As that wasn’t provided, I am only guessing here.

I have tried to update simpleITK and apply your code, and I get the same results as you now. Thanks for the help!

1 Like

There is one empty file 1.2.826.0.1.3417726.3.798598.20201008132235010.dcm with slope/intercept 1/0 and all values are 0. You can try to remove the file, it will not break uniformity of the image (it is edge). May be it will work better without the file, such files sometimes make difficulties with calculation of output pixel type and it is already not easy for PET, because for every slice may be different slope/intercept. Didn’t try with SimpleITK, not sure it helps, but FYI.

in my app min/max is exactly the same as reported in above post [0, 4883997.44304984], output data type is double.

Sorry, off-topic, not related to user question
@zivy could you kindly test what min/max values you get if the same series is opened in multi-frame DICOM file (converted to Legacy Converted Enhanced PET Image Storage with D.Clunie’s java class). I am afraid there is a bug. Thank you.

Edit: GDCM takes for multi-frame file slope/intercept from Shared Functional Groups Sequence or 1st frame in Per-frame Functional Groups Sequence and applies to the whole image, but they are different for every frame (specially PET). S. here and here.

Hello @mihail.isakov,

Thanks for looking into this. Given that this is a GDCM issue, please post it on the gdcm-developers mailing list.

@zivy Thank you. Sorry, my projects are not affected, i’ll not do anything with the issue in the near future. It was just FYI, because ITK/SimpleITK IO are probably affected.