#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 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).
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/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
Of course, adjust tests and clients (if any).
Comment (by levill_r):
Add those files to the list:
* source:trunk/milena/mln/morpho/closing_area.hh
* source:trunk/milena/mln/morpho/closing_attribute.hh
--
Ticket URL: <https://trac.lrde.org/olena/ticket/130#comment:4>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.