June 2009 - Olena-patches

[Olena] #136: Delegate rgb operators
by Olena 13 Jul '09

13 Jul '09

#136: Delegate rgb operators ----------------------------------+----------------------------------------- Reporter: garrigues | Owner: Olena Team Type: enhancement | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: vectorial values rgb | ----------------------------------+----------------------------------------- Some operators on rgb values are defined (see source:trunk/milena/mln/value/rgb.hh). FIXME: We should not need to define these operators, thanks to Milena's global operator resolution mechanism based on mln::Object. See what prevent us to use this mechanism. For example : There a no operators defined on int_u values because in source:trunk/milena/mln/value/ops.hh we delegate the operation on int_u and on all Scalar<V> to the equivalent type. We could do the same for vectorial values. it will avoid duplicating metal::vec operators in rgb. We could also introduce an new concept : arithmetic value which by default, use operators of its equiv type. -- Ticket URL: <https://trac.lrde.org/olena/ticket/136> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

[Olena] #146: Ensure the output value type is large enough in labeling algorithms
by Olena 13 Jul '09

13 Jul '09

#146: Ensure the output value type is large enough in labeling algorithms -------------------------------+-------------------------------------------- Reporter: levill_r | Owner: levill_r Type: defect | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: overflow labeling | -------------------------------+-------------------------------------------- Most labeling algorithm do not check that the output value is large enough to hold the whole set of labels. This is at least the case in * source:trunk/milena/mln/labeling/regional_minima.hh * source:trunk/milena/mln/labeling/regional_maxima.hh * source:trunk/milena/mln/morpho/meyer_wst.hh These algorithms should trigger an error if this happens, even if the output value type is not equipped to detect overflows. -- Ticket URL: <https://trac.lrde.org/olena/ticket/146> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

[Olena] #150: Deducing/computing the « complementary » neighborhood
by Olena 13 Jul '09

13 Jul '09

#150: Deducing/computing the « complementary » neighborhood --------------------------+------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: task | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: connectivity | --------------------------+------------------------------------------------- (Suggested by Aroune.) Some algorithms require two neighborhoods: one for the objects of an image (foreground), and one for the background. Most of the time, the latter can be deduced (or computed) from the former, and ''vice versa'' (there might be some cases where a choice can occur, but we'll leave this aside for the moment). * Write a routine for the simplest cases (regular grids). * Search for a general definition (presumably expressed in the context of complexes) to extend this routine to the complex cases (graph-based domains, etc.) -- Ticket URL: <https://trac.lrde.org/olena/ticket/150> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

[Olena] #151: Comparison operators (equality) on (concrete) windows and neighborhoods
by Olena 13 Jul '09

13 Jul '09

#151: Comparison operators (equality) on (concrete) windows and neighborhoods ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: defect | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- (Suggested by Aroune.) Define missing `operator==` on concrete windows and neighborhoods, so that we can compare them : {{{ #!cpp if (nbh == c8()) /// ... }}} -- Ticket URL: <https://trac.lrde.org/olena/ticket/151> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

[Olena] #152: Add a debug mode to Milena
by Olena 13 Jul '09

13 Jul '09

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

2 1

[Olena] #179: Float precision issues with epsilon
by Olena 13 Jul '09

13 Jul '09

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

2 2

[Olena] #165: Separate sites sets from their psites?
by Olena 13 Jul '09

13 Jul '09

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

2 1

[Olena] #191: Support g++ 3.4
by Olena Trac 10 Jul '09

10 Jul '09

#191: Support g++ 3.4 -------------------------+-------------------------------------------------- Reporter: theo | Owner: theo Type: enhancement | Status: new Priority: critical | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | -------------------------+-------------------------------------------------- g++ 3.4 is the default compiler on Cygwin. -- Ticket URL: <https://trac.lrde.org/olena/ticket/191> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

1 2

« Build successful »
by Roland Levillain 30 Jun '09

30 Jun '09

https://buildfarm.lrde.org/buildfarm/oln/ Recent Builds: * (Jun 30 17:53) rev=[4224] success #264: build successful [...] Linux dallas 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux Woohoo. The release seems close! We still need to clean up a few things: - fix builds on other hosts/platforms; - choose a license for the documentation; - ensure some files are up to date (NEWS, INSTALL, etc.); - prepare an announce [1]; - etc. I'll check the remaining tickets tomorrow. Notes: [1] Like this one: https://www.lrde.epita.fr/pipermail/vaucanson/2009q2/000860.html

1 0

4224: tests/morpho/closing/approx/Makefile.am: add test outputs to CLEANFILES.
by Guillaume Lazzara 30 Jun '09

30 Jun '09

--- milena/ChangeLog | 5 +++++ milena/tests/morpho/closing/approx/Makefile.am | 7 +++++++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/milena/ChangeLog b/milena/ChangeLog index a8e29fe..5fa5f9c 100644 --- a/milena/ChangeLog +++ b/milena/ChangeLog @@ -1,5 +1,10 @@ 2009-06-30 Guillaume Lazzara <guillaume.lazzara(a)lrde.epita.fr> + * tests/morpho/closing/approx/Makefile.am: add test outputs to + CLEANFILES. + +2009-06-30 Guillaume Lazzara <guillaume.lazzara(a)lrde.epita.fr> + Regen headers.mk and unit-tests.mk. * milena/headers.mk, diff --git a/milena/tests/morpho/closing/approx/Makefile.am b/milena/tests/morpho/closing/approx/Makefile.am index 8afb5a9..c9eb6b6 100644 --- a/milena/tests/morpho/closing/approx/Makefile.am +++ b/milena/tests/morpho/closing/approx/Makefile.am @@ -25,3 +25,10 @@ check_PROGRAMS = \ structural_SOURCES = structural.cc TESTS = $(check_PROGRAMS) + + +# FIXME: each test should clean its output, temporary output should +# not be cleaned up by make. +CLEANFILES = \ + out.pbm \ + ref.pbm -- 1.5.6.5

1 0