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?
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.
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
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.
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
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.
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.