Rolling Ball

[Breukers, C (TNW)]

Hello,

 

I have an image with fluorescence cells on a dark background.

Why are the cells (signal) still present even if I set the rolling ball
diameter much smaller than my typical cell diameter?

 

This happens even when I set the diameter to 1 pixel (my cell is more
than 4 pixels in diameter).

And how come that you can set the rolling ball diameter to even 0.001
pixel?

 

You would expect that the complete signal will be subtracted completely
resulting in a value of 0, so a complete dark image.

 

Regards,

Christian

---------------------------------------------------
Faculty of Sciences and Technology

MIRA Institute for Biomedical Technology and Technical Medicine

Department of Medical Cell BioPhysics
The Netherlands



 

[Michael Schmid]

Hi Christian,

unless you check "sliding paroboloid", at very low values of the ball  
diameter you get a kind of edge detection. Even a ball of radius 1  
won't touch the edges and corners of a box from the inside. Radii  
less than 1 are interpreted as 1 because this algorithm requires a  
radius of at least 1.
Furthermore, the data are smoothed before rolling the ball (to reduce  
the impact of outliers), so even if you could set radius=0 you would  
subtract the smoothed image from the original. There is an option to  
disable smoothing.

Also, this legacy algorithm uses some tricks such as downscaling to  
reduce the computing time. Actually these scale the ball in a way  
that is not really consistent, so, e.g., when changing the radius  
from 10.00 to 10.01 you get a jump in the behavior. Since many people  
rely on 'Subtract Background' to behave as it always did, this cannot  
be changed any more.

If you check "Sliding Paraboloid", the ball is replaced by a  
paraboloid that has the same curvature at the apex as a ball of that  
radius; here you can have any value of the radius > 0.0001.  
Obviously, the width of the paraboloid can be much more than the  
radius if there is a large jump of the image data, especially in a 16-
bit or 32-bit images.
By the way, also the "Sliding Paraboloid" algorithm is an  
approximation, it does not really use a paraboloid (which would be  
very slow) but it rather slides parabolae in different directions  
over the image. Doing the full calculation would be very slow...

For RGB images, one more option that you should care about is  
'Separate Colors'. If you don't check it, the operation only works on  
the brightness, but leaves the hue and saturation untouched.

Michael
________________________________________________________________

On 11 Dec 2009, at 10:31, Christian Breukers wrote:

> Hello,
>
>
>
> I have an image with fluorescence cells on a dark background.
>
> Why are the cells (signal) still present even if I set the rolling  
> ball
> diameter much smaller than my typical cell diameter?
>
>
>
> This happens even when I set the diameter to 1 pixel (my cell is more
> than 4 pixels in diameter).
>
> And how come that you can set the rolling ball diameter to even 0.001
> pixel?
>
>
>
> You would expect that the complete signal will be subtracted  
> completely
> resulting in a value of 0, so a complete dark image.
>
>
>
> Regards,
>
> Christian
>
> ---------------------------------------------------
> Faculty of Sciences and Technology
>
> MIRA Institute for Biomedical Technology and Technical Medicine
>
> Department of Medical Cell BioPhysics
> The Netherlands
>
>
>
>

[Gabriel Landini]

On Friday 11 December 2009, you wrote:
> Actually these scale the ball in a way
> that is not really consistent, so, e.g., when changing the radius
> from 10.00 to 10.01 you get a jump in the behavior. Since many people
> rely on 'Subtract Background' to behave as it always did, this cannot
> be changed any more.

Hi Michael,
Why not? One can add a checkbox for an alternative or more precise
algorithm...  (like the sliding paraboloid option which seems to reduce some
ugly artifacts) and set this as default via the StartupMacros file if one
wants the better method.

I think some other algorithms have changed over the years (wasn't the gaussian
filter one of those?).
I agree that it would be better not to *break* things, but this seems like a
worthy improvement. One could replace the old algorithm for a new one and
still provide a plugin using the old method for those who want to repeat the
old behaviour.

I am not convinced that a posteriori background subtraction should be
privileged as to not be ever changed for better algorithms. It is not only a
last resort method, but also tends to introduce artifacts. Do we want that
forever? [I am sure somebody will say "yes" :-)  ].

Cheers

Gabriel

[Michael Schmid]

Hi Gabriel,

in my view the rolling ball algorithm as such is problematic for a few
reasons:

(1) The 'radius' mixes two different units, length units and pixel value
units. In principle, one should have an ellipsoid where one can
independently vary the radius in x, y on the one hand and the radius of
curvature in pixel value units on the other hand. For a ball, there is no
way to scale it in a way that it consistently treats images with very
different pixel value ranges, e.g. 0-255 and 0-65535. For an image with
large pixel values, the ball will appear almost like a flat disk,
resulting in almost the same operation as subtracting the minimum-filtered
image from the original one.

(2) It is difficult to do a sliding-ball algorithm reasonably fast for
large radii. Methods to speed it up cause some of the artifacts:
- For large radii, only the central portion of the ball is used (and it is
a square that is used). This causes no problems for an 8-bit image with
smoothly varying pixel values, but for 16-bit or float images with with
large gradients it will be mostly the edge of this square area that
touches the surface and thus defines the background.
- Downscaling has caused quite bad edge artifacts for some images in the
original version. These should be fixed since version 1.39q or so, but
nevertheless, some downscaling artifacts cannot be avoided (see macro
below). There is also a bug in the downscaling algorithm that causes the
jumps in behavior e.g. at r=10 (the ball is scaled not only in x&y , but
also in the third 'pixel value' dimension). Fixing this would change the
behavior significantly and break established macros and procedures, but
would it be really worth while adding a checkbox for fixing one problem
alone?

The sliding paraboloid algorithm completely avoids problem (1) - you can
scale a parabola along its axis or perpendicular to it, and it always
remains a parabola. It has also one other advantage: If you add a constant
slope to the image, the result won't change at all (a parabola plus a
constant slope is a parabola again). Furthermore, it does not use
downscaling and thus has no downscaling artifacts.

The sliding paraboloid is not artifact-free because an exact
implementation would again be prohibitive in computing time, but I
consider these artifacts not as bad as those of the the rolling ball. If
you select 'create background (don't subtract)' you can sometimes see the
artifacts as ridges at angles that are multiples of 45°.

Thus, I would vote for normally using the sliding paraboloid and
considering the rolling ball a legacy method. In some way, the sliding
parabola is the 'exact algorithm' checkbox that you propose. Of course, if
you find something better, e.g. a better implementation of the rolling
ball, I would be happy to see it in ImageJ!

A note on Gaussian Blur: There was a trick to keep compatibility: The
'radius' was renamed to 'sigma (radius)'. If ImageJ finds the old word
'radius' in a macro or IJ.run command of a plugin, it automatically
corrects the value, so that it gets the right value of sigma. But it does
not revert to the old less accurate procedure, I think that this would be
useless.


Best wishes,

Michael

---

Example for downscaling artifacts:
//foregrould color should be black (double click color picker)
newImage("test", "8-bit White", 512, 512, 1);
makeRectangle(207, 0, 305, 512);
run("Fill", "slice");
run("Select None");
run("Rotate... ", "angle=5 grid=1 interpolation=Bilinear");
run("Subtract Background...", "rolling=111");

______________________________________________________________________
On Sat, December 12, 2009 12:44, Gabriel Landini wrote:

> On Friday 11 December 2009, you wrote:
>> Actually these scale the ball in a way
>> that is not really consistent, so, e.g., when changing the radius
>> from 10.00 to 10.01 you get a jump in the behavior. Since many people
>> rely on 'Subtract Background' to behave as it always did, this cannot
>> be changed any more.
>
> Hi Michael,
> Why not? One can add a checkbox for an alternative or more precise
> algorithm...  (like the sliding paraboloid option which seems to reduce
> some
> ugly artifacts) and set this as default via the StartupMacros file if one
> wants the better method.
>
> I think some other algorithms have changed over the years (wasn't the
> gaussian
> filter one of those?).
> I agree that it would be better not to *break* things, but this seems like
> a
> worthy improvement. One could replace the old algorithm for a new one and
> still provide a plugin using the old method for those who want to repeat
> the
> old behaviour.
>
> I am not convinced that a posteriori background subtraction should be
> privileged as to not be ever changed for better algorithms. It is not only
> a
> last resort method, but also tends to introduce artifacts. Do we want that
> forever? [I am sure somebody will say "yes" :-)  ].
>
> Cheers
>
> Gabriel
>