[Olena] #162: Implement windows, neighborhoods, and corresponding iterators for complex-based images
9 Sep
2008
9 Sep
'08
3 p.m.
#162: Implement windows, neighborhoods, and corresponding iterators for complex-
based images
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: task | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
For a given (fixed) dimension ''n'' and a psite ''p'' on
a ''n''-face,
implement windows/neighborhoods (and corresponding iterators) returning
* the set of (''n''-1)-faces adjacent to ''p'' (using
``mln::p_faces``
and ``mln::faces_psite``?);
* the set of (''n''+1)-faces adjacent to ''p'' (using
``mln::p_faces``
and ``mln::faces_psite``?);
* the set of ''n''-faces sharing a (''n''-1)-face with
''p'';
* the set of ''n''-faces sharing a (''n''-1)-face or
(''n''-2)-face (by
transitivity) with ''p'' (is it useful?);
* 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''.
* 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.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/162>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
9 Sep
9 Sep
4:22 p.m.
#162: Implement windows, neighborhoods, and corresponding iterators for complex-
based images
-----------------------+----------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: task | Status: new
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 set of (''n''-1)-faces adjacent to ''p'' (using
``mln::p_faces``
and ``mln::faces_psite``?);
* the set of (''n''+1)-faces adjacent to ''p'' (using
``mln::p_faces``
and ``mln::faces_psite``?);
* the set of ''n''-faces sharing a (''n''-1)-face with
''p'';
* the set of ''n''-faces sharing a (''n''-1)-face or
(''n''-2)-face (by
transitivity) with ''p'' (is it useful?);
* 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''.
* 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.
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``?);
`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 or (''n''-2)-face (by
transitivity) with ''p'' (is it useful?);
`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_cell_window_p`:: Likewise, but excluding ''p'' (named «
''p''-hat* » in couprie.08.pami).
* 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):
Give names to some of the windows (and neighborhoods). They're probably
bad (and maybe not needed, if we manage to factor the whole thing into a
single class), but we can change them later.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/162#comment:1>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
26 Sep
26 Sep
8:20 a.m.
#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:
-----------------------+----------------------------------------------------
Changes (by levill_r):
* status: new => assigned
--
Ticket URL: <https://trac.lrde.org/olena/ticket/162#comment:2>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
1 p.m.
#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 or (''n''-2)-face (by
transitivity) with ''p'' (is it useful?);
`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_cell_window_p`:: Likewise, but excluding ''p'' (named «
''p''-hat* » in couprie.08.pami).
* 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``?);
`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_cell_window_p`:: 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):
Tidy the description.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/162#comment:3>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
1:16 p.m.
#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_cell_window_p`:: 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``?);
`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.
Comment (by levill_r):
s/complex_cell_window_p/complex_boundary_cell_window/.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/162#comment:4>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
2 Oct
2 Oct
9:57 p.m.
#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.
9:58 p.m.
#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``?)~~ (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.
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 and r2460);
~~`complex_higher_window`~~:: ~~the set of (''n''+1)-faces adjacent to
''p'' (using ``mln::p_faces`` and ``mln::faces_psite``?)~~ (mostly done
in
r2459 and r2460);
`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):
(Fix previous change.)
--
Ticket URL: <https://trac.lrde.org/olena/ticket/162#comment:6>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
17 Oct
17 Oct
12:56 p.m.
#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``?)~~ (mostly done
in r2459 and r2460);
~~`complex_higher_window`~~:: ~~the set of (''n''+1)-faces adjacent to
''p'' (using ``mln::p_faces`` and ``mln::faces_psite``?)~~ (mostly done
in r2459 and r2460);
`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 and r2460);
~~`complex_higher_window`~~:: ~~the set of (''n''+1)-faces adjacent to
''p'' (using ``mln::p_faces`` and ``mln::faces_psite``?)~~ (mostly done
in
r2459 and r2460);
`complex_m_lower_window`:: for ''m'' < ''n''
(''m'' being dynamic), the
set of ''m''-faces « transitively adjacent » to ''p'';
`complex_m_higher_window`:: for ''m'' > ''n''
(''m'' being dynamic), the
set of ''m''-faces « transitively adjacent » to ''p'';
`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 transitively
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.
Note that some of these iterators might implement operators on complexes,
see
http://en.wikipedia.org/wiki/Simplicial_complex#Closure.2C_star.2C_and_link.
Comment (by levill_r):
Add more iterators to implement (`complex_m_lower_window` and
`complex_m_higher_window`).
--
Ticket URL: <https://trac.lrde.org/olena/ticket/162#comment:7>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
1:13 p.m.
#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``?)~~ (mostly done
in r2459 and r2460);
~~`complex_higher_window`~~:: ~~the set of (''n''+1)-faces adjacent to
''p'' (using ``mln::p_faces`` and ``mln::faces_psite``?)~~ (mostly done
in r2459 and r2460);
`complex_m_lower_window`:: for ''m'' < ''n''
(''m'' being dynamic), the
set of ''m''-faces « transitively adjacent » to ''p'';
`complex_m_higher_window`:: for ''m'' > ''n''
(''m'' being dynamic), the
set of ''m''-faces « transitively adjacent » to ''p'';
`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 transitively
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.
Note that some of these iterators might implement operators on complexes,
see
http://en.wikipedia.org/wiki/Simplicial_complex#Closure.2C_star.2C_and_link.
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''~~ (done in r2459, r2460, and r2514);
~~`complex_higher_window`~~:: ~~the set of (''n''+1)-faces adjacent to
''p''~~ (done in r2459, r2460 and r2517);
~~`complex_lower_higher_window`~~:: ~~the set of (''n''-1)- and
(''n''+1)-faces adjacent to ''p''~~ (done in r2496 and
r2518);
`complex_m_lower_window`:: for ''m'' < ''n''
(''m'' being dynamic), the
set of ''m''-faces « transitively adjacent » to ''p'';
`complex_m_higher_window`:: for ''m'' > ''n''
(''m'' being dynamic), the
set of ''m''-faces « transitively adjacent » to ''p'';
`complex_lower_dim_connected_window`:: the set of ''n''-faces sharing
a
(''n''-1)-face with ''p'' (''corresponding
iterators on complex are ready,
but the neighborhood/window--which are almost template typedefs!) are to
be implemented'');
`complex_higher_dim_connected_window`:: the set of ''n''-faces sharing
a
(''n''+1)-face with ''p''
(''likewise'');
`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 transitively
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.
Note that some of these iterators might implement operators on complexes,
see
http://en.wikipedia.org/wiki/Simplicial_complex#Closure.2C_star.2C_and_link.
Comment (by levill_r):
Update the status of this ticket.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/162#comment:8>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
18 Oct
18 Oct
5:08 p.m.
#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''~~ (done in r2459, r2460, and r2514);
~~`complex_higher_window`~~:: ~~the set of (''n''+1)-faces adjacent to
''p''~~ (done in r2459, r2460 and r2517);
~~`complex_lower_higher_window`~~:: ~~the set of (''n''-1)- and
(''n''+1)-faces adjacent to ''p''~~ (done in r2496 and
r2518);
`complex_m_lower_window`:: for ''m'' < ''n''
(''m'' being dynamic), the
set of ''m''-faces « transitively adjacent » to ''p'';
`complex_m_higher_window`:: for ''m'' > ''n''
(''m'' being dynamic), the
set of ''m''-faces « transitively adjacent » to ''p'';
`complex_lower_dim_connected_window`:: the set of ''n''-faces sharing
a
(''n''-1)-face with ''p'' (''corresponding
iterators on complex are
ready, but the neighborhood/window--which are almost template typedefs!)
are to be implemented'');
`complex_higher_dim_connected_window`:: the set of ''n''-faces sharing
a
(''n''+1)-face with ''p''
(''likewise'');
`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 transitively
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.
Note that some of these iterators might implement operators on complexes,
see
http://en.wikipedia.org/wiki/Simplicial_complex#Closure.2C_star.2C_and_link.
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''~~ (done in r2459, r2460, and r2514);
~~`complex_higher_window`~~:: ~~the set of (''n''+1)-faces adjacent to
''p''~~ (done in r2459, r2460 and r2517);
~~`complex_lower_higher_window`~~:: ~~the set of (''n''-1)- and
(''n''+1)-faces adjacent to ''p''~~ (done in r2496 and
r2518);
`complex_m_lower_window`:: for ''m'' < ''n''
(''m'' being dynamic), the
set of ''m''-faces « transitively adjacent » to ''p'';
`complex_m_higher_window`:: for ''m'' > ''n''
(''m'' being dynamic), the
set of ''m''-faces « transitively adjacent » to ''p'';
~~`complex_lower_dim_connected_window`~~:: ~~the set of ''n''-faces
sharing a (''n''-1)-face with ''p''~~ (done in r2605 and
r2606);
~~`complex_higher_dim_connected_window`~~:: ~~the set of ''n''-faces
sharing a (''n''+1)-face with ''p''~~ (done in r2605 and
r2606);
`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 transitively
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.
Note that some of these iterators might implement operators on complexes,
see
http://en.wikipedia.org/wiki/Simplicial_complex#Closure.2C_star.2C_and_link.
Comment (by levill_r):
Kill more items.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/162#comment:9>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
22 Oct
22 Oct
12:49 p.m.
#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''~~ (done in r2459, r2460, and r2514);
~~`complex_higher_window`~~:: ~~the set of (''n''+1)-faces adjacent to
''p''~~ (done in r2459, r2460 and r2517);
~~`complex_lower_higher_window`~~:: ~~the set of (''n''-1)- and
(''n''+1)-faces adjacent to ''p''~~ (done in r2496 and
r2518);
`complex_m_lower_window`:: for ''m'' < ''n''
(''m'' being dynamic), the
set of ''m''-faces « transitively adjacent » to ''p'';
`complex_m_higher_window`:: for ''m'' > ''n''
(''m'' being dynamic), the
set of ''m''-faces « transitively adjacent » to ''p'';
~~`complex_lower_dim_connected_window`~~:: ~~the set of ''n''-faces
sharing a (''n''-1)-face with ''p''~~ (done in r2605 and
r2606);
~~`complex_higher_dim_connected_window`~~:: ~~the set of ''n''-faces
sharing a (''n''+1)-face with ''p''~~ (done in r2605 and
r2606);
`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 transitively
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.
Note that some of these iterators might implement operators on complexes,
see
http://en.wikipedia.org/wiki/Simplicial_complex#Closure.2C_star.2C_and_link.
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''~~ (done in r2459, r2460, and r2514);
~~`complex_higher_window`~~:: ~~the set of (''n''+1)-faces adjacent to
''p''~~ (done in r2459, r2460 and r2517);
~~`complex_lower_higher_window`~~:: ~~the set of (''n''-1)- and
(''n''+1)-faces adjacent to ''p''~~ (done in r2496 and
r2518);
~~`complex_m_face_window`~~:: ~~for a given ''m'' (being dynamic), the
set of ''m''-faces « transitively adjacent » to ''p''~~
(done in r2630 and
r2631);
~~`complex_lower_dim_connected_window`~~:: ~~the set of ''n''-faces
sharing a (''n''-1)-face with ''p''~~ (done in r2605 and
r2606);
~~`complex_higher_dim_connected_window`~~:: ~~the set of ''n''-faces
sharing a (''n''+1)-face with ''p''~~ (done in r2605 and
r2606);
`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 transitively
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.
Note that some of these iterators might implement operators on complexes,
see
http://en.wikipedia.org/wiki/Simplicial_complex#Closure.2C_star.2C_and_link.
Comment (by levill_r):
Kill done items.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/162#comment:10>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
14 May
14 May
4:57 p.m.
#162: Implement windows, neighborhoods, and corresponding iterators for complex-
based images
-----------------------+----------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: task | Status: closed
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Resolution: fixed | Keywords:
-----------------------+----------------------------------------------------
Changes (by levill_r):
* status: assigned => closed
* resolution: => fixed
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''~~ (done in r2459, r2460, and r2514);
~~`complex_higher_window`~~:: ~~the set of (''n''+1)-faces adjacent to
''p''~~ (done in r2459, r2460 and r2517);
~~`complex_lower_higher_window`~~:: ~~the set of (''n''-1)- and
(''n''+1)-faces adjacent to ''p''~~ (done in r2496 and
r2518);
~~`complex_m_face_window`~~:: ~~for a given ''m'' (being dynamic), the
set of ''m''-faces « transitively adjacent » to ''p''~~
(done in r2630
and r2631);
~~`complex_lower_dim_connected_window`~~:: ~~the set of ''n''-faces
sharing a (''n''-1)-face with ''p''~~ (done in r2605 and
r2606);
~~`complex_higher_dim_connected_window`~~:: ~~the set of ''n''-faces
sharing a (''n''+1)-face with ''p''~~ (done in r2605 and
r2606);
`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 transitively
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.
Note that some of these iterators might implement
operators on complexes,
see
http://en.wikipedia.org/wiki/Simplicial_complex#Closure.2C_star.2C_and_link.
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''~~ (done in r2459, r2460, and r2514);
~~`complex_higher_window`~~:: ~~the set of (''n''+1)-faces adjacent to
''p''~~ (done in r2459, r2460 and r2517);
~~`complex_lower_higher_window`~~:: ~~the set of (''n''-1)- and
(''n''+1)-faces adjacent to ''p''~~ (done in r2496 and
r2518);
~~`complex_m_face_window`~~:: ~~for a given ''m'' (being dynamic), the
set of ''m''-faces « transitively adjacent » to ''p''~~
(done in r2630 and
r2631);
~~`complex_lower_dim_connected_window`~~:: ~~the set of ''n''-faces
sharing a (''n''-1)-face with ''p''~~ (done in r2605 and
r2606);
~~`complex_higher_dim_connected_window`~~:: ~~the set of ''n''-faces
sharing a (''n''+1)-face with ''p''~~ (done in r2605 and
r2606);
[wiki:Olena/ComplexBasedImages] contains a summary of these constructs.
Additional proposals have been moved to #188.
--
Comment:
Close this ticket, move remaining items to #188 for milestone:"Olena 1.1".
--
Ticket URL: <https://trac.lrde.org/olena/ticket/162#comment:11>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
5474
days inactive
5721
days old
11 comments
2 participants
participants (2)
-
Olena -
Olena Trac