March 2008 - Olena-patches

[Olena] #134: Overhaul the generation of the documentation
by Olena 05 Sep '13

05 Sep '13

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

2 7

[Olena] #126: Speed up tests
by Olena 03 May '10

03 May '10

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

2 3

[Olena] #129: Reintegrate oln.m4 (full or a part of it) into Olena 1.0
by Olena 07 Apr '10

07 Apr '10

#129: Reintegrate oln.m4 (full or a part of it) into Olena 1.0 -----------------------------------+---------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: new Priority: minor | Milestone: Olena 1.0ß Component: Olena | Version: 1.0 Keywords: configure autoconf M4 | -----------------------------------+---------------------------------------- In Olena 0.11, `oln.m4` (which might be renamed to `olena.m4`) provided useful services to both the Olena package (search for libraries, set up flags for tests, etc.) and autoconfiscated packages using Olena, by providing a `--with-oln` (to be renamed to `--with-olena`) flag. We should reintegrate a part of these features, possibly in two M4 macro packages: * one for Olena, * one for Olena-based projects. -- Ticket URL: <https://trac.lrde.org/olena/ticket/129> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image library.

2 2

[Olena] #132: Use gcov
by Olena 05 Aug '09

05 Aug '09

#132: Use gcov ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: task | Status: new Priority: major | Milestone: Olena 1.0ß Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- 1. Use `gcov` to check which parts of Olena are actually covered (instantiated and checked) by the test suite. 1. Automate with make. 1. Optionally use the LTP GCOV Extension (`lcov`) : http://ltp.sourceforge.net/coverage/lcov.php -- Ticket URL: <https://trac.lrde.org/olena/ticket/132> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image library.

2 3

[Olena] #124: Ensure I/O operations on images holding greater-than-8-bit values are robust w.r.t. endianness
by Olena 13 Jul '09

13 Jul '09

#124: Ensure I/O operations on images holding greater-than-8-bit values are robust w.r.t. endianness ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: task | Status: new Priority: minor | Milestone: Olena 1.0ß Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- This might be difficult to check, since it's platform-dependant. At least, we should check this (with the build farm) on a host with an endianness different than IA-32's or Intel 64's (e.g., a SPARC station). According to http://en.wikipedia.org/wiki/Endianness, * Intel IA-32 (and probably Intel 64 and AMD 64) are little-endian; * Motorola 68k, Sun SPARC and IBM System/370 processors are little- endian; * PowerPC, ARM, DEC Alpha, MIPS, HP PA-RISC and Intel IA-64 processors are bi-endian. -- Ticket URL: <https://trac.lrde.org/olena/ticket/124> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image library.

2 3

[Olena] #136: Delegate rgb operators
by Olena 13 Jul '09

13 Jul '09

#136: Delegate rgb operators ----------------------------------+----------------------------------------- Reporter: garrigues | Owner: Olena Team Type: enhancement | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: vectorial values rgb | ----------------------------------+----------------------------------------- Some operators on rgb values are defined (see source:trunk/milena/mln/value/rgb.hh). FIXME: We should not need to define these operators, thanks to Milena's global operator resolution mechanism based on mln::Object. See what prevent us to use this mechanism. For example : There a no operators defined on int_u values because in source:trunk/milena/mln/value/ops.hh we delegate the operation on int_u and on all Scalar<V> to the equivalent type. We could do the same for vectorial values. it will avoid duplicating metal::vec operators in rgb. We could also introduce an new concept : arithmetic value which by default, use operators of its equiv type. -- Ticket URL: <https://trac.lrde.org/olena/ticket/136> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

[Olena] #128: Handle carefully tests using X11
by Olena 10 Jun '09

10 Jun '09

#128: Handle carefully tests using X11 ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: defect | Status: new Priority: major | Milestone: Olena 1.0ß Component: Milena | Version: 1.0 Keywords: test | ----------------------+----------------------------------------------------- Some tests require X11 visualization programs such as `display` (from !ImageMagick) or `xv`. This is an issue since * the they might not be installed on the machine; * the host/session on which tests are executed might not run a X11 display. IMHO, we could either 1. move them out of the `check` target (and have them launched by the `check-all`/`check-full` target, or a check-x11 target); or 2. have `configure` check whether the required programs are present, as well as a (usable) X11 session. (Maybe the Vaucanson Team ran into such questions; ask them.) -- Ticket URL: <https://trac.lrde.org/olena/ticket/128> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image library.

2 2

[Olena] #125: Ambiguity in comparaison with literals
by Olena 09 Jun '09

09 Jun '09

#125: Ambiguity in comparaison with literals --------------------------------+------------------------------------------- Reporter: garrigues | Owner: theo Type: defect | Status: new Priority: major | Milestone: Olena 1.0ß Component: Milena | Version: 1.0 Keywords: literals operators | --------------------------------+------------------------------------------- This test shows the problem : {{{ #!cpp # include <mln/value/gl8.hh> # include <mln/literal/all.hh> int main() { using mln::value::gl8; using mln::literal::white; gl8 b; b == white; } }}} The compiler can't find the right operator== to compate graylevel with literals. Here is the error output : {{{ test.cc: In function 'int main()': test.cc:11: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: ../../mln/literal/ops.hh:252: note: candidate 1: typename mln::trait::op::eq<O, O>::ret mln::operator==(const mln::Object<E>&, const mln::Literal<L>&) [with O = mln::value::graylevel<8u>, L = mln::literal::white_t] ../../mln/value/internal/gray_f.hh:317: note: candidate 2: bool mln::value::operator==(const mln::value::Integer<I>&, const mln::value::graylevel_f&) [with I = mln::value::graylevel<8u>] }}} -- Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/125> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image library.

2 1

[Olena] #122: [TRAITS] image_if_base
by Olena 28 May '09

28 May '09

#122: [TRAITS] image_if_base ---------------------+------------------------------------------------------ Reporter: duhamel | Owner: Olena Team Type: defect | Status: new Priority: major | Milestone: Olena 1.0ß Component: Milena | Version: 1.0 Keywords: | ---------------------+------------------------------------------------------ In source:trunk/milena/mln/core/internal/image_if_base.hh data trait is suspect. For example an image_if from an image1d has always data trait raw ! -- Ticket URL: <https://trac.lrde.org/olena/ticket/122> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image library.

2 1

[Olena] #131: Implement area closing and attribue closing
by Olena 28 May '09

28 May '09

#131: Implement area closing and attribue closing --------------------------------------------------------+------------------- Reporter: levill_r | Owner: Olena Team Type: defect | Status: new Priority: minor | Milestone: Static 1.0 Component: Milena | Version: 1.0 Keywords: completion dual naming routines algorithms | --------------------------------------------------------+------------------- Currently, these files are available: * source:trunk/morpho/mln/opening_area.hh * source:trunk/morpho/mln/opening_attribute.hh but there is no equivalent for closings. Implement them. BTW, these files and their routines are called `opening_area` and `opening_attribute`, which is not elegant. Of course the goal is to put forward the opening term; but IMHO, we should use namespace to do this, not prefixes. Or rename them to `area_opening` and `attribute_opening`, which are much more natural. Anyway, any further discussion on the subject of naming algorithms should be carried on in another ticket. -- Ticket URL: <https://trac.lrde.org/olena/ticket/131> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image library.

2 2