October 2008 - Olena-patches

[Olena] #128: Handle carefully tests using X11
by Olena 10 Jun '09

10 Jun '09

#128: Handle carefully tests using X11 ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: defect | Status: new Priority: major | Milestone: Olena 1.0ß Component: Milena | Version: 1.0 Keywords: test | ----------------------+----------------------------------------------------- Some tests require X11 visualization programs such as `display` (from !ImageMagick) or `xv`. This is an issue since * the they might not be installed on the machine; * the host/session on which tests are executed might not run a X11 display. IMHO, we could either 1. move them out of the `check` target (and have them launched by the `check-all`/`check-full` target, or a check-x11 target); or 2. have `configure` check whether the required programs are present, as well as a (usable) X11 session. (Maybe the Vaucanson Team ran into such questions; ask them.) -- Ticket URL: <https://trac.lrde.org/olena/ticket/128> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image library.

2 2

[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] #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