faire un OCR

[bigbill]

hello

je dois faire un OCR. Donc en partant d'une image, je dois pouvoir en extraire un texte.
Pour cela, je dois donc analyser l'image.
Et la ? Je pense que pour m'y prendre,je dois faire une matrice de points, non ? cad analyser pixel par pixel si un pixel est noir ou pas, et renvoyer le résultat dans cette matrice. Ensuite essayer de reconnaître cette lettre mais c'est autre chose.

Est-ce que pour cette première partie c à peu près ça ? Dites moi si je me trompe....

[Le Furet]

C'est une façon de faire. Ca marchera bien si ton texte est (par exemple) blanc et si tu es sûr que le reste de l'image n'est pas blanc.

Sinon, tu auras des pixels parasite.

Il y a plus efficace mais plus compliqué. Par exemple, tu peux découper ton image en blocs 8*8 ou 16*16, appliquer une DCT (Discrete Cosine Transform : Tranformée en Cosinus Discret, celle utilisé pour la compression JPEG), et regarder les blocs gardant de hautes valeurs pour les coefficients correspondant aux contours verticaux et horizontaux.

Il y a aussi un filtre chargé de détecter contours horizontaux et verticaux, je crois que c'est le filtre de Hough maisje peux dire une connerie, je me réveille juste.

Dans tous les cas, pour lapartie extraction ou la partie OCR, citeseer est ton ami

[Catbull]

Il me semble que les algos de reconnaissance de texte se base sur la logique flou...

[bigbill]

les algos se basant sur la logique floue ?
oula, c flou ça......

quant à l'autre solution donnée par le Furet (....), ça me semble bien cho....
je crois que je vais rester sur mon idée

alors comme ça, oui, les pixels parasites à virer, je note....
et après j'essaie de différencier les pixels noirs des pixels blancs, puis je découpe d'abord horizontalement (pour les lignes) puis verticalement (pour les lettres) en tenant compte que certaines peuvent être plus grandes ou plus grosses.
Pour le principe, c tjs bon ? enfin, c une façon de faire ?

[rbag]

Pour ce que j'en sais des algos d'ocr, il me semble qu'il faut d'abord nettoyer l'image, supprimer les zones de non texte (images) et extraire les contours des lettres pour faciliter le travail de reconnaissance. Il faut ensuite séparer lettres par lettres le texte puis les analyser une par une dans un réseau de neurones pour rapprocher au plus du modèle d'apprentissage.

Par contre pour séparer les lignes et chaque caractère, il faut prendre en compte que le texte n'est pas toujours scanné très droit et éventuellement corriger cela avant le traitement. Des méthodes pour améliorer la reconnaissance se basent sur des dictionnaires: une fois que le mot est reconnu, on cherche une correspondance dans un dictionnaire et si l'on ne le trouve pas, on repasse sélectivement les lettres suspectes dans l'analyseur pour tomber sur un mot qui existe.

[Le Furet]

Dans tous les cas, l'OCR, le vrai, c'est un problème mathématiquement pas évident du tout. Déjà, quelle est ta source (scan ? Image numérique), ton type d'écriture (manuelle, sujette à la déformation (cause scan) ou image faite par ordinateurs avec lettres propres et variant peu) ?

Tu espères quelle efficacité ?

Si tu veux un truc basique et qui doit déjà être assez rigolo à programmer, regarde les sources de Subrip, un programme qui sert à récupérer les sous-titres des DVDs.

[Catbull]

J'ai déjà travaillé sur un logiciel de reconnaissance de forme. Le principe de reconnaissance était le suivant :
- Identifier des critères de discrimination pour chaque forme à distinguer

Ces critères peuvent être la circonférence de objet (ou périmètre), la surface, le diametre (ou la diagonale), la rotondité, le nombre de branches, le nombre d'élément, etc...

Si tu ne devais identifier que 2 lettres i et o par exemple un seul critère suffit : la rotondité par exemple. Pour 26 lettres (+tous les autres caractères) et 50 polices de caratèress différentes il te faudra une combinaison de critère (pas évident à définir).

--> C'est de la logique floue : une lettre est plus ou moins un a, un b un c etc... par ce que cette lettre sera plus ou moins ronde, allongée, convexe, concave, conique, triangulaire etc...

Comme le dit rbag, il faut faire un pré-traitement sur l'image afin de l'épurer de retracer les contours, cloturer (éventuellement l'image), boucher les trous etc...

PS : La matrice de point dont tu parlais permet de calculer le périmètre, la rondeur etc des lettres. La logique floue n'intervient que dans ce que tu appelles une autre chose...

[bigbill]

ah oui, mais ça, c autre chose .......

Pour répondre déjà au Furet, la source, c un scan. D'abord je vais essayer plus simple, avec des images faites par ordi et plus tard, si ça marche bien, alors j'enchaînerai avec les lettres manuscrites, qui je le suppose doit être bien chiant à faire....

mais il faut définir tout seul les critères de reconnaissance ? je croyais que ça fonctionnait avec un réseau de neurones. A savoir, faire passer à la machine un bon nombre de fois la lettre a, b, c ..... pour toutes les polices. Et après, faire passer la matrice de points ( donnée par l'analyse de l'image ), et la comparer avec ce que la machine a mémorisé et le comparer. Je pensais justement que l'avantage du réseau de neurones était qu'il apprenait tout tout seul....

[Mac LAK]

[Hypothèse : OCR d'un texte dactylographié, scanné assez proprement]

Par rapport aux conditions initiales, la première chose à faire est effectivement de nettoyer l'image, et de la "mettre droite".
Pour ça, tu peux utiliser la pente moyenne de la première ligne, par exemple, ou les marges verticales si ton texte est assez bien justifié.

Pour le nettoyage, un seuillage pour commencer, suivi soit d'une segmentation, soit d'une suppression des pixels isolés.

Après tout ça, tu as un texte propre. Tu peux alors chercher les différentes lettres, ou pour être plus précis, pour chaque lettre de l'image, une zone rectangulaire englobant la lettre. Tu peux "extraire" ce rectangle de l'image d'origine, et ensuite appliquer l'algo de reconnaissance de ton choix.

1) Méthode primaire (voire primitive) : comparer, après mise à l'échelle, avec des caractères de référence obtenus par "impression" de chaque lettre de chaque fonte, la comparaison étant faite pixel par pixel. Le plus grand pourcentage de concordance a gagné. Ca marche bien si le texte est imprimé avec une fonte installée sur ton PC. Ne pas oublier d'égaliser les histogrammes avant la comparaison.

2) Méthode plus élaborée : Segmenter le caractère, chercher la séquence de vecteurs composant le caractère.
Par exemple, un "H" est composé de 3 vecteurs, dont les tailles et directions relatives sont plus ou moins constantes. Tu prends un point d'origine (le départ de segment le plus en haut à gauche par exemple), et tu cherches ces vecteurs pour les comparer à une base, obtenue elle aussi par analyse des caractères produits par les fontes sur ton PC (histoire d'alimenter un peu la base de connaissances de l'algo).
C'est une comparaison algébrique (différence de vecteurs) ou géométrique, suivant comment tu le vois.

3) Raffinement : méthode 2), la reconnaissance passant via un réseau neuronal afin de pouvoir apprendre de nouveaux caractères. De toutes façons, à la base, ça ne marchera proprement qu'avec une image segmentée, j'ai des doutes sur un réseau neuronal basé sur une comparaison "bitmap" (la base de connaissances serait proprement monstrueuse !!!).

Quel que soit la méthode choisie, il faudra de toutes façons constituer une base de connaissances "à la main"... Pour les comparaisons bitmap, tu peux à la limite de contenter de "tracer" la lettre de référence à la volée, la liste des fontes étant triée par fréquence d'utilisation suivant les résultats de l'OCR. Pour la base vectorielle, c'est plus difficile de le faire à la volée, la segmentation pouvant être une opération assez longue => un programme de "compilation" de cette base peut être requis pour obtenir des performances un minimum décentes.

Par contre, il semble que tu aie une fausse idée d'un réseau neuronal : il n'apprend rien tout seul si tu n'en as pas décidé ainsi, le problème se résumant souvent à coder intelligemment la base de connaissance de l'algo, et surtout à savoir l'augmenter sans la parasiter (ce qui induirait une dégénérescence de l'algo à court terme). Demande aux spécialistes des réseaux neuronaux, ils devraient te confirmer que ce n'est pas un problème trivial.

[bigbill]

ouille ça faisait longtemps
dsl mais c seulement maintenant que je peux commencer à m'y mettre faute de temps....

bon, comme j'en suis encore qu'au tout début, je suppose que j'ai une image scannée nickel bien cadrée, toute propre sans trace de chocolat dessus ( je bouffe bcp qd je travaille ...)
maintenant 1ere chose : je dois à présent détecter ce que sont des lignes ( horizontalement ) et après, ce que sont des lettres ( verticalement ) c bon ?
mais bon, je vais d'abord me concentrer sur les lignes ( qui sera la base pour détecter les lettres )
(j'ai découvert qu'on pouvait utiliser qqch qui s'appelait sdl et qui semble assez cool. )
Mais la pour les lignes, ça risque d'être cho, parce qu'il y a des lettres plus hautes ou plus basses que d'autres non ? comment on fait ?

[Sub0]

Salut!

Je te conseillerais de jeter un oeil sur les programmes disponibles (gratuits sur le net) pour t'en inspirer et de voir les options qu'ils possèdent pour la reconnaissance... Par exemple, j'en ai un qui me permet de choisir une police true type qui se rapprocherait du texte à analyser... Le programme va alors se servir de cette police (vectorielle) pour le traitement...

Bon courage, à+

Envoyé par Le Furet

Par exemple, tu peux découper ton image en blocs 8*8 ou 16*16, appliquer une DCT (Discrete Cosine Transform : Tranformée en Cosinus Discret, celle utilisé pour la compression JPEG), et regarder les blocs gardant de hautes valeurs pour les coefficients correspondant aux contours verticaux et horizontaux.

juste une question le Furet ( je ne suis pas un expert en maths ) :quel serait l'intérêt de filtrer avec une DCT ??

Quel que soit la méthode choisie, il faudra de toutes façons constituer une base de connaissances "à la main"...

Yes tout à fait mais par exemple sous Windows on peut effectuer une comparaison avec les fontes disponibles ;

supprimer les zones de non texte (images)

On est d'accord rbag ; mais qu'est ce qui me dit qu'un ensemble de pixels représente une lettre .
Pas évident d'enlever tous les pixels qui ne correspondant pas aux lettre proprement dit

[Mac LAK]

Envoyé par mat.M

Yes tout à fait mais par exemple sous Windows on peut effectuer une comparaison avec les fontes disponibles ;

Oui, mais il est risqué de ne se baser que sur les fontes disponibles sur le poste client : qui te dit que ce ne sera pas un Windows "minimal", sans les fontes installées par Office, par exemple ?
=> Il faut, sur une machine sur laquelle BEAUCOUP de fontes sont installées, "caractériser" chaque fonte (sans inclure cette fonte dans le programme, car ça serait une copie illégale) => c'est ça que j'appelle une "base de connaissance faite à la main".

[bigbill]

sans doute mais là en fait, vous me parlez tous "déjà" de reconnaissance des caractères ( qui sont donc déjà prélevés du texte scanné ).
Mais pour l'instant j'en suis qu'au prélèvement des caractères .... mm pas, j'en suis qu'au prélèvement des lignes. Et comme je suis un peu lent et un peu nul en programmation, je réfléchis bcp, je passe du temps, mais ça avance pas du tout !!!
Là, je pense regarder chaque ligne de pixels, voir si il y a un seul pixel noir, si oui, c que la ligne n'est pas terminée, si il n'y en a pas, ça veut dire que la ligne précédent est terminée, et que je peux renvoyer l'index de cette ligne ( et sa hauteur )
en plus j'essaie de faire ça à l'aide de SDL ( que je peine à utiliser car tout juste découvert ) donc c pour ça que je galère un peu....

mais à part ça, le principe est bon ?

[Le Furet]

Envoyé par mat.M

juste une question le Furet ( je ne suis pas un expert en maths ) :quel serait l'intérêt de filtrer avec une DCT ??

C'est une méthode que j'ai lue dans un papier sur citeseer. L'idée est toute bête : les contours verticaux et horizontaux surreprésentés dans les lettres de l'alphabet latin se traduisent par des coefficients anormalement hauts dans les coefs correspondant de la DCT. Tu fais un seuillage sur ces coefficients, tu obtiens un ensemble de blocs fortement susceptibles de contenir du texte.

Tu ne gardes que les blocs formant des lignes, et tu te retrouves avec une zone de l'image ayant de très fortes chances de contenir du texte.

Je l'avais implémenté pour faire une petite appli permettant de retrouver les sous-titres sur une video avec des sous-titres incrustés (type fansub), ça marchait très bien, même quand le sous-titre était de la même couleur que le fond, cas dans lequel une méthode "classique" (donner la couleur du texte a priori, et repérer les pixels de cette couleur) se fourvoyait lamentablement.

Ca a été la première fois que le fait d'avoir fait autant de maths dans ma vie m'a paru pouvoir avoir une utilité

[SKZ81]

Ton projet est quand même très ambicieux...
Un OCR pour du texte dactylographié, encore passe, mais pour du texte manuscript, quelqu'un qui se défini d'

Envoyé par bigbill

un peu lent et un peu nul en programmation

devrais savoir poser la barre moins haut.
Je parle en connaissance de cause, combien de fois j'ai pas eu envie de boire la mer avant de me rendre compte que tout ce que j'arrivais à faire c'était de boire la tasse !!! Attention aux déceptions dûes à un trop-plein d'ambition...

Dans un premier temps, pour ton algo, tu devrais chercher la Bounding box optimale. C'est à dire le plus petit quadrilataire qui n'intersecte pas un caractère. Il ne faut pas oublié qu'il peut y avoir des rotations avec un scan ; donc il sera necessaire de BANIR l'hypothèse selon laquelle la hauteur de la ligne en début et fin de ligne est égale...

[Sub0]

Effectivement, je suis aussi de ton avis SKZ81... mais bon, ce n'est pas un projet irréalisable, il suffira d'être persévérant et de travailler régulièrement... Bigbill, si tu ne l'as pas déjà fait, je te conseil de faire une petite recherche sur Google. Perso, je bosse avec Delphi et j'ai pu trouver des choses très intérressantes, voir des sources... Tu trouveras ci-dessous, une API permettant d'obtenir cette fonctionalité :
http://www.neoptec.com/public_html/produits/api/api.php

Et d'autres liens trouvés sur Google.
http://www.developpez.net/forums/viewtopic.php?t=96691
http://www.image-etc.com/produits/imagxpress.htm

Une idée par exemple, tu peux contacter des auteurs d'OCR qui sauront te conseiller...
Bon courage, à+

[bigbill]

ouais, je sais que la barre est un peu haute pour moi (et quand qqn se définit soi-même comme nul c qu'il est vraiment nul ....)
mais cette barre, c pas moi qui l'ai posée ! en fait, c un devoir et je suis obligé de le faire. Evidemment je fais pas tout, c un travail de groupe ( heureusement .... les algorithmes de reconnaissances qui ont été proposés auparavant, j'ai bien l'impression que j'arriverai JAMAIS à un tel niveau ! )

ah et puis à propos, la feuille scannée que je traiterais, sera déjà traitée par un autre membre du groupe donc je suppose que tous les pb de rotation, hauteur de ligne début et fin .... sont réglés

en tout cas, ça avance ( un peu )

[ALEX77]

La réalisation d'un OCR est quelque chose de TRES TRES difficile.

Et je sais de quoi je parle vous pouvez me croire je m'y suis essayé. 8)

Celui qui m'a le plus fasciné est FineReader, sa facilité de reconnaissance est déconcertante et à pleurer. Sur une page en 300 ppp, il faut le voir pour le croire. Les OCR ont depuis beaucoup progressé pour atteindre la quasi perfection.

Bigbill, si tu peux essayer FineReader, tu comprendras la difficulté de l'opération car il cela consiste en gros à :

-analyser la page : repérer les blocs de texte et les différencier des images
-remettre la page bien droite (deskewing pour le connaisseurs)
-analyser chaque bloc : segmenter les lignes, puis isoler les caractères, en sachant que dans certaines polices de caractères, certains caractères s'emboîtent les uns dans les autres (comme "Fin" par exemple en Times New Roman, le i est à l'intérieur du F)

La méthode que j'ai essayé est proche de la tienne. En fait je n'ai pas besoin de deviner pour mon application la police de caractère à tester puique cette appplication récupère des formulaire grâce à un scanner à chargeur automatique et donc lorsqu'on créé un formulaire, on renseigne quelle police de caractère on va tester. Il faut fixer un taux de tolérance, et encore quelques paramètres comme le nombre le pixels minimum entre chaque caractère considérés comme des espaces, etc... mais ça fonctionne pas trop mal.

J'aimerais changer de méthode et faire en sorte que le programme "squelettise" ou en déduise des courbes mathémathiques comme là encore c'est un secret bien gardé. L'idée est de "squelettiser", d'en déduire des courbes et d'attribuer un poids à chacune de ces courbes, le score obtenu oriente le choix du caractère reconnu.

C'est la méthode d'analyse qui permet non seulement de reconnaitre des polices de caractères inconnues (sans avoir besoin comme dans le cas d'une analyse matricielle de renseigner celle qu'on doit tester) mais c'est celle ci qui est utilisée par les logiciels du marché tels qu'Omnipage, FineReader, etc... les pros quoi.

Si quelqu'un a des tuyaux moi aussi ça m'intérresse de pouvoir faire ça !

Je vous mets quelques liens :

http://http.cs.berkeley.edu/~fateman/kathey/ code source en C++, projet OCRchie
http://jocr.sourceforge.net/download.html code source encore en C++, projet GOCR s'utilise en ligne de commande
http://web.mit.edu/stanrost/www/cs585p1/p1.html comment faire un OCR avec MatLab
http://www.efg2.com/Lab/ImageProcessing/index.html faire un OCR c'est aussi comprendre et manipuler les pixels, faire de l'image processing, ce site est une mine d'or pour la manipulation d'image en Delphi

En espérant que cela a pu vous être utile.

[bigbill]

merciiii
les sites que tu m'a passé semblent bien clairs, bien cools, nickel.

à part ça, ton autre méthode d'analyse, ben ... je suis très mal placé pour te dire quoi que ce soit dessus.
dsl