#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: -----------------------+---------------------------------------------------- Old 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).
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. Files to be reverted include (at least): * source:trunk/milena/mln/morpho/closing_area.hh File to be moved to the attic (but not removed) include (at least): * source:trunk/milena/mln/neighb/get.hh * source:trunk/milena/mln/neighb/image.hh Don't forget to adjust tests. = 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/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 might be 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 (by levill_r): Update. -- Ticket URL: <https://trac.lrde.org/olena/ticket/130#comment:9> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.