December 2008 - Olena-patches

[Olena] #178: Improve the way Trimesh is handled within Olena
by Olena 27 May '09

27 May '09

#178: Improve the way Trimesh is handled within Olena ----------------------------------------+----------------------------------- Reporter: levill_r | Owner: Olena Team Type: enhancement | Status: new Priority: major | Milestone: Olena 1.0 Component: Olena | Version: 1.0 Keywords: distribution configuration | ----------------------------------------+----------------------------------- Motivation/rationale: 1. Most Olena users do not want Trimesh. 1. We probably get rid of Trimesh someday (I need to check-in some replacement code first!). To do: * Add a `--with-trimesh` option in source:trunk/configure.ac, along with an Automake conditional (e.g., `WITH_TRIMESH`), set to `no` by default. * Use this conditional to enable/disable the trimesh directory in the `SUBDIRS` variable of source:trunk/external/Makefile.am. -- Ticket URL: <https://trac.lrde.org/olena/ticket/178> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

[Olena] #175: Use std::vector to store data of mln::image[123]d<T>
by Olena 27 May '09

27 May '09

#175: Use std::vector to store data of mln::image[123]d<T> ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: proposal | Status: new Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Currently, the following classes use plain dynamically-allocated memory to store their data (values): * source:trunk/milena/mln/core/image/image1d.hh * source:trunk/milena/mln/core/image/image2d.hh * source:trunk/milena/mln/core/image/image2d_h.hh * source:trunk/milena/mln/core/image/image3d.hh We could try to replace these arrays with `std::vectors`. Pros: * Automatic memory management. * Direct access (using pointers) is still possible, thanks to the ISO/IEC C++ Standard; see paragraph 23.2.4.1: "(...) The elements of a vector are stored contiguously, meaning that if `v` is a `vector<T, Allocator>` where `T` is some type other than `bool`, then it obeys the identity `&v[n] == &v[0] + n` for all `0 <= n < v.size()`". * Optimized storage for boolean values, thanks to the `std::vector<bool>` specialization. Cons: * We can't iterate on an `std::vector<bool>` using a pointer; but we can provide optimized specialization for that very case, that could as fast as pointer iterations (IMHO). -- Ticket URL: <https://trac.lrde.org/olena/ticket/175> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 2

[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