
En débuggant du code utilisant Olena, j'ai passé du temps sur un problème avant de comprendre ce qui se passait, mais j'ai fini par trouver (ouf!). Un algo qui travaille sur une image avec voisinage, mais qui se fiche de son voisinage (la variante de l'érosion qui prend une fenêtre, par ex.) perd l'information de voisinage dans l'image de sortie. Quelque part, c'est normal, mais c'est assez dérangeant (on a toujours une image_with_nbh<>, mais son voisinage est vide). Voici un exemple qui illustre mon problème : #include <oln/core/2d/image2d.hh> #include <oln/morpho/erosion.hh> #include <oln/core/gen/image_with_nbh.hh> using namespace oln; int main () { image2d<int> ima1 (3, 3); typedef image_with_nbh<image2d<int>, neighborhood2d> ima_type; ima_type ima2 = join(ima1, neighb_c4()); std::cout << "ima2.nbh_get().card () = " << ima2.nbh_get().card () << std::endl; // A naive approach (the neighborhood is lost!). ima_type ima3 = morpho::erosion (ima2, win_c4p()); std::cout << "ima3.nbh_get().card () = " << ima3.nbh_get().card () << std::endl; // The cumbersome (but right) way. ima_type ima4 (morpho::erosion (ima2, win_c4p()).image(), ima2.nbh_get ()); std::cout << "ima4.nbh_get().card () = " << ima4.nbh_get().card () << std::endl; } Et voici ce qui se passe à l'exécution : brasilia ~/tmp/oln-tests % ./lost-nbh ima2.nbh_get().card () = 4 ima3.nbh_get().card () = 0 ima4.nbh_get().card () = 4 La construction de ima4 illustre le work-around que j'ai utilisé. (Je sais que la copie/affectation d'images est un problème dont nous avions déjà évoqué.)

Roland Levillain wrote:
En débuggant du code utilisant Olena, j'ai passé du temps sur un problème avant de comprendre ce qui se passait, mais j'ai fini par trouver (ouf!).
Un algo qui travaille sur une image avec voisinage, mais qui se fiche de son voisinage (la variante de l'érosion qui prend une fenêtre, par ex.) perd l'information de voisinage dans l'image de sortie. Quelque part, c'est normal, mais c'est assez dérangeant (on a toujours une image_with_nbh<>, mais son voisinage est vide).
Voici un exemple qui illustre mon problème :
#include <oln/core/2d/image2d.hh> #include <oln/morpho/erosion.hh> #include <oln/core/gen/image_with_nbh.hh>
using namespace oln;
int main () { image2d<int> ima1 (3, 3);
typedef image_with_nbh<image2d<int>, neighborhood2d> ima_type; ima_type ima2 = join(ima1, neighb_c4()); std::cout << "ima2.nbh_get().card () = " << ima2.nbh_get().card () << std::endl;
// A naive approach (the neighborhood is lost!). ima_type ima3 = morpho::erosion (ima2, win_c4p()); std::cout << "ima3.nbh_get().card () = " << ima3.nbh_get().card () << std::endl;
// The cumbersome (but right) way. ima_type ima4 (morpho::erosion (ima2, win_c4p()).image(), ima2.nbh_get ()); std::cout << "ima4.nbh_get().card () = " << ima4.nbh_get().card () << std::endl; }
Et voici ce qui se passe à l'exécution :
brasilia ~/tmp/oln-tests % ./lost-nbh ima2.nbh_get().card () = 4 ima3.nbh_get().card () = 0 ima4.nbh_get().card () = 4
La construction de ima4 illustre le work-around que j'ai utilisé.
(Je sais que la copie/affectation d'images est un problème dont nous avions déjà évoqué.)
c'est dû à .size() au lieu de .info() : oln_type_of(I, concrete) erosion_(const abstract::binary_image<I>& input, const abstract::window<W>& win) { entering("->generic_on_set"); registering(input, "input"); oln_type_of(I, concrete) output(input.size(), "output"); // FIXME: the use of .info() instead of .size() above would // allow to create output with the proper neighborhood // if input is an image_with_nbh... oln_type_of(I, fwd_piter) p(input.size()); for_all_p (p) output[p] = win_and_value(input, p, win); exiting("->generic_on_set"); return output; } simon, tes modifs urgent !!!
participants (2)
-
Roland Levillain
-
Thierry GERAUD