#130: Do not pass neighborhoods as arguments to algorithms -----------------------+---------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: defect | Status: assigned Priority: major | Milestone: Olena 1.1 Component: Milena | Version: 1.0 Resolution: | Keywords: -----------------------+---------------------------------------------------- Changes (by levill_r): * milestone: Olena 1.0ß => Olena 1.1 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 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/closing_area.hh * source:trunk/milena/mln/morpho/closing_attribute.hh * source:trunk/milena/mln/morpho/Rd.hh * source:trunk/milena/mln/morpho/opening_area.hh * source:trunk/milena/mln/morpho/opening_attribute.hh
These files are also using neighborhoods, and should be, IMHO, converted to windows:
* source:trunk/milena/mln/canvas/labeling.hh
Of course, adjust tests and clients (if any).
New description: = Olena 1.0 = For the moment, revert changes so that neighborhoods are actually passed as arguments of algorithms. We'll improve this in Olena 1.1. = Olena 1.1 = 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/closing_area.hh * source:trunk/milena/mln/morpho/closing_attribute.hh * source:trunk/milena/mln/morpho/Rd.hh * source:trunk/milena/mln/morpho/opening_area.hh * source:trunk/milena/mln/morpho/opening_attribute.hh These files are also using neighborhoods, and should be, IMHO, converted to windows: * source:trunk/milena/mln/canvas/labeling.hh Of course, adjust tests and clients (if any). We already have a `mln::neighb::image` morpher adding a neighborhood, but it should be shipped with Olena 1.1 (not Olena 1.0). We then should adjust window-based morpho algorithms so that they can work on images with neighborhoods (work started in r1686 and r1688, but far from being complete). Comment: Postpone this task to Olena 1.1. -- Ticket URL: <https://trac.lrde.org/olena/ticket/130#comment:8> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.