faire un OCR

**bigbill** · 30/12/2004, 14h22

bonjour

ça y est, j'ai non sans mal réussi à avoir qq résultats pour prélever des lignes ( je sais c peut être facile pour vous mais bon, moi.... ).
Mais là, je vois un autre pb :
en règle générale, mon truc devrait marcher, mais ça doit marcher pour tous les cas, mm les cas plus chiants.
Par exemple, j'ai essayé de prélever une ligne ne contenant que des i , ou que des é , bref, les lettres qui se décomposent en deux parties. Et évidemment, mon algo les séparent : la ligne de i est séparée en une ligne de points, et une ligne de barres. C pas tout à fait ce que je veux .....

J'ai essayé de faire des rapports de hauteurs, mais là encore, si il résout ce pb, il en rajoute un autre.
Est-ce-qu'il une régle spécifique pour la hauteurs des lettres ?
ou alors vous avez peut être une autre solution ?

**Mac LAK** · 30/12/2004, 14h58

Envoyé par bigbill

Est-ce-qu'il une régle spécifique pour la hauteurs des lettres ?

Pas à ma connaissance.

Envoyé par bigbill

ou alors vous avez peut être une autre solution ?

Plutôt que d'isoler les lignes de lettres, qui peuvent être variables en hauteur comme tu t'en es rendu compte, pourquoi ne pas plutôt chercher la hauteur des interlignes, qui sont constantes, elles ? Ca me paraît être une piste intéressante à suivre...

**bigbill** · 30/12/2004, 17h03

pourquoi ne pas plutôt chercher la hauteur des interlignes, qui sont constantes, elles ?

ben je sais pas, par exemple, l'interligne n'est pas égal entre 2 lignes de hauteur maximale ( par exemple, une ligne contenant un f et un p minuscule ) et 2 lignes de hauteur minimale ( une ligne ne contenant que des a, e , i.....)

**ALEX77** · 30/12/2004, 17h14

Bigbill, Tu développes ton OCR avec quel langage déjà ?

**bigbill** · 30/12/2004, 17h50

en C, pkoi ?

**Mac LAK** · 30/12/2004, 17h54

Envoyé par bigbill

ben je sais pas, par exemple, l'interligne n'est pas égal entre 2 lignes de hauteur maximale ( par exemple, une ligne contenant un f et un p minuscule ) et 2 lignes de hauteur minimale ( une ligne ne contenant que des a, e , i.....)

Si, elle est égale, c'est juste que tu n'as pas bien saisi ce qu'est l'interligne... C'est l'espacement entre les deux lignes "basses" de deux lignes consécutives, c'est à dire la ligne "virtuelle" sur laquelle sont "posées" les lettres.
Sur une lettre matricielle, ça donne ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
........................
..####....####..........
.##..##..##..##.........
.##..##..##.............
.######..##.......####..
.##..##..##.......#...#.
.##..##..##..##...#...#.
.##..##...####....#####.   <-- C'est cette ligne qui est la "base" de mesure.
..................#.....
.................###....
..####....####..........
.##..##..##..##.........
.##..##..##.............
.######..##.......####..
.##..##..##.......#...#.
.##..##..##..##...#...#.
.##..##...####....#####.   <-- Donc, ici, l'interligne est de 9 pixels.
..................#.....
.................###....

En pratique, il "suffit" d'éliminer les "pics" de pixels sur la partie inférieure de tes blocs de pixels, pour en déduire la ligne de référence. Tu dois pouvoir t'en sortir en repérant la ligne la plus basse et possédant le plus de pixels noirs.
Si tu fais la même chose pour toutes les lignes, tu vas pouvoir calculer l'interligne moyenne de la page. Tu vas surtout pouvoir calculer les extréma de valeur de l'interligne : par exemple, si une majuscule est située sous une lettre longue comme "f" ou "p", tu vas avoir une valeur proche du minima. Par contre, si tu as un point, une virgule ou autre caractère "bas" sous un caractère comme "°" ou "²", ou des guillemets, tu auras une valeur proche du maximum.

Après, tu vas donc avoir tes multiples blocs (un "i" étant constitué de deux blocs, comme un "é"). Si deux blocs sont séparés par moins de pixels en hauteur que la valeur moyenne de l'interligne (ou valeur minimale, suivant le raffinement du calcul de ce minimum), c'est qu'ils font partie du même caractère.

Tu vois mieux ce que je veux dire ?

**ALEX77** · 30/12/2004, 18h00

Pour BigBill :

en C, pkoi ?

Parce que si tu m'avais dit Delphi j'aurais peut être pu te filer un coup de main mais le C... j'y comprends que dalle

Toujours est-il que tu sera plus avantagé par rapport aux sites que je t'ai passé qui utilise le langage C pour les projets OCR qu'ils proposent. Car pour moi, j'ai eu du mal à comprendre la transcription C <--> Delphi.

**bigbill** · 30/12/2004, 18h16

aaaaa ok,
très interessant, enfin je veux dire que j'aurai pas du tout pensé à ça.
N'empêche, Mac LAK, t'as du te casser le cul à faire le schéma, mais au moins j'ai mieux compris avec ça.

Bon, je retourne bosser ça.
Merci.

**Mac LAK** · 30/12/2004, 20h22

Envoyé par bigbill

N'empêche, Mac LAK, t'as du te casser le cul à faire le schéma, mais au moins j'ai mieux compris avec ça.

Même pas : vive UltraEdit et le fait d'avoir pas mal travaillé avec les fontes bitmap...

Enfin, si tu as compris, ça me paie de l'effort ! ;-)

**maamar** · 31/12/2004, 22h44

voila un lien pour une thèse tres interressante
"Experiments in Image Segmentation for Automatic US License Plate Recognition"

http://scholar.lib.vt.edu/theses/available/etd-07022004-132444/

**Mac LAK** · 01/01/2005, 04h18

Envoyé par maamar

voila un lien pour une thèse tres interressante
"Experiments in Image Segmentation for Automatic US License Plate Recognition"

http://scholar.lib.vt.edu/theses/available/etd-07022004-132444/

Effectivement, cette thèse est très intéressante...
J'apprécie beaucoup moins son application (

de radars automatiques !!!!), mais ça n'enlève rien à l'intérêt du document.

**ALEX77** · 01/01/2005, 12h06

Peut être trouverez vous votre bonheur dans ces documents (en espagnol) qui expliquent le fonctionnement d'un système OCR :

http://www.cvc.uab.es/shared/teach/master/ocr1.pdf
http://www.cvc.uab.es/shared/teach/master/ocr2.pdf

Si quelqu'un arrive à faire une application en se basant là dessus, qu'il me contacte ! Apparement j'ai pas trouvé plus complet comme documentation, il ya des shémas des illustrations... bref avec ça, les OCR ne devraient plus avoir de secret pour les non initiés. Même si on ne trouve pas de code source, les théories y sont expliquées.

En espérant que ça vous sera utile.

**bigbill** · 01/01/2005, 20h35

oui c'est très complet ....mais c en espagnol et c cho de comprendre ce qu'ils essaient de faire passer,
déjà que le truc en anglais, j'ai pas compris gd chose.....

**bigbill** · 01/01/2005, 23h36

mac lac j'ai un très très gros pb ....

j'ai essayé de faire ta méthode en calculant la ligne de "base" sur laquelle sont posées les lettres, mais j'ai bo y passer toute la journée, mon prog m'envoie chier à chq fois!!
je suppose que tu sais lire le C :
j'essaie de faire une fonction renvoyant la base d'une ligne, connaissant la limite haute [b}]y_haut[/b] d'une ligne, et sa limite basse y_bas( en pixel)

int calc_base(SDL_Surface *image, int y_haut, int y_bas)
{
int i;
int max = y_haut;

for (i = y_haut; i < y_bas; i++)
{
if (ligne_nbnoir(image,max) <= (2*ligne_nbnoir(image,i+1)))
max = i + 1;
}
return (max);
}

vala la fonction ligne_nbnoir(image, y) calcule le nbr de pixels sur l'image de la y-ième ligne.

par contre pour la condition if( ligne_nb.......) si j'ai multiplié par deux ligne_nbnoir(image,i+1), c juste pour privilégier les lignes basses. C une meth très bête je sais, et ne me demandez pas pkoi j'ai pris cette solution plutot qu'une autre, je sais pas.

En fait, j'essaie de garder l'index de la ligne possédant le plus de pixel. Mais à chaque fois, ce que la fonction me retourne, c ( y_bas - 1), ça commence à me faire légèrement chier....

tu peux me guider un petit peu

? c urgent !
et pour les autres, si vous avez une idée, ou que vous voyez une erreur ds mon code ( yen a forcément une

...) , n'hésitez pas

**Mac LAK** · 02/01/2005, 02h57

[NOTE : Pense aux balises CODE /CODE stp]

Envoyé par bigbill

mac lac j'ai un très très gros pb ....

Au vu de ta fonction, c'est normal, je pense. Et c'est Lak avec un "K".

Je vais utiliser des termes mathématiques pour décrire ce qu'il faut chercher :
- Pour chaque ligne de bas en haut, sur un nombre de lignes variable (disons 40 à 60% de la hauteur générale du bloc au maximum), il faut calculer le nombre de pixels "allumés" de la ligne, mémoriser ce résultat.

Exemple : Sur un bloc initial de 100 pixels de haut (0..99), tu vas calculer ça sur les lignes numérotées de 80 à 99 inclus, et ranger ce décompte de pixels dans un vecteur [0..19]

- Ensuite, le but est de chercher soit une variation brutale du nombre de pixels, soit un maximum local.

Sur l'exemple précédent, on obtient ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 1 ........................  =>  0
 2 ..####....####..........  =>  8
 3 .##..##..##..##.........  =>  8
 4 .##..##..##.............  =>  6
 5 .######..##.......####..  => 12
 6 .##..##..##.......#...#.  =>  8
 7 .##..##..##..##...#...#.  => 10
 8 .##..##...####....#####.  => 13
 9 ..................#.....  =>  1
10 .................###....  =>  3

La première colonne est l'indice de ligne, ensuite la ligne, la dernière est le nombre de pixels par ligne.
Reporté en graphique, le nombre de pixels par ligne donne ça :

Là, tu peux te rendre compte que tu as une courbe assez haute pour les lignes 2 à 8 incluses, puis une chute brutale pour la ligne 9.
Dans ton cas précis, une fois ces données calculées (appelons PC[i] le nombre de pixels de la ligne "i"), il faut calculer les variations, c'est à dire pour chaque ligne i, la différence (PC[i]-PC[i+1]). On obtient un nouveau tableau VPC[], contenant ces variations. Bien sûr, il n'y a pas de variation pour la dernière ligne.
Toujours dans l'exemple ci-dessus, on obtient : VPC = { -8, 0, -2, +6, -4, +2, +3, -12, +2 }
On cherche le "-12", et on peut l'identifier par le fait que non seulement cette valeur est plus élevée que la précédente, mais aussi plus élevée que la suivante, c'est un "pic" négatif. Il suffit de chercher la plus grande variation (en valeur absolue) négative, et tu verras que sur ce tableau, c'est -12. Mais pour que ce soit "juste", il faut rester sur les lignes basses de ton bloc, sinon tu risques des fausses détections.

- Une fois cette ligne de référence trouvée, tu vas pouvoir, pour toutes les lignes de texte de la page, trouver la ligne de base correspondante. Il te suffit, ensuite, de faire une moyenne des différences de hauteur pour trouver la valeur moyenne de l'interligne (penser à éliminer les valeurs aberrantes, par exemple au moyen d'une régression linéaire).

Envoyé par bigbill

if (ligne_nbnoir(image,max) <= (2*ligne_nbnoir(image,i+1)))

Je n'ai pas compris cette ligne : tu cherches un maximum "simple", le facteur 2 n'a rien à foutre là !!
De plus, à chaque fois tu prends un "i+1" dans tes indices, j'avoue que je ne comprends pas à quoi il sert (mis à part ralentir le code et ne pas traiter la ligne "y_haut"), et produire un effet de bord en dépassant la limite basse "y_bas". Bref, pas bon.

Je te le répète : il ne faut pas analyser tout le bloc, mais seulement la partie basse, sinon le début des lettres ou les majuscules/minuscules vont perturber le calcul !

Je pense que ce type de calcul que tu as choisi est trop simpliste pour être efficace, mais bon, c'est à tester quand même : on a parfois de bonnes surprises, surtout si tu calcule ensuite l'interligne par une régression linéaire.
Cependant, j'aurais plutôt écrit un truc comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
int calc_base(SDL_Surface *image, int y_haut, int y_bas) { 
  int i, mc, mt ;
  int max = y_bas;
 
  mc=ligne_nbnoir(image,max) ;
  for (i=y_bas; i<y_haut; i--) { 
    mt=ligne_nbnoir(image,i) ;
    if (mt>mc) {
      max=i ; 
      mc=mt ;
    }
  } 
  return max ; 
}

Le parcours se fait de bas en haut, avec optimisation des appels à "ligne_nbnoir".

Envoyé par bigbill

En fait, j'essaie de garder l'index de la ligne possédant le plus de pixel. Mais à chaque fois, ce que la fonction me retourne, c ( y_bas - 1), ça commence à me faire légèrement chier....

Comme tu as dû t'en rendre compte sur mes explications ci-dessus, c'est un tout petit peu plus complexe, mais ce n'est pas terrible non plus.
J'ai beaucoup détaillé l'algo, mais on peut méchamment l'optimiser et tout faire en une seule passe. J'ai préféré m'attarder sur le principe pour que tu comprennes ce que j'avais en tête.

C'est un peu plus clair pour toi ?

**bigbill** · 02/01/2005, 11h04

scuse Mac LaK...
bon je viens juste de lire ton message, et je peux pas te dire si j'ai tout pigé du premier coup, mais ya déjà un truc bizarre :

pour ton calcul de différence PC[i] - PC[i+1] , ton tablo VPC, ce serait pas plutôt :

{-8, 0, 2, -6, 4, -2, -3, 12, -2} ?

puisqu'on cherche la valeur absolue max, ça revient au mm, mais c'est juste histoire de savoir si j'ai carrément pas pigé le truc, ou si c toi qui a fait des erreurs de calcul....

**ALEX77** · 02/01/2005, 11h07

Encore un lien utile pour toi Bigbill :

http://www.loria.fr/~abelaid/Enseign...cours8-ocr.pdf

**bigbill** · 02/01/2005, 12h16

uéééééé, cool !!! ( parce qu'il est un français )

merci, ça va peut être m'inspirer un peu plus

**ALEX77** · 02/01/2005, 12h50

Ceci dit, même les docs en espagnol (pour le peu que l'on essaye de traduire) sont déjà de bonne qualité. Le seul inconvénient majeur c'est de comprendre la jargon mathématique et les formules compliquées et bien évdement de les adapter en algorithme... mais grâce aux shémas et aux illustrations, on s'aperçoit qu'il existe d'autres méthodes auxquelles on aurait pas pensé...

BigBill si ton problème est de trouver les caractères alors ceci devrait plus que jamais t'intéresser :

Pour séparer les caractères, il faut d'abord séparer les lignes. Dans l'hypothèse où l'on connait déjà le bloc d'image à analyser. On prend donc une zone de l'image de coordonnées TRect que l'on va "balayer".

Voici comment faire à ma façon :

-balayer de haut en bas l'image en fixant un seuil de pixels (1 ou 2) qui corresponds aux "pattes" des lettres, pixels, parasites. Chaque ligne complètement blanche ou qui a au maximum 1 ou 2 pixels est considérée comme vide. Dès que l'on trouve une ligne "non vide", retenir dans une variable Y1 le premier point Y (là où commence la première ligne non vide). On peut maintenant continuer jusqu'à rencontrer une ligne vide et on retiendra Y2 la ligne de pixels juste d'avant : ce qui donnera un rectangle (0,Y1,[largeur de l'image],Y2)

Pour trouver les caractères, c'est à peu près la même chose sauf qu'il faut procéder verticalement, de gauche à droite, on retient d'abord X1 puis X2. On peut donc en déduire grâce aux coordonées de la ligne, les rectangles correspondants à chaque caractère.

Il faut aussi pouvoir rogner les zones blanches autour du caractère afin de ne garder que le caractère aux bords du rectangle. Utiliser le même procéder en balayant horizontalement, de haut en bas puis de bas en haut, verticalement, de gauche à droite et de droite à gauche.

Au final, on peut ensuite comparer le caractère dans une matrice et afficher le résultat. Mais là encore, il y a du boulot

Seuil de tolérance, espaces minimum entre caractère considérés comme espaces, ratio de L/H, etc...

Pour résumer, les étapes les plus cruciales : Segmentation des caractères et méthode de reconnaissance.

**Mac LAK** · 02/01/2005, 19h22

Envoyé par bigbill

pour ton calcul de différence PC[i] - PC[i+1] , ton tablo VPC, ce serait pas plutôt :

Oui, je me suis trompationné... ;-) [Mauvaise Foi] C'était pour voir si tu suivais, voyons !! [/Mauvaise Foi]

Par contre, le sens de variation a son importance, c'est pour ça qu'il ne faut pas prendre la valeur absolue de la différence, mais bien la différence "normale", avec signe.

faire un OCR

Traitement d'images

Discussions similaires

Partager

Partager