#126: Speed up tests
-------------------------+--------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: enhancement | Status: new
Priority: major | Milestone: Olena 1.0ß
Component: Milena | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
Some tests take a very long time to execute. Main causes are:
* input image(s) are too big [[BR]] => they should be reduced (sometimes,
testing on `lena.pgm` is just too costly);
* the default, non-optimized compilation settings (`-O0 -ggdb`) produces
very inefficient code for certain algorithms [[BR]] => we should locally
increase the level of optimization (e.g., `-O1` or `-O2`) for these tests,
and '''document''' this in `Makefile.am` (explain why we made changes in
`CXXFLAGS` for a given test).
We might want to make a list of lengthy tests here before solving this
ticket.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/126>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image library.
#129: Reintegrate oln.m4 (full or a part of it) into Olena 1.0
-----------------------------------+----------------------------------------
Reporter: levill_r | Owner: levill_r
Type: enhancement | Status: new
Priority: minor | Milestone: Olena 1.0ß
Component: Olena | Version: 1.0
Keywords: configure autoconf M4 |
-----------------------------------+----------------------------------------
In Olena 0.11, `oln.m4` (which might be renamed to `olena.m4`) provided
useful services to both the Olena package (search for libraries, set up
flags for tests, etc.) and autoconfiscated packages using Olena, by
providing a `--with-oln` (to be renamed to `--with-olena`) flag.
We should reintegrate a part of these features, possibly in two M4 macro
packages:
* one for Olena,
* one for Olena-based projects.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/129>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image library.
#173: Complete the graph fusion example started with Géraud Béguin
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: minor | Milestone:
Component: other | Version: 1.0
Keywords: IGR |
----------------------+-----------------------------------------------------
See:
* source:branches/cleanup-2008/milena/sandbox/beguin/irm.cc
* source:branches/cleanup-2008/milena/sandbox/beguin/fusion_graph.hh
--
Ticket URL: <https://trac.lrde.org/olena/ticket/173>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#132: Use gcov
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: major | Milestone: Olena 1.0ß
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
1. Use `gcov` to check which parts of Olena are actually covered
(instantiated and checked) by the test suite.
1. Automate with make.
1. Optionally use the LTP GCOV Extension (`lcov`) :
http://ltp.sourceforge.net/coverage/lcov.php
--
Ticket URL: <https://trac.lrde.org/olena/ticket/132>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image library.
#181: Improve the download page
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: proposal | Status: new
Priority: minor | Milestone: Olena 1.0
Component: other | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
Some Web sites of software projects asks for some (non mandatory)
information before proceeding to download. For instance, each download
link from the [http://www.itksnap.org/ ITK-SNAP] project redirects to a
page similar to this one :
http://www.itksnap.org/download/snap/register.php?link=itksnap-1.6.0.1-2008…
where the user is invited to give some information (name,
company/organization, etc.). The next page offers the user the
opportunity to subscribe to one or several of the project's mailing
list(s), then starts the download.
I (Roland) think this would useful to have something similar on the Olena
download page.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/181>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#124: Ensure I/O operations on images holding greater-than-8-bit values are
robust w.r.t. endianness
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: minor | Milestone: Olena 1.0ß
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
This might be difficult to check, since it's platform-dependant. At
least, we should check this (with the build farm) on a host with an
endianness different than IA-32's or Intel 64's (e.g., a SPARC station).
According to http://en.wikipedia.org/wiki/Endianness,
* Intel IA-32 (and probably Intel 64 and AMD 64) are little-endian;
* Motorola 68k, Sun SPARC and IBM System/370 processors are little-
endian;
* PowerPC, ARM, DEC Alpha, MIPS, HP PA-RISC and Intel IA-64 processors
are bi-endian.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/124>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image library.
#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.
#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.
#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.
#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.