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