- Olena-patches

[Olena] #171: Complete and factor the classic/regular point types
by Olena 18 May '09

18 May '09

#171: Complete and factor the classic/regular point types ------------------------------+--------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: task | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: code duplication | ------------------------------+--------------------------------------------- Several tasks, that may be performed independently: * Add `mln::point1df` and `mln::point2df`.[[BR]] (Class `mln::point3df` is already implemented, see source:branches/cleanup-2008/milena/mln/core/alias/point3df.hh.) * For ''N'' in {1, 2, 3}, factor the implementation of `mln::point`''N''`d` and `mln::point`''N''`df`.[[BR]] (See * source:branches/cleanup-2008/milena/mln/core/alias/point3d.hh, and * source:branches/cleanup-2008/milena/mln/core/alias/point3df.hh, which share most of their code!) Remark: all these types are located in `mln/core/alias/`, but they are more than mere aliases; move them elsewhere? -- Ticket URL: <https://trac.lrde.org/olena/ticket/171> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

[Olena] #153: Write a test using Ubigraph
by Olena 18 May '09

18 May '09

#153: Write a test using Ubigraph -----------------------------------+---------------------------------------- Reporter: levill_r | Owner: Olena Team Type: task | Status: new Priority: trivial | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: rendering third-party | -----------------------------------+---------------------------------------- Ubigraph is a promising graph manipulation and visualization project: * http://ubietylab.net/ubigraph/ We could write a small test exercising its display capabilities, e.g., the construction of a skeleton on a binary, graph-based image (even a 2-D image on a regular grid). Check the license(s); the client part is Free Software, but the server doesn't seem so. -- Ticket URL: <https://trac.lrde.org/olena/ticket/153> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

[Olena] #143: Reorganize milena/mln/core/
by Olena 18 May '09

18 May '09

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

2 3

Re: [Olena-patches] [Olena] #114: Add support for libfitsio
by Olena Trac 18 May '09

18 May '09

#114: Add support for libfitsio -----------------------+---------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: task | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: autoconf m4 macro -----------------------+---------------------------------------------------- Changes (by levill_r): * milestone: Olena 1.1 => Olena 1.0 Comment: Set back to milestone:"Olena 1.0". Postpone again to milestone:"Olena 1.1" if we do not have enough time. -- Ticket URL: <https://trac.lrde.org/olena/ticket/114#comment:5> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

1 0

[Olena] #167: Write iterators on complexes
by Olena 18 May '09

18 May '09

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

2 6

[Olena] #161: Implement more complex psite iterators
by Olena 18 May '09

18 May '09

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

2 3

[Olena] #140: Add points having floating-point coordinates
by Olena 18 May '09

18 May '09

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

2 1

[PATCH 2/2] Adjust the documentation of 2- and 3-dimensional point types.
by Roland Levillain 18 May '09

18 May '09

* mln/core/alias/point2d.hh, mln/core/alias/point3d.hh: Here. --- milena/ChangeLog | 6 ++++++ milena/mln/core/alias/point2d.hh | 15 +++++++++------ milena/mln/core/alias/point3d.hh | 8 ++++---- 3 files changed, 19 insertions(+), 10 deletions(-) diff --git a/milena/ChangeLog b/milena/ChangeLog index 1bea379..6c85c11 100644 --- a/milena/ChangeLog +++ b/milena/ChangeLog @@ -1,5 +1,11 @@ 2009-05-18 Roland Levillain <roland(a)lrde.epita.fr> + Adjust the documentation of 2- and 3-dimensional point types. + + * mln/core/alias/point2d.hh, mln/core/alias/point3d.hh: Here. + +2009-05-18 Roland Levillain <roland(a)lrde.epita.fr> + Add a floating-point 1-dimensional point type. * mln/core/alias/point1d.hh (mln::point1df): New. diff --git a/milena/mln/core/alias/point2d.hh b/milena/mln/core/alias/point2d.hh index 898cf92..5bf7d9c 100644 --- a/milena/mln/core/alias/point2d.hh +++ b/milena/mln/core/alias/point2d.hh @@ -1,5 +1,5 @@ -// Copyright (C) 2007, 2008, 2009 EPITA Research and Development Laboratory -// (LRDE) +// 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 @@ -31,11 +31,12 @@ /// \file mln/core/alias/point2d.hh /// -/// Definition of the mln::point2d alias and of its construction -/// routine. +/// Definition of the mln::point2d and mln::point2df aliases and of +/// their construction routines. # include <mln/core/point.hh> -# include <mln/core/concept/site_proxy.hh> // For site_const_impl and site_mutable_impl. +// For site_const_impl and site_mutable_impl. +# include <mln/core/concept/site_proxy.hh> # include <mln/core/internal/force_exact.hh> @@ -44,8 +45,10 @@ namespace mln /// Type alias for a point defined on the 2D square grid with /// integer coordinates. - /// typedef point<mln::grid::square, mln::def::coord> point2d; + + /// Type alias for a point defined on the 2D square grid with + /// floating-point coordinates. typedef point<mln::grid::square, mln::def::coordf> point2df; diff --git a/milena/mln/core/alias/point3d.hh b/milena/mln/core/alias/point3d.hh index ceff9c1..81296c8 100644 --- a/milena/mln/core/alias/point3d.hh +++ b/milena/mln/core/alias/point3d.hh @@ -1,5 +1,5 @@ -// Copyright (C) 2007, 2008, 2009 EPITA Research and Development Laboratory -// (LRDE) +// 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 @@ -31,8 +31,8 @@ /// \file mln/core/alias/point3d.hh /// -/// Definition of the mln::point3d alias and of its construction -/// routine. +/// Definition of the mln::point3d and mln::point3df aliases and of +/// their construction routines. # include <mln/core/point.hh> // For site_const_impl and site_mutable_impl: -- 1.6.2.4

1 0

[PATCH 1/2] Add a floating-point 1-dimensional point type.
by Roland Levillain 18 May '09

18 May '09

* mln/core/alias/point1d.hh (mln::point1df): New. Adjust documentation. --- milena/ChangeLog | 7 +++++++ milena/mln/core/alias/point1d.hh | 13 ++++++++----- 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/milena/ChangeLog b/milena/ChangeLog index b1a2676..1bea379 100644 --- a/milena/ChangeLog +++ b/milena/ChangeLog @@ -1,3 +1,10 @@ +2009-05-18 Roland Levillain <roland(a)lrde.epita.fr> + + Add a floating-point 1-dimensional point type. + + * mln/core/alias/point1d.hh (mln::point1df): New. + Adjust documentation. + 2009-05-18 Guillaume Sadegh <sadegh(a)lrde.epita.fr> New tests for browsing on graphs. diff --git a/milena/mln/core/alias/point1d.hh b/milena/mln/core/alias/point1d.hh index ac13d44..6fd8477 100644 --- a/milena/mln/core/alias/point1d.hh +++ b/milena/mln/core/alias/point1d.hh @@ -31,8 +31,8 @@ /// \file mln/core/alias/point1d.hh /// -/// Definition of the mln::point1d alias and of its construction -/// routine. +/// Definition of the mln::point1d and mln::point1df aliases and of +/// their construction routines. # include <mln/core/point.hh> // For site_const_impl and site_mutable_impl. @@ -43,11 +43,14 @@ namespace mln { - /// Type alias for a point defined on the 1D square grid with - /// integer coordinates. - // + /// Type alias for a point defined on the 1D ruler with integer + /// coordinates. typedef point<grid::tick, def::coord> point1d; + /// Type alias for a point defined on the 1D ruler with + /// floating-point coordinates. + typedef point<grid::tick, def::coordf> point1df; + namespace internal { -- 1.6.2.4

1 0

3850: Fix compilation issues in graph first search.
by Guillaume Lazzara 18 May '09

18 May '09

* mln/canvas/browsing/internal/graph_first_search.hh: add new routine 'next'. --- milena/ChangeLog | 7 ++++ .../canvas/browsing/internal/graph_first_search.hh | 38 ++++++++++++++++++- 2 files changed, 43 insertions(+), 2 deletions(-) diff --git a/milena/ChangeLog b/milena/ChangeLog index 06ccdcd..28473f7 100644 --- a/milena/ChangeLog +++ b/milena/ChangeLog @@ -1,3 +1,10 @@ +2009-05-18 Guillaume Lazzara <lazzara(a)lrde.epita.fr> + + Fix compilation issues in graph first search. + + * mln/canvas/browsing/internal/graph_first_search.hh: add new routine + 'next'. + 2009-05-15 Guillaume Lazzara <lazzara(a)lrde.epita.fr> Fix tests. diff --git a/milena/mln/canvas/browsing/internal/graph_first_search.hh b/milena/mln/canvas/browsing/internal/graph_first_search.hh index 66020f8..a8f4537 100644 --- a/milena/mln/canvas/browsing/internal/graph_first_search.hh +++ b/milena/mln/canvas/browsing/internal/graph_first_search.hh @@ -66,6 +66,8 @@ */ # include <deque> +# include <queue> +# include <stack> # include <mln/core/concept/iterator.hh> # include <mln/core/concept/browsing.hh> # include <mln/core/concept/graph.hh> @@ -90,7 +92,7 @@ namespace mln class C> class graph_first_search_t : public Browsing< E > { - typedef C<unsigned> container_t; + typedef C<util::vertex_id_t> container_t; public: template <typename G, typename F> void operator()(const Graph<G>&, F& f) const; @@ -100,6 +102,38 @@ namespace mln # ifndef MLN_INCLUDE_ONLY + + /// Call the correct member on the container. + + template <typename T> + inline + util::vertex_id_t + next(const std::queue<T>& queue) + { + return queue.front(); + } + + template <typename T> + inline + util::vertex_id_t + next(const std::stack<T>& stack) + { + return stack.top(); + } + + template <typename S> + inline + util::vertex_id_t + next(const S& stack) + { + /// Not defined yet! + mlc_abort(S)::check(); + return 0; + } + + + + template <typename E, template <typename T, typename Sequence = std::deque<T> > class C> @@ -124,7 +158,7 @@ namespace mln f.new_component_from_vertex(v.id()); // <--- new_component_from_vertex while (!queue.empty()) { - util::vertex<G> current_v = g.vertex(queue.front()); + util::vertex<G> current_v = g.vertex(next(queue)); f.process_vertex(current_v.id()); // <--- process_vertex queue.pop(); for (unsigned nv = 0; nv < current_v.nmax_nbh_vertices(); ++nv) -- 1.5.6.5

1 0