#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