#170: Get rid of typedef mln::internal::image_base::coord
-------------------------+--------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: enhancement | Status: new
Priority: minor | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: point |
-------------------------+--------------------------------------------------
In source:branches/cleanup-2008/milena/mln/core/internal/image_base.hh,
`mln::internal::image_base` defines a typedef `coord`, which reduces the
genericity of this class:
{{{
#!cpp
/// Coordinate associated type.
typedef mln_deduce(S, site, coord) coord;
}}}
A consequence is that the site type `S::site` must define an associated
type `coord` (hence `std::vector<point2d>` is not a valid site type), yet
we had decided that there should be no prerequisites on the interfaces of
sites in Milena.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/170>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#168: Revamp mln::topo::internal::complex_data<D>
-------------------------+--------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: enhancement | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: cleanup |
-------------------------+--------------------------------------------------
See source:branches/cleanup-2008/milena/mln/topo/complex.hh
* Store only the indices of adjacent faces in `complex_data<D>`: we don't
really need actual faces there, and it costs a lot (memory, execution
time, design complexity, etc.)
* Then (or concurrently) simplify the design: use an array of array
instead of an ad hoc type list.
* The '''dynamic''' access(es) to the set of ''n''-faces of a complex
(e.g., `mln::complex::nfaces(unsigned)`) has (have) a linear complexity!
We should get rid of that. We could create an index at the creation of
the complex, mapping dynamic dimension numbers to the corresponding
(static) mixin/data.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/168>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing 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.
#171: Complete and factor the classic/regular point types
------------------------------+---------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: code duplication |
------------------------------+---------------------------------------------
Several tasks, that may be performed independently:
* Add `mln::point1df` and `mln::point2df`.[[BR]]
(Class `mln::point3df` is already implemented, see
source:branches/cleanup-2008/milena/mln/core/alias/point3df.hh.)
* For ''N'' in {1, 2, 3}, factor the implementation of
`mln::point`''N''`d` and `mln::point`''N''`df`.[[BR]]
(See
* source:branches/cleanup-2008/milena/mln/core/alias/point3d.hh, and
* source:branches/cleanup-2008/milena/mln/core/alias/point3df.hh,
which share most of their code!)
Remark: all these types are located in `mln/core/alias/`, but they are
more than mere aliases; move them elsewhere?
--
Ticket URL: <https://trac.lrde.org/olena/ticket/171>
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.
#161: Implement more complex psite iterators
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: task | Status: new
Priority: major | Milestone:
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
As of r2148, we only have a single piter couple on complex :
`mln::p_complex_fwd_piter_` and `mln::p_complex_bkd_piter_`
(source:trunk/milena/mln/core/p_complex_piter.hh:2148).
Comments (FIXMEs) at the end of
source:trunk/milena/tests/core/complex_image.cc:2148 suggest to add these
additional iterators:
* iterators on ''n''-faces with ''n'' fixed in [0, ''d''] (using
`mln::p_faces` and `mln::faces_psite`?)
* iterators on ''n''-faces with ''n'' in a subset of [0, ''d''];
* etc.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/161>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#140: Add points having floating-point coordinates
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: task | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
Name regular instances `point1df`, `point2df` and `point3df`.
(N.B.: Aroune will need them so as to build the 3-d surface graph from a
set of triangles.)
--
Ticket URL: <https://trac.lrde.org/olena/ticket/140>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#162: Implement windows, neighborhoods, and corresponding iterators for complex-
based images
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: task | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
For a given (fixed) dimension ''n'' and a psite ''p'' on a ''n''-face,
implement windows/neighborhoods (and corresponding iterators) returning
* the set of (''n''-1)-faces adjacent to ''p'' (using ``mln::p_faces``
and ``mln::faces_psite``?);
* the set of (''n''+1)-faces adjacent to ''p'' (using ``mln::p_faces``
and ``mln::faces_psite``?);
* the set of ''n''-faces sharing a (''n''-1)-face with ''p'';
* the set of ''n''-faces sharing a (''n''-1)-face or (''n''-2)-face (by
transitivity) with ''p'' (is it useful?);
* the set of the faces in the ``cell'' including ''p'' (named
``''p''-hat'' in
couprie.08.pami), i.e., the set of all ''m''-faces adjacent to ''p'',
where ''m'' is in [0, ''n''-1].[[BR]]
In that definition, ''p'' is said adjacent to an ''m''-face ''q'' if
there is a sequence (''m,,1,,'', ''m,,2,,'', ..., ''m,,k,,'') of faces so
that
* ''m,,1,,'' is an (''n''-1)-face adjacent to ''p'' ;
* ''m,,2,,'' is an (''n''-2)-face adjacent to ''m,,1,,'' ;
* ... (and so on)
* ''m,,k,,'' is an (''m''+1)-face adjacent to ''q''.
* what else?
As in #139, we might want to factor things using implementation classes:
* ``mln::internal::complex_vicinity``
* ``mln::internal::complex_vicinity_piter``
We might even be able to factor them with graph-based ones.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/162>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.