PROPOSAL: Implementing Morphology Operators

[anthony]

PROPOSAL: Implementing Morphology Operators
A staged process...

The existing operations -gaussian and -convolve are only methods currently implemented to allow you to do 'morphological' operations within IM at this time. For more information see...
http://en.wikipedia.org/wiki/Mathematical_morphology
http://homepages.inf.ed.ac.uk/rbf/HIPR2/morops.htm

Currently -gaussian is restricted to a -convolve using a pre-prepared array of floating point numbers, while the -convolve operator itself allows the user to provide those floating point numbers. both functions use the same library function, and restricted to a square 'convolution' kernel, and both to a weighted average of the channel values (according to the channel setting)

The proposal to develop the new operations in stages...
First the kernel generation
Second add simple morphological methods
Third wrapper to provide more complex compound morphology


FIrst
Expand -convolve to call a library function to parse the provided kernel string, so as to allow a more varied kernel defination.

For example: expand the 'floating point list from... '1,1,1,1,1,....'
to also allow for kernel definitions of the form.... '{geometry}:1,1,1,1,1,1....'
where {geometry} is of the form W[xH[+X+Y] defining the width, and optionally the height, and center offset of the center point within the kernel.

Internally the floating point array will be expanded to include 4 extra numbers prepended on the front defining these values for passing the defined kernel on into the 'convolve' function (no other call change is needed, though may break other API's)

This string can also be further expanded to allow special 'morphological kernels such as

• 'gaussian, {radius}x{sigma}' the normal gaussian bell curve kernel

and the typical morphological (boolean) kernels such as....

• 'square,{radius}' a square of size radius*2+1, defaulting to a 3x3 square
• 'diamond, {radius}' a diamond kernel defaulting to a 3x3 diamond
• 'disk, {radius}' a morphological circle using floating point radius
• 'rectangle,{geometry}' a rectangle (or square) with more user control

For example:
-convolve 'disk,5' will convolve using a disk shaped area.

This will then mean that -gaussian is equevelent to a -convolve 'gaussian,{args}', which is essentually what IM is currently



Second
To make better use of the new internal library function to generate a kernel from the given user string, a new operator that can do more than just a simple 'weighted average', of gaussian and convolve.

Code: Select all

    -morphology  {method} {arguments}

where {arguments} is typically the same kernel definition I defined above, but expanding the convoltion library function with different methods.

• average normal weighted average style of convolution
• minimum minimum value found in each channel
  (found in the defined kernel region, after thresholding the kernel at 0.5)
• maximum maximum value found in each channel (ditto)
• erode select PIXEL with the minimum gray-scale intensity found (ditto)
• dilate select PIXEL with maximum gray-scale intensity found (ditto)

Other 'simple' convolutions such as some form of 'thresholding'. Or even 'shape locating' methods may also be implemented based on tri-level kernels.. (For example: 0 = much be dark, 1= must be bright, and 0.5=don't care )

Essentially this means that -convolve is simply an alias for a -morphology average


Thrid
Make a further wrapper around the morphology library call to handle compound morphological operations, but otherwise just pass the operation through as previously.

• open an 'erode' followed by a 'dilate'
• close an 'dilate' followed by a 'open'

What else Well the above will work and should be relativity simple to implement.
So what is missing, from the above that would be harder to implement later?

[fmw42]

Here are some other more complicated operators to consider:

Statistical filters
For example: k-nearest neighbors average, and such. For k-nearest neighbor average, one averages only the k pixels that have graylevel (color) closest to the center. Two option are typical. One includes the center pixel in the average and one excludes the center pixel in the average. This can be done with a square/rectangular kernel or with a circular one, etc. other shapes.

The inclusion or exclusion of the center pixel should be an option considered in potential changes to -convolve, -gaussian, etc.

Another is a thresholded average. One averages only those pixels that are closer than some color distance threshold from the center pixel. Second form averages only those pixels that are further than some color distance threshold from the center pixel.

Others are (see my script statsfilt):

geometric mean
harmonic mean
Lp mean
contraharmonic mean
inverse distance weighted average

also
(quantized) mode

and possibly (only for speed)
separable convolution -- one 1D row and one 1D column kernels (same as two passes with -convolve using 1D kernels)