Discretization of disk footprints (also ellipse, ball)

[grlee77]

Description

When constructing footprints (structuring elements) corresponding to a disk, the following code is currently used:

scikit-image/skimage/morphology/footprints.py

Lines 118 to 120 in d85b064

	L = np.arange(-radius, radius + 1)
	X, Y = np.meshgrid(L, L)
	return np.array((X ** 2 + Y ** 2) <= radius ** 2, dtype=dtype)

A second possibility is the following:

return np.array((X ** 2 + Y ** 2) <= (radius + 0.5) ** 2, dtype=dtype)

where the radius has been extended by 0.5 voxels. Practially the former means the edge of the disk falls at the voxel center a distance radius away, while for the later, the disk extends to the outer edge of that same voxel. A concrete illustration of this is given for radius = 3 (vs. 3.5) below:

Below is an illustration where the top row are the currently returned footprints for skimage.morphology.disk and the bottom row are the footprints with the proposed modification.

I don't know that the existing behavior is technically a bug, but it is more a matter of what convention is chosen. To me, the lower row look visually more disk-like (although radius=1 is too coarse to resemble a disk in either case).

If this change is made for disk, the same convention should be used for ball and ellipse as well.

[grlee77]

Additional considerations:
1.) calling footprints.ellipse(radius, radius) resembles the "proposed" disks more than the "current" ones, although they are not identical for all choices of radius.
2.) The "current" implementation is consistent with the disks produced by Matlab (there are existing tests that verify this)
3.) OpenCV has a "MORPH_ELLIPSE" shape, but apparently not a disk one. If I make ellipses of the corresponding size they actually end up slightly asymmetric, resembling "current" along one axis, but "proposed" along the other! (seems undesirable)

We could potentially allow both conventions by adding a keyword-only strict_radius parameter with default value of True corresponding to the current behavior and a value of False corresponding to the proposed shape here.

[grlee77]

ImageMagick deals with this by allowing specification of a floating point radius which for example matches "current" when the radius is a whole number or "proposed" if the radius is a half pixel number. Size is always (floor(radius) * 2 + 1, floor(radius) * 2 + 1)
see: https://legacy.imagemagick.org/Usage/morphology/#disk

[rfezzani]

Hi @grlee77, and thank you for raising this. I agree, your proposed implementation looks visually more disk-like!
I like the idea of strict_radius argument 👍