#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.
#157: Improve depency tracking in Swilena
-------------------------+--------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: enhancement | Status: new
Priority: minor | Milestone: Olena 1.0
Component: Swilena | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
Our hand-made build system does not seem to track dependencies very well
in Swilena/Python. Improve this.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/157>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing 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.
#149: Revamp util::graph
-------------------------+--------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: enhancement | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
* Get rid of superfluous dynamic allocations (w.r.t. vertices & edges
handling).
* Move properties attached to vertices and edges out of the graph (this
should allow the merging of `util::graph` and
`util::internal::graph_base`.
* Allow the removal of vertices and edges. Don't forget to warn users
about the invalidation of vertex and edge ids (handlers).
* Stop using the term « id » (« identifier ») for vertices and edges, and
prefer the term « handler » ? (The BGL call them « descriptors ».)
All these changes might bring us closer to the BGL' `adjacency_list`. See
how we could factor things, while not requiring a dependency on the BGL.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/149>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#153: Write a test using Ubigraph
-----------------------------------+----------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: trivial | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: rendering third-party |
-----------------------------------+----------------------------------------
Ubigraph is a promising graph manipulation and visualization project:
* http://ubietylab.net/ubigraph/
We could write a small test exercising its display capabilities, e.g., the
construction of a skeleton on a binary, graph-based image (even a 2-D
image on a regular grid).
Check the license(s); the client part is Free Software, but the server
doesn't seem so.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/153>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#143: Reorganize milena/mln/core/
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: minor | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
(This ticket is just a proposal. We might close it even if no change
occur in `milena/mln/core`.)
There are many things in source:trunk/milena/mln/core/, that could be
reorganized and/or split in several directories/subdirectories:
* basic/classic images and entites (`mln::image2d`, etc.)
* graph-based images and entities (`mln::graph_image`, etc.)
* non classic images and associated tools (`mln::rle_image`, etc.)
* morphers (`mln::cast_image`, etc.)
* internal/core mechanisms (`initialize.hh` etc.)
* general tools (`contract.hh`, `inplace.hh`, etc.)
* concepts (though they are located in their own directory,
`mln/core/concept/`)
* implementation/factoring classes (thought most of them are in
`mln/core/internal/`)
* other entities, that should be moved elsewhere (`mln::h_vec`, etc.)
* and so on.
To my (Roland) mind, we should:
1. Identify the different kind of files present in `core/`.
2. Assign one (maybe two) kinds to each file of this directory.
3. Determine a new file layout, and perform the moves.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/143>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#167: Write iterators on complexes
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: task | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
Most of this task is described in
[source:branches/cleanup-2008/milena/tests/topo/complex.cc
tests/topo/complex.cc] (r2411) :
{{{
/*------------------------------.
| Iterators on adjacent faces. |
`------------------------------*/
/* FIXME: Write and exercise more iterators (see
milena/tests/core/complex_image.cc) and ticket #162
(https://trac.lrde.org/olena/ticket/162) */
/* Iterate on the the set of (n-1)-faces adjacent to AF.
Note: this can be solved with iterators where the dimension can
be either static or dynamic.
Let's start with a dynamic one, as it would allow us to
write something like this:
mln_fwd_citer_(topo::complex<D>) f(c);
mln_fwd_lower_nciter(topo::complex<D>) n(c);
for_all(c)
for_all(n)
// ...
(Note: we might want to get rid of the name `citer', and use
`fiter' everywhere.).
A static version might be useful (and more efficient) too.
Likewise, our iterators on n-faces (both faces_piter and
complex_faces_piter) use a static `n'. We should also have
n-faces iterators where n could be dynamic.
But first, we need to clarify (existing) names.
-----------------------------------------------------------------
Current name New name Definition
-----------------------------------------------------------------
complex<D> (n/a) General complex
face<N, D> face_data<N, D> Face data
face_handle<N, D> n_face<N, D> (Static) n-face handle
faces_set<N, D> n_faces_set<N, D> Set of face handles
any_face_handle<D> face<D> Dynamic face handle
complex_fwd_iter_<D>(c) face_fwd_iter<D>(c) | Iterators on all
complex_bkd_iter_<D>(c) face_bkd_iter<D>(c) | faces of c
complex_iter_base_<F, E> complex_iter_base<F, E>
| Factoring base
| class.
-----------------------------------------------------------------
(Note: get rid of trailing underscores, even for entities in
mln::internal::.)
Next, write these:
-----------------------------------------------------------------
Name Definition
-----------------------------------------------------------------
n_faces_fwd_iter<D>(c) | Iterators on n-faces,
n_faces_bkd_iter<D>(c) | n being dynamic
adj_lower_faces_fwd_iter<D>(c, f) | Iterators on the adjacent
adj_lower_faces_bkd_iter<D>(c, f) | (lower) (n-1)-faces of the
| n-face f of the complex c,
| n being dynamic
adj_higher_faces_fwd_iter<D>(c, f) | Iterators on the adjacent
adj_higher_faces_bkd_iter<D>(c, f) | (higher) (n+1)-faces of the
| n-face f of the complex c,
| n being dynamic
adj_lower_dim_connected_n_faces_fwd_iter<D>(c, f)
adj_lower_dim_connected_n_faces_bkd_iter<D>(c, f)
(FIXME: These names are admittedly too long.)
| Iterators on the the set of
| n-faces sharing an adjacent
| (n-1)-face with f, n being
| dynamic
adj_higher_dim_connected_n_faces_fwd_iter<D>(c, f)
adj_higher_dim_connected_n_faces_bkd_iter<D>(c, f)
(FIXME: These names are admittedly too long.)
| Iterators on the the set of
| n-faces sharing an adjacent
| (n+1)-face with f, n being
| dynamic
cell_fwd_iter<D>(c, f) | Iterators on the set of the
cell_bkd_iter<D>(c, f) | faces in the « cell »
| including p, i.e. the set of
| all m-faces adjacent to p,
| where m is in [0, n-1];
| this set is name « f-hat »
cell_boundary_fwd_iter<D>(c, f) | Likewise, but excluding p;
cell_boundary_bkd_iter<D>(c, f) | this set is named « p-hat* »
-----------------------------------------------------------------
We could also have generic iterators based on predicated, and
even use them to provide first (non efficient) implementations of
the iterators from the previous list.
-----------------------------------------------------------------
Name Definition
-----------------------------------------------------------------
generic_face_fwd_iter<D>(c, pred) | Generic face iterators on c
generic_face_bkd_iter<D>(c, pred) | using predicate pred to
| define the iterated subset.
-----------------------------------------------------------------
I'm unsure about the following existing iterators; should we keep
them? What are they good for, except testing our code?
-----------------------------------------------------------------
Current name Definition
-----------------------------------------------------------------
complex_faces_fwd_iter_<N, D> Iterators on N-faces, N being
complex_faces_fwd_iter_<N, D> static, acting as proxies of
face_handle<N, D>'s.
faces_fwd_iter_<N, D> Iterators on N-faces, N being
faces_fwd_iter_<N, D> static, acting as proxies of
any_face_handle<N, D>'s.
-----------------------------------------------------------------
*/
}}}
(This should be turned into actual documentation, BTW.)
See also #162 for applications of these iterators in windows/neighborhoods
and images.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/167>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
