#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.
#231: Split the implementation of graph in two : fast vs safe
-------------------------+--------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: enhancement | Status: new
Priority: major | Milestone: Olena 1.1
Component: Milena | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
(Re)start a branch revamp-graph:
* Create a safe version of `util::graph` (as well as associated types :
vertex, edge), having the same interface as the original.
* Then remove all unnecessary code from the current version to have a
truly fast version (in particular, remove pointers to graph in vertex and
edge descriptors).
* Factor as much as possible, of course.
* And document.
* Further work: try to apply the same recipe to complexes, and adjust
`p_complex`, `complex_image`, etc. as well, to support both
implementations (fast and safe), possibly with a mechanism selecting one
version by default.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/231>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#253: convert::from_to is not flexible for the user
---------------------+------------------------------------------------------
Reporter: lazzara | Owner: lazzara
Type: defect | Status: new
Priority: major | Milestone:
Component: Milena | Version: 2.0
Keywords: |
---------------------+------------------------------------------------------
convert::from_to allows the user to convert values to another value type.
Current mechanism does not allow the user to provide its own conversion
functions.
To add a new conversion function, an overload of from_to_() must be
declared in the namespace mln::convert::over_load.
A forward declaration must be added to from_to.hxx in order to make it
taken into account by g++ while resolving the overloaded functions. This
way, we ensure the fact that g++ is aware of this definition at the very
beginning.
This method is intrusive and definitely error prone since the forward
declarations may not be maintained correctly.
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/253>
Olena <http://olena.lrde.epita.fr>
Olena, a software platform dedicated to image processing.
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Olena, a generic and efficient image processing platform".
The branch try-next has been deleted
was 856f489ee9fbbfde026dddff7377f7a27e7c9452
-----------------------------------------------------------------------
856f489ee9fbbfde026dddff7377f7a27e7c9452 Fix compilation in Scribo.
-----------------------------------------------------------------------
hooks/post-receive
--
Olena, a generic and efficient image processing platform