#183: Have mln::complex_image be more flexible w.r.t. its domain --------------------------+------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: new Priority: critical | Milestone: Olena 1.1 Component: Milena | Version: 1.0 Resolution: | Keywords: site set --------------------------+------------------------------------------------- Changes (by levill_r): * milestone: Olena 1.0 => Olena 1.1 Old description:
`mln::complex_image` makes it mandatory us to assign values to ''each'' face of a complex. But sometimes, we are only interested by a subset of a complex (e.g., its edges). We should have the choice of the domain of a `mln::complex_image`.
Hint: see how Guillaume revamped the graph-based images, using functions (i.e. domain + value -> image). I (Roland) still consider actual images types are desirable, but we could implement them as wrappers of function- based images.
I have set the priority of this ticket to 2 (« critical ») because we really need this feature for the examples of the ISMM'09 and DGCI'09 submissions.
New description: `mln::complex_image` makes it mandatory us to assign values to ''each'' face of a complex. But sometimes, we are only interested by a subset of a complex (e.g., its edges). We should have the choice of the domain of a `mln::complex_image`. Hint: see how Guillaume revamped the graph-based images, using functions (i.e. domain + value -> image). I (Roland) still consider actual images types are desirable, but we could implement them as wrappers of function- based images. I have set the priority of this ticket to 2 (« critical ») because we really need this feature for the examples of the ISMM'09 submission. -- Comment: Postponed to [milestone:"Olena 1.1" Olena 1.1]. -- Ticket URL: <https://trac.lrde.org/olena/ticket/183#comment:1> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.