Olena-patches February 2009

olena-patches@lrde.epita.fr

12 participants
266 discussions

[Olena] #143: Reorganize milena/mln/core/

by Olena

#143: Reorganize milena/mln/core/ ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: task | Status: new Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- (This ticket is just a proposal. We might close it even if no change occur in `milena/mln/core`.) There are many things in source:trunk/milena/mln/core/, that could be reorganized and/or split in several directories/subdirectories: * basic/classic images and entites (`mln::image2d`, etc.) * graph-based images and entities (`mln::graph_image`, etc.) * non classic images and associated tools (`mln::rle_image`, etc.) * morphers (`mln::cast_image`, etc.) * internal/core mechanisms (`initialize.hh` etc.) * general tools (`contract.hh`, `inplace.hh`, etc.) * concepts (though they are located in their own directory, `mln/core/concept/`) * implementation/factoring classes (thought most of them are in `mln/core/internal/`) * other entities, that should be moved elsewhere (`mln::h_vec`, etc.) * and so on. To my (Roland) mind, we should: 1. Identify the different kind of files present in `core/`. 2. Assign one (maybe two) kinds to each file of this directory. 3. Determine a new file layout, and perform the moves. -- Ticket URL: <https://trac.lrde.org/olena/ticket/143> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

15 years, 7 months

[Olena] #167: Write iterators on complexes

by Olena

#167: Write iterators on complexes ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: task | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Most of this task is described in [source:branches/cleanup-2008/milena/tests/topo/complex.cc tests/topo/complex.cc] (r2411) : {{{ /*------------------------------. | Iterators on adjacent faces. | `------------------------------*/ /* FIXME: Write and exercise more iterators (see milena/tests/core/complex_image.cc) and ticket #162 (https://trac.lrde.org/olena/ticket/162) */ /* Iterate on the the set of (n-1)-faces adjacent to AF. Note: this can be solved with iterators where the dimension can be either static or dynamic. Let's start with a dynamic one, as it would allow us to write something like this: mln_fwd_citer_(topo::complex<D>) f(c); mln_fwd_lower_nciter(topo::complex<D>) n(c); for_all(c) for_all(n) // ... (Note: we might want to get rid of the name `citer', and use `fiter' everywhere.). A static version might be useful (and more efficient) too. Likewise, our iterators on n-faces (both faces_piter and complex_faces_piter) use a static `n'. We should also have n-faces iterators where n could be dynamic. But first, we need to clarify (existing) names. ----------------------------------------------------------------- Current name New name Definition ----------------------------------------------------------------- complex<D> (n/a) General complex face<N, D> face_data<N, D> Face data face_handle<N, D> n_face<N, D> (Static) n-face handle faces_set<N, D> n_faces_set<N, D> Set of face handles any_face_handle<D> face<D> Dynamic face handle complex_fwd_iter_<D>(c) face_fwd_iter<D>(c) | Iterators on all complex_bkd_iter_<D>(c) face_bkd_iter<D>(c) | faces of c complex_iter_base_<F, E> complex_iter_base<F, E> | Factoring base | class. ----------------------------------------------------------------- (Note: get rid of trailing underscores, even for entities in mln::internal::.) Next, write these: ----------------------------------------------------------------- Name Definition ----------------------------------------------------------------- n_faces_fwd_iter<D>(c) | Iterators on n-faces, n_faces_bkd_iter<D>(c) | n being dynamic adj_lower_faces_fwd_iter<D>(c, f) | Iterators on the adjacent adj_lower_faces_bkd_iter<D>(c, f) | (lower) (n-1)-faces of the | n-face f of the complex c, | n being dynamic adj_higher_faces_fwd_iter<D>(c, f) | Iterators on the adjacent adj_higher_faces_bkd_iter<D>(c, f) | (higher) (n+1)-faces of the | n-face f of the complex c, | n being dynamic adj_lower_dim_connected_n_faces_fwd_iter<D>(c, f) adj_lower_dim_connected_n_faces_bkd_iter<D>(c, f) (FIXME: These names are admittedly too long.) | Iterators on the the set of | n-faces sharing an adjacent | (n-1)-face with f, n being | dynamic adj_higher_dim_connected_n_faces_fwd_iter<D>(c, f) adj_higher_dim_connected_n_faces_bkd_iter<D>(c, f) (FIXME: These names are admittedly too long.) | Iterators on the the set of | n-faces sharing an adjacent | (n+1)-face with f, n being | dynamic cell_fwd_iter<D>(c, f) | Iterators on the set of the cell_bkd_iter<D>(c, f) | faces in the « cell » | including p, i.e. the set of | all m-faces adjacent to p, | where m is in [0, n-1]; | this set is name « f-hat » cell_boundary_fwd_iter<D>(c, f) | Likewise, but excluding p; cell_boundary_bkd_iter<D>(c, f) | this set is named « p-hat* » ----------------------------------------------------------------- We could also have generic iterators based on predicated, and even use them to provide first (non efficient) implementations of the iterators from the previous list. ----------------------------------------------------------------- Name Definition ----------------------------------------------------------------- generic_face_fwd_iter<D>(c, pred) | Generic face iterators on c generic_face_bkd_iter<D>(c, pred) | using predicate pred to | define the iterated subset. ----------------------------------------------------------------- I'm unsure about the following existing iterators; should we keep them? What are they good for, except testing our code? ----------------------------------------------------------------- Current name Definition ----------------------------------------------------------------- complex_faces_fwd_iter_<N, D> Iterators on N-faces, N being complex_faces_fwd_iter_<N, D> static, acting as proxies of face_handle<N, D>'s. faces_fwd_iter_<N, D> Iterators on N-faces, N being faces_fwd_iter_<N, D> static, acting as proxies of any_face_handle<N, D>'s. ----------------------------------------------------------------- */ }}} (This should be turned into actual documentation, BTW.) See also #162 for applications of these iterators in windows/neighborhoods and images. -- Ticket URL: <https://trac.lrde.org/olena/ticket/167> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

15 years, 7 months

[Olena] #161: Implement more complex psite iterators

by Olena

#161: Implement more complex psite iterators ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: task | Status: new Priority: major | Milestone: Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- As of r2148, we only have a single piter couple on complex : `mln::p_complex_fwd_piter_` and `mln::p_complex_bkd_piter_` (source:trunk/milena/mln/core/p_complex_piter.hh:2148). Comments (FIXMEs) at the end of source:trunk/milena/tests/core/complex_image.cc:2148 suggest to add these additional iterators: * iterators on ''n''-faces with ''n'' fixed in [0, ''d''] (using `mln::p_faces` and `mln::faces_psite`?) * iterators on ''n''-faces with ''n'' in a subset of [0, ''d'']; * etc. -- Ticket URL: <https://trac.lrde.org/olena/ticket/161> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

15 years, 7 months

[Olena] #140: Add points having floating-point coordinates

by Olena

#140: Add points having floating-point coordinates ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: task | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Name regular instances `point1df`, `point2df` and `point3df`. (N.B.: Aroune will need them so as to build the 3-d surface graph from a set of triangles.) -- Ticket URL: <https://trac.lrde.org/olena/ticket/140> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

15 years, 7 months

[Olena] #182: Repair Swilena

by Olena

#182: Repair Swilena ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: defect | Status: new Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- [source:trunk/swilena Swilena] is broken since the end of Summer 2008 (before the merging back of [source:branches/cleanup-2008 cleanup-2008/] into [source:trunk/ trunk/]). Have it compile and pass the tests again. -- Ticket URL: <https://trac.lrde.org/olena/ticket/182> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

15 years, 7 months

[Olena] #162: Implement windows, neighborhoods, and corresponding iterators for complex-based images

by Olena

#162: Implement windows, neighborhoods, and corresponding iterators for complex- based images ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: task | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- For a given (fixed) dimension ''n'' and a psite ''p'' on a ''n''-face, implement windows/neighborhoods (and corresponding iterators) returning * the set of (''n''-1)-faces adjacent to ''p'' (using ``mln::p_faces`` and ``mln::faces_psite``?); * the set of (''n''+1)-faces adjacent to ''p'' (using ``mln::p_faces`` and ``mln::faces_psite``?); * the set of ''n''-faces sharing a (''n''-1)-face with ''p''; * the set of ''n''-faces sharing a (''n''-1)-face or (''n''-2)-face (by transitivity) with ''p'' (is it useful?); * the set of the faces in the ``cell'' including ''p'' (named ``''p''-hat'' in couprie.08.pami), i.e., the set of all ''m''-faces adjacent to ''p'', where ''m'' is in [0, ''n''-1].[[BR]] In that definition, ''p'' is said adjacent to an ''m''-face ''q'' if there is a sequence (''m,,1,,'', ''m,,2,,'', ..., ''m,,k,,'') of faces so that * ''m,,1,,'' is an (''n''-1)-face adjacent to ''p'' ; * ''m,,2,,'' is an (''n''-2)-face adjacent to ''m,,1,,'' ; * ... (and so on) * ''m,,k,,'' is an (''m''+1)-face adjacent to ''q''. * what else? As in #139, we might want to factor things using implementation classes: * ``mln::internal::complex_vicinity`` * ``mln::internal::complex_vicinity_piter`` We might even be able to factor them with graph-based ones. -- Ticket URL: <https://trac.lrde.org/olena/ticket/162> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

15 years, 7 months

[Olena] #130: Don not pass neighborhoods as argument to algorithms

by Olena

#130: Don not pass neighborhoods as argument to algorithms ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: defect | Status: new Priority: major | Milestone: Olena 1.0ß Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- 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 -- Ticket URL: <https://trac.lrde.org/olena/ticket/130> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image library.

15 years, 7 months

[Olena] #159: Distribute SWIG wrappers

by Olena

#159: Distribute SWIG wrappers -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: enhancement | Status: new Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | -------------------------+-------------------------------------------------- According to Alexandre Hamez, files generated by `swig` (e.g., `*.py` and `*-wrap.cc`) are portable. We should distribute them, as * it would save users wanting to use Swilena some time; * it would free them to have SWIG to compile Swilena. To do: * distribute these files (remove `nodist_` prefixes); * ensure they're available at distribution time (use `dist-hook` in `Makefile.am`); * add generated files to `MAINTAINERCLEANFILES`; * adjust `configure.ac`? (see what Alexandre uses). -- Ticket URL: <https://trac.lrde.org/olena/ticket/159> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

15 years, 7 months

milena r3444: Correct references to mln::morpho::closing_... and opening_...

by Frederic Bour

URL: https://svn.lrde.epita.fr/svn/oln/trunk/milena ChangeLog: 2009-02-28 Frederic Bour <bour(a)lrde.epita.fr> Correct references to mln::morpho::closing_... and opening_... * mln/accu/height.hh, * mln/accu/volume.hh, * mln/morpho/all.hh, * mln/morpho/essential.hh: Replace mln::morpho::closing_ by mln::morpho::closing:: * tests/morpho/Makefile.am: Removed old tests * tests/morpho/complex_image_wst.cc, * tests/morpho/lena_line_graph_image_wst1.cc, * tests/morpho/meyer_wst_long.cc: Correct references. --- mln/accu/height.hh | 5 +++-- mln/accu/volume.hh | 5 +++-- mln/morpho/all.hh | 4 ++-- mln/morpho/essential.hh | 4 ++-- tests/morpho/Makefile.am | 3 --- tests/morpho/complex_image_wst.cc | 4 ++-- tests/morpho/lena_line_graph_image_wst1.cc | 4 ++-- tests/morpho/meyer_wst_long.cc | 4 ++-- 8 files changed, 16 insertions(+), 17 deletions(-) Index: trunk/milena/tests/morpho/meyer_wst_long.cc =================================================================== --- trunk/milena/tests/morpho/meyer_wst_long.cc (revision 3443) +++ trunk/milena/tests/morpho/meyer_wst_long.cc (revision 3444) @@ -40,7 +40,7 @@ #include <mln/value/label_16.hh> #include <mln/morpho/gradient.hh> -#include <mln/morpho/closing_area.hh> +#include <mln/morpho/closing/area.hh> #include <mln/morpho/meyer_wst.hh> #include <mln/convert/to_window.hh> @@ -65,7 +65,7 @@ image2d<int_u8> grad = morpho::gradient(input, c4().win()), - clo = morpho::closing_area(grad, c4(), 200); + clo = morpho::closing::area(grad, c4(), 200); // Perform a Watershed Transform. typedef value::label_16 L; Index: trunk/milena/tests/morpho/complex_image_wst.cc =================================================================== --- trunk/milena/tests/morpho/complex_image_wst.cc (revision 3443) +++ trunk/milena/tests/morpho/complex_image_wst.cc (revision 3444) @@ -51,7 +51,7 @@ #include <mln/norm/l2.hh> -#include <mln/morpho/closing_area.hh> +#include <mln/morpho/closing/area.hh> #include <mln/morpho/meyer_wst.hh> #include <mln/convert/to.hh> @@ -197,7 +197,7 @@ `-----------------*/ // Currently, does nothing (lambda = 1). - dist_ima_t closed_dist_ima = morpho::closing_area(dist_ima, nbh, 1); + dist_ima_t closed_dist_ima = morpho::closing::area(dist_ima, nbh, 1); /*------. | WST. | Index: trunk/milena/tests/morpho/Makefile.am =================================================================== --- trunk/milena/tests/morpho/Makefile.am (revision 3443) +++ trunk/milena/tests/morpho/Makefile.am (revision 3444) @@ -28,9 +28,6 @@ line_graph_image_morpho \ meyer_wst \ meyer_wst_long \ - opening_area \ - opening_height \ - opening_volume \ rank_filter \ skeleton_constrained \ thinning Index: trunk/milena/tests/morpho/lena_line_graph_image_wst1.cc =================================================================== --- trunk/milena/tests/morpho/lena_line_graph_image_wst1.cc (revision 3443) +++ trunk/milena/tests/morpho/lena_line_graph_image_wst1.cc (revision 3444) @@ -68,7 +68,7 @@ #include <mln/util/graph.hh> #include <mln/morpho/gradient.hh> -#include <mln/morpho/closing_area.hh> +#include <mln/morpho/closing/area.hh> #include <mln/morpho/meyer_wst.hh> #include <mln/value/int_u8.hh> @@ -109,7 +109,7 @@ // Simplify the input image. image2d<input_val_t> work(input.domain()); - work = morpho::closing_area(gradient, c4(), 10); + work = morpho::closing::area(gradient, c4(), 10); /*-------------. | Line graph. | Index: trunk/milena/mln/accu/volume.hh =================================================================== --- trunk/milena/mln/accu/volume.hh (revision 3443) +++ trunk/milena/mln/accu/volume.hh (revision 3444) @@ -38,8 +38,8 @@ The class mln/accu/volume is not a general-purpose accumulator; it is used to implement volume-based connected filters. - \see mln::morpho::closing_volume - \see mln::morpho::opening_volume + \see mln::morpho::closing::volume + \see mln::morpho::opening::volume */ # include <mln/accu/internal/base.hh> @@ -69,6 +69,7 @@ /// root pixel. See mln::morpho::closing_volume and /// mln::morpho::opening_volume for actual uses of this /// accumulator. + /// FIXME: Replaced by mln::morpho::attribute::volume typedef util::pix argument; /// The value type associated to the pixel type. typedef typename argument::value value; Index: trunk/milena/mln/accu/height.hh =================================================================== --- trunk/milena/mln/accu/height.hh (revision 3443) +++ trunk/milena/mln/accu/height.hh (revision 3444) @@ -38,8 +38,8 @@ The class mln/accu/height is not a general-purpose accumulator; it is used to implement height-based connected filters. - \see mln::morpho::closing_height - \see mln::morpho::opening_height + \see mln::morpho::closing::height + \see mln::morpho::opening::height */ # include <mln/accu/internal/base.hh> @@ -69,6 +69,7 @@ /// root pixel. See mln::morpho::closing_height and /// mln::morpho::opening_height for actual uses of this /// accumulator. + /// FIXME: Replaced by mln::morpho::attribute::height typedef util::pix argument; /// The value type associated to the pixel type. typedef typename argument::value value; Index: trunk/milena/mln/morpho/all.hh =================================================================== --- trunk/milena/mln/morpho/all.hh (revision 3443) +++ trunk/milena/mln/morpho/all.hh (revision 3444) @@ -57,6 +57,7 @@ # include <mln/morpho/closing.hh> +# include <mln/morpho/closing/all.hh> # include <mln/morpho/complementation.hh> # include <mln/morpho/contrast.hh> # include <mln/morpho/dilation.hh> @@ -69,9 +70,8 @@ # include <mln/morpho/meyer_wst.hh> # include <mln/morpho/min.hh> # include <mln/morpho/minus.hh> -# include <mln/morpho/opening_area.hh> -# include <mln/morpho/opening_attribute.hh> # include <mln/morpho/opening.hh> +# include <mln/morpho/opening/all.hh> # include <mln/morpho/plus.hh> # include <mln/morpho/Rd.hh> # include <mln/morpho/rank_filter.hh> Index: trunk/milena/mln/morpho/essential.hh =================================================================== --- trunk/milena/mln/morpho/essential.hh (revision 3443) +++ trunk/milena/mln/morpho/essential.hh (revision 3444) @@ -41,8 +41,8 @@ # include <mln/morpho/includes.hh> # include <mln/morpho/laplacian.hh> # include <mln/morpho/meyer_wst.hh> -# include <mln/morpho/opening_area.hh> -# include <mln/morpho/opening_attribute.hh> +# include <mln/morpho/opening/area.hh> +# include <mln/morpho/opening/attribute.hh> # include <mln/morpho/opening.hh> # include <mln/morpho/rank_filter.hh> # include <mln/morpho/top_hat.hh>

15 years, 9 months

milena r3445: Add sharpness accumulator

by Edwin Carlinet

URL: https://svn.lrde.epita.fr/svn/oln/trunk/milena ChangeLog: 2009-02-28 Edwin Carlinet <carlinet(a)lrde.epita.fr> Add sharpness accumulator. * morpho/attribute/sharpness.hh: New. --- sharpness.hh | 224 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 224 insertions(+) Index: trunk/milena/mln/morpho/attribute/sharpness.hh =================================================================== --- trunk/milena/mln/morpho/attribute/sharpness.hh (revision 0) +++ trunk/milena/mln/morpho/attribute/sharpness.hh (revision 3445) @@ -0,0 +1,224 @@ +// Copyright (C) 2007, 2008, 2009 EPITA Research and Development +// Laboratory (LRDE) +// +// This file is part of the Olena Library. This library is free +// software; you can redistribute it and/or modify it under the terms +// of the GNU General Public License version 2 as published by the +// Free Software Foundation. +// +// This library is distributed in the hope that it will be useful, +// but WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +// General Public License for more details. +// +// You should have received a copy of the GNU General Public License +// along with this library; see the file COPYING. If not, write to +// the Free Software Foundation, 51 Franklin Street, Fifth Floor, +// Boston, MA 02111-1307, USA. +// +// As a special exception, you may use this file as part of a free +// software library without restriction. Specifically, if other files +// instantiate templates or use macros or inline functions from this +// file, or you compile this file and link it with other files to +// produce an executable, this file does not by itself cause the +// resulting executable to be covered by the GNU General Public +// License. This exception does not however invalidate any other +// reasons why the executable file might be covered by the GNU General +// Public License. + +#ifndef MLN_MORPHO_ATTRIBUTE_SHARPNESS_HH +# define MLN_MORPHO_ATTRIBUTE_SHARPNESS_HH + +/// \file mln/morpho/attribute/sharpness.hh +/// +/// Define an accumulator that computes the sharpness of a +/// component. (sharpness = volume of the component / volume of box bounding the component. + +# include <mln/core/concept/accumulator.hh> +# include <mln/accu/internal/base.hh> +# include <mln/morpho/attribute/volume.hh> +# include <mln/morpho/attribute/height.hh> + + +namespace mln +{ + + // Forward declaration. + namespace morpho { + namespace attribute { + template <typename I> + class sharpness; + } + } + + + // Traits. + + namespace trait + { + + template <typename I> + struct accumulator_< morpho::attribute::sharpness > + { + typedef accumulator::has_untake::no has_untake; + typedef accumulator::has_set_value::no has_set_value; + typedef accumulator::has_stop::no has_stop; + typedef accumulator::when_pix::use_v when_pix; + }; + + } // end of namespace mln::trait + + + namespace morpho + { + + namespace attribute + { + + /// Sharpness accumulator class. + /// + /// The parameter \p I is the image type on which the accumulator + /// of pixels is built. + template <typename I> + struct sharpness + : public mln::accu::internal::base< double, sharpness > + { + typedef mln_value(I) argument; + + sharpness(); + + /// Manipulators. + /// \{ + void init(); + + void take(const mln_value(I)& v); + void take(const sharpness& other); + + void take_as_init(const mln_value(I)& v); + /// \} + + /// Get the value of the accumulator. + double to_result() const; + + /// Check whether this accu is able to return a result. + /// Always true here. + bool is_valid() const; + + /// Give the area of the component. + unsigned area() const; + + /// Give the height. + unsigned height() const; + + /// Give the volume of the component. + unsigned volume() const; + + protected: + /// The height of the component. + typename mln::morpho::attribute::height height_; + /// The volume of the component. + typename mln::morpho::attribute::volume volume_; + }; + + + +# ifndef MLN_INCLUDE_ONLY + + template <typename I> + inline + sharpness::sharpness() + { + init(); + } + + template <typename I> + inline + void + sharpness::init() + { + volume_.init(); + } + + template <typename I> + inline + void + sharpness::take(const mln_value(I)& v) + { + if (! is_valid()) + { + take_as_init(v); + return; + } + volume_.take(v); + height_.take(v); + } + + template <typename I> + inline + void + sharpness::take(const sharpness& other) + { + mln_invariant(is_valid()); + volume_.take(other.volume_); + height_.take(other.height_); + } + + template <typename I> + inline + void + sharpness::take_as_init(const mln_value(I)& v) + { + volume_.take_as_init(v); + height_.take_as_init(v); + } + + template <typename I> + inline + double + sharpness::to_result() const + { + return (double)volume_.to_result() / (double)(volume_.area() * height_.to_result()); + } + + template <typename I> + inline + unsigned + sharpness::area() const + { + return volume_.area(); + } + + template <typename I> + inline + unsigned + sharpness::volume() const + { + return volume_.to_result(); + } + + template <typename I> + inline + unsigned + sharpness::height() const + { + return height_.to_result(); + } + + template <typename I> + inline + bool + sharpness::is_valid() const + { + return volume_.is_valid() && height_.is_valid(); + } + +# endif // ! MLN_INCLUDE_ONLY + + } // end of namespace mln::morpho::attribute + + } // end of namespace mln::morpho + +} // end of namespace mln + + +#endif // ! MLN_MORPHO_ATTRIBUTE_SHARPNESS_HH

15 years, 9 months

← Newer
1
2
3
4
5
6
7
8
...
27
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Olena-patches February 2009