#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.

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 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). -- Ticket URL: <https://trac.lrde.org/olena/ticket/130#comment:2> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image library.

#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.

#130: Do not pass neighborhoods as arguments to algorithms -----------------------+---------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: defect | Status: new Priority: major | Milestone: Olena 1.0ß Component: Milena | Version: 1.0 Resolution: | Keywords: -----------------------+---------------------------------------------------- Changes (by levill_r): * owner: Olena Team => levill_r -- Ticket URL: <https://trac.lrde.org/olena/ticket/130#comment:6> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

#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.

#130: Postpone attached neighborhoods for Olena 1.1 -----------------------+---------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: defect | Status: assigned Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: -----------------------+---------------------------------------------------- Changes (by levill_r): * summary: Do not pass neighborhoods as arguments to algorithms => Postpone attached neighborhoods for Olena 1.1 * milestone: Olena 1.1 => Olena 1.0 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.

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).

New description: This ticket contains work for both Olena 1.0 and Olena 1.1. Don't close it too soon! (And don't forget to update the milestone to « Olena 1.1 » when the work regarding Olena 1.0 is done.) = 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). -- Ticket URL: <https://trac.lrde.org/olena/ticket/130#comment:10> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.