Particle Analyzer dependent on Segmentation background color

Here is an example to show this problem on macro “Java”,

imp = IJ.openImage("C:/Users/user/Desktop/biofilm_stack_02.tif");
Prefs.blackBackground = true;
IJ.run(imp, "Convert to Mask", "");
IJ.run(imp, "Analyze Particles...", "display clear add");

The count would be 1093 now with inverting the LUT of the segmented image,

IJ.run(imp, "Invert LUT", "");
IJ.run(imp, "Analyze Particles...", "display clear add");

the count is 18.

The problem would be solvable by checking if the image is inverted or not. If inverted then I would invert it back and run the ParticleAnalyzer.

if(!segmentedImage.isInvertedLut()) 
IJ.run(segmentedImage, "Invert LUT","");

but the problem that I found is that the Jar file needs the inverse of what the IDE needs, also the IDE on one computer is the inverse than the IDE on another computer. I really can’t know the image Processing reason behind this. Here is the image that I used for testing,

If there is any source that I can read about that could be a start for knowing more would be appreciated.

I can understand that this is frustrating. But the needed flexibility to process images of very different content and imaging modality requires such complexity (i.e. images with dark or bright background).

In my experience specifying the following settings in scripts usually solves most of these issues. Making at least the settings of the specific instance of Fiji consistent.

IJ.run("Options...", "iterations=1 count=1 black");
IJ.run("Colors...", "foreground=white background=black selection=yellow");

Otherwise one really needs to make sure this is solved properly per application (image input etc).

2 Likes

Hello Mourka and Christopher -

First, just to confirm, you are quite correct that the result of
Analyze Particles... depends on the “BlackBackground”
option setting.

To add to the potential confusion, the options Christopher
mentions are persistent options – that is, they are remembered
even if you exit and restart ImageJ. (This is not necessarily a
bad thing, but you need to be aware of it.)

So if you run some one-off processing that changes the option
from what you normally use, and then exit ImageJ (without
changing the option back), the next time you run ImageJ it
“won’t work” for certain workflows. And the option can get
changed (unexpectedly for you) if you run somebody else’s
macro that changes the option out from under you.

Christopher’s suggestion of always starting your macros with
some boilerplate to set the options to your preferred states may
be the safest way to go. (But then your macro can become the
one that changes an option out from under somebody else.)

Thanks, mm

2 Likes

Well for a macro or any kind of program one requires a consistent state.
I agree that changing a persistent setting without the user knowing explicitly is a bad idea. Maybe that boiler plate should include a resetting of the original state
But that adds one more thing. But maybe there is a setting that I am not aware of that is only instance specific. Or maybe there should be one :wink:

1 Like

Someone wrote me an Email with a solution.
Adding these lines to a macro can be a way to save and restore the environment:

saveSettings();

// code

restoreSettings;
2 Likes