#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.
#177: Provide safe value types to represent sizes
---------------------------------------+------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: proposal | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: conversion cast promotion |
---------------------------------------+------------------------------------
For instance we currently use either `unsigned` (bad) or `std::size_t`
(less bad) to represent a size (or a cardinal), but none of them is really
safe: as Théo and Matthieu recently said, adding an `int` with an
`unsigned` can lead to unexpected results.
We should provide safe replacement type(s) (or merely typedef(s) over
existing safe types), and stop using unsafe C++ built-in types.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/177>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#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.
