Auto Threshold calculation and Bright and contrast auto adjust issue



I have just update FIJI with the last version today ImageJ 1.52e and I realized that the calculation of the threshold value done using auto threshold method now depends on the way Bright and Contrast has been set (before to have pressed apply).

It looks not right to me, since the auto adjust has not been applied, so the threshold calculation should have been done on the raw pixel values of the image.

I took a screenshot to demonstrate it:

On the right, the auto Bright and contrast is not set and I then select the threshold method Yen and pressed auto

On the left, the auto Bright and contrast is set and I then select the threshold method Yen and pressed auto

You can download the test image here :

So is that’s a bug of the interface or a feature?



Hi. I believe the applet does the thresholding on the binned histogram of 16bit images.
If you want to do it on the pixel data, try the Auto_Threshold command, which works on the raw pixel data as you were expecting.


This is a “feature”. To get the old behavior, click “Reset” in the “B&C” window. Or use the setAutoThreshold(“Yen dark”) macro function. To get the new behavior, use setAutoThreshold(“Yen dark no-reset”).


Thanks for the quick reply I never pay attention to that this action recorded contain a no-reset option. I had some users that got confused with this behavior, is that a recent change in ImageJ ?

Thanks for the explanation


Thanks from me too, I also noticed this and was a bit confused.

In particular, I wanted to set a single threshold for all pixels above/below a fixed value. Adjusting the slider in the normal Image → Adjust → Threshold… dialog, I found the lower threshold was constrained to match with the Brightness/Contrast slider… and I couldn’t get all the ‘darker’ pixels without changing this.

The behavior for the lower slider also seems to change is Stack histogram is selected.

I might just need to get used to it, but I’m not sure I personally like the Brightness/Contrast impacting the results in this way. I generally tell students that adjusting the Brightness/Contrast sliders is ok because it doesn’t impact the pixel values unless they press ‘Apply’ (although they should always be cautious and check if they are unsure)… but now it potentially does impact analysis results, in a way that seems to me quite subtle and easy to miss.

The only real advantage I can see to the change is that previously one or two extreme outlier pixels could thwart the threshold by pushing the remaining values into a single histogram bin… but it rarely happened in practice. Are there other advantages?


This change was made in ImageJ 1.52e, released on 11 July 2018.

* The "Threshold" tool no longer resets the display range of 16-bit and 32-bit images.


I have to second @petebankhead on this

This is just terrible for people trying to find a good Auto threshold method by hand while they’re exploring their dataset. If the auto-threshold now depends on the display, it is going to be very difficult to reproduce results.

I’m pretty worried about it, now that I think about it.




Hi @Wayne

might it be possible to turn this “feature” off per default? We just had issues during a course. Students complained that thresholding is not reproducible. I’m afraid they are right. If you point me to the code where this is implemented, I’m happy to support in making a checkbox to an options dialog which is per default off.

I hope, for the sake for reproducible science, that we can change this feature from an OPT-OUT to an OPT-IN strategy.




Good day Robert,

thanks for insisting on this crucial question!

No matter what will be implemented in the end, it must be clear to the user of the auto-threshold feature what the actual setting is, or, even better, that the value range is presently restricted.

In other words, it is not sufficient to have a switch, the user must know the position of the switch (or better its consequences) when (s)he uses the auto-threshold feature.

I’d propose that a warning in the “auto-threshold”-dialog appears, if the value range is restricted.
(I prefer no extra window for this warning.)




that’s so true and right in my opinion.
I really think that a visualization tool like brightness and contrast it should never in any case impact on analysys.
for many reasons.
honestly I really don’t see any pro to have this feature.

auto threshold has to work only with the raw data of the image.

hope it can be removed…
have a nice weekend


The latest daily build (1.52i8) adds a “Reset range” checkbox to the “Threshold” dialog, which is set by default.


Hi @Wayne ,

thanks for your support! I tested 1.52i8. I couldn’t see a real difference when the checkbox is turned on and off. So, I’m not 100%ly sure if the changes are effective.

However, I was more concerned about long-term reproducibility of macros applying brightness/contrast and auto-thresholding. When I saw the post above, I was afraid, that old macros suddenly deliver different results. This would have been a serious issue. However, this is not the case:

If anybody wants to reproduce that, this is the example image I used. And this is the example macro:

run("Duplicate...", " ");

// measurement after reset contrast
run("Duplicate...", " ");
setOption("BlackBackground", true);
run("Convert to Mask");

// measurement after fixed contrast
run("Duplicate...", " ");
setAutoThreshold("Default dark");
setMinAndMax(100, 255);
setOption("BlackBackground", true);
run("Convert to Mask");

// measurement after auto contrast
run("Duplicate...", " ");
run("Enhance Contrast", "saturated=0.35");
setOption("BlackBackground", true);
run("Convert to Mask");

run("Close All");

Thanks also to all others for the heads-up! I really enjoy how we as a community tackle issues like this one. :slight_smile:



The “Reset Range” option, changed to “Don’t reset range” in the latest daily build (1.52i9), only applies to 16 and 32 bit images. Try testing this option with the 16-bit M51 Galaxy sample image. With the range set to 0-1284, you get a MaxEntropy threshold of 504 when “Don’t reset range” is enabled and 2259 when it is not. Note that different code is recorded when “Don’t reset range” is enabled.

With “Don’t reset range”:

Without “Don’t reset range”:


Dear Wayne (@Wayne),

I think your suggestion is a possible solution …

In your first screen shot “With ‘Don’t reset range’:” the upper limit of the lower slider isn’t really intuitive. Shouldn’t it show the value 1284?

With best regards



The “Threshold” window shows the threshold range (504-65535). The “B&C” (Brightness/Contrast) window shows the display range (0-1284).


The “Threshold” window shows the threshold range (504-65535). The “B&C” (Brightness/Contrast) window shows the display range (0-1284).

Dear Wayne (@Wayne),

I’m aware of this but what the "Threshold” window shows isn’t to the point. The upper limit of the shown histogram isn’t 65535 but 1284.

Sorry for insisting



Hi @Wayne,

I tried with the m51.tif and I have some issues with the new checkbox in 1.52i9: When I turn on/off the new checkbox a couple of times, initially it is doing nothing (the thresholded area doesn’t change) and then at some point the thresholded area disappears and the threshold window looks like this:


I guess, that’s not intentional?

@Herbie: The upper threshold of 65535 appears right to me as all the pixels between 1284 and 65535 are considered as part of the positive area.

Again, thanks for your efforts. :slight_smile:



Good day Robert,

maybe I’m missing something or we are speaking of different issues.

I refer to this image posted above by Wayne:

When looking at the threshold-histogram and at its slider values I see a discrepancy:

  1. The lower threshold is 504 and this is indicated in the histogram by the left red border.
  2. If the left red border stands for 504, then the rightmost border, i.e. the end of the displayed histogram, cannot stand for 65535, at least if the gray scaling of the histogram is linear.
  3. Because “Don’t reset range” is checked, I assume that the threshold is computed with respect to the restricted range that is 0 to 1284, which appears to be reflected by the shown histogram but not by the numerical limits.
    (As Wayne pointed out, it is of course reflected by the histogram of the B&C-dialog.)

Please tell me if and at which point I’m wrong.




@Herbie The text field containing the value 65535 is the upper threshold applied to get the red area in the image. If you set it to 1284 (try it out!) there will be a black hole inside the red area in the image. That’s why 65536 is right. Furthermore, it is nowhere stated that this textfield contains the upper bound of the histogram.



Thanks Robert,


[…] it is nowhere stated that this textfield contains the upper bound of the histogram.

appears to be an explanation but I strongly plead that this should be so.

However, for the time being let’s agree with the given facts, then I don’t understand what “Don’t reset range” means.
If I restrict the range of gray values in the B&C-dialog and check “Don’t reset range” in the threshold-dialog, I assume that the threshold is computed with respect to the restricted range, i.e. here 0 to 1284, and not with respect to the full 16bit range, i.e. 0 to 65535. I understand the latter behavior being in action if “Don’t reset range” is unchecked.



Presently it appears as if the threshold computation must be distinguished from the resulting image display.
This is terribly confusing.