April 2009 - Olena-patches

[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] #180: algebra::vec's != operators cannot be used.
by Olena 08 Jun '09

08 Jun '09

#180: algebra::vec's != operators cannot be used. ---------------------+------------------------------------------------------ Reporter: lazzara | Owner: Olena Team Type: defect | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: | ---------------------+------------------------------------------------------ The following example does not compile. test.cc: {{{ # include <mln/algebra/vec.hh> int main() { using namespace mln::algebra; vec<3, float> a, b; bool c = (a != b); } }}} g++ -I. test.cc {{{ test.cc: In function 'int main()': test.cc:6: error: cannot convert 'mln::algebra::vec<3u, bool>' to 'bool' in initialization ./mln/core/routine/ops.hh: In function 'typename mln::trait::op::neq<L, R>::ret mln::operator!=(const mln::Object<E>&, const mln::Object<O2>&) [with O1 = mln::algebra::vec<3u, float>, O2 = mln::algebra::vec<3u, float>]': test.cc:6: instantiated from here ./mln/core/routine/ops.hh:528: error: conversion from 'bool' to non-scalar type 'mln::algebra::vec<3u, bool>' requested }}} Note that if '(a != b)' is replaced by '(a == b)' or '!(a == b)', this example compiles. -- Ticket URL: <https://trac.lrde.org/olena/ticket/180> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

[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] #177: Provide safe value types to represent sizes
by Olena 28 May '09

28 May '09

#177: Provide safe value types to represent sizes ---------------------------------------+------------------------------------ Reporter: levill_r | Owner: Olena Team Type: proposal | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: conversion cast promotion | ---------------------------------------+------------------------------------ For instance we currently use either `unsigned` (bad) or `std::size_t` (less bad) to represent a size (or a cardinal), but none of them is really safe: as Théo and Matthieu recently said, adding an `int` with an `unsigned` can lead to unexpected results. We should provide safe replacement type(s) (or merely typedef(s) over existing safe types), and stop using unsafe C++ built-in types. -- Ticket URL: <https://trac.lrde.org/olena/ticket/177> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

[Olena] #178: Improve the way Trimesh is handled within Olena
by Olena 27 May '09

27 May '09

#178: Improve the way Trimesh is handled within Olena ----------------------------------------+----------------------------------- Reporter: levill_r | Owner: Olena Team Type: enhancement | Status: new Priority: major | Milestone: Olena 1.0 Component: Olena | Version: 1.0 Keywords: distribution configuration | ----------------------------------------+----------------------------------- Motivation/rationale: 1. Most Olena users do not want Trimesh. 1. We probably get rid of Trimesh someday (I need to check-in some replacement code first!). To do: * Add a `--with-trimesh` option in source:trunk/configure.ac, along with an Automake conditional (e.g., `WITH_TRIMESH`), set to `no` by default. * Use this conditional to enable/disable the trimesh directory in the `SUBDIRS` variable of source:trunk/external/Makefile.am. -- Ticket URL: <https://trac.lrde.org/olena/ticket/178> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 1

[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

[Olena] #170: Get rid of typedef mln::internal::image_base::coord
by Olena 27 May '09

27 May '09

#170: Get rid of typedef mln::internal::image_base::coord -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: enhancement | Status: new Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: point | -------------------------+-------------------------------------------------- In source:branches/cleanup-2008/milena/mln/core/internal/image_base.hh, `mln::internal::image_base` defines a typedef `coord`, which reduces the genericity of this class: {{{ #!cpp /// Coordinate associated type. typedef mln_deduce(S, site, coord) coord; }}} A consequence is that the site type `S::site` must define an associated type `coord` (hence `std::vector<point2d>` is not a valid site type), yet we had decided that there should be no prerequisites on the interfaces of sites in Milena. -- Ticket URL: <https://trac.lrde.org/olena/ticket/170> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 2

[Olena] #168: Revamp mln::topo::internal::complex_data<D>
by Olena 18 May '09

18 May '09

#168: Revamp mln::topo::internal::complex_data<D> -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: new Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: cleanup | -------------------------+-------------------------------------------------- See source:branches/cleanup-2008/milena/mln/topo/complex.hh * Store only the indices of adjacent faces in `complex_data<D>`: we don't really need actual faces there, and it costs a lot (memory, execution time, design complexity, etc.) * Then (or concurrently) simplify the design: use an array of array instead of an ad hoc type list. * 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. -- Ticket URL: <https://trac.lrde.org/olena/ticket/168> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

2 2