#134: Overhaul the generation of the documentation
-------------------------+--------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: enhancement | Status: new
Priority: major | Milestone: Olena 1.0ß
Component: Milena | Version: 1.0
Keywords: doc |
-------------------------+--------------------------------------------------
Changes introduced in r1606 downgraded many features that were present
before! In particular, source:trunk/milena/doc/Doxyfile.in has been
downgraded from Doxygen version 1.5.2 to Doxygen 1.5.1 (why!?).
Let's start again on a sound basis. The best way is probably to reused
`Doxyfile.in` from a previous revision (e.g,
source:trunk/milena/doc/Doxyfile.in#1476), and add current features (e.g.,
double documentation generation).
--
Ticket URL: <https://trac.lrde.org/olena/ticket/134>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#147: Write a script to automatically generate file skeletons for Olena
-----------------------+----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: trivial | Milestone:
Component: Milena | Version: 1.0
Keywords: generator |
-----------------------+----------------------------------------------------
A Ruby script would be nice, but the language doesn't really matter.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/147>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#160: Revamp complexes
----------------------------+-----------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: enhancement | Status: new
Priority: minor | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: cleanup rename |
----------------------------+-----------------------------------------------
* Move complexes from `mln/core/` to `mln/topo/`.
* 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. Ask Roland for details.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/160>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#188: Implement more windows, neighborhoods, and corresponding iterators for
complex-based images
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: task | Status: new
Priority: minor | Milestone: Olena 1.1
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
This ticket is a sequel to #162.
In addition to the neighborhoods, windows, and iterators for complex-based
images from #162, implement windows/neighborhoods (and corresponding
iterators) returning the following elements (where ''n'' is a (fixed)
dimension and ''p'' a psite on an ''n''-face).
`complex_cell_window`:: 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 transitively 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''.
`complex_boundary_cell_window`:: Likewise, but excluding ''p'' (named «
''p''-hat* » in couprie.08.pami).
And maybe:
`complex_lower_dims_connected_window`:: the set of ''n''-faces sharing a
(''n''-1)-face or (''n''-2)-face etc. (by transitivity) with ''p'' (is it
useful?);
`complex_higher_dims_connected_window`:: the set of ''n''-faces sharing a
(''n''+1)-face or (''n''+2)-face etc. (by transitivity) with ''p'' (is it
useful?);
* 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);
* we could have one or several generic classes, using static or dynamic
predicates, to implement those windows and neighborhoods.
Note that some of these iterators might implement operators on complexes,
see
http://en.wikipedia.org/wiki/Simplicial_complex#Closure.2C_star.2C_and_link.
Do not forget to update [wiki:Olena/ComplexBasedImages].
--
Ticket URL: <https://trac.lrde.org/olena/ticket/188>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#139: Factor common code shared by graph-related piters, windows and
neighborhoods
--------------------------+-------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: enhancement | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: graph factor |
--------------------------+-------------------------------------------------
This tasks refers to these classes:
* `mln::graph_elt_window`
* `mln::graph_elt_neighborhood`
* `mln::line_graph_elt_window`
* `mln::line_graph_elt_neighborhood`
* `mln::graph_window_fwd_piter`
* `mln::graph_window_bkd_piter`
* `mln::graph_neighborhood_fwd_piter`
* `mln::graph_neighborhood_bkd_piter`
* `mln::line_graph_window_fwd_piter`
* `mln::line_graph_window_bkd_piter`
* `mln::line_graph_neighborhood_fwd_piter`
* `mln::line_graph_neighborhood_bkd_piter`
Note: we should factor other graph-related classes as well (psites,
images, etc.), but this is less urgent; open another ticket to handle
those.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/139>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#185: Unify algorithms morpho::skeleton_constrained and
topo::breadth_first_thinning
-------------------------+--------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: enhancement | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
Two (very similar) skeletonization algorithms have been developed:
1. source:trunk/milena/mln/morpho/skeleton_constrained.hh
2. source:trunk/milena/mln/topo/skeleton/breadth_first_thinning.hh
The first algorithm is probably a bit more generic, as it takes a priority
function as input. It has not been tested on complex-based images (known
to be supported by the second algorithm).
Unify both algorithm (within `topo/skeleton/`), probably using a canvas.
Some elements like the constraint or the priority function should provide
default values; the only mandatory arguments should be the input image,
the neighborhood and the simplicity function.
Do not forget to move/adjust corresponding tests/programs accordingly.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/185>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#145: Add a n-dimensional regular image type on a cubical/rectangular grid
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
This image type, e.g.
{{{
#cpp
template <unsigned Dim, typename T>
class regular_image
}}}
(with `Dim` being the dimension and `T` the value type) would generalize
`image1d`, `image2d` and `image3d`.
* First, develop a version with no support for borders.
* Then, add support for borders.
See the code in Olena 0.11: a similar image type was present in this
version.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/145>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#138: Factor code between native and BGL-based graph structures
---------------------------------+------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: boost graphs factor |
---------------------------------+------------------------------------------
This is a continuing work of #123.
* Ensure the native and BGL-based graphs offer the same services.
* Ensure graph-based images can be built upon any of these categories of
graphs.
* Milena should provide a uniform interface, whatever the graph engine
used (native or BGL-based).
* Moreover, `configure` should check for the BGL presence and usability,
and disable the BGL-based code when needed (at least in tests, and in
compiled tools -- we should install headers, even if the BGL is not
present, IMHO).
--
Ticket URL: <https://trac.lrde.org/olena/ticket/138>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#169: Lighten the repository
-------------------------+--------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: enhancement | Status: new
Priority: minor | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
Getting a fresh working copy from the repository takes time, as there are
many medium- or big-sized files (images and meshes). We should probably
remove some of them, or move them elsewhere.
Of course, we should remove most of these files from the distribution as
well.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/169>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.