Handschrifterkennung
-
Korbinian schrieb:
zur zentrierung und rotation: das macht grad ne kollegin von mir. man kann solche sachen immer als drehung und verschiebung ansehen, und das kannst du mit einer matrix erreichen.
rotationen um 90, 180 oder 270 grad sind vermutlich nicht extrem sinnvoll. kleinere so um 20 grad kriegste nur mit so fetten verlusten hin, daß es unfug wäre. daher dachten wir nicht an rotationen.
wegen der verluste sollten die verschiebungen auch nur um ganze pixelgrößen sein.vielleicht noch eine kleine idee dazu: man könnte einfach (nachdems nur wenig zeichen sind) das zu klassifizierende zentrieren, dann von einem guten sample "abziehen" und dann entsprechend die klasse, die den kleinsten betrag (vom vektor) hat, als referenz zum drehen hernehmen.
aber wie danach drehen?
-
das drehen geht über matrizen, wie schon gesagt. wenn man 3 punkte im orginal und dem zu drehenden hat, dann geht das. wenn du willst frag ich meine arbeitsplatz nachbarin, wenn ich sie sehe
-
was nehmt ihr als Klassifkator?
bye
tt
-
Jester schrieb:
kingruedi würde gern z.b. sowas wie wxwindows dafür sehn, damit er das ganze projekt bei sich laufen lassen kann, hab ich recht?
jo, wär ein bisschen Schade, wenn das Projekt eh Plattformunabhängig ist, dass es dann an der GUI scheitert
@king: wär vielleicht gleich was für dich, mit einzusteigen, falls du zeit und lust hast
hab leider gerade mehrere Projekte, an denen ich mitwirke. Hautprächlich das Widget System GOTT, dass noch einiges an Arbeit brauch.
-
Zum Thema Rotation fällt mir nur Stichwort FFT ein. Hab leider keine Ahnung, wie man im FFT - Raum eine Mustererkennung durchführt. Ich weiß nur, das es im FFT - Raum egal ist, wo und wie sich dort ein Objekt befindet -> hauptsache die auftretetenden Frequenzen sind signifikant genug.
-
Ich bin mir nicht so sicher, ob FFT da was bringen würde.
Zu den Rotationen: Schon klar, daß man Rotationen durch Matrizen ausdrücken kann. Leider sind unsere Vektoren aber diskret, sodaß wir riesige Fehler beim rotieren rausbekommen. Zudem wissen wir auch nicht so genau in welche Richtung wir denn rotieren sollen...
Ich denke das zentrieren bringt was, von der Rotation erhoffe ich mir nicht allzuviel.Bin leider noch nicht dazu gekommen am Source zu schrauben, vielleicht heute abend. Rechnet nicht vor morgen mit dem Zeug.
MfG Jester
-
TheBigW schrieb:
Zum Thema Rotation fällt mir nur Stichwort FFT ein. Hab leider keine Ahnung, wie man im FFT - Raum eine Mustererkennung durchführt. Ich weiß nur, das es im FFT - Raum egal ist, wo und wie sich dort ein Objekt befindet -> hauptsache die auftretetenden Frequenzen sind signifikant genug.
Eine Mustererkennung im Ortsbereich funktioniert genauso wie eine Erkennung im Originalbereich, schließlich liegen weiterhin "gesetzte Pixel" vor, die man mit einem Original in Deckung bringen will.
Also sollte man die gleichen Algorithmen einsetzen können wie zuvor auch.
ABER ich bin mir nicht so ganz über den Sinn sicher. Falls einer mal Bilder transformieren will, ich kann dazu mein Diplomarbeitsprogramm zur Verfügung stellen, da könnt Ihr ein bißchen FFT machen und Euch die Bilder im Ortsbereich ansehen.
Denn eine Sache ist klar, ein gedrehtes Bild ergibt auch ein anderes transformiertes Bild [Identität, Linearität der Abbildung, bla], ich bin mir nur jetzt nicht sicher, wie die Drehung im Bildbereich aussehen wird, welche Frequenzen anders sind.
Evtl. kann man dann die Bilderkennung auf die Amplitude des transformierten Vektors begrenzen und vernachlässigt die Phaseninformation... das könnte sein. Aber der komplexe transformierte FFT-Vektor ist für gedrehte Bilder anders.
Hugh!
-
Ich vermute auch mal, daß die Amplitude gleich bleibt und sich nur die Phase ändert. Das blöde dabei ist: Die Hauptinformation von Bildern ist in der Phase kodiert.
Kann man leicht nachprüfen, indem man mal ein Bild transformiert und dann bei der Rücktransformation eine der beiden Informationen wegläßt. Wenn man nur die Phase benutzt kann man danach noch einiges erkennen. Verwendet man nur die Amplitude bleibt kaum was übrig.
MfG Jester
-
kingruedi schrieb:
Jester schrieb:
kingruedi würde gern z.b. sowas wie wxwindows dafür sehn, damit er das ganze projekt bei sich laufen lassen kann, hab ich recht?
jo, wär ein bisschen Schade, wenn das Projekt eh Plattformunabhängig ist, dass es dann an der GUI scheitert
Es gibt bei jedem Projekt eine wichtige Regel: "first things first!".
Anbetracht der vielfältigen zu lösenden Probleme im mathematischen Background führt diese Forderung vom Weg ab. Projekte scheitern dann, wenn die Ziele zu weiträumig gesteckt sind und zu wenig Zwischenziele vorhanden sind. Diskussionen über GUIs zum jetzigen Zeitpunkt führen IMO vom Weg ab und legen den Grundstein für das Scheitern, da die Komplexität der Anforderungen rascher erhöht wird als die Bearbeitung erfolgen kann.
-
Jester schrieb:
Ich vermute auch mal, daß die Amplitude gleich bleibt und sich nur die Phase ändert. Das blöde dabei ist: Die Hauptinformation von Bildern ist in der Phase kodiert.
Naja, ist ja auch kein Wunder, schließlich lässt man damit dann ja "die Hälfte" von Re und Im weg... das bleibt nicht spurlos.
Trotzdem wäre es interessant ob aber die in der Amplitude vorhandene Information nicht ausreicht für die Mustererkennung, da hat TheBigW schon recht.
Denn bei einem eindimensionalen Vektor kann ich viele Systemidentifikationen auch auf der Amplitude ausführen, da die Phase nur Verschiebungen enthält, die nichts mit der Charakteristik zu tun haben.
Grundsätzlich finde ich daher die Idee zumindest der Überprüfung wert. Für diesen Test kann ich gerne was zur Verfügung stellen, man braucht dann zwar die Bilder als Bitmap/TIFF/bla, aber damit lässt sich schnell ein Unterschied zwischen a und a sehen... das Programm kann Re/Im/Ampl/Phase-Bilder getrennt darstellen.
-
Okay, das ist wohl auf jeden Fall einen Versuch wert. Würde ich aber für den Moment auch erstmal noch etwas weiter hinten anstellen, da ich andere Dinge momentan für vielversprechender halte.
Heute abend werde ich hoffentlich dazu kommen den Code zu überarbeiten. Dann schauen wir mal weiter.Nochmal was zur GUI:
Eigentlich entwickeln wir eine Bibliothekt, die Handschrifterkennung von Einzelbuchstaben realisiert. Das hat mit ner GUI erstmal garnichts zu tun. Um unsere Lib zu testen und auch vorführen zu können brauchen wir aber ne kleine Demoapplikation, und weil's einfach und schnell ging haben wir die halt mit MFC gemacht. Aber ich verstehe diese GUI nicht als Bestandteil der Lib.
-
weg
-
2dimensionale fft. ich such mal in meinem buch, wo das erklärt ist
-
Das ist einfach einmal FFT in X-Richtung und danach in Y-Richtung (oder umgekehrt). Formel hab ich... Aber ich weiß verspreche mir momentan nicht zuviel davon...
-
wie habt ihr eigentlich bisher definiert wie welcher buchstabe aussehen soll?
was man villeicht auch versuchen kann ist massenweise verschieden schriftproben von buchstaben (wenn am besten erstmal von einer person) über ein neuronales netz zu jagen... wenn das dann genug gelernt hat kann man veruschen ob das netzt schlau genug ist sowas zu erkennen...
-
Wir habens zwar nicht mit neuralen Netzen gemacht, aber wir haben in der Tat viele, viele Samples erstellt.
-
Wir habens zwar nicht mit neuralen Netzen gemacht, aber wir haben in der Tat viele, viele Samples erstellt.
und was habt ihr dann mit den samples gemacht?
nen mittelwert genommen? das hätte bestimmt nicht gut funktioniert... oder vergleicht ihr einen buchstaben immer mit z.b. 10 soll-a's
wie genau habt ihr denn nun einen bestimmten buchstaben definiert und wie läuft der vergleich ab?
-
@windalf: im augenblick ist es ein ziemlich billiger next neighbour, und das sample set manuell erstellt (überwachtes lernen
die merkmalvektoren wurden über pca extrahiertwerde demnächst für dieses projekt einen bayes klassifikator, sowie eine support vektor maschine einzubauen
-
Hallo!
Ihr könnt einen fix und fertigen Installshield-Installer bekommen. 1 Stunde ausprobieren, danach Idee verwerfen oder verwenden.
Keine Bücher notwendig.
-
Habt ihr mal über die Verwendung von Fourier-Deskriptoren nachgedacht?