#178: Improve the way Trimesh is handled within Olena
----------------------------------------+-----------------------------------
Reporter: levill_r | Owner: Olena Team
Type: enhancement | Status: new
Priority: major | Milestone: Olena 1.0
Component: Olena | Version: 1.0
Keywords: distribution configuration |
----------------------------------------+-----------------------------------
Motivation/rationale:
1. Most Olena users do not want Trimesh.
1. We probably get rid of Trimesh someday (I need to check-in some
replacement code first!).
To do:
* Add a `--with-trimesh` option in source:trunk/configure.ac, along with
an Automake conditional (e.g., `WITH_TRIMESH`), set to `no` by default.
* Use this conditional to enable/disable the trimesh directory in the
`SUBDIRS` variable of source:trunk/external/Makefile.am.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/178>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#175: Use std::vector to store data of mln::image[123]d<T>
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: proposal | Status: new
Priority: minor | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
Currently, the following classes use plain dynamically-allocated memory to
store their data (values):
* source:trunk/milena/mln/core/image/image1d.hh
* source:trunk/milena/mln/core/image/image2d.hh
* source:trunk/milena/mln/core/image/image2d_h.hh
* source:trunk/milena/mln/core/image/image3d.hh
We could try to replace these arrays with `std::vectors`.
Pros:
* Automatic memory management.
* Direct access (using pointers) is still possible, thanks to the ISO/IEC
C++ Standard; see paragraph 23.2.4.1:
"(...) The elements of a vector are stored contiguously, meaning that
if `v` is a `vector<T, Allocator>` where `T` is some type other than
`bool`, then it obeys the identity `&v[n] == &v[0] + n` for all `0 <= n <
v.size()`".
* Optimized storage for boolean values, thanks to the `std::vector<bool>`
specialization.
Cons:
* We can't iterate on an `std::vector<bool>` using a pointer; but we can
provide optimized specialization for that very case, that could as fast as
pointer iterations (IMHO).
--
Ticket URL: <https://trac.lrde.org/olena/ticket/175>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#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.
