Bonjour a tous  ,
 
Je suis en stage a l etranger et mon professeur m a demandé de programmer la transformée de Hough en C bien qu il sache que je suis debutante. Ce programme a pour but de detecter les lignes blanches de la route dans une image.( c est un programme que j utilise apres avoir filtré l image par le filtre de Sobel)
Je ne sais pas ce qui ne va pas dans mon programme, il compile mais il ne detecte pas bien les lignes, je ne sais plus quoi faire...! cela doit etre dans l'algorithme, mais je ne trouve plus rien a changer...
 
Voila mon programme:
Je vous en supplie aidez moi s'il vous plait!!!!
 

extern "C" 
{ 
#include <pgm.h> 
} 
#include <stdio.h> 
 
#include <math.h> 
 
#include <pam.h> 
 
 
 
main(int argc, char *argv[]) 
{ 
 
 
 
  int x, y; 
  int dx,dy; 
  int G; 
  FILE *infile, *outfile; 
  int cols, lignes, format,thetadeg,rr; 
  gray maxval; 
  gray **table1, **table2, ;//two * to have a 2 dimension table **accumulateur 
  int k,e,d,max,p,q,retient,bidul,s,lala,a,b,acc,rint,tint,yint,A,B,rint2,lala2; 
  int m=0; 
  int j=0; 
  int i=0; 
  double rmax,r,theta,c; 
  double co,pi,thetaRad; 
  const int m_FacteurEtalement = 20000; 
 
 
 
 
 
 
 
  int **accumulateur2= new int*[m_FacteurEtalement]; 
  for(lala=0;lala<m_FacteurEtalement;lala++) { 
    accumulateur2[lala] = new int[m_FacteurEtalement]; 
 
  } 
 
 
  if (argc!=3) { 
    printf("Mauvais Nombres Arguments\n" ); 
    return 0 ; 
  } 
 
 
  // Reading of the file 
  pgm_init(&argc, argv); 
  infile = pm_openr(argv[1]); 
  pgm_readpgminit( infile, &cols, &lignes, &maxval, &format );//reading of the file called infile 
  table1 = new gray*[lignes];// reservation of an espace of the memory. the espace size is "rows"/ 
  table2 = new gray*[lignes]; 
 
 
  for (y = 0; y <lignes; y++) {//for each ligne y 
    table1[y] = pgm_allocrow (cols);// reservation of a memory space with the size of one column 
    table2[y] = pgm_allocrow (cols); 
 
    pgm_readpgmrow( infile, table1[y], cols, maxval, format);//read but also filed the new created space (grayrow) with the original image(whiwh is in the file infile) 
  } 
 
 
  rmax=floor( sqrt(lignes^2+cols^2)+1); 
 
 
 
  //INITIALISATION IMAGE2 
 
  for(y = 0; y < lignes; y++) 
    { 
      for(x = 0; x < cols; x++){ 
 
        table2[y][x]=0; 
      } 
    } 
 
 
  //INITIALISATION ACCUMULATEUR 
 
  for(y = 0; y < m_FacteurEtalement; y++) 
    { 
      for(x = 0; x < m_FacteurEtalement; x++) 
        { 
          accumulateur2[y][x]=0; 
        } 
    } 
 
 
 
 
 
 
 
 
 
  //INCREMENTATION ACCUMULATEUR 
 
  for(x = 0; x < lignes; x++) 
    { 
 
      for(y = 0; y < cols; y++)//parcours de l'image1 
 
        { 
 
          if (table1[x][y]>60 )//si le pixel est blanc 
 
            { 
 
              for (thetadeg = 0; thetadeg <360; thetadeg++) 
 
                { 
                  thetaRad=6.28*thetadeg/360;//conversion en radian 
                  r=x*cos(thetaRad)+y*sin(thetaRad) ; // tracage des "lignes" dans l accumulateur 
                  rint = static_cast<int>(r); // j en fait un entier car je devrais l'utiliser comme indice de tableau 
                  rint2=-rint; 
 
                  if (-rint<m_FacteurEtalement && rint<0 ) 
                    { 
 
                      accumulateur2[rint2][thetadeg]++; 
 
                    } 
                } 
            } 
        } 
    } 
 
 
 
 
 
 
  //TRACAGE DE LIGNES DANS LA NOUVELLE IMAGE 
 
 
  for(rr = 0; rr < m_FacteurEtalement; rr++) //parcours de l accumulateur -------------> nombre pê a changer 
    { 
      for(thetadeg = 0; thetadeg < 360; thetadeg++) 
        { 
 
          if (accumulateur2[rr][thetadeg]>59) // --------------pê a changer 
 
            { 
              for(x = 0; x< lignes; x++) //parcours de l image2 
                { 
                  thetaRad=6.28*thetadeg/360; 
                  A=static_cast<int>((cos(thetaRad))/sin(thetaRad)); 
                  B=static_cast<int>(-rr/sin(thetaRad)); 
 
                  if (-A*x+B<cols && -A*x+B>0 && A!=0){ 
                    table2[x][-A*x+B]=255; 
                  } 
 
                } 
 
            } 
        } 
 
    } 
 
 
 
 
 
 
  // Saving 
  outfile = pm_openw(argv[2]); 
  pgm_writepgminit( outfile, cols, lignes, maxval, 0 ); 
  for (y = 0; y<lignes; y++){ 
    pgm_writepgmrow(outfile, table2[y],cols, maxval, 0); 
  } 
 
 
 
 
  //release of space 
 
  for (y=0; y<lignes;y++){ 
    pgm_freerow( table1[y] ); 
    pgm_freerow( table2[y] ); 
 
  } 
  free(table1); 
  free(table2); 
 
  pm_close( outfile ); 
  pm_close( infile ); 
 
 
 
 
  for(lala=0;lala<rmax;lala++){ 
    delete accumulateur2[lala]; 
  } 
  delete [] accumulateur2; 
 
 
 
 
}

 
 
Merci de m'avoir lue
PS: je compile comme ca:  
g++ main.cpp -o prob -L"C:\Program Files\GnuWin32\lib" -I"C:\Program Files\GnuWin32\include" -lnetpbm
 
[Note de la modération: reformaté et mis dans la bonne catégorie C++, vu les delete [] finaux]

Je ne suis pas familier de l'implémentation de ces algorithmes de transformation mathématique, mais sans commentaires ton code est à peu près imbitable pour moi et je doute qu'un autre (à moins d'être un champion de ce genre d'algo) ne soit plus à l'aise et plus enclin à y consacrer du temps pour comprendre ton implémentation.

Si l'implémentation est ok, le problème vient peut être de ton image d'entrée ou de tes constantes dans le code ?
Je pense que Hough doit être un algo assez sensible, à manier avec du recul, pas comme un gros Sobel des familles pour les contours.

On doit pouvoir trouver des dizaines d'exemples d'implémentations sur google, avec des images tests.
Je peux te montrer une implémentation qui fonctionne, en espérant que ça puisse t'apporter une aide quelconque.
Tu en as une abondamment commentée et qui fonctionne plutôt bien dans le projet AForge. C'est du .Net mais les types utilisés sont essentiellement des types primitifs et les fonctions sont les opérations mathématiques de base, il y a juste un petit peu d'orienté objet mais rien d'impossible à faire autrement en C. Le seul truc particulier c'est l'utilisation des types Bitmap en fin de calcul pour produire la sortie.
Le code source :
http://code.google.com/p/aforge/so [...] rmation.cs
Une petite doc : http://www.aforgenet.com/framework [...] c75d9c.htm
Ceci dit comme tu as déjà tenté une première approche et que la leur en est loin je ne sais pas si ça t'aidera. A voir ton code et tes commentaires en franglais je me doute que c'est déjà une repompe de quelque chose...

pas mieux

par contre quand on travaille sur des images, on utilise généralement des tableau à une dimension, ce qui est beaucoup, beaucoup plus facile à utiliser et à manipuler (ça t'évite les doubles pointeurs,etc). Je te conseillerais de faire cela et de recréer ton algo from scratch.

la correspondance est :

image[y][x] = tab[x + SX*y], où SX est la taille en X de ton image. Tu peux créer une macro par exemple pour acceder à tes images :

quand tu alloues un tableau pour une image, c'est:

2/ il faut aussi que tu vérifies comment fonctionne ton algo sur les bords de ton image .... c'est une source d'erreur fréquente, car une image est un ouvert de R2. Après, je sais pas si c'est ça le problème mais les "problèmes de bords" peuvent se propager sur l'image et donner n'importe nawak.

3/ vérifie les problèmes de cast. A mon avis l'erreur est là. Exemple : tu déclare un

et tu affectes la valeur de retour de floor(); qui renvoie un flottant ou un double.

good luck

sauf que non. Les allocations façon NRC sont bien plus simples que ces calculs d'index, cf les MOULTS topics que j'ai fait sur le sujet.
le coup du tab[i+h*j] est vraiment bof et est source d'erreurs.

yo,

c'est quoi les allocations façons NRC ? En tous cas tous le monde autour de moi utilisait des tableaux 1D, j'ai jamais vu personne utiliser des tableaux 2D en fait, mais bon c dans la recherche donc bon.

Au risque de dire une connerie je suis quasi sûr qu'il parle de ceci : http://www.nrbook.com/a/bookcpdf.php (par exemple, y a plein d'autres liens, cf Numerical Recipes in C)
C'est un ensemble d'astuce et de best practices pour tout ce qui touche aux maths. Très instructif d'ailleurs pour quiconque travaille avec ça par contre faut un solide bagage mathématique et beaucoup de café pour suivre parfois...

Et en l'occurrence pour les tableaux 2D je pense qu'il parle du principe de tiling qui consiste à ne pas parcourir tout le tableau mais à découper celui-ci en zones carrées parcourues séquentiellement, ce qui va plus vite qu'un parcours intégral. Mais là je ne suis pas sûr du tout qu'il parle de ça .
Fais une recherche sur son pseudo tu devrais trouver de quoi il s'agit (à moins que tu ne préfères lire le bouquin )

Si ça peut aider : http://www.google.fr/search?q=joel [...] =firefox-a

 
je doute pas de l'interêt de l'allocation NRC pour de l'optim de brutor pour des tableaux de dimensions N>2
 
pour un stage, pour coder la transformée de ouf je pense pas que ce soit nécessaire    
 
perso, je trouve que les tableaux 1D c'est vachement plus facile à utiliser (un seul free, pas de doubles pointeurs, etc). Mais bon après c'est comme gVim vs Emacs, il y aura toujours débat!
 

Je pense qu'il parle du fait d'allouer ton tableau 1D à l'ancienne et d'ajouter en plus un tableau de pointeurs vers les débuts de chaque ligne, un peu comme ça :  
 

 
Tu gardes un tableau 1D pour les masoc... gens qui aiment bien. Et tu peux accéder simplement à la case (i,j) en faisant
 

 
Tout ce que tu perds, c'est l'allocation de (hauteur)*size_t, c'est pas très grave avec des grosses images.

 
je dis pas le contraire, juste que filer des bonnes habitudes au gens, c'est pas plus mal
Je peut te dire que quadn tu devras faire des trucs genre deroulage de tableau 3D + blocking + strip-mining tu seras bien content 'avoir un acces en i,j,k qu'un polynome infmae

Question : j'ai vu dans wikipedia que la transfo de Hough était brevetée. Ca veut pas dire que quand on veut l'utiliser dans un programme il faut verser des sous au détenteur du brevet?

C'est possible (j'en sais absolument rien en fait ) mais ça m'etonne un peu... En imagerie c'est assez fréquemment utilisé, il y en a des implémentations libres un peu partout et des variantes (comme celle qui étend l'algo d'origine aux autres formes géométriques)... Je pense que c'est plus une histoire de protection intellectuelle de la paternité du truc qu'une histoire de sous.

le brevet date de 1962 et un brevet, même le plus velu possible ne peut pas durer plus de 20 ans, pour que la propriété intellectuelle ne joue pas un rôle de ralentisseur de l'utilisation des avancées technologiques (en informatique, ça peut faire rire 20 ans, mais le concept de brevet est plus ancien et cette limite peut trouver son sens).  

Une petite remarque en passant: plutôt que thetaRad=6.28*thetadeg/360 écris thetaRad=(6.28*thetadeg)/360 c'est plus lisible, et tu est sure qu'il va pas y avoir d'abord une division entière thetadeg/360 (ce n'est peut être pas le cas ici, mais je n'ai jamais eu envie de m'encombrer l'esprit avec les tables d'ordre de précédence quand un parenthèsage bien fait permet de ne pas se poser la question).

Au lieu de faire plusieurs fois

for (thetadeg = 0; thetadeg <360; thetadeg++)
    {
        thetaRad=6.28*thetadeg/360;//conversion en radian
        .....
    }
peut être qu'utiliser un tableau a 360 entrées avec la valeur en radian calculé une fois pour toutes serait plus simple.
D'autre part, la pratique habituelle est de faire: thetaRad = (thetadeg * M_PI) / 180 ou on utilise la constante M_PI définie dans <math.h>

Autre point:
A=static_cast<int>((cos(thetaRad))/sin(thetaRad));
B=static_cast<int>(-rr/sin(thetaRad));
A et B sont calculés au niveau de la 3e boucle interne, mais ils sont invariants et calculables au niveau de la 2eme.

A+,