May 2008 - Olena-patches

[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] #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] #143: Reorganize milena/mln/core/
by Olena 18 May '09

18 May '09

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

2 3

[Olena] #140: Add points having floating-point coordinates
by Olena 18 May '09

18 May '09

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

2 1

[Olena] #130: Don not pass neighborhoods as argument to algorithms
by Olena 14 May '09

14 May '09

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

2 11

[Olena] #142: Add iterators on graphs
by Olena 18 Oct '08

18 Oct '08

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

2 3

[Olena] #127: Generalize the definition of the Sobel gradient
by Olena 17 Jun '08

17 Jun '08

#127: Generalize the definition of the Sobel gradient -------------------------+-------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: enhancement | Status: new Priority: trivial | Milestone: Component: Milena | Version: 1.0 Keywords: | -------------------------+-------------------------------------------------- For the moment (rev. 1656), the Sobel gradient only works on 2-D images. We could generalize its definition to n-D (regular) images. For instance, a 3-D version is mentioned in http://www.aravind.ca/cs788h_Final_Project/gradient_estimators.htm. -- Ticket URL: <https://trac.lrde.org/olena/ticket/127> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image library.

1 1

[Olena] #135: Name Confilts between util::node and util::node.
by Olena 08 Jun '08

08 Jun '08

#135: Name Confilts between util::node and util::node. -----------------------+---------------------------------------------------- Reporter: garrigues | Owner: Olena Team Type: defect | Status: new Priority: major | Milestone: Olena 1.0ß Component: Milena | Version: 1.0 Keywords: | -----------------------+---------------------------------------------------- We have two util::node : one for the graph implementation and also one for the tree. see source:/trunk/milena/mln/util/tree.hh and source:/trunk/milena/mln/util/internal/graph_base.hh -- Ticket URL: <https://trac.lrde.org/olena/ticket/135> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.

1 4