Wrong Bit Depth

Hi there,

I have a problem reading DICOM with ImageJ
Here is a sample DICOM to reproduce the problem : https://we.tl/t-JLR0Ihg9Za

If I open these images with ImageJ I have error message saying “wrong bit depth; 16 expected, 32 found” and I got missing slices in the stack(one part of the stack is duplicated in place of missing slices).

If I select " open as 32bits float" or “Ignore rescale slope” in the DICOM option then the reading is OK, all images are in place.

The reading was fine before 1.52i, Could it be a regression somewhere ?


Just to add a clue, when I downgrade to IJ 1.51, everything goes back to normal

By default, the DICOM reader in ImageJ no longer ignores RescaleSlope values not equal to 1.0. You can revert to the previous behavior by enabling “Ignore Rescale Slope” in Edit>Options>DICOM. If you do not see this option, upgrade to the current version (1.52n) using the Help>Upgrade ImageJ command.

1 Like

Dear @wayne,

It’s good that the rescale slope is applyed however I think there is a more important problem.

In the sample I set, if you open it without checking “32 bit” or “ignore rescale” slope the opened stack is wrong (the images itself are wrong)
Starting with the stack size, I just drag and drop the folder to open it as a stack.

With 32bit selected I got a stack of 234 images (which is the correct number)
Without 32bits (and without checking ignore rescale slope) the stack is 187 images so some images are lost during the reading

If I check 32 bit OR ignore rescale slope I got back 234 but with neither of this option the reading of DICOM has a problem and slices are missing (without generating any error message)


Dear @wayne,

I figured that when I open the folder by drag and drop I got 47 log message saying
“wrong bit depth; 16 expected, 32 found”
These 47 message correspond to the missing slice during opening (234 when 32 bit activated but 187 without).

So the reader are rejecting some slice.
These slice comes from the same acquisition from the same PET device, I don’t think there is really some slices in 16bit and other in 32 bits (I don’t know how to check but I don’t think it is possible to have in a same dicom series different 16bit/32 bit encoding)

Best regards,


This bug is fixed in the latest ImageJ daily build (1.52o8).

In general Pet Ct problems are problems with our software and we shouldn’t bother you before doing our homework. In this case I knew nothing of the problem.

This morning I sat down with my debugger to see what is going on. The stack has 234 slices from 0 to 233. Most of these slices are arrays of shorts but the following:
109 -> 140
162 -> 167
184 -> 186
194 -> 198
are arrays of floats. I expect the stack to be a uniform type, either all shorts or all floats.
I clicked the ignore slope scale and looked again at the rescale slope factors. Most to them are 1.0 but there are exceptions where the factor is greater than 1.0. These exceptions occur at precisely the locations where shorts are replaced by floats.
Presumably in 1.52i they are all floats which is the reason that happens to work.
I don’t think you intended to mix shorts and floats. Is that correct?

From my point of view it is still easier, and more memory efficient to use the check box and leave the data “as is”, but the user is the one who decides, not us.

If the rescale slope can’t be applied in 16bits wouldn’t be better to not apply at all if 32 bits is not selected ?

I think it would be closer to what it was before (I guess the rescale slope have never been aplied before the introduction of 32bits DICOM).
So it would have only 1 option to open dicom in 32 bits that will have the rescale slope calculation but not the 16 bits (to not break image reading)

By default, the DICOM reader applies the RescaleSlope when it is not equal to 1.0, and this requires conversion to 32-bits. If a series has mixed RescaleSlopes some images can open as 32-bit and others as 16-bit. The latest ImageJ daily build (1.52o8) works around this problem by converting all images in the series to 32-bit.

I didn’t realize you intended mixed bit depths.
It is my problem and I will fix it on my end.

This problem is fixed in the latest ImageJ daily build (1.52o8).

Thanks Wayne,
This morning I checked the latest daily build. Yes, the problem which Salim reported is gone. I had also made a fix for the official version, so it works no matter what.
This is much nicer than the dark days where without a work around we were blown out of the water.

Thank you so much,
Didn’t get the time to try but seems a very good solution !