May 2011 - Olena-patches

[Olena] #160: Revamp complexes
by Olena 29 Aug '13

29 Aug '13

#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.

2 12

[Olena] #227: List of dependencies out of date in the wiki
by Olena Trac 29 Aug '13

29 Aug '13

#227: List of dependencies out of date in the wiki --------------------------+------------------------------------------------- Reporter: jonathan | Owner: Olena Team Type: defect | Status: new Priority: major | Milestone: Component: Milena | Version: 1.0 Keywords: Dependencies | --------------------------+------------------------------------------------- In the download page, [http://www.lrde.epita.fr/cgi- bin/twiki/view/Olena/Download], the list of dependencies is out of date. Especially for the git repository version, additional dependencies are needed to build the documentation. It should be clarified in the wiki or the building procedure should be improved. ****************** A non exhaustive(?) list of dependencies: autogen automake1.7 autoconf make g++ libboost-dev texlive-latex-base texlive-extra-utils pgf HeVeA latex2html doxygen imagemagick dot2tex -- Ticket URL: <https://trac.lrde.org/olena/ticket/227> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

1 2

[Olena] #232: Update contributors' list on Olena's Web site
by Olena Trac 25 Jul '13

25 Jul '13

#232: Update contributors' list on Olena's Web site ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: task | Status: new Priority: major | Milestone: Olena 1.1 Component: Web | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- This page : https://www.lrde.epita.fr/cgi-bin/twiki/view/Olena/Contributors should be updated with the latest version (e.g., from branch `next`) of this file : source:AUTHORS Better: write a script to automate the conversion, so as to simplify the process of updating this page down to a copy-and-paste operation. -- Ticket URL: <https://trac.lrde.org/olena/ticket/232> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

1 2

[Olena] #236: Implement a VTK loader
by Olena Trac 12 Feb '13

12 Feb '13

#236: Implement a VTK loader ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: task | Status: new Priority: minor | Milestone: Olena 1.1 Component: Milena | Version: 1.0 Keywords: I/O | ----------------------+----------------------------------------------------- I.e., `mln::io::vtk::load`. See also source:milena/mln/io/vtk/save.hh. -- Ticket URL: <https://trac.lrde.org/olena/ticket/236> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

1 1

[Olena] #188: Implement more windows, neighborhoods, and corresponding iterators for complex-based images
by Olena Trac 12 Feb '13

12 Feb '13

#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.

1 1

[Olena] #139: Factor common code shared by graph-related piters, windows and neighborhoods
by Olena 05 Dec '12

05 Dec '12

#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.

2 6

[Olena] #185: Unify algorithms morpho::skeleton_constrained and topo::breadth_first_thinning
by Olena Trac 05 Dec '12

05 Dec '12

#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.

1 2

[Olena] #145: Add a n-dimensional regular image type on a cubical/rectangular grid
by Olena 05 Dec '12

05 Dec '12

#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.

2 3

[Olena] #138: Factor code between native and BGL-based graph structures
by Olena 05 Dec '12

05 Dec '12

#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.

2 3

[Olena] #231: Split the implementation of graph in two : fast vs safe
by Olena Trac 05 Dec '12

05 Dec '12

#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.

1 1