- Olena-patches

Re: [Olena-patches] [Olena] #84: Olena 1.0 Code Examples (as documentation)
by Olena Trac 13 Jul '09

13 Jul '09

#84: Olena 1.0 Code Examples (as documentation) -----------------------+---------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: task | Status: closed Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: fixed | Keywords: doc -----------------------+---------------------------------------------------- Changes (by levill_r): * status: new => closed * resolution: => fixed -- Ticket URL: <https://trac.lrde.org/olena/ticket/84#comment:3> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

1 0

Re: [Olena-patches] [Olena] #7: Miscellaneous tasks related to the Olena 1.0 release process
by Olena Trac 13 Jul '09

13 Jul '09

#7: Miscellaneous tasks related to the Olena 1.0 release process -----------------------+---------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: task | Status: closed Priority: major | Milestone: Olena 1.0 Component: Olena | Version: 1.0 Resolution: fixed | Keywords: release NEWS dates copyright headers sandbox -----------------------+---------------------------------------------------- Changes (by levill_r): * status: new => closed * resolution: => fixed Comment: Mostly done. We do not check for Boost Tuple, just warn about in `README`. -- Ticket URL: <https://trac.lrde.org/olena/ticket/7#comment:15> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

1 0

Re: [Olena-patches] [Olena] #85: Ensure the milena/tests/ hierarchy follows milena/mln/'s one
by Olena Trac 13 Jul '09

13 Jul '09

#85: Ensure the milena/tests/ hierarchy follows milena/mln/'s one -----------------------+---------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: task | Status: closed Priority: critical | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by levill_r): * status: new => closed * resolution: => fixed -- Ticket URL: <https://trac.lrde.org/olena/ticket/85#comment:4> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

1 0

[Olena] #146: Ensure the output value type is large enough in labeling algorithms
by Olena 13 Jul '09

13 Jul '09

#146: Ensure the output value type is large enough in labeling algorithms -------------------------------+-------------------------------------------- Reporter: levill_r | Owner: levill_r Type: defect | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: overflow labeling | -------------------------------+-------------------------------------------- Most labeling algorithm do not check that the output value is large enough to hold the whole set of labels. This is at least the case in * source:trunk/milena/mln/labeling/regional_minima.hh * source:trunk/milena/mln/labeling/regional_maxima.hh * source:trunk/milena/mln/morpho/meyer_wst.hh These algorithms should trigger an error if this happens, even if the output value type is not equipped to detect overflows. -- Ticket URL: <https://trac.lrde.org/olena/ticket/146> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

[Olena] #150: Deducing/computing the « complementary » neighborhood
by Olena 13 Jul '09

13 Jul '09

#150: Deducing/computing the « complementary » neighborhood --------------------------+------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: task | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: connectivity | --------------------------+------------------------------------------------- (Suggested by Aroune.) Some algorithms require two neighborhoods: one for the objects of an image (foreground), and one for the background. Most of the time, the latter can be deduced (or computed) from the former, and ''vice versa'' (there might be some cases where a choice can occur, but we'll leave this aside for the moment). * Write a routine for the simplest cases (regular grids). * Search for a general definition (presumably expressed in the context of complexes) to extend this routine to the complex cases (graph-based domains, etc.) -- Ticket URL: <https://trac.lrde.org/olena/ticket/150> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

[Olena] #151: Comparison operators (equality) on (concrete) windows and neighborhoods
by Olena 13 Jul '09

13 Jul '09

#151: Comparison operators (equality) on (concrete) windows and neighborhoods ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: defect | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- (Suggested by Aroune.) Define missing `operator==` on concrete windows and neighborhoods, so that we can compare them : {{{ #!cpp if (nbh == c8()) /// ... }}} -- Ticket URL: <https://trac.lrde.org/olena/ticket/151> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

[Olena] #152: Add a debug mode to Milena
by Olena 13 Jul '09

13 Jul '09

#152: Add a debug mode to Milena -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: enhancement | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | -------------------------+-------------------------------------------------- Like the Debug mode of the GNU C++ Library (http://gcc.gnu.org/onlinedocs/libstdc++/manual/spine.html) Milena should provide a debug mode that could be switched on/off with a macro definition. This debug mode should * integrate [source:trunk/milena/mln/core/contract.hh mln/core/contract.hh]'s macros (like `mln_assertion`): * add (and merge with current) dynamic checks where applicable (as in the GNU C++ Library's Debug Mode); * add (and merge with current) static checks where applicable (as in GNU C++ Library's Compile Time Checks); * trigger the debug mode of the GNU C++ Library (http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html) where applicable; * trigger Compile Time Checks from the GNU C++ Library (http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch29.html) where applicable; * and possibly: undef `NDEBUG` (`-UNDEBUG`) to ensure C++'s `assert`'s are checked. -- Ticket URL: <https://trac.lrde.org/olena/ticket/152> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

[Olena] #179: Float precision issues with epsilon
by Olena 13 Jul '09

13 Jul '09

#179: Float precision issues with epsilon ---------------------+------------------------------------------------------ Reporter: lazzara | Owner: Olena Team Type: defect | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | ---------------------+------------------------------------------------------ In level::stretch, we use float variables to do the following: {{{ float epsilon = mln_epsilon(float), M = mln_max(V) + 0.5f - epsilon, m = 0.0f - 0.5f + epsilon; }}} 'm' is precise enough since it is a really low value. However, M is not precise enough since mln_max(V) may be a high value, so we will loose decimal precision if we store that number as float. As a result, M is always equal to 'mln_max(V) + 0.5' which introduce a bug in level::stretch. This issue can be avoided by using double variables instead, but do we really want that? Don't we want to handle that issue in a more generic way? -- Ticket URL: <https://trac.lrde.org/olena/ticket/179> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 2

[Olena] #165: Separate sites sets from their psites?
by Olena 13 Jul '09

13 Jul '09

#165: Separate sites sets from their psites? ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: proposal | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Many files containing the definitions site sets, located in source:branches/cleanup-2008/milena/mln/core/site_set/, include the related psite and piters. Split them into several files? (And add convenience headers including all of them?) -- Ticket URL: <https://trac.lrde.org/olena/ticket/165> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

4285: Do not move documentation files if srcdir == builddir.
by Guillaume Lazzara 13 Jul '09

13 Jul '09

* doc/ref_guide/Makefile.am, * doc/tutorial/Makefile.am, * doc/white_paper/Makefile.am: check if srcdir == builddir. --- milena/ChangeLog | 8 ++++++++ milena/doc/ref_guide/Makefile.am | 5 +++-- milena/doc/tutorial/Makefile.am | 5 +++-- milena/doc/white_paper/Makefile.am | 5 +++-- 4 files changed, 17 insertions(+), 6 deletions(-) diff --git a/milena/ChangeLog b/milena/ChangeLog index 287e058..2ee2ea3 100644 --- a/milena/ChangeLog +++ b/milena/ChangeLog @@ -1,5 +1,13 @@ 2009-07-13 Guillaume Lazzara <guillaume.lazzara(a)lrde.epita.fr> + Do not move documentation files if srcdir == builddir. + + * doc/ref_guide/Makefile.am, + * doc/tutorial/Makefile.am, + * doc/white_paper/Makefile.am: check if srcdir == builddir. + +2009-07-13 Guillaume Lazzara <guillaume.lazzara(a)lrde.epita.fr> + Fix documentation generation. * doc/examples/Makefile.am: Check if directory exists before diff --git a/milena/doc/ref_guide/Makefile.am b/milena/doc/ref_guide/Makefile.am index 31a5abb..9870a07 100644 --- a/milena/doc/ref_guide/Makefile.am +++ b/milena/doc/ref_guide/Makefile.am @@ -68,8 +68,9 @@ ref-guide-pdf: $(REF_GUIDE_PDF) $(REF_GUIDE_PDF): ref_guide.tex $(srcdir)/../figures.stamp TEXINPUTS=$(TEXINPUTS) pdflatex $< TEXINPUTS=$(TEXINPUTS) pdflatex $< - TEXINPUTS=$(TEXINPUTS) pdflatex $< \ - && mv -f ref_guide.pdf $(srcdir) + TEXINPUTS=$(TEXINPUTS) pdflatex $< \ + test "$(top_srcdir)" == "$(top_builddir)" \ + || mv -f $(builddir)/ref_guide.pdf $(srcdir) # FIXME: Regenerating figures.stamp requires make to go back to the # parent directory. We already do the opposite (descending from diff --git a/milena/doc/tutorial/Makefile.am b/milena/doc/tutorial/Makefile.am index 3a2c61f..12f52ad 100644 --- a/milena/doc/tutorial/Makefile.am +++ b/milena/doc/tutorial/Makefile.am @@ -66,8 +66,9 @@ tutorial-pdf: $(TUTORIAL_PDF) $(TUTORIAL_PDF): tutorial.tex $(srcdir)/../figures.stamp TEXINPUTS=$(TEXINPUTS) pdflatex $< TEXINPUTS=$(TEXINPUTS) pdflatex $< - TEXINPUTS=$(TEXINPUTS) pdflatex $< \ - && mv -f tutorial.pdf $(srcdir) + TEXINPUTS=$(TEXINPUTS) pdflatex $< \ + test "$(top_srcdir)" == "$(top_builddir)" \ + || mv -f tutorial.pdf $(srcdir) # FIXME: Regenerating figures.stamp requires make to go back to the # parent directory. We already do the opposite (descending from diff --git a/milena/doc/white_paper/Makefile.am b/milena/doc/white_paper/Makefile.am index 5901d0e..66b42cb 100644 --- a/milena/doc/white_paper/Makefile.am +++ b/milena/doc/white_paper/Makefile.am @@ -75,8 +75,9 @@ white-paper-pdf: $(WHITE_PAPER_PDF) $(WHITE_PAPER_PDF): white_paper.tex $(PNGS) TEXINPUTS=$(TEXINPUTS) pdflatex $< TEXINPUTS=$(TEXINPUTS) pdflatex $< - TEXINPUTS=$(TEXINPUTS) pdflatex $< \ - && mv -f white_paper.pdf $(srcdir) + TEXINPUTS=$(TEXINPUTS) pdflatex $< \ + test "$(top_srcdir)" == "$(top_builddir)" \ + || mv -f white_paper.pdf $(srcdir) dist_doc_DATA = \ -- 1.5.6.5

1 0