Initial display range min/max for 32-bit floating images

[abstracted1]

What kind of logic does ImageJ use when computing the initial display range for 32-bit floating images?

I need to replicate this calculation (outside of ImageJ) for the lower/upper display range histogram levels (on image load).

Upper histogram level

From what I observe, the upper histogram value seems to be consistently equivalent to the 99.9% percentile of the histogram.

Lower histogram level

However, the lower histogram value does not seem to be calculated in the same fashion. Opening various images of mine (sorry I cannot share the images), I find that the lower value percentile varies between 0.1-3% (generally 0.1% seems rather common), depending on the image. How is this lower value calculated?

Observations

• The "Auto" contrast in the B/C window (even when repeatedly clicked) produces different display range extents than the initial image load.
• Calling resetMinAndMax() on the image's FloatProcessor sets the display range to the actual minimum/maximum value of the image. (I would have thought this would get called during image load to initialize the display range, but appears not).
• Older documentation (https://imagej.net/ij/docs/guide/146-28.html) has the sentence: “It may happen that the initial windowing performed by ImageJ on these high bit–depth (or HDR[?]) images is suboptimal.”. This sounds related but is missing details.

[rasband]

As far as I know, the initial display range of 32-bit images is based on the minimum and maximum pixel value. Please provide an example 32-bit image where this is not the case.

[abstracted1]

Hi rasband, thank you for the response. Here is an example below, the tif file has only been drag-and-dropped onto imagej:

Here is link to download the original tif image (let me know if there is some preferred upload method):
https://mega.nz/file/vgwABZrI#EY8ntc46ZmKWVnZChVeB7g1sO1xKZLwZrsHO7m58XIk

[rasband]

Thanks for the link to the 3.tif sample image. This file was created by ImageJ, which saved the display range (488.1423 - 7837.1738) in the tiff header and ImageJ is using this range when it opens the file.

Open the file in debug mode to see the information stored in the tiff header.

This is the output of Image>Show Info, which shows the display range saved with the file ("Display range:") as well as the range calculated from the min/max pixel values ("Pixel value range:").

ImageJ 1.54p; Java 13.0.6 [64-bit]; Mac OS X 11.4; 299MB of 7000MB (4%)

Title: 3.tif
Width: 2038.6812 nm (2048)
Height: 2038.6812 nm (2048)
Size: 16MB
Resolution: 1.0046 pixels per nm
Pixel size: 0.9954x0.9954 nm^2
ID: -21
Bits per pixel: 32 (float, grayscale LUT)
Display range: 488.1423 - 7837.1738
Pixel value range: -14 - 63658
No threshold
Magnification: 0.33
ScaleToFit: false
Uncalibrated
Path: /Users/wayne/Downloads/3.tif
Screen location: 225,25 (1280x800)
SetMenuBarCount: 44 (56ms)
Properties: 1 (Slice_Label)
No overlay

[abstracted1]

Thank you rasband, it appears the same display range was first embedded in the dm3 metadata (our tif files originate from hardware that naively writes dm3/4 files) and propagated to the tif header when the dm3 is loaded then written to tif in imagej.

I did not realize that our acquisition hardware stored the display range in it's files and that imagej would propagate it after tif conversion.

Thanks, this answers my question.

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/how-does-imagej-compute-contrast-levels-on-open/109932/3