Why is latest Fiji opening 16 bit images as 32 bit images

Up until the latest versions of Fiji the option under Edit->Options->Dicom->Open as 32-bit float was always honored. Now for some reason, on certain series, the checkbox choice for this option is being ignored. What has changed and why? Shouldn’t the user’s choice be respected?
This is doubling memory usage as well as other problems which now need a work around.

If possible, could it be changed back to respect the user’s choice?

Did you update to ImageJ version 1.52i?



I am looking now and it is indeed ImageJ 1.52i. Before a couple of updates ago, all was well.

There was a change and Wayne explained the reason for it somewhere, either on this forum or on the ImageJ-list. I actually can’t find the posts.

Perhaps this helps you further: Search for DICOM on this webPage.

Good luck


I contacted Wayne years ago about this change. At that time Wayne agreed to have the default of 32 bit unchecked. I forget things and other people forget things, but options are around so people can choose what they want for their own needs. We shouldn’t start to suddenly ignore the values of the options.

If some application needs 32 bits, the correct way to implement it would be to suggest to change the value of the Edit->Options->dicom value, but to just ignore the option altogether seems wrong in my eyes.
The user’s choice should trump everything else.

Sorry I’m not the correct address for this problem and I only wanted to help with what I faintly remember. Because I never ever had to do with the DICOM-format I’m absolutely incompetent and I can only say that the discussed problem had something to do with the special gray value calibration that, AFAIK originally started with the Hounsfield units and their bipolar range used in CT-imaging.

So please forgive me that I can’t substantially help with your problems and please try to find the posts in which an explanation may be found, or simply ask Wayne to somewhere write down a memo dealing with the import of DICOM images to ImageJ.



Finally I found the relevant thread on the Forum:


Hello Ilan -

If this is related to the side issue mentioned in the thread that Herbie
linked to in one of his replies, then this could be caused by your DICOM
image having a non-trivial “Rescale Slope” (i.e., not equal to 1).

If this is what is going on, it should be the case that with
" Edit->Options->Dicom->Open as 32-bit float" unchecked,
16-bit DICOMS will usually be opened as 16-bit images, but
if they have a non-trivial “Rescale Slope,” they will be opened
as (32-bit) floats, even if the option is unchecked.

Is this the problem that you’re seeing – 16-bit images being opened
as floats even with that option unchecked?

This change was made about a month ago (restoring an old fix of
Wayne’s that got reverted somehow).

Could you check if your DICOM image has a non-trivial “Rescale
Slope”? (You can see this by opening your DICOM image and running
Image > Show Info.... This will show the DICOM metadata, and
you can see if it has a “Rescal Slope,” and if its value is something
other than 1.) Also, could you upload an example image to a file-sharing
site and post the link here?

(If this “Rescale Slope” thing is not the cause of your issue, then
something else is going on, and it would also be helpful if you
could link to an example image so we can look further.)

Regardless, Wayne will be the expert on this, and knows the history
of why these “Open as 32-bit float” changes were made.

My belief (could be mistaken) is that the current DICOM input code
does not properly handle a non-trivial “Rescale Slope” unless it
converts the image to float, so if you need “Rescale Slope” you
might have to live with floats as a workaround, or perhaps you
could scheme up some feature request that would otherwise meet
your needs.

Thanks, -mm

This data is definitely non trivial rescale slope. PET data has been this way since day 1.

I ftp’d the data directly to Wayne as I couldn’t figure out how to add it to the forum.
The link is https://spaces.hightail.com/receive/sRertFeFYe

I hope that I don’t have to live with floats as they take double the space and it could affect the number of studies which can be simultaneously displayed. Multiple studies show disease progression/regression and can be important. In any case it should be the user who decides and we need to respect his decision.

Hello Ilan -

I looked at two of the DICOM images in the .zip file you linked to (the
first and last by alphabetical order). They are indeed 16-bit images with
non-trivial Rescale Slope (i.e., not equal to 1).

As such, with the current version of ImageJ (1.52i) they will automatically
be converted to float when they are read in, regardless of whether the
“DICOM… > Open as 32-bit float” option is set. And with the ImageJ
version from a month or so ago, they would have been opened as
16-bit images (not converted to float), but the Rescale Slope would
have been ignored.

You imply that opening these images in ImageJ used to work for you.
Are you sure that at one time ImageJ opened these images for you
both as 16-bit images, and using (not ignoring) the Rescale Slope?
Could ignoring the Rescale Slope be “good enough” for what you are
doing? I suggest this because I think this was probably what was
happening for you in the past.

Could you give us an ImageJ version number for which this worked
to your satisfaction? Or, if you’re not sure of the version, a date or
date range for when things were working for you?

Wayne would know the long-term history, but recently ImageJ would
lose the Rescale Slope if it opened 16-bit DICOM images as 16-bit.

(The two of your images that I looked at had zero for the “Rescale
Intercept,” so this may not be relevant to you, but, as an aside, if
ImageJ opens a 16-bit DICOM image as 16-bit and the image has
a non-trivial “Rescale Slope,” the “Rescale Intercept” will also be

Thanks, mm

I want to thank you very much for your help with the problem of the OP.

Because the OP works with medical data it is of utmost importance to treat them in an absolutely correct manner. If for whatever reasons an image is incorrectly calibrated, it will have a strong impact on its evaluation. Dealing with such data in a medical context is more than simply careless, it is dangerous.

Thanks again


On PET images the intercept should always be zero. It is the slope which is important. I see in the data I sent the slope goes from 3.5 to 0.12, or something in that range.

You are probably correct that both the intercept and slope are ignored, but the Pet-Ct viewer definitely uses the slope strongly.

It is actually a slight advantage that the input data ignores the slope as the hot brain is toned down.

Unless he actively chooses to look at the original input data, it is not used for viewing. There are too many Windows for all the input data and they tend to confuse the screen.

Yes the medical data must be treated absolutely correctly. In our case it is mainly cancers. The viewer displays the data the same way as GE, Siemens and a lot of other manufacturers.

This has been checked for several years.


as far as this thread is concerned, we aren’t dealing with a viewer but with ImageJ, hence with a tool for image processing and I guess the results serve for medical purposes as well. Then it really matters how images are imported and calibrated because the processing results will reflect the right or wrong calibration in one or the other fashion.



I have no objection to any options which are added. Wayne will in fact add a new option in the daily build.
It is most important to follow the user’s requests, not what we deem to be important.

Just to be complete our help pages are at http://petctviewer.org/ and https://sourceforge.net/p/bifijiplugins/wiki/Pet%20Ct%20Viewer%20Help/


The latest daily build (1.52j34) adds a “Ignore Rescale Slope and open as 16-bit” checkbox to the Edit>Options>DICOM dialog box.