April 2009 - Olena-patches

[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] #182: Repair Swilena
by Olena 15 May '09

15 May '09

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

2 2

[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

[Olena] #130: Don not pass neighborhoods as argument to algorithms
by Olena 14 May '09

14 May '09

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

2 11