#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.
#149: Revamp util::graph
-------------------------+--------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: enhancement | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
* Get rid of superfluous dynamic allocations (w.r.t. vertices & edges
handling).
* Move properties attached to vertices and edges out of the graph (this
should allow the merging of `util::graph` and
`util::internal::graph_base`.
* Allow the removal of vertices and edges. Don't forget to warn users
about the invalidation of vertex and edge ids (handlers).
* Stop using the term « id » (« identifier ») for vertices and edges, and
prefer the term « handler » ? (The BGL call them « descriptors ».)
All these changes might bring us closer to the BGL' `adjacency_list`. See
how we could factor things, while not requiring a dependency on the BGL.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/149>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#153: Write a test using Ubigraph
-----------------------------------+----------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: trivial | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: rendering third-party |
-----------------------------------+----------------------------------------
Ubigraph is a promising graph manipulation and visualization project:
* http://ubietylab.net/ubigraph/
We could write a small test exercising its display capabilities, e.g., the
construction of a skeleton on a binary, graph-based image (even a 2-D
image on a regular grid).
Check the license(s); the client part is Free Software, but the server
doesn't seem so.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/153>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#143: Reorganize milena/mln/core/
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: minor | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
(This ticket is just a proposal. We might close it even if no change
occur in `milena/mln/core`.)
There are many things in source:trunk/milena/mln/core/, that could be
reorganized and/or split in several directories/subdirectories:
* basic/classic images and entites (`mln::image2d`, etc.)
* graph-based images and entities (`mln::graph_image`, etc.)
* non classic images and associated tools (`mln::rle_image`, etc.)
* morphers (`mln::cast_image`, etc.)
* internal/core mechanisms (`initialize.hh` etc.)
* general tools (`contract.hh`, `inplace.hh`, etc.)
* concepts (though they are located in their own directory,
`mln/core/concept/`)
* implementation/factoring classes (thought most of them are in
`mln/core/internal/`)
* other entities, that should be moved elsewhere (`mln::h_vec`, etc.)
* and so on.
To my (Roland) mind, we should:
1. Identify the different kind of files present in `core/`.
2. Assign one (maybe two) kinds to each file of this directory.
3. Determine a new file layout, and perform the moves.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/143>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#140: Add points having floating-point coordinates
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: task | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
Name regular instances `point1df`, `point2df` and `point3df`.
(N.B.: Aroune will need them so as to build the 3-d surface graph from a
set of triangles.)
--
Ticket URL: <https://trac.lrde.org/olena/ticket/140>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#130: Don not pass neighborhoods as argument to algorithms
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: defect | Status: new
Priority: major | Milestone: Olena 1.0ß
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
Neighborhoods shall be bound to images: they are a property of them.
Hence an algorithm (at least a facade) shall not accept an image along
with an ''external'' neighborhood. Most of the time, these algorithms are
based on windows improperly called neighborhoods.
Here is the list of files to revamp, as of revision 1663:
* source:trunk/labeling/level.spe.hh
* source:trunk/labeling/regional_maxima.hh
* source:trunk/labeling/regional_minima.hh
* source:trunk/make/voronoi.hh
* source:trunk/milena/mln/geom/labeling/blobs.hh
* source:trunk/milena/mln/geom/seeds2tiling_roundness.hh
* source:trunk/milena/mln/labeling/background.hh
* source:trunk/milena/mln/labeling/flat_zones.hh
* source:trunk/milena/mln/labeling/foreground.hh
* source:trunk/milena/mln/labeling/level.hh
* source:trunk/morpho/Rd.hh
* source:trunk/morpho/dilation.hh
* source:trunk/morpho/opening_area.hh
* source:trunk/morpho/opening_attribute.hh
--
Ticket URL: <https://trac.lrde.org/olena/ticket/130>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image library.
#159: Distribute SWIG wrappers
-------------------------+--------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: enhancement | Status: new
Priority: minor | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
According to Alexandre Hamez, files generated by `swig` (e.g., `*.py` and
`*-wrap.cc`) are portable. We should distribute them, as
* it would save users wanting to use Swilena some time;
* it would free them to have SWIG to compile Swilena.
To do:
* distribute these files (remove `nodist_` prefixes);
* ensure they're available at distribution time (use `dist-hook` in
`Makefile.am`);
* add generated files to `MAINTAINERCLEANFILES`;
* adjust `configure.ac`? (see what Alexandre uses).
--
Ticket URL: <https://trac.lrde.org/olena/ticket/159>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#142: Add iterators on graphs
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: task | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
We need these, at least:
* iterator on vertices (forward, backward)
* iterator on edges (forward, backward)
* iterator on the adjacent edges of a vertex (forward, backward)
* iterator on the adjacent edges of an edge (forward, backward)
--
Ticket URL: <https://trac.lrde.org/olena/ticket/142>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
