Handschrifterkennung
-
Schön!
Ich hab mir gestern mal Gedanken gemacht, wie man das Trennen der Samples beschleunigen kann, das werde ich mal testen.
Ja, wie Korbinian sagte gibt es bereits ein funktionierendes Framework. Das ganze ist in C++ geschrieben und größtenteils portabel, die Oberfläche ist derzeit mit MFC gemacht.
Aber das alles kann man sich in den nächsten Tagen dann runterladen.MfG Jester
-
Wäre nett, wenn du an die Infos bezüglich Hugh denken könntest.
-
Hab ich schon gescannt, liegt aber noch auf dem Rechner meines Mitbewohners. Werd ich Dir wohl morgen dann zumailen.
Ist halt etwas umfangreicher(2-3MB), aber ich hoffe das macht nichts.MfG Jester
-
Achja, noch ein Feature, das wir einbauen sollten:
-Buchstaben vor dem erkennen zentrieren(Idee: volkard, ich):
Alle Pixel durchschauen und den mit größtem/kleinstem x/y-Wert finden. Von diesen 4 Punkten den Durchschnitt bilden und dann das Bild so verschieben, daß dieser Punkt in der Mitte liegt. Dann ist der Buchstabe in der Mitte und wir sind ein Problem los.
MfG Jester
-
btw. Mein bescheidener Wunsch:
(bitte mach das System Plattform unabhängig und integrierbar (als Library). Könnte sowas gut für GOTT (GUI On Transparent Technology - Widget System) gebrauchen)
-
Die Lib an sich ist vollständig in Standard C++ geschrieben. Nur die Ein/Ausgabe ist mit MFC gemacht. Bis vor dem Forum-Treffen lief alles in der Konsole. Sollte also kein Problem sein.
MfG Jester
-
Jester schrieb:
Hab ich schon gescannt, liegt aber noch auf dem Rechner meines Mitbewohners. Werd ich Dir wohl morgen dann zumailen.
Ist halt etwas umfangreicher(2-3MB), aber ich hoffe das macht nichts.MfG Jester
Danke schön. Lads einfach auf den c++.de-ftp hoch, dann haben wir keine probleme bezüglich Größe.
-
Ich hoffe ich kann das auch ohne Probleme in C# benutzten
Weil das würde mich auch mal interessieren.
-
Danke schön. Lads einfach auf den c++.de-ftp hoch, dann haben wir keine probleme bezüglich Größe.
mach doch lieber ein SourceForge Projekt daraus, dann kannst du auch gleich CVS und andere Features (wie Webspace) benutzen.
Nur die Ein/Ausgabe ist mit MFC gemacht.
solange man keine MFC Sachen benutzen muss und die weglassen kann (btw. warum nicht lieber was Platformunabhängiges), ist das egal.
-
kingruedi schrieb:
Danke schön. Lads einfach auf den c++.de-ftp hoch, dann haben wir keine probleme bezüglich Größe.
mach doch lieber ein SourceForge Projekt daraus, dann kannst du auch gleich CVS und andere Features (wie Webspace) benutzen.
Das war auf die Sachen bezüglich Hugh bezogen ...
kingruedi schrieb:
Nur die Ein/Ausgabe ist mit MFC gemacht.
solange man keine MFC Sachen benutzen muss und die weglassen kann (btw. warum nicht lieber was Platformunabhängiges), ist das egal.
Hä? Nur die Oberfläche ist MFC, hat Jester doch geschrieben ...
-
@deus
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?
@king: wär vielleicht gleich was für dich, mit einzusteigen, falls du zeit und lust hast
@jester:
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. 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.
-
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.