Images Have Edges: Now What?
Many G'MIC commands decide how to write an output pixel by accessing a neighborhood of input pixels, usually centered around the pixel in question. (See convolve
). In principle, the neighborhood may be arbitrarily large, in practice it is a ball or sphere just a few pixels across.
All this is well and good so long as we deal with images of infinite extent, but computer manufacturers behave badly when asked to provide such capacity, so as a practical matter, images have both finite extent and, therefore, edges. Difficulties arise with edges. At some point, a part of a neigborhood won't exist because the pixels are off an edge. How does one access a pixel that is not there?
In the absence of data, one often reaches for policy. G'MIC commands which need to worry about boundaries generally sport a boundary parameter which specifies up to three possible policies:
The flags 0, dirichlet, 1, neumann, and 2 cyclic are used consistently throughout G'MIC where the command in question performs some sort of operation entailing moving a kernel (a pixel and its neighborhood) over a surface, where it must, perforce eventually deal with edges and corners. These policies work well in some circumstances and poorly in others. There is no one 'right' approach; the choice usually depends on which set of limitations one can best live with. Many commands which operate on neighborhoods around input pixels do not fully implement the three policies; often the cyclic case is omitted.
G'MIC is an open-source software distributed under the
CeCILL free software licenses (LGPL-like and/or
Copyrights (C) Since July 2008,
David Tschumperlé - GREYC UMR CNRS 6072, Image Team.