DÉTECTION DES DROITES DANS UNE IMAGE : HOUGH
cs_Kirua
Messages postés
3006
Date d'inscription
dimanche 14 avril 2002
Statut
Membre
Dernière intervention
31 décembre 2008
-
19 juil. 2007 à 00:22
kami0o Messages postés 1 Date d'inscription mercredi 14 octobre 2009 Statut Membre Dernière intervention 7 juin 2011 - 7 juin 2011 à 17:30
kami0o Messages postés 1 Date d'inscription mercredi 14 octobre 2009 Statut Membre Dernière intervention 7 juin 2011 - 7 juin 2011 à 17:30
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/43486-detection-des-droites-dans-une-image-hough
https://codes-sources.commentcamarche.net/source/43486-detection-des-droites-dans-une-image-hough
7 juin 2011 à 17:30
Peace,
Gaara
12 mars 2010 à 22:31
8 nov. 2009 à 23:27
Ps : Jpense que tu t'en "fou" mais si tu es intéressé je peux te le passer.
Et encore merci pour tout ceux qui m'ont aidé.
A+
5 nov. 2009 à 13:55
bool CImage::Barycentre(CImage *ImgDest)
{
if(hBmp==0){
MessageBox(NULL,"Barycentre : L'image source est vide",
NULL,MB_OK|MB_ICONWARNING);
return 0;
}
if(ImgDest==0)
ImgDest=this;
POINT Pt;
int i,j,Pij,X,Y,k,l,cpt,MoyenneX,MoyenneY;
bool **Buffer;
queue Fifo,FifoSave;
CImage ImgTmp(this);
ImgDest->Copy(this);
ImgDest->Fill(0,0,0);
//Cette image permet de visualiser les pixels déjà visités.
Buffer=AllocT_bool(Width,Height,FALSE);
//Pour tous les pixels de l'image
for(i=0;i<Width;i++)
for(j=0;j<Height;j++)
if(Buffer[i][j]==FALSE)
{
Buffer[i][j]=TRUE;
Pij=(int) ImgTmp.ucBits[(i+j*Width)*4];
if(Pij!=255)
continue;
Pt.x=i;Pt.y=j;
Fifo.push(Pt);
FifoSave.push(Pt);
do
{
Pt=Fifo.front();
Fifo.pop();
X=Pt.x;Y=Pt.y;
for(k=-1;k<=1;k++)
for(l=-1;l<=1;l++)
if(X+k>=0 && Y+l>=0 && X+k<Width && Y+l<Height)
if(!(k==0 && l==0))
if(Buffer[X+k][Y+l]==FALSE && ImgTmp.ucBits[(X+k+(Y+l)*Width)*4] == 255)
{
Buffer[X+k][Y+l]=TRUE;
Pt.x=X+k;Pt.y=Y+l;
Fifo.push(Pt);
FifoSave.push(Pt);
}
}
while(!Fifo.empty());
if(FifoSave.empty())
continue;
cpt=0;
MoyenneX=0;
MoyenneY=0;
while(!FifoSave.empty())
{
Pt=FifoSave.front();
FifoSave.pop();
MoyenneX+=Pt.x;
MoyenneY+=Pt.y;
cpt++;
}
ImgDest->SetPixel((int)((double) MoyenneX/(double)cpt),(int)((double) MoyenneY/(double)cpt),255,255,255);
}
SetBitmapBits (ImgDest->hBmp,(Width*Height)*4,ImgDest->ucBits);
ImgDest->ImgType=BIN;
DesAllocT_bool(Buffer,Width);
return true;
}
A+
5 nov. 2009 à 11:27
Mais de toute façon je programmerai sur Matlab, j'ai aperçu une fonction sur ce logiciel qui permettait de faire les contours directement. Mais après pour avoir les coordonnées de chaque point dans un tableau, je ne vois pas du tout comment faire.
La programmation, le traitement d'image et moi ne vont pas très bien ensemble.
Merci pour votre aide.
5 nov. 2009 à 09:00
Tu pourrais faire:
-un seuillage (automatique ou non) =>où chaque groupe de point noir représente une composante connexe.
-Une fermeture des trous : pour pallier aux éventuelles défaillance du seuilage
-Puis tu calcule le barycentre de chaque composante connexe et tu as la position de tes points noirs.
Tous les traitements mentionnés sont disponibles ici : http://ImAnalyse.free.fr
A+
4 nov. 2009 à 20:54
Je dirais : fais une recherche de contours fermés ayant une aire raisonnable et ( si ça suffit pas ) contenant principalement du noir.
http://www710.univ-lyon1.fr/~bouakaz/OpenCV-0.9.5/docs/ref/OpenCVRef_ImageProcessing.htm#decl_cvFindContours
4 nov. 2009 à 19:02
Je vais expliquer un peu plus. Dans le cadre de mon PFE en dernière année d'école d'ingénieur, je dois modéliser l'interface eau air lors de petites oscillations verticales pour voir le phénomène de l'instabilté de Faraday.
On dispose d'une caméra rapide, on place une mire (ici une feuille transparente avec des points noirs disposés dessus) sous le liquide et avec le mouvement de l'eau les points noires ne seront plus disposés pareil à différents instants t (à cause de la diffraction de la lumière). Cela me permettra de calculer la profondeur d'eau à un instant t à une position (x,y).
Et ce que je cherche c'est de pouvoir mettre sous forme d'un tableau les coordonnées des différents points noirs (ou taches noires) de chaque photo. Sachant qu'il y aura probablement des milliers de photos et donc beaucoup de points, le faire à la main serait beaucoup trop fastidieux.
Donc en clair avec une photo en noire et blanc composé que de points noirs j'aimerais avoir un tableau pour chaque photo contenant les coordonnées de chaque point (qui ne sont pas parfaitement des points...)
Merci j'espère avoir été assez clair. Pour info je suis complètement novice dans le traitement d'images ( ce qui n'est pas du tout mon domaine).
Merci
4 nov. 2009 à 13:11
A+
4 nov. 2009 à 12:13
J'aimerais savoir si vous connaissiez un programme qui permettrait de détecter des points sur une image en noir et blanc (constitué que de points noirs). Avoir en retour un tableau avec les coordonnées de tous les points. C'est dans le cadre de mon PFE et cela me serait très utile.
Merci
14 avril 2009 à 08:26
10 avril 2009 à 15:18
Bon je voulais maintenant changer d'image , c'est à dire je veux utiliser une image autre que celles dans le dossier , sachant qu'ils ont la même extension mais pas la même taille
7 avril 2009 à 10:42
Janouta, je rejoins l'avis de Kirua, il faudrait que tu réécrives le code, ce sera bien plus bénéfique pour toi. Cependant, si tu veux compiler cette source, va ici et télécharge les sources de CMUgraphique:
http://pistol.petesampras.free.fr
C'est un veille lib qui n'évolue plus, il peut donc y avoir des problèmes de compatibilité avec les compilos actuels.
A+
7 avril 2009 à 10:24
1) Tu as juste besoin de l'algo de détection, pas de toute la partie "affichage" de ce code. Dans ce cas, tu n'auras pas besoin de cmugraphique non plus. Retire simplement le bout de code qu'il te faut du code-source.
2) Idem que ci-dessus, mais tu as du temps pour ton projet: alors réécrit l'algo toi-même. C'est facile, et tu peux t'inspirer de ce code-ci, sans avoir à le compiler. C'est clairement la méthode préférée.
3) Tu comptes utiliser la partie "affichage" de ce code dans ton projet: alors il faut effectivement que tu arrives à compiler ce code complet, et je ne sais pas t'aider.
7 avril 2009 à 09:57
peut etre c une question Bête mais j'ai essayé de tester ce programme mais j'ai pas arrivé j'ai toujours des erreurs ,je pense que c'est à cause des biblio , il reconnait pas la biblio Cmugraphique.h , je travaille sur DevC++ et j'ai vraiment besoin de ce code pour avancer dans mon projet.
Merci d'avance pour la réponse
Cordialement
7 déc. 2007 à 23:25
7 déc. 2007 à 17:29
6 déc. 2007 à 18:31
Je veux garder x constant et dériver en fonction de y, donc c'est bien d_ronde pixels / d_ronde y , non ?
6 déc. 2007 à 17:06
6 déc. 2007 à 14:25
Pour la première partie, je n'ai pas regardé le code...dsl
Pour ta 2nde question, en effet pour gagner du temps tu peux faire un filtre vertical directement-> tu auras moins de points selectionnés donc moins de calculs. Cependant, s'il y a des obliques (des lignes verticales imparfaites) avec des pas de discrétisations espacés tu risques de les rater parfois.
Ensuite si tu cherches uniquement dans le plan vertical, pour optimiser tu peux en effet réduire ton espace discret selon Theta (au regard de la "verticalité" de ce que tu cherches)
6 déc. 2007 à 14:07
Je ne veux détecter que les lignes verticales.
Est-ce que ça vaut le coup de faire un vrai Sobel ? Pourquoi ne pas appliquer que la dérivée discrète partielle en y ?
Après, je suppose qu'il y a bien moyen d'optimiser aussi l'écriture dans l'image de la transformée .. genre ne pas dessiner la sinosoide sur 200 px de large, mais seulement sur les bords et au milieu...idem pour tous les autres traitements.
Vous en pensez quoi ?
6 déc. 2007 à 13:58
Bon par contre: pourquoi diable est-ce que des lignes diagonales apparaissent à partir d'un certain seuil ?
Quand on regarde la transformée seuillée, on voit qu'il y a deux séries de pixels alignés verticalement, et qui produisent fort logiquement ces lignes diagonales.
Et d'ailleurs, ça se voit dans la transformée non seuillée, ya quelques chtirs problèmes à ces mêmes endroits.
Vu que les courbes sont dessinées par ce simple appel :
ImgHough->DrawCosinus(R,Theta,1);
J'en conclus que c'est DrawCosinus qui foire ...
Le problème c'est que le code est bien trop simple pour pouvoir planter ... je sais vraiment pas quoi en penser.
Qqun a une idée ? peut-être que c'est quand tu resample dans [0 255] ?
9 août 2007 à 16:21
9 août 2007 à 16:17
9 août 2007 à 16:09
9 août 2007 à 15:54
Pour les extrema, il suffit juste de créer une structure qui prend les extrema en même temps que l'accumulation se fait (Xmin, Ymin) et (Xmax, Ymax). Càd que chaque sinusoide "écrit" en plus de l'incrémentation de l'accumulateur une borne ou non par un simple test (au début Min=Max quand une droite passe par un seul point).
Après pour les accumlutations avec des densités de probabilité (type cloche gaussienne discrétisée) ou pondération par valeur de niveau de gris, la démarche reste la même avec plus d'écriture.
En gros on rajoute 2 dimensions supplémentaires (en plus de l'espace de vote).
Pour le quid des droites de la forme x=k (je sens la question venir :)), il faut bien penser à traiter les cas des doites de la forme y=ax+b et x=cy+d différemment en fonction de rho et teta.
9 août 2007 à 15:51
Une façon de le faire, mais ça prendrait énormément de mémoire, ce serait de retenir, pour chaque pixel de la TH, quels points du gradient ont contribué à augmenter son poids. De cette manière, on aurait la liste des points du segment de droite, et il suffirait de prendre les extrêmes. Mais la quantité de mémoire nécessaire serait de l'ordre de O(n^4) je pense :/. (avec n la largeur de l'image, considérant des images carrées).
9 août 2007 à 15:38
J'aimerai bien savoir si quelqu'un a déjà réglé ce genre de problèmes.
9 août 2007 à 15:04
9 août 2007 à 14:16
Ce que je pensais faire était une comparaison de la TH inverse avec l'image du gradient. Mais cela ne me semble pas très judicieux dans le sens où dans l'image du gradient, les points avec un fort gradient peut s'écarter de la droite tracée...
Je suis aussi preneur de toutes les idées.
9 août 2007 à 13:26
Quelqu'un aurait une idée élégante pour détecter les "bornes" des droites trouvées? Sur l'image de l'exemple, assez logiquement, les segments de droite sont considérés comme des droites qui traversent toute l'image. Ce serait vrmnt classe d'arriver à détecter les limites des segments.
8 août 2007 à 10:04
Je tenais à remercier Pistol grace à qui j'ai reussi à trouver mes erreurs et donc à finir ma transformée de Hough en JAVA.
Je ne detecte pour le moment qu'une droite mais c'est déja un bon début.
Pour ceux que ca interesserais, ma source est ici. Il y a surment des optimisations à faire mais bon... On verras ca plus tard ;)
http://www.javafr.com/codes/TRANSFORMEE-HOUGH_43704.aspx
Bonne continuation à tous ;)
Zolotaya
8 août 2007 à 08:44
Voila Kirua, j'ai apporté les modifications que tu m'avais suggéré.
Tu pourras te forger ta propre opinion mais je ne trouve pas que se soit une meilleure méthode. Elle est beaucoup plus longue et la modification de la TH est légère. Mais il semble quand même que cette méthode permet d'avoir des maxima plus nette. Elles semble donc de meilleur qualité.
A+
7 août 2007 à 16:55
Donc toutes mes remarques restent valables.
Merci pour le lien, il a l'air très intéressant, je vais le potasser.
A+
7 août 2007 à 16:46
En gros j'ai mon image de départ (avec 1 droite pour le moment).
Je parcours cette image et des que je trouve un pixel, je trace toutes les droites possibles passant par ce point.
D'un coter je trace un graphique (qui me sert juste pour voir le rendu des sinusoïde) et de l'autre, pour chaque Rho et theta trouvé j'incrémente de 1 la case d'un tableau d'entier corrsespondant (accu[rho][theta]++). C'est ce tableau que je parcours autant de foie que je cherche de droites.
J'ai donc comme informations pour ma transformée inverse juste la distance (Rho) et theta (en degré).
Sinon voila un liens si ca t'interesse sur la TH que je trouve pas mal (un peu complexe pour moi)sur la détéction des maximas.
www.dmi.usherb.ca/~egli/ciro2005.pdf
Bon courage à toi
Zolotaya
7 août 2007 à 16:31
Ce n'est pas une méthode très économique en temps de calcul et en plus je ne pense pas que tu aies tous les points qui t'intéressent.
Je pense qu'un simple seuillage sur la TH peut déjà faire l'affaire.
Pour la transformée de Hough inverse, utilise la même méthode de débuguage. Met un unique point sue la TH et calcul la TH inverse. Tant que ça ne marche pas avec un point, ce n'est pas la peine de continuer.
La TH inverse, je l'ai codé dans ce programme mais tu devras sûrement l'adapter car je n'es pas pris la même origine que toi.
A+
7 août 2007 à 16:03
Merci pour tes conseils, j'ai pu ciblé mon prroblème.
Pour mes maximas, je parcours mon tableau une premiere foie à la recherche du maximum (la plus grande valeur). Pour les maximas suivant cherche le maxima strictement inférieur au dernier maxima trouvé. Je fait cela par rapport à un seuil fixé (10 droites par exemple, ca ca reste à faire).
Sinon apparament, d'aprés quelques essais simple (1 petite droite horizontale et 1 verticale), je me suis appercu que mon accumulateur étais bon (mon theta et mon Rho sont correcte).
Mon problème viens de ma transformée inverse! Elle est toute fausse!
Ca serait possible d'avoir un petit algo sur la transformée inverse?
Zolotaya.
7 août 2007 à 13:32
Pour mieux répondre à ton problème, j'aimerai avoir quelques infos supplémentaires.
Comment tu effectues la détection des maxima locaux car apparemment c'est cette fonction qui ne va pas?
Est ce que tu es sur que l'image d'accumulation dans le domaine de Hough est correcte: tu pourrais enregistrer cette image pour le vérifier.
Et un autre conseil, pour le débuggage, il est toujours plus facile de créer sa propre image la plus simple possible. Ici tu peux mettre uniquement 2 points avant de calculer la transformée de Hough. Tu auras alors 2 sinusoïdes et uniquement 1 maxima. La tu pourras aussi débuguer ta fonction trouver les maxima.
Voila, j'espère que comme commencement ça pourra d'aider.
A+
6 août 2007 à 16:28
Bon voila, j'essai depuis un moment (mais je n'y arrive pas) d'implémenter la transformée de Hough en JAVA.
Le truc est que je ne sais pas de ou viens mon problème. J'ai déjà chercher sur d'autres forum mais sans succés hélas.
Actuellement je prend une image, je la binarise et j'éfféctue une détéction des contours dessus. Jusque la tout vas bien!
voila mon image binarisée. http://imageshack.us
une foie que j'obtiens cette image, je la parcours et quand je trouve un pixel non noir, je calcul la sinusoïde.
(ca normalement ca marche!) voila le résultat :
http://imageshack.us
Le graphique est tracé avec JFreeChart, c'est donc pour moi juste un indicateur visuel!
Le problème survient quand je cherche les valeurs maximales dans mon accumulateur. J'obtiens ces valeurs la!
maxi 38 theta 85 rho = 74
maxi 43 theta 86 rho = 67
maxi 57 theta 87 rho = 59
maxi 65 theta 87 rho = 60
maxi est mon nombre de pixel par case, theta l'angle en degré et rho la distance. Sauf qu'il y a rien à moin de 120 pixels de l'origine (laissé en haut à gauche).
Voila un bout du code.
for (int x = 0 ; x < bi.getWidth() ; x++) {
for (int y = 0 ; y < bi.getHeight() ; y++){
// Si le pixel n'appartient pas au fond (n'est pas noir)
int rgb = bi.getRGB(x, y);
rgb = rgb & 0xFF;
if (rgb > 0){
// Series pour tracher le graphique
XYSeries series = new XYSeries("hough"+compt);
for (int angle = 0 ; angle < 360 ; angle ++){
double theta = Math.toRadians(angle);
double rho = x*Math.cos(theta) + y*Math.sin(theta);
int indexAngle = (int) (angle);
int indexRho = (int) Math.abs(rho);
accu[indexAngle][indexRho]++;
series.add(theta, rho);
}
dataset.addSeries(series);
// BufferdImage pour voir les pixels traités (tous)
dst.setRGB(x, y, rgb);
compt++;
}
}
}
Auriez vous une idée de ou peut venir ce problème? On m'a dit que la facon de faire étais bonne mais apparament ca suffit pas... A moin que je ne soit pas douer (ca c fort possible aussi).
Sinon j'avais trouvé un site qui traite le calcul des maximums dans l'accumulateur par l'approche de gaussiennes. Si ca vous interesse dite le moi j'essairai de le retrouver ;)
Cordialement,
Zolotaya
6 août 2007 à 08:40
J'avais réfléchi sur le fait de calculer une transformée de Hough sur une image en niveau de gris sans utiliser le filtre de Sobel mais j'avais vite arrêté car justement, je ne savais pas comment pondérer la TH.
La c'est une excellente idée, merci Kirua, je vais coder cela et je reposterais le résultat obtenu. Je vais aussi essayer d'optimiser le seuillage de la TH par la même occasion. Je ne suis pas satisfait du résultat obtenu lors de la TH inverse.
A+
4 août 2007 à 17:05
je suis en train de lire le document http://irevues.inist.fr/bitstream/2042/2334/3/02.PDF+TEXTE.pdf, et à la page 5 ils proposent un truc intéressant: plutôt que de décider d'un seuil pour le filtre sobel et d'appliquer la TH aux points conservés (réputés points de contour), une idée est d'appliquer une TH directement après le sobel (sans seuil), mais avec une pondération, ie: on dessine les sinusoides de hough plus ou moins "fort" selon que le gradient au niveau du point considéré était lui-même plus ou moins fort.
Tu as fait des essais dans ce sens? Je serais curieux de savoir ce que ça donne ^^.
31 juil. 2007 à 16:48
Dès septembre, j'aurai dans le cadre de mes études un cours sur les signaux et systèmes, ce qui devrait m'amener un pas plus loin dans les notions de FFT, filtres continus/discrets 1D/2D, cool cool ^^.
Je vais potasser ça, j'ai qq jours libres :).
C'est génial ton sujet de thèse, ça me botterait bcp de travailler dans ce genre de domaines. Tu as fait quoi comme études et où ça? Je fais des maths appliquées à l'UCL.
26 juil. 2007 à 19:08
Dans une partie, j'ai utilisé deux TH pour retrouver dans un espace 3D de points des câbles suspendus; une pour détecter les droites et une autres pour trouver des chaînettes (détail de l'algo ici: www.wipo.int/pctdb/en/wo.jsp?IA=WO2007010113&wo=2007010113&DISPLAY=DOCS ). Pour les droites le principal souci était de trouver les bons seuils et les bons pas de discrétisation. Cette partie n'étant pas la plus coûteuse en temps de calculs le plus dur était de détecter les chaînettes pour tendre vers du temps réel.
Je ne peux sur cette partie de ma thèse (à mon grand regret) que divulguer le principe général de l'algo qui a été protégé par mon entreprise dans le cadre d'un système puisque le brevet est publié (je suis contre les brevets qui protègent du code uniquement que ce soit dit! ^^) mais pas les sources.
Par contre comme je disais plus haut il faudra que je fasse passer sur le site mes algos de TH optimisées pour les droites et les ellipses faits avec glut et opengl. Mais avant il faut que je les commente bien mieux sinon il seront inexploitables! Je vais profiter de mes vacances dans quelques semaines pour m'y atteler, ça fera une meilleure base de discussion. En vrac, pour jeter les bases de l'optimisation, il faut avoir une idée de ce que l'on cherche; c'est à dire as t on une idée du nombre de droites potentielles à trouver ?(pour détecter les lignes d'un cours de tennis par exemple!) Si oui, on fait des heuristiques pour ne pas avoir à reparcourir tout le tableau des max, sinon il faut rentrer dans des algo de recherche de max.
A+
26 juil. 2007 à 08:42
Merci à toi pour tous les liens, surtout pour celui des filtres. Il est très complet et je ne connaissais pas tous les filtres présentés. Je regarderai un peu plus précisement.
Sinon c'était quoi le sujet de ta thèse? Ta reconnaissance de forme était exclusivement basé sur la TH?
Parce que j'aimairai bien voir tourner un vrai algo bien optimisé.
A+
24 juil. 2007 à 17:42
Ayant fait ma thèse en imagerie numérique sur la reconnaissance de forme et notamment sur transformée de Hough (TH), je ne resiste pas quand je vois des discussions sympa comme celles ci.
Tout d'abord, pour KIRUA qui souhaite un peu plus de mathématiques; je le renvoie à cette excellente référence : http://irevues.inist.fr/bitstream/2042/2334/3/02.PDF+TEXTE.pdf , qui résume et formalise assez bien les principe de base des différentes TH (1 à m et m à 1).
Sans rentrer dans tous les détails et avancées récentes, aujourd'hui les principaux problèmes tournent généralement autour du choix des maxima et des pas de discrétisation dans l'espace d'accumulation de Hough.
Pour le filtrage, si vous avez du temps(!), -c'est un sujet également passionnant- je vous recommande cette page : http://perso.enst.fr/~maitre/BETI/Filtrage.html qui synthétise assez bien quels filtres utiliser selon ce que l'on souhaite chercher.
Si vous avez des questions, n'hésitez pas!
Il faudra un de ces jours que je mette au propre les KM de code que j'ai fait sur ces sujets pour en faire profiter les autres sur ce forum où je ne fais que passer et regarder; faute de temps...
Je n'ai pas eu le temps de regarder le source dans le détail, mais j'y apporterai ma contribution! Promis!
Bonne soirée
23 juil. 2007 à 09:50
D'un point de vue esthétique c'est vraiment subjectif, donc tu as sûrement raison. Cependant, d'un point de vue du traitement de l'image, le filtre de Sobel est bien plus utilisé que celui de Prewitt. (90% des fois on utilisera Sobel). Le gradient obtenu est beaucoup plus facilement exploitable puisque la différence entre les niveaux de gris est bien plus marquée.
19 juil. 2007 à 18:20
19 juil. 2007 à 13:21
Dans le même genre je peux te proposer le filtre de Prewitt ou de Roberts. Il s'applique comme le filtre de sobel.
Un autre filtre sympa à tester c'est le filtre repoussage:
[-2,-1,0;-1,1,1;0,1,2]. Il donne des choses assez surprenantes.
Ya bien sure tous les filtres classiques: moyenne, médian, laplacien, pseudo filtre...
Le pseudo filtre est pas mal du tout, il crée un certain relief dans l'image.( [0,-1,0;-1,2,0;0,0,0] + 128 )
Photoshop propose plein d'autre filtres mais je ne sais pas trop comment ils sont construit. Si quelqu'un à de la doc sur ces filtre, je suis preneur.
Ammuse toi bien Kirua
19 juil. 2007 à 12:41
Je vais me renseigner sur la transformée de Hough. J'ai déjà lu un article descriptif sur wikipdia, mais il n'y a pas de développement mathématique.
Tu connais d'autres filtres ou traitements qui pourraient être amusants à tester? Ca m'intéresserait de trifatouiller avec tout ça :).
19 juil. 2007 à 08:24
Tu as tout juste, c'est exactement ce que je fais.
Je ne sais pas si cela existe de calculer une transformée de Hough sur une image en niveau de gris. Sans doute, mais il faudrait attribuer des poids différents pour chaque valeur de niveau de gris pour espérer trouver les droites de l'image.
En calculant le gradient en prétraitement, on met directement en valeur les contours de l'image ce qui facilite grandement la détection de droite et améliore la vitesse du traitement.
Ca fait des figures assez artistique la transformée direct de Hough?
19 juil. 2007 à 00:22
* tu appliques l'opérateur gradient (Sobel) à l'image
* tu binarise au moyen d'un seuil, pour isoler les contours
* pour chaque point "vrai" (blanc) de l'image, tu traces la sinusoïde de Hough associée dans une nouvelle image, en incrémentant la brillance des pixels
* tu utilises un seuil pour binairser l'image résultante, ce qui te donne quelques points blancs
* tu appliques l'inverse de la transformée de Hough à ces points-là, pour obtenir des droites dans l'image original
Correct?
Je sais que ça ressemble fort à la description que tu fais, mais le doute subsiste en moi au niveau de la transformée directe de Hough. J'aurais pas fait comme ça, mais ça a l'air fichtrement plus simple que de calculer des points de concurrence de millions de sinusoïdes e façon analytique ^^.