#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.
#182: Repair Swilena
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: defect | Status: new
Priority: minor | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
[source:trunk/swilena Swilena] is broken since the end of Summer 2008
(before the merging back of [source:branches/cleanup-2008 cleanup-2008/]
into [source:trunk/ trunk/]). Have it compile and pass the tests again.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/182>
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.
#130: Don not pass neighborhoods as argument to algorithms
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: defect | Status: new
Priority: major | Milestone: Olena 1.0ß
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
Neighborhoods shall be bound to images: they are a property of them.
Hence an algorithm (at least a facade) shall not accept an image along
with an ''external'' neighborhood. Most of the time, these algorithms are
based on windows improperly called neighborhoods.
Here is the list of files to revamp, as of revision 1663:
* source:trunk/labeling/level.spe.hh
* source:trunk/labeling/regional_maxima.hh
* source:trunk/labeling/regional_minima.hh
* source:trunk/make/voronoi.hh
* source:trunk/milena/mln/geom/labeling/blobs.hh
* source:trunk/milena/mln/geom/seeds2tiling_roundness.hh
* source:trunk/milena/mln/labeling/background.hh
* source:trunk/milena/mln/labeling/flat_zones.hh
* source:trunk/milena/mln/labeling/foreground.hh
* source:trunk/milena/mln/labeling/level.hh
* source:trunk/morpho/Rd.hh
* source:trunk/morpho/dilation.hh
* source:trunk/morpho/opening_area.hh
* source:trunk/morpho/opening_attribute.hh
--
Ticket URL: <https://trac.lrde.org/olena/ticket/130>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image library.
