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