gabrielhdt / gama Goto Github PK

Lors de certaines séparations de contours, le parcours se passe mal, un pixel se retrouve isolé et le programme renvoie une KeyError ou pop() from an empty list.

Problème dans les contours séparés: si un pixel d'un contour a 3 voisins (e.g. le pixel juste avant un coin de carré), il ne sera pas compté dans le contour et se retrouvera (par différence ensembliste) dans l'autre, alors qu'il n'a rien à y faire.

Le problème vient du calcul des tangentes: si start.x == end.x, alors un des points de contrôle risque d'être confondu avec le point de départ ou d'arrivée. Une solution est d'utiliser plus souvent les cubiques véritables.

Dans le cas d'un contour arenamorphe (côtés de longueur au moins 2), pas d'extrema trouvés.

Si deux contours s'intersectent l'une des zones connexes n'aura pas le contour.

En lançant list_curves([cont]), l'erreur suivante est obtenue

File "test.py", line 34, in test_tg
    curves = cp.list_curves([cont])
  File "/home/gabriel/workspace/vcs/GAMA/control_points.py", line 79, in list_curves
    curves.append(curve)
UnboundLocalError: local variable 'curve' referenced before assignment

avec cont un carré défini par:

cont.xys += [ie.Pixel(10 + i, i) for i in range(10, 21)]                    
cont.xys += [ie.Pixel(30 - i, 20 + i) for i in range(1, 11)]                
cont.xys += [ie.Pixel(20 - i, 30 - i) for i in range(1, 11)]                
cont.xys += [ie.Pixel(10 + i, 20 - i) for i in range(1, 11)]

Le problème semble résider dans les conditions
if len(contour.xys) < 3: et while start != c_end: qui ne couvriraient pas tous les cas, laissant curve non initialisée lors de l'appel curves.append(curve).

Régler la profondeur maximale de récursion, voir
https://docs.python.org/3/library/sys.html#sys.setrecursionlimit.

Avec des contours d'une largeur de 1 pixel (une ligne), la ligne est aperçue si le contour est attaqué de l'extérieur, pas de l'intérieur. Il restera un contour non fermé après séparation des contours. Tests réalisés avec

Si la séparation du contour démarre sur un agencement type:

• pixel en (0, 0)
• pixel en (1, 0)
• pixel en (0, 1)
• pixel en (2, 1)
  alors le programme peut parcourir dans l'ordre:

1. Pixel(0, 0)
2. Pixel(1, 0)
3. Pixel(0, 1)
   puis continuer du côté gauche, laissant le Pixel(2, 1) sans voisins et faisant planter le programme lors du pop() ligne 170:

inspix = neighbourhood.pop()
KeyError: 'pop from an empty set'

Jusqu'où peut-on considérer l'intersection des tangentes? Actuellement, si l'intersection dépasse le rectangle formé par les deux pixels, on ne considère pas l'intersection des tangentes, cf validate_flyby() dans control_points. La fonction peut-être modifiée.

Lors de la séparation d'un contour, la présence d'un pixel ayant 2 voisins proches peut engendrer le saut d'un des voisins et laisser alors un contour (raw_minusloop) avec seulement le pixel exclu. Sa suppression est envisageable (petite quantité de pixels). Peut être comparé avec les autres contours. À suivre.

Could be more efficient to return a list of stacks when separating contours, each stack being a block of neighbours. Would cost less in terms of computing when sorting.

Le programme detection_contour(...) boucle infiniment. En affichant la variable voisins_contourless à chaque appel, on remarque que le programme tombe dans un état périodique:

...
[<Pixel at 0, 2>]                                                               
[<Pixel at 1, 1>, <Pixel at 1, 3>]                                              
[<Pixel at 0, 0>, <Pixel at 0, 2>]                                              
[<Pixel at 1, 1>, <Pixel at 0, 2>]                                              
[<Pixel at 0, 2>]                                                               
[<Pixel at 1, 1>, <Pixel at 1, 3>]
...

En affichant l'attribut unread à chaque appel, on obtient (au bout d'un nombre d'itérations) une alternance False True False True ... jusqu'à dépassement de la max recursion depth. En fait, le <Pixel at 1, 1> reste toujours à True, les autres sont bien à False.

Peut-être faut-il examiner la manière dont python stocke les variables lors d'appels récursifs (mise à jour de celles là dans les appels précédents ou non), ou utiliser une matrice de booléen remplaçant les attributs.

Possibilité de séparer le calcul de la précision de pente_s de pente_e. Nécessite de connaître le point d'inflexion suivant, voire tous?

Éviter la formation de triangles dans thinner(), sources de bugs.

À partir d'une simili cardioïde définie dans contour_tests, list_curves me renvoie

[array([[ 10.        ,  20.        ],
       [ 22.99270073,  42.99270073],
       [ 31.        ,  19.        ]]),
 array([[ 31.        ,  19.        ],
       [ 11.23595506,  19.97378277],
       [ 11.        ,  21.        ]])]

ce qui donne, après le passage dans la nouvelle fonction curves2curvemat:

[[ 10.          20.        ]
 [ 22.99270073  42.99270073]
 [ 31.          19.        ]
 [ 11.23595506  19.97378277]
 [ 11.          21.        ]]

et le dessin suivant

Le point de contrôle [23, 43] peut-être dû à un problème de repère (origine en haut à gauche). Les deux derniers points sont également faux, peut-être un problème de translation? On ne les voit pas sur la figure mais on obtient deux courbes de Bézier, qui se chevauchent ici.

Compléter l'attribut colour des contours en fonction de la couleur de la zone dans l'image.

Si une zone longe le bord, alors le contour de cette zone n'est pas fermé. Testé avec le logo python, donnant une matrice greyscale avec un seuil de 0.1 après un regroupement de couleurs:

Détermination des contours par seuillages successifs, pourrait être plus précis.

La séparation des contours se fait nécessairement avant affinage, car ce dernier restreint le nombre de voisins par pixel à deux, incompatible avec des intersections de contours. Le problème réside dans l'intersection de contours (à vérifier) et dans la présence de ``couloirs'' i.e. une ligne d'un pixel bordée par deux contours différents, générant un quadrillage rempli sur la longueur de la ligne

Le find_inflexion() à corriger, trop de points de contrôle sur des lignes droites et l'utilisation de is_vert est mal implémentée

Identifié les waypoints donnés par scanlines() pour forcer la tangente droite d'un côté du point et ainsi assurer la ligne droite entre les deux points du scanlines.

Utile ou non? Ne semble pas pertinent.