Thresholding Issue: White background changed to dark background

Hello,

Previously, when I would threshold one of my images with the dark background feature checked, the background would be white and the cells I was counting would be black and upon analyzing the particles I would get an accurate cell count. However now when I threshold doing the same thing, the background is black and the cells are white. When I change the thresholding bars to make the background white and cells black it just counts the background as one large cell and gives me a very low count of about 1 or 2.

Does anyone have any idea why this may be or how I can get my thresholding properties back to what they initially were? Any assistance would be appreciated!

Vanessa

Check if some images use the “inverted LUT”.

Hi Gabriel, thanks for your help. Where would I go to confirm that? My image itself doesn’t appear to have an inverted LUT so I don’t think that is the cause. The backgrounds is only black when I try to threshold the image.

Please see an example below
The image on the left is what is occurring now, where as the image on the right is what the thresholded image looked like before when I was counting. However Now when I threshold to make it look like the image on the right the background is being counted as one cell instead of counting the cells in the image.

The image should say “Inverting LUT” in the info bar, at the top, if it uses one.
Also there are settings, like Process>Binary>Options where there is a “Black background” checkbox.
The thresholding applet has also a “Black background” option. So there are quite a few places where you might have inadvertedly left unchecked. Sorry, but without more details it is not possible to know why you got those results.
If you put the mouse over a black area and you get a value of 255 in the IJ window, you are using an inverted LUT. If you get “0” you are not.
The Blobs image in the File>Open Samples, uses an inverted LUT.

2 Likes

I have a general question about this “issue”, why is it so important to leave to the user the possibility to check black or white background?
Is it not really better and more stable decide definitely black or white background? so when someone write a macro or a plugin has not to check everytime if in that particular session of imagej the image has inverted LUT, black backround checked or not, and so on?
Thank you,
Emanuele

If you are looking for supernovas you do not want to detect black holes… and vice versa.

Take these options as s part of the flexibility of IJ. In some programs (I think Optimas) this was called “image polarity” and you made a choices at the very start when you install the software. Then you were stuck with that.
Historically PCs considered black as background but macs had white backgrounds with black characters. What is the object and which pixel colour it should be is therefore relative when you are dealing with arbitrary images.

My personal preference in 8 bit images is to have background as 0 and “object” as foreground with 255 and never use inverting LUTs (try debugging the IMP logical operation between a “normal” binary image and another with the inverted LUT!) but early mac users might have disagreed. So there is no way round to be careful with these options and know what you are doing.

If you want IJ to behave in a particular manner which is not the default, then you can record those options in a macro and then copy that part to the StartupMacros.txt file. I do this. You only have to remember to sent this file to others if you want them to replicate the same behaviour as in your install.

1 Like

Yes Gabriel,
I get the point.
But in general I think that it is not a good flexibility.
I deal every day with many users and most of the time a Macro or Plugin doesn’t work in a machine but it works in another one since for some, random, reasons in a machine you have Black Background in another one not.
Only my opiniong of course: for example Matlab or other software say black is background and it is zero intensity, if you are interested in Black Holes invert your image; but when you threshold 0 is background and 1(better than 255 if you are using a bw image…) is “foreground”.
And ok I really agree with you that for me it is better for logical operations! and I really don’t see good reasons to use inverted LUT but I am not an early Mac users.

OK thank you for discussion!
have a nice day,
Emanuele

Yes, I agree, it would be better to settle this, but in trying to do so it would break many other things, so it is a bit late to try to fix. It does not only affect threshold setting, think about erosion and dilation, any process that uses binary images, etc.
In my plugins I use explicit choices to make sure that I do not depend on somebody else’s settings, and I use the options in the StartupMacros file. Maybe you can suggest your users the same or provide them with the same settings you use.

1 Like

I agree that this is a common problem, lamentably. You might find this section of the Troubleshooting page helpful to quickly share with your users. (Also: please feel welcome to enhance it with other common “plugin results differ between machines” culprits!)

I also agree that all these user settings are the bane of reproducible analysis. But I am confident that ImageJ’s support for reproducible analyses will improve with time, such that e.g. these user settings are all noted somehow as part of each exported workflow.

2 Likes

5 posts were split to a new topic: Inconsistent particle count results on different machines