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