Blöd ist, wenn die eine Seite um einen Pixel versetzt gerendert wird und einige Graustufen doch anders sind.
Wenn nur der Text verglichen werden soll dann konvertiert man einfach in ein Schwarzweissbild - das beseitigt Probleme bei nicht übereinstimmenden Graustufen. Grundsätzlich lässt sich bei dieser Art von Problemen sagen das man, wenn man kann, immer alle Informationen weglassen soll die im Moment nicht notwendig sind.
D.h. sind die Seiten auch nach dem Rendern identisch, also 1:1 pixelgenau?
Wenn es sich so einfach darstellen würde wäre das Problem ja schon gelöst.
Ansonsten würde ich die Bitmaps auf Ähnlichkeit hin vergleichen.
Der Ähnlichkeitsindex von Bildern wäre/ist eine gute Idee wenn es bei dem Vergleich tatsächlich auf optische Gleichheit ankommt und das Ausgangsmaterial dem entspricht. Da gab es ja hier auch mal diese Veröffentlichung :
http://www.delphipraxis.net/144655-b...tion-zncc.html
Als Optimierung / Verbesserung würde ich vorher das zu vergleichende Bild auf die gleiche Größe wie das Referenzbild skalieren, dadurch würden auch gleich aussehende Dokumente erkannt werden wenn beispielsweise eines A4 und eines A5 wäre.
Falls es sich um Formulare handelt kann mann normalerweise die Linienstruktur vergleichen, da die meisten Formulare Striche, Kästen und ähnlichen optische Elemente haben funktioniert das ganz gut. Das wäre dann die Anwendug der Hough-Transformation und ein Graph-Matching.
Wenn inhaltliche Gleichheit gefragt ist dann muss man sich Klarmachen das der gleiche Text vollkommen unterschiedlich aussehen kann, beispielsweise wenn er mal in einer mal in zwei in Spalten formatiert ist, mal mit Grafiken angereichert ist und mal ohne usw. und das der optische Vergleich einen dann vollkommen in die Irre führen kann.
In diesem Fall müsste man zunächst die Elemente/Zonen auf dem Dokument indentifizieren und versuchen festzustellen welcher Art die Zonen sind. Entweder man bastelt das selbst, was aber nicht ohne ist, als erster Ansatzpunkt sei der y-x Cut Algorithmus genannt der ein Dokument in Zonen zerlegen kann oder man greift auf eine OCR/OCR zurück die diese Information auch liefert.
Wenn es kein Geld kosten darf kommt man mit Tesseract ganz gut weiter, es gibt sogar einen Wrapper in FPC dafür.
http://code.google.com/p/tesseract-ocr/
Ich selbst verwende das relativ preisgünstige OCR
SDK von Nicomsomft. Kostet für In-House Anwendungen so um die 400 €, ich habe ein wenig mehr als 1200 € dafür bezahlt um meine Anwendungen auch weitergeben zu dürfen :
http://www.nicomsoft.com
Preislisch nach oben offen sind die SDKs von ABBY, Leadtools und vielen anderen.
Anschließend zerlegt man sein Dokument in Zonen. Wenn man es perfekt machen will dann baut man sich aus den Zonen einen Baum der das Dokument beschreibt (bzw. verwendet den oben genannten y-x cut algorithmus der bei richtiger Implementierung einen Baum liefert) und vergleicht die Bäume untereinander. Wenn man es etwas einfacher mag dann vergleicht man zunächst gleichartige Zonen miteinander indem man einen einfachen Feature-Vektor bildet
1. Anzahl der Bildzonen - Anzahl der Bildzonen im Referenzbild
2. Anzahl der Textzonen - Anzahl der Textzonen im Referenzbild
3. Anzahl der Barcodes - Anzahl der Barcodes im Referenzbild
usw.
Für die jeweiligen (nicht Text-Zonen ) sucht man dann die am bestem passenden Übereinstimmen die sich eindeutig bilden lassen. Am Beispiel von Bildzonen :
Vergleiche alle Bildzonen miteinander (beispielsweise mit dem ZNCC) - gruppiere diese Eindeutig so das die Summe der Ähnlichkeiten max. wird
und nimmt diesen Wert in den Eigenschafts-Vektor auf. Das gleiche macht man für Barcodes, Texte usw.
Bei Textzonen muss man aufpassen ob die Aufteilung in Zonen eine Rolle spielt oder ob nur der Text relevant ist. Falls nur der Text relevant ist kann man den Vergleich auf Wortbasis über alle Zonen ziehen und daraus wieder einen Feature-Vektor aufbauen. Entweder man baut den Vektor aus allen vorkommenden Worten auf, oder nur aus bestimmten Schlüsselwörtern. Im Fall 2 ist das aber eher die Prüfung ob zwei Dokument in die gleiche Kategorie fallen.
Beispiel für der, die, das
1. Anzahl des Wortes "der" in Doc 1 - Anzahl in Doc 2
2. Anzahl des Wortes "die" in Doc 1 - Anzahl in Doc 2
3. Anzahl des Wortes "das" in Doc 1 - Anzahl in Doc 2
Falls auch die Lage bzw. der Aufbau des Dokumentes in den Vergleich eingehen soll dann müssen eben die Zonen vergleichen werden und nicht der gesamte Text. Die Prüfung auf einzelen Wörter hat übrigens den Vorteil das Formatierungsanweisungen ausgefiltert werden können.
Die Vektoren auszuwerten ist dann nur noch ein untergeordnetes Problem.
cu Ha-Jö