September 2008 - Olena-patches

[Olena] #125: Ambiguity in comparaison with literals
by Olena 09 Jun '09

09 Jun '09

#125: Ambiguity in comparaison with literals --------------------------------+------------------------------------------- Reporter: garrigues | Owner: theo Type: defect | Status: new Priority: major | Milestone: Olena 1.0ß Component: Milena | Version: 1.0 Keywords: literals operators | --------------------------------+------------------------------------------- This test shows the problem : {{{ #!cpp # include <mln/value/gl8.hh> # include <mln/literal/all.hh> int main() { using mln::value::gl8; using mln::literal::white; gl8 b; b == white; } }}} The compiler can't find the right operator== to compate graylevel with literals. Here is the error output : {{{ test.cc: In function 'int main()': test.cc:11: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: ../../mln/literal/ops.hh:252: note: candidate 1: typename mln::trait::op::eq<O, O>::ret mln::operator==(const mln::Object<E>&, const mln::Literal<L>&) [with O = mln::value::graylevel<8u>, L = mln::literal::white_t] ../../mln/value/internal/gray_f.hh:317: note: candidate 2: bool mln::value::operator==(const mln::value::Integer<I>&, const mln::value::graylevel_f&) [with I = mln::value::graylevel<8u>] }}} -- Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/125> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image library.

2 1

[Olena] #163: Decide into what mln_?iter(T) should expand
by Olena 09 Jun '09

09 Jun '09

#163: Decide into what mln_?iter(T) should expand ---------------------------------+------------------------------------------ Reporter: levill_r | Owner: Olena Team Type: proposal | Status: new Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: convention shortcut | ---------------------------------+------------------------------------------ In source:trunk/milena/mln/core/macros.hh, the macros {{{ #!cpp mln_?iter(T) mln_?iter_(T) }}} expand as {{{ #!cpp typename T::fwd_?iter T::fwd_?iter }}} Shouldn't they expand as {{{ #!cpp typename T::?iter T::?iter }}} ? -- Ticket URL: <https://trac.lrde.org/olena/ticket/163> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 3

[Olena] #157: Improve depency tracking in Swilena
by Olena 09 Jun '09

09 Jun '09

#157: Improve depency tracking in Swilena -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: enhancement | Status: new Priority: minor | Milestone: Olena 1.0 Component: Swilena | Version: 1.0 Keywords: | -------------------------+-------------------------------------------------- Our hand-made build system does not seem to track dependencies very well in Swilena/Python. Improve this. -- Ticket URL: <https://trac.lrde.org/olena/ticket/157> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 2

[Olena] #144: Fix load (and maybe save) routine(s) for ASCII-encoded PBM images
by Olena 29 May '09

29 May '09

#144: Fix load (and maybe save) routine(s) for ASCII-encoded PBM images -------------------------------------+-------------------------------------- Reporter: levill_r | Owner: Olena Team Type: defect | Status: new Priority: critical | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: I/O IO input output pbm | -------------------------------------+-------------------------------------- Théo discovered on May 28, 2008 that the load routine for ASCII-encoded PBM (boolean) images was broken (and maybe the save routine, too). The other ASCII-based Netpbm should be checked as well. Don't close this ticket until all of these routine have been inspected and declared safe! -- Ticket URL: <https://trac.lrde.org/olena/ticket/144> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 2

[Olena] #122: [TRAITS] image_if_base
by Olena 28 May '09

28 May '09

#122: [TRAITS] image_if_base ---------------------+------------------------------------------------------ Reporter: duhamel | Owner: Olena Team Type: defect | Status: new Priority: major | Milestone: Olena 1.0ß Component: Milena | Version: 1.0 Keywords: | ---------------------+------------------------------------------------------ In source:trunk/milena/mln/core/internal/image_if_base.hh data trait is suspect. For example an image_if from an image1d has always data trait raw ! -- Ticket URL: <https://trac.lrde.org/olena/ticket/122> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image library.

2 1

[Olena] #131: Implement area closing and attribue closing
by Olena 28 May '09

28 May '09

#131: Implement area closing and attribue closing --------------------------------------------------------+------------------- Reporter: levill_r | Owner: Olena Team Type: defect | Status: new Priority: minor | Milestone: Static 1.0 Component: Milena | Version: 1.0 Keywords: completion dual naming routines algorithms | --------------------------------------------------------+------------------- Currently, these files are available: * source:trunk/morpho/mln/opening_area.hh * source:trunk/morpho/mln/opening_attribute.hh but there is no equivalent for closings. Implement them. BTW, these files and their routines are called `opening_area` and `opening_attribute`, which is not elegant. Of course the goal is to put forward the opening term; but IMHO, we should use namespace to do this, not prefixes. Or rename them to `area_opening` and `attribute_opening`, which are much more natural. Anyway, any further discussion on the subject of naming algorithms should be carried on in another ticket. -- Ticket URL: <https://trac.lrde.org/olena/ticket/131> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image 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] #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