Posted by
Michael Schmid on
Dec 12, 2009; 3:32pm
URL: http://imagej.273.s1.nabble.com/Rolling-Ball-tp3690109p3690112.html
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
>