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