Olena-patches April 2009

olena-patches@lrde.epita.fr

11 participants
187 discussions

[Olena] #152: Add a debug mode to Milena

by Olena

#152: Add a debug mode to Milena -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: enhancement | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | -------------------------+-------------------------------------------------- Like the Debug mode of the GNU C++ Library (http://gcc.gnu.org/onlinedocs/libstdc++/manual/spine.html), Milena should provide a debug mode that could be switched on/off with a macro definition. This debug mode should * integrate [source:trunk/milena/mln/core/contract.hh mln/core/contract.hh]'s macros (like `mln_assertion`): * add (and merge with current) dynamic checks where applicable (as in the GNU C++ Library's Debug Mode); * add (and merge with current) static checks where applicable (as in GNU C++ Library's Compile Time Checks); * trigger the debug mode of the GNU C++ Library (http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html), where applicable; * trigger Compile Time Checks from the GNU C++ Library (http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch29.html), where applicable; * and possibly: undef `NDEBUG` (`-UNDEBUG`) to ensure C++'s `assert`'s are checked. -- Ticket URL: <https://trac.lrde.org/olena/ticket/152> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

15 years, 5 months

[Olena] #179: Float precision issues with epsilon

by Olena

#179: Float precision issues with epsilon ---------------------+------------------------------------------------------ Reporter: lazzara | Owner: Olena Team Type: defect | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | ---------------------+------------------------------------------------------ In level::stretch, we use float variables to do the following: {{{ float epsilon = mln_epsilon(float), M = mln_max(V) + 0.5f - epsilon, m = 0.0f - 0.5f + epsilon; }}} 'm' is precise enough since it is a really low value. However, M is not precise enough since mln_max(V) may be a high value, so we will loose decimal precision if we store that number as float. As a result, M is always equal to 'mln_max(V) + 0.5' which introduce a bug in level::stretch. This issue can be avoided by using double variables instead, but do we really want that? Don't we want to handle that issue in a more generic way? -- Ticket URL: <https://trac.lrde.org/olena/ticket/179> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

15 years, 5 months

[Olena] #165: Separate sites sets from their psites?

by Olena

#165: Separate sites sets from their psites? ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: proposal | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Many files containing the definitions site sets, located in source:branches/cleanup-2008/milena/mln/core/site_set/, include the related psite and piters. Split them into several files? (And add convenience headers including all of them?) -- Ticket URL: <https://trac.lrde.org/olena/ticket/165> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

15 years, 5 months

[Olena] #155: Reuse existing script to factor the Makefile machinery in Swilena

by Olena

#155: Reuse existing script to factor the Makefile machinery in Swilena -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: new Priority: minor | Milestone: Olena 1.0 Component: Swilena | Version: 1.0 Keywords: | -------------------------+-------------------------------------------------- For instance, there are parts to be factored in source:trunk/swilena/python/Makefile.am. See what TC, Olena 0.11 and clspr used. -- Ticket URL: <https://trac.lrde.org/olena/ticket/155> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

15 years, 6 months

[Olena] #184: Clean the bread-first thinning (skeleton) algorithm

by Olena Trac

#184: Clean the bread-first thinning (skeleton) algorithm ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: defect | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- * Use `image_if` and operator `|` when it is compatible with `complex_image` in source:trunk/milena/apps/statues/mesh_complex_skel.cc. * Likewise in source:trunk/milena/mln/topo/detach.hh. * Use a cell iterator (when available) in the implementation of `mln::make::cell` (source:trunk/milena/mln/make/cell.hh). * Make `mln::topo::is_facet` (source:trunk/milena/mln/topo/is_facet.hh) a method of `mln::complex_psite` (or even of `mln::topo::face`). * Address various `FIXME`s in source:trunk/milena/mln/topo/skeleton/breadth_first_thinning.hh. * Implement the other algorithm (''A1'') from couprie.08.pami to check the simplicity of a cell in source:trunk/milena/mln/topo/is_simple_cell (and factor). -- Ticket URL: <https://trac.lrde.org/olena/ticket/184> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

15 years, 6 months

[Olena] #156: Kill a maximum of warnings in Swilena

by Olena

#156: Kill a maximum of warnings in Swilena -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: new Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | -------------------------+-------------------------------------------------- The Python wrappers have been written quickly, and they lack some information (base classes, etc.), making `swig` emit a lot of warnings. Most of them are harmless, however they clutter the output of the build. Get rid of them. -- Ticket URL: <https://trac.lrde.org/olena/ticket/156> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

15 years, 6 months

[Olena] #128: Handle carefully tests using X11

by Olena

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

15 years, 6 months

[Olena] #125: Ambiguity in comparaison with literals

by Olena

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

15 years, 6 months

[Olena] #183: Have mln::complex_image be more flexible w.r.t. its domain

by Olena Trac

#183: Have mln::complex_image be more flexible w.r.t. its domain -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: new Priority: critical | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: site set | -------------------------+-------------------------------------------------- `mln::complex_image` makes it mandatory us to assign values to ''each'' face of a complex. But sometimes, we are only interested by a subset of a complex (e.g., its edges). We should have the choice of the domain of a `mln::complex_image`. Hint: see how Guillaume revamped the graph-based images, using functions (i.e. domain + value -> image). I (Roland) still consider actual images types are desirable, but we could implement them as wrappers of function- based images. I have set the priority of this ticket to 2 (« critical ») because we really need this feature for the examples of the ISMM'09 and DGCI'09 submissions. -- Ticket URL: <https://trac.lrde.org/olena/ticket/183> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

15 years, 6 months

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

by Olena

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

15 years, 6 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Olena-patches April 2009