Project management platform of the CMM: Issueshttp://morphm.ensmp.fr/http://morphm.ensmp.fr/favicon.ico?15861924492013-09-13T11:50:23ZProject management platform of the CMM
Redmine Morph-M - Anomalie #236 (Nouveau): Renommage de fonctions dans users/morard/FastLinehttp://morphm.ensmp.fr/issues/2362013-09-13T11:50:23ZEtienne Decencière
<p>Toutes les fonctions dont les noms sont du type <strong>MaxClosing</strong> dans le module FastLine devraient s'appeler <strong>MinClosing</strong>. Il s'agit uniquement d'un problème de nom, vu que ces fonctions font appel à la fonction <strong>MaxOpening</strong> correspondante après inversion de l'image d'entrée.</p> Morph-M - Anomalie #67 (Résolu): MorpheeMorphoMaxTree : erreur de compilation sous Linux - et pr...http://morphm.ensmp.fr/issues/672009-11-17T09:10:18ZEtienne Decencière
<p>J'utilise gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3 .</p>
<p>J'obtiens less erreurs suivantes :</p>
<p>/home/decencie/src/trunk/addons/free/MorphoMaxTree/pythonExt/PythonExport.cpp: In function ‘morphee::RES_C morphee::MorphoMaxTree::<unnamed>::t_Py_MaxTreeWithBox(const morphee::ImageInterface*, const morphee::ImageInterface*, const morphee::selement::NeighborList&, morphee::ImageInterface*, boost::python::api::object&)’:<br />/home/decencie/src/trunk/addons/free/MorphoMaxTree/pythonExt/PythonExport.cpp:269: erreur: expected primary-expression before ‘>’ token<br />/home/decencie/src/trunk/addons/free/MorphoMaxTree/pythonExt/PythonExport.cpp:269: erreur: expected primary-expression before ‘)’ token<br />/home/decencie/src/trunk/addons/free/MorphoMaxTree/pythonExt/PythonExport.cpp: In function ‘morphee::RES_C morphee::MorphoMaxTree::<unnamed>::t_Py_MaxTreeWithBox(const morphee::ImageInterface*, const morphee::selement::NeighborList&, morphee::ImageInterface*, boost::python::api::object&)’:<br />/home/decencie/src/trunk/addons/free/MorphoMaxTree/pythonExt/PythonExport.cpp:298: erreur: expected primary-expression before ‘>’ token<br />/home/decencie/src/trunk/addons/free/MorphoMaxTree/pythonExt/PythonExport.cpp:298: erreur: expected primary-expression before ‘)’ token</p>
<p>Elles ont la même cause. Dans le premier cas, il s'agit de la ligne:</p>
<pre>
tTreeBox g = maxTree.getGraphWithBox<tTreeBox>();
</pre>
<p>Sur mon système, le problème disparait avec la correction suivante:</p>
<pre>
tTreeBox g = maxTree.template getGraphWithBox<tTreeBox>();
</pre>
<p>On peut corriger de la même façon la ligne 298.</p>
<p>Je veux bien intégrer la modification sur le serveur svn, si une bonne volonté vérifie que ça marche aussi sous Windows.</p> Morph-M - Anomalie #63 (Nouveau): Bug implémentation de ImLambdaLevelinghttp://morphm.ensmp.fr/issues/632009-10-08T14:20:51ZJean Felder
<p>Au cours du tp de l'école d'été nous avons constaté une différence entre l'implémentation du LambdaLeveling à partir de la définition usuelle et celle de Morph-M : ImLambdaLeveling.</p>
<p>On peut constater cette différence sur le ficher joint test.py.</p>
<p>Béatriz soupçonne le fait qu'en C++ on fait un LowLeveling et puis un HighLeveling (ou l'inverse) ce qui peut nous amener a ne pas être complètement symétriques.</p> Morph-M - Anomalie #62 (Nouveau): Conversions couleur avec des images UINT8http://morphm.ensmp.fr/issues/622009-09-22T17:41:17ZBeatriz Marcotegui
<p>Les fonctions de conversion couleur travaillent avec des images en flotant. Quand ensuite on veut utiliser les images pour les filtrer/segmenter il faut revenir sur des images UINT8. Lors des TPs, cette conversion se fait en utilisant la fonction stretchImage. Ceci me parait un peu dangereux. En effet, le stretch d'une image avec une faible dynamique cree des forts contrastes artificiels (si on a une image peu saturee, ce n'est pas la peine de forcer la saturation a aller de 0 a 255).</p>
<p>Par ailleurs, avec morph-m on n'arrive pas a reproduire les resultats de segmentation qu'on obtenait avec xlim. En particulier, il faut beaucoup plus d'etapes de waterfall pour obtenir une route en une seule region, ou le ciel en une seule region aussi.</p>
<p>Pour ces deux raisons, j'ai rajoute dans morph-M des fonctions de conversion couleur en masquant a l'utilisateur le passage par des images flottantes (en reprenant les formules xlim). Voici les noms de ces fonctions:</p>
<p>ColorConvertRGBToXYZ_int,ColorConvertXYZToLAB_int,ColorConvertLABToXYZ_int,ColorConvertXYZToRGB_int.</p>
<p>Un dispatch UINT8, UINT8 a egalement ete rajoute dans la fonction colorSpaceTransform_RGB___HLS_l1. <br />Ceci est fait "un peu" dans la precipitation. Ce n'est pas souhaitable que la meme fonction (avec le meme nom!) normalise les images si on passe comme parametre des images UINT8 et que cette normalisation soit inexistante si on lui passe des images flotantes. Idealement il faudrait passer comme parametre si la normalisation est souhaitee, et il faudrait eviter le stretch a l'aveugle (forcer la sortie entre 0 et 255). Il faudra egalement verifier si les formules de conversion sont les memes dans les differentes versions et definir la conversion en flotant une seule fois.</p>
<p>En resume, ce qui reste a faire:</p>
<p>- verifier les formules de conversion utilisees par les versions "_int" et celles existant dans les premieres versions de morph-M</p>
<p>- quand on lui passe des image UINT8, les convertir en flotant et utiliser les fonctions de conversion en flotant, pour normaliser apres</p>
<p>- definir proprement les valeurs min,max a utiliser dans la normalisation (selon le espace couleur utilise), en evitant le forcing 0-255.</p>
<p>Je crois que c'est tout, en tout cas il faut que j'y aille!</p>
<p>Bea</p> Morph-M - Anomalie #61 (Assigné): CMake : simplifier la gestion des modules FFThttp://morphm.ensmp.fr/issues/612009-06-19T14:03:54ZEtienne Decencière
<p>Certains choix d'options dans le CMake liées aux modules FFT provoquent des problèmes de dépendances au moment de la compilation. C'est d'ailleurs pour cette raison qu'en ce moment la compilation nocturne du module FFT se passe mal.</p>
<p>Il faudrait revoir ces différentes options, et les dépendances correspondantes.</p> Morph-M - Anomalie #58 (Nouveau): Developers Guide : install instructionshttp://morphm.ensmp.fr/issues/582009-03-06T16:07:17ZBeatriz Marcotegui
<p>Le point 3.1 du "developers guide", Compilation and Installation, Under Linux n'est pas actualisé. Il fait reference a ./build.sh au lieu de cmake.</p> Morph-M - Anomalie #57 (Nouveau): Problème avec les recherches dans "C++ core documentation" (dox...http://morphm.ensmp.fr/issues/572009-03-04T18:45:42ZEtienne Decencière
<p>Les recherches dans la doc doxygen du coeur (C++ core documentation) produisent un charabia incompréhensible.</p> Morph-M - Anomalie #56 (Résolu): Liens dans Graphs->Documentationhttp://morphm.ensmp.fr/issues/562009-02-23T10:47:44ZEtienne Decencière
<p>Dans le projet Graphs, onglet Documentation, le lien vers la doc C++ ne marche pas.</p> Morph-M - Anomalie #54 (Assigné): pb segmentation volumiquehttp://morphm.ensmp.fr/issues/542009-01-20T15:28:38ZBeatriz Marcotegui
<p>pb segmentation volumique avec des images 3D.</p>
<p>Le script joint permet de reproduire le probleme. Le resultat est tout simplement aberrant. Le resultat s'ameliore si:<br />- on reduit la taille de l'image (3 frames a la place de 10, c'est le parametre qu'on passe a exercice2()<br />- on change d'element structurant (6 -> 26)</p>
<p>Le nombre de regions semble etre en cause, mais l'image labels est une image 32 bits et le nombre des labels pour 10 trames est d'environ 21000.</p>
<p>Le probleme est le meme quand on travaille avec le critere de surface au lieu du critere volumique.</p>
<p>J'ai teste sous xlim et cela ne lui pose pas de probleme.</p>
<p>Quelqu'un peut apporter un peu de lumiere?</p> Morph-M - Anomalie #53 (Assigné): seg volumique: arete entre regions non voisines.http://morphm.ensmp.fr/issues/532009-01-20T14:23:57ZBeatriz Marcotegui
<p>Apres une segmentation hierarchique volumique de l'image cameraman,<br />l'arete la plus importante (celle qu'on ellimine si on demande a <br />l'algo de segmenter en 2 regions) relie deux regions qui NE SONT PAS CONNEXES!!</p>
<p>(Je n'ai pas oublie le +1 pour passer du label dans l'image au noeud du graphe;-).</p>
<p>Cette arete se trouve entre les regions 1759-1804.</p>
<p>Quelqu'un a une explication? Je joins le fichier python pour reproduirele probleme.</p> Morph-M - Assistance #52 (Nouveau): Error: Initialiseurs trop nombreuxhttp://morphm.ensmp.fr/issues/522008-12-17T10:14:22ZJorge Hernandezhernandez@cmm.ensmp.fr
<p>Je suis en train de faire le « dispach » d’une fonction, et je suis tombé avec le problème de trop d’initialiseurs. Est-ce que quelqu’un a une idée de comme résoudre le problème ?</p> Morph-M - Evolution #51 (Nouveau): Graphs : rename getChildrenhttp://morphm.ensmp.fr/issues/512008-12-05T14:32:05ZEtienne Decencière
<p>Several functions working on graphs, which used to work on trees, have names that are not appropriate anymore.</p>
<p>For instance, getChildren should be renamed into getNeighbors.</p> Morph-M - Anomalie #44 (Nouveau): Doc développeurs : rajouter une section sur les tests unitai...http://morphm.ensmp.fr/issues/442008-12-01T15:32:27ZEtienne Decencière
<p>Description:<br />----------------------------------------<br />La doc développeurs n'explique pas comment mettre en place des tests unitaires.</p>
<p>#1 19/05/2008 17:46 (etienne)<br />---------------------------------------------------------------------------<br />Change: status: "pending" -> "accepted" <br />Change: assignees: "[]" -> "['morphmdev']" <br />Change: topic: "" -> "Others" <br />Change: solution: "" -> "Ecrire la section pertinente." <br />Change: importance: "medium" -> "low" <br />Change: title: "" -> "Doc développeurs : rajouter une section sur les tests unitaires" <br />Change: classification: "Bug" -> "Documentation" <br />Change: description: "" -> "La doc développeurs n'explique pas comment mettre en place des tests unitaires."</p> Morph-M - Evolution #38 (Nouveau): setActiveWindow() et ge stion des débordements http://morphm.ensmp.fr/issues/382008-12-01T14:55:37ZEtienne Decencière
<p>Description:<br />----------------------------------------<br />Les débordements des fenêtres actives ne sont pas gérés de la même façon en<br />fonction du bord concerné. En 2D, avec les conventions usuelles, si la fenêtre<br />déborde à gauche ou en haut, elle est déplacée de façon à ce qu'elle rentre dans<br />l'image. Si elle déborde à droite ou en bas, elle est coupée.<br />Ce comportement, hérité de Xlim3D, garantit que la fenêtre active obtenue n'est<br />jamais vide.<br />Personnellement, je préférerais un mécanisme qui gère de la même façon les<br />différents bords. Je propose de toujous prendre l'intersection entre la fenêtre<br />active demandée et l'image (c'est à dire, toujours couper la fenêtre active).<br />Dans ce cas, un problème se pose lorsque l'intersection est vide. On pourrait<br />alors:<br />1) Ne rien faire (garder la fenêtre active précédente?) et rendre un RES en<br />conséquence;<br />2) avoir une fenêtre active vide ? Plus rigueureux, mais source potentielle de<br />problèmes pour les utilisateurs... (et je ne sais pas si cette éventualité<br />bizarre a été prévue par les autres fonctions, et en particulier par les<br />itérateurs).</p>
<p>#1 23/11/2007 11:25 (etienne)<br />---------------------------------------------------------------------------<br />Change: status: "pending" -> "accepted" <br />Change: assignees: "[]" -> "['morphmdev', 'raffi', 'Thomas', 'Tibs']" <br />Change: topic: "" -> "UI" <br />Change: importance: "medium" -> "low" <br />Change: title: "" -> "setActiveWindow() et gestion des débordements" <br />Change: classification: "Bug" -> "Feature" <br />Change: description: "" -> "Les débordements des fenêtres actives ne sont pas gérés de la même façon en fonction du bord concerné. En 2D, avec les conventions usuelles, si la fenêtre déborde à gauche ou en haut, elle est déplacée de façon à ce qu'elle rentre dans l'image. Si elle déborde à droite ou en bas, elle est coupée.</p>
<p>Ce comportement, hérité de Xlim3D, garantit que la fenêtre active obtenue n'est jamais vide.</p>
<p>Personnellement, je préférerais un mécanisme qui gère de la même façon les différents bords. Je propose de toujous prendre l'intersection entre la fenêtre active demandée et l'image (c'est à dire, toujours couper la fenêtre active).</p>
<p>Dans ce cas, un problème se pose lorsque l'intersection est vide. On pourrait alors:</p>
<p>1) Ne rien faire (garder la fenêtre active précédente?) et rendre un RES en conséquence;</p>
<p>2) avoir une fenêtre active vide ? Plus rigueureux, mais source potentielle de problèmes pour les utilisateurs... (et je ne sais pas si cette éventualité bizarre a été prévue par les autres fonctions, et en particulier par les itérateurs).</p>
<p>"</p> Morph-M - Anomalie #8 (Assigné): Tests unitaires pour le block-matchinghttp://morphm.ensmp.fr/issues/82008-11-28T11:47:24ZEtienne Decencière
<p>Tests unitaires pour le block-matching.</p>