#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.
#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.
#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.
#172: Experiment SCOOP 1.5/2 with C++0x concepts
-------------------------+--------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: enhancement | Status: new
Priority: trivial | Milestone: Olena 2.0
Component: Olena-NG | Version: 2.0
Keywords: |
-------------------------+--------------------------------------------------
What I call SCOOP 1.5 is the paradigm currently used in Milena 1.0 (as of
Nov. 2008), and SCOOP 2 the paradigm described in the MPOOL'08 paper (used
in Olena-NG).
--
Ticket URL: <https://trac.lrde.org/olena/ticket/172>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#148: Missing files in the distribution of Olena 0.11
------------------------+---------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: defect | Status: new
Priority: trivial | Milestone: Olena 0.11.1
Component: Milena | Version: 0.11
Keywords: EXTRA_DIST |
------------------------+---------------------------------------------------
Reported by Théo, relaunching `bootstrap.sh` from a distributed tarball of
Olena 0.11:
{{{
este% ./bootstrap.sh
sh: Can't open ./cleanup.sh
sh: Can't open ./gen_filelists.sh
}}}
--
Ticket URL: <https://trac.lrde.org/olena/ticket/148>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#126: Speed up tests
-------------------------+--------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: enhancement | Status: new
Priority: major | Milestone: Olena 1.0ß
Component: Milena | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
Some tests take a very long time to execute. Main causes are:
* input image(s) are too big [[BR]] => they should be reduced (sometimes,
testing on `lena.pgm` is just too costly);
* the default, non-optimized compilation settings (`-O0 -ggdb`) produces
very inefficient code for certain algorithms [[BR]] => we should locally
increase the level of optimization (e.g., `-O1` or `-O2`) for these tests,
and '''document''' this in `Makefile.am` (explain why we made changes in
`CXXFLAGS` for a given test).
We might want to make a list of lengthy tests here before solving this
ticket.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/126>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image library.
