November 2008 - Olena-patches

[Olena] #170: Get rid of typedef mln::internal::image_base::coord
by Olena 27 May '09

27 May '09

#170: Get rid of typedef mln::internal::image_base::coord -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: enhancement | Status: new Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: point | -------------------------+-------------------------------------------------- In source:branches/cleanup-2008/milena/mln/core/internal/image_base.hh, `mln::internal::image_base` defines a typedef `coord`, which reduces the genericity of this class: {{{ #!cpp /// Coordinate associated type. typedef mln_deduce(S, site, coord) coord; }}} A consequence is that the site type `S::site` must define an associated type `coord` (hence `std::vector<point2d>` is not a valid site type), yet we had decided that there should be no prerequisites on the interfaces of sites in Milena. -- Ticket URL: <https://trac.lrde.org/olena/ticket/170> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 2

[Olena] #168: Revamp mln::topo::internal::complex_data<D>
by Olena 18 May '09

18 May '09

#168: Revamp mln::topo::internal::complex_data<D> -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: cleanup | -------------------------+-------------------------------------------------- See source:branches/cleanup-2008/milena/mln/topo/complex.hh * Store only the indices of adjacent faces in `complex_data<D>`: we don't really need actual faces there, and it costs a lot (memory, execution time, design complexity, etc.) * Then (or concurrently) simplify the design: use an array of array instead of an ad hoc type list. * The '''dynamic''' access(es) to the set of ''n''-faces of a complex (e.g., `mln::complex::nfaces(unsigned)`) has (have) a linear complexity! We should get rid of that. We could create an index at the creation of the complex, mapping dynamic dimension numbers to the corresponding (static) mixin/data. -- Ticket URL: <https://trac.lrde.org/olena/ticket/168> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 2

[Olena] #149: Revamp util::graph
by Olena 18 May '09

18 May '09

#149: Revamp util::graph -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | -------------------------+-------------------------------------------------- * Get rid of superfluous dynamic allocations (w.r.t. vertices & edges handling). * Move properties attached to vertices and edges out of the graph (this should allow the merging of `util::graph` and `util::internal::graph_base`. * Allow the removal of vertices and edges. Don't forget to warn users about the invalidation of vertex and edge ids (handlers). * Stop using the term « id » (« identifier ») for vertices and edges, and prefer the term « handler » ? (The BGL call them « descriptors ».) All these changes might bring us closer to the BGL' `adjacency_list`. See how we could factor things, while not requiring a dependency on the BGL. -- Ticket URL: <https://trac.lrde.org/olena/ticket/149> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

3 7

[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

[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

[Olena] #162: Implement windows, neighborhoods, and corresponding iterators for complex-based images
by Olena 14 May '09

14 May '09

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

2 11