#183: Have mln::complex_image be more flexible w.r.t. its domain --------------------------+---------------------- Reporter: levill_r | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Milena | Version: 1.0 Resolution: | Keywords: site set --------------------------+---------------------- Changes (by levill_r): * owner: levill_r => * priority: critical => minor * milestone: Olena 2.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 submission.

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. -- -- Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/183#comment:2> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient image processing platform