#130: Do not pass neighborhoods as arguments to algorithms -----------------------+---------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: defect | Status: new Priority: major | Milestone: Olena 1.0ß Component: Milena | Version: 1.0 Resolution: | Keywords: -----------------------+---------------------------------------------------- Old description:
Neighborhoods shall be bound to images: they are a property of them. Hence an algorithm (at least a facade) shall not accept an image along with an ''external'' neighborhood.
Most of the time, these algorithms are based on windows improperly called neighborhoods (i.e., input is of type `Neighborhood<N>&` instead of `Window<W>&`). In fact for most algorithms we want two versions of the interface :
* One with the input image(s) passed as argument, where a neighborhood is attached to the image(s) itself/themselves ; * One with the input images(s) passed as argument plus a window (or windows) also passed as argument.
For instance: {{{ #!cpp // Version using an image to which a neighborhood is attached (to be // enforced by a static precondition.) template <typename I> mln_concrete(I) dilation(const Image<I>& input);
// Version using an image and a window. template <typename I, typename W> mln_concrete(I) dilation(const Image<I>& input, const Window<W>& se); }}}
Of course, this does not prevent us to write algorithms working only on windows, or working only on neighborhoods (i.e., with a single facade).
Here is the list of files to revamp, as of revision 1663:
* source:trunk/labeling/level.spe.hh * source:trunk/labeling/regional_maxima.hh * source:trunk/labeling/regional_minima.hh * source:trunk/make/voronoi.hh * source:trunk/milena/mln/geom/labeling/blobs.hh * source:trunk/milena/mln/geom/seeds2tiling_roundness.hh * source:trunk/milena/mln/labeling/background.hh * source:trunk/milena/mln/labeling/flat_zones.hh * source:trunk/milena/mln/labeling/foreground.hh * source:trunk/milena/mln/labeling/level.hh * source:trunk/morpho/Rd.hh * source:trunk/morpho/dilation.hh * source:trunk/morpho/opening_area.hh * source:trunk/morpho/opening_attribute.hh
Of course, adjust tests and clients (if any).
New description: Neighborhoods shall be bound to images: they are a property of them. Hence an algorithm (at least a facade) shall not accept an image along with an ''external'' neighborhood. Most of the time, these algorithms are based on windows improperly called neighborhoods (i.e., input is of type `Neighborhood<N>&` instead of `Window<W>&`). In fact for most algorithms we want two versions of the interface : * One with the input image(s) passed as argument, where a neighborhood is attached to the image(s) itself/themselves ; * One with the input images(s) passed as argument plus a window (or windows) also passed as argument. For instance: {{{ #!cpp // Version using an image to which a neighborhood is attached (to be // enforced by a static precondition.) template <typename I> mln_concrete(I) dilation(const Image<I>& input); // Version using an image and a window. template <typename I, typename W> mln_concrete(I) dilation(const Image<I>& input, const Window<W>& se); }}} Of course, this does not prevent us to write algorithms working only on windows, or working only on neighborhoods (i.e., with a single facade). Here is the list of files to revamp, as of revision 1692: * source:trunk/milena/mln/geom/labeling/blobs.hh * source:trunk/milena/mln/geom/seeds2tiling_roundness.hh * source:trunk/milena/mln/labeling/background.hh * source:trunk/milena/mln/labeling/flat_zones.hh * source:trunk/milena/mln/labeling/foreground.hh * source:trunk/milena/mln/labeling/level.hh * source:trunk/milena/mln/labeling/level.spe.hh * source:trunk/milena/mln/labeling/regional_maxima.hh * source:trunk/milena/mln/labeling/regional_minima.hh * source:trunk/milena/mln/make/voronoi.hh * source:trunk/milena/mln/morpho/Rd.hh * source:trunk/milena/mln/morpho/opening_area.hh * source:trunk/milena/mln/morpho/opening_attribute.hh Of course, adjust tests and clients (if any). Comment (by levill_r): Update: * Adjust the list of files to reavamp. * Remove source:trunk/milena/mln/morpho/dilation.hh (fixed since). -- Ticket URL: <https://trac.lrde.org/olena/ticket/130#comment:3> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.