January 2010 - Olena-patches

[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] #209: Fix copyright headers in documentation
by Olena Trac 30 Nov '12

30 Nov '12

#209: Fix copyright headers in documentation ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: defect | Status: new Priority: minor | Milestone: Olena 1.1 Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- LaTeX files in milena/doc/ have the special clause: {{{ As a special exception, you may use this file as part of a free software library without restriction. Specifically, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other files to produce an executable, this file does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. }}} which is meaningless! Remove it. Moreover, we might want to consider another license for the documentation, like the GNU FDL or the LPPL (I'm not sure the GPL is suited for documentation). EDIT: The products (e.g. `tutorial.pdf`) have FDL headers! WTF? -- Ticket URL: <https://trac.lrde.org/olena/ticket/209> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

1 2

[Olena] #169: Lighten the repository
by Olena 30 Nov '12

30 Nov '12

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

2 5

[Olena] #222: Clean up the Git repository
by Olena Trac 29 Nov '12

29 Nov '12

#222: Clean up the Git repository -----------------------------+---------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: task | Status: new Priority: minor | Milestone: Component: Olena | Version: 1.0 Keywords: rewrite history | -----------------------------+---------------------------------------------- Warning, this requires a whole rewriting of the repository with `git- filter-branch`. Notify users in advance. To be performed during vacations? Tasks: * Author name: s/Nicolas Croiset/Tristan Croiset/. * Remove copyrighted files. * ... (list them here) * What else? -- Ticket URL: <https://trac.lrde.org/olena/ticket/222> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

1 1

[Olena] #202: Document build procedures
by Olena Trac 29 Nov '12

29 Nov '12

#202: Document build procedures ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: task | Status: new Priority: critical | Milestone: Component: Trac | Version: 1.0 Keywords: gcc icpc | ----------------------+----------------------------------------------------- Write a Trac page (several pages?) on these topics: * Why `make` is the way to go. * Why you should (normally) run `bootstrap` only once. * Why you should (normally) run `configure` only once per build directory. * How to build Olena with the Intel C++ Compiler (ICC) * By setting it a build time (not very good). * By setting it a configuration time (better). * By setting it in a `config.site` file (the best). * How to automate things using `CONFIG_SITE`. * Why compiling from Emacs (using `M-x compile`) is better than... * ...Compiling with `make` from a terminal. * ...Compiling with `g++` from a terminal (arg!). This is not restricted to Olena, so we might want to move this material elsewhere later. -- Ticket URL: <https://trac.lrde.org/olena/ticket/202> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

1 2

[Olena] #224: Automatically generate ChangeLog entries
by Olena Trac 29 Nov '12

29 Nov '12

#224: Automatically generate ChangeLog entries -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: new Priority: major | Milestone: Component: Milena | Version: 1.0 Keywords: | -------------------------+-------------------------------------------------- Instead of documenting changes both in Git messages ''and'' !ChangeLog entries, just rely on the first and generate the latter. Use Jim Meyering's `git-to-changelog` script. * http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=build- aux/gitlog-to-changelog * http://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/gitlog-to- changelog We can pick some hints and ideas here: * http://git.savannah.gnu.org/cgit/coreutils.git/plain/HACKING * http://git.savannah.gnu.org/cgit/coreutils.git/plain/Makefile.am * http://cyberelk.net/tim/2009/06/25/generating-changelog-files-from- commit-logs/ I suggest we still 1. Record the !ChangeLog into the repository, so that we can fix it (and keep the fixes!). 1. Keep the date of the last !ChangeLog generation so that we generate only the missing entries next time. There's a additional problem with Olena's repository: we have several !ChangeLogs and the system should be either smart enough to find the right !ChangeLog (!ChangeLogs?) or accept tags/metadata to generate entries at the right place. -- Ticket URL: <https://trac.lrde.org/olena/ticket/224> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

1 3