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