November 2008 - Olena-patches

[Olena] #155: Reuse existing script to factor the Makefile machinery in Swilena
by Olena 10 Jun '09

10 Jun '09

#155: Reuse existing script to factor the Makefile machinery in Swilena -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: new Priority: minor | Milestone: Olena 1.0 Component: Swilena | Version: 1.0 Keywords: | -------------------------+-------------------------------------------------- For instance, there are parts to be factored in source:trunk/swilena/python/Makefile.am. See what TC, Olena 0.11 and clspr used. -- Ticket URL: <https://trac.lrde.org/olena/ticket/155> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 2

[Olena] #156: Kill a maximum of warnings in Swilena
by Olena 10 Jun '09

10 Jun '09

#156: Kill a maximum of warnings in Swilena -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: new Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | -------------------------+-------------------------------------------------- The Python wrappers have been written quickly, and they lack some information (base classes, etc.), making `swig` emit a lot of warnings. Most of them are harmless, however they clutter the output of the build. Get rid of them. -- Ticket URL: <https://trac.lrde.org/olena/ticket/156> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 2

[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] #163: Decide into what mln_?iter(T) should expand
by Olena 09 Jun '09

09 Jun '09

#163: Decide into what mln_?iter(T) should expand ---------------------------------+------------------------------------------ Reporter: levill_r | Owner: Olena Team Type: proposal | Status: new Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: convention shortcut | ---------------------------------+------------------------------------------ In source:trunk/milena/mln/core/macros.hh, the macros {{{ #!cpp mln_?iter(T) mln_?iter_(T) }}} expand as {{{ #!cpp typename T::fwd_?iter T::fwd_?iter }}} Shouldn't they expand as {{{ #!cpp typename T::?iter T::?iter }}} ? -- Ticket URL: <https://trac.lrde.org/olena/ticket/163> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 3

[Olena] #157: Improve depency tracking in Swilena
by Olena 09 Jun '09

09 Jun '09

#157: Improve depency tracking in Swilena -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: enhancement | Status: new Priority: minor | Milestone: Olena 1.0 Component: Swilena | Version: 1.0 Keywords: | -------------------------+-------------------------------------------------- Our hand-made build system does not seem to track dependencies very well in Swilena/Python. Improve this. -- Ticket URL: <https://trac.lrde.org/olena/ticket/157> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 2

[Olena] #144: Fix load (and maybe save) routine(s) for ASCII-encoded PBM images
by Olena 29 May '09

29 May '09

#144: Fix load (and maybe save) routine(s) for ASCII-encoded PBM images -------------------------------------+-------------------------------------- Reporter: levill_r | Owner: Olena Team Type: defect | Status: new Priority: critical | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: I/O IO input output pbm | -------------------------------------+-------------------------------------- Théo discovered on May 28, 2008 that the load routine for ASCII-encoded PBM (boolean) images was broken (and maybe the save routine, too). The other ASCII-based Netpbm should be checked as well. Don't close this ticket until all of these routine have been inspected and declared safe! -- Ticket URL: <https://trac.lrde.org/olena/ticket/144> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 2

[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

[Olena] #175: Use std::vector to store data of mln::image[123]d<T>
by Olena 27 May '09

27 May '09

#175: Use std::vector to store data of mln::image[123]d<T> ----------------------+----------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: proposal | Status: new Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Currently, the following classes use plain dynamically-allocated memory to store their data (values): * source:trunk/milena/mln/core/image/image1d.hh * source:trunk/milena/mln/core/image/image2d.hh * source:trunk/milena/mln/core/image/image2d_h.hh * source:trunk/milena/mln/core/image/image3d.hh We could try to replace these arrays with `std::vectors`. Pros: * Automatic memory management. * Direct access (using pointers) is still possible, thanks to the ISO/IEC C++ Standard; see paragraph 23.2.4.1: "(...) The elements of a vector are stored contiguously, meaning that if `v` is a `vector<T, Allocator>` where `T` is some type other than `bool`, then it obeys the identity `&v[n] == &v[0] + n` for all `0 <= n < v.size()`". * Optimized storage for boolean values, thanks to the `std::vector<bool>` specialization. Cons: * We can't iterate on an `std::vector<bool>` using a pointer; but we can provide optimized specialization for that very case, that could as fast as pointer iterations (IMHO). -- Ticket URL: <https://trac.lrde.org/olena/ticket/175> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 2