
#162: Implement windows, neighborhoods, and corresponding iterators for complex- based images -----------------------+---------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: task | Status: assigned Priority: major | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: -----------------------+---------------------------------------------------- Old description:
For a given (fixed) dimension ''n'' and a psite ''p'' on a ''n''-face, implement windows/neighborhoods (and corresponding iterators) returning the following elements.
`complex_lower_window`:: the set of (''n''-1)-faces adjacent to ''p'' (using ``mln::p_faces`` and ``mln::faces_psite``?); `complex_higher_window`:: the set of (''n''+1)-faces adjacent to ''p'' (using ``mln::p_faces`` and ``mln::faces_psite``?);
`complex_lower_dim_connected_window`:: the set of ''n''-faces sharing a (''n''-1)-face with ''p''; `complex_higher_dim_connected_window`:: the set of ''n''-faces sharing a (''n''+1)-face with ''p'';
`complex_cell_window`:: the set of the faces in the « cell » including ''p'' (named « ''p''-hat » in couprie.08.pami), i.e. the set of all ''m''-faces adjacent to ''p'', where ''m'' is in [0, ''n''-1].[[BR]] In that definition, ''p'' is said adjacent to an ''m''-face ''q'' if there is a sequence (''m,,1,,'', ''m,,2,,'', ..., ''m,,k,,'') of faces so that * ''m,,1,,'' is an (''n''-1)-face adjacent to ''p'' ; * ''m,,2,,'' is an (''n''-2)-face adjacent to ''m,,1,,'' ; * ... (and so on) * ''m,,k,,'' is an (''m''+1)-face adjacent to ''q''. `complex_boundary_cell_window`:: Likewise, but excluding ''p'' (named « ''p''-hat* » in couprie.08.pami).
And maybe:
`complex_lower_dims_connected_window`:: the set of ''n''-faces sharing a (''n''-1)-face or (''n''-2)-face etc. (by transitivity) with ''p'' (is it useful?); `complex_higher_dims_connected_window`:: the set of ''n''-faces sharing a (''n''+1)-face or (''n''+2)-face etc. (by transitivity) with ''p'' (is it useful?);
* what else?
As in #139, * we might want to factor things using implementation classes: * ``mln::internal::complex_vicinity`` * ``mln::internal::complex_vicinity_piter`` (we might even be able to factor them with graph-based ones); * we could have one or several generic classes, using static or dynamic predicates, to implement those windows and neighborhoods.
New description: For a given (fixed) dimension ''n'' and a psite ''p'' on a ''n''-face, implement windows/neighborhoods (and corresponding iterators) returning the following elements. ~~`complex_lower_window`~~:: ~~the set of (''n''-1)-faces adjacent to ''p'' (using ``mln::p_faces`` and ``mln::faces_psite``?)~~ (mostly done in r2459); ~~`complex_higher_window`~~:: ~~the set of (''n''+1)-faces adjacent to ''p'' (using ``mln::p_faces`` and ``mln::faces_psite``?)~~ (mostly done in r2459); `complex_lower_dim_connected_window`:: the set of ''n''-faces sharing a (''n''-1)-face with ''p''; `complex_higher_dim_connected_window`:: the set of ''n''-faces sharing a (''n''+1)-face with ''p''; `complex_cell_window`:: the set of the faces in the « cell » including ''p'' (named « ''p''-hat » in couprie.08.pami), i.e. the set of all ''m''-faces adjacent to ''p'', where ''m'' is in [0, ''n''-1].[[BR]] In that definition, ''p'' is said adjacent to an ''m''-face ''q'' if there is a sequence (''m,,1,,'', ''m,,2,,'', ..., ''m,,k,,'') of faces so that * ''m,,1,,'' is an (''n''-1)-face adjacent to ''p'' ; * ''m,,2,,'' is an (''n''-2)-face adjacent to ''m,,1,,'' ; * ... (and so on) * ''m,,k,,'' is an (''m''+1)-face adjacent to ''q''. `complex_boundary_cell_window`:: Likewise, but excluding ''p'' (named « ''p''-hat* » in couprie.08.pami). And maybe: `complex_lower_dims_connected_window`:: the set of ''n''-faces sharing a (''n''-1)-face or (''n''-2)-face etc. (by transitivity) with ''p'' (is it useful?); `complex_higher_dims_connected_window`:: the set of ''n''-faces sharing a (''n''+1)-face or (''n''+2)-face etc. (by transitivity) with ''p'' (is it useful?); * what else? As in #139, * we might want to factor things using implementation classes: * ``mln::internal::complex_vicinity`` * ``mln::internal::complex_vicinity_piter`` (we might even be able to factor them with graph-based ones); * we could have one or several generic classes, using static or dynamic predicates, to implement those windows and neighborhoods. Comment (by levill_r): Kill done items. -- Ticket URL: <https://trac.lrde.org/olena/ticket/162#comment:5> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.