- Ein Web-Tool, das den Aufwand reduziert, Dokumentbilder erst in Text zu übertragen und anschließend neu zu strukturieren, indem es sie in strukturiertes Markdown umwandelt
- Die Web-Eingabe ist derzeit vor allem auf Bild-Uploads ausgelegt; PDF-Unterstützung soll laut Hinweis bald folgen
- Der Dienst basiert auf dem npm-Paket llama-ocr und Together AI
- In JavaScript kann man der Funktion
ocr filePath und TOGETHER_API_KEY übergeben und ein Markdown-Ergebnis erhalten
- Da sowohl Web-Uploads als auch Code-Aufrufe unterstützt werden, lässt sich die Umwandlung von Dokumentbildern je nach Bedarf manuell oder im Entwicklungs-Workflow ausprobieren
Bilddokumente in Markdown umwandeln
- LlamaOCR.com ist ein Tool, das hochgeladene Dokumente in Markdown umwandelt
- Die Webseite wirbt mit „Upload an image to turn it into structured markdown“ und erzeugt per Bild-Upload strukturiertes Markdown
- PDF-Unterstützung ist mit „soon“ gekennzeichnet; der derzeitige Funktionsumfang konzentriert sich also auf Bilder
Verwendung im Code
- Mit dem npm-Paket llama-ocr lässt sich OCR in JavaScript-Code ausführen
import { ocr } from 'llama-ocr';
const markdown = await ocr({
filePath: './trader-receipt.jpg',
apiKey: process.env.TOGETHER_API_KEY
});
- Im Beispiel wird bei
filePath der Pfad zur Bilddatei angegeben und bei apiKey die Umgebungsvariable TOGETHER_API_KEY übergeben
- Der Dienst basiert auf llama-ocr und Together AI
1 Kommentare
Meinungen auf Hacker News
Ich bin der Entwickler von llama-ocr. Danke fürs Teilen und für die positive Resonanz. Ich brauchte eine einfache OCR-API, habe sie Anfang dieser Woche gebaut und parse Bilder mit Llama 3.2 Vision, gehostet bei Together.ai, in strukturiertes Markdown.
Es gibt das Ganze auch als npm-Paket. Ich plane außerdem Funktionen wie PDF-Parsing und JSON-Antworten hinzuzufügen; wenn es Fragen gibt, versuche ich sie zu beantworten.
Ich frage mich, ob so eine starke Umformung erwartetes oder wünschenswertes Verhalten ist. Die Ausgabe ist mal eine Aufzählungsliste und mal eine Tabelle, was die spätere automatische Verarbeitung etwas erschwert.
Ich frage mich, ob ihr solche Use Cases ebenfalls berücksichtigt habt.
Ich würde gern wissen, welche Arten von Fehlern es im Vergleich zu bestehenden OCR-Systemen macht.
Das hier schickt einfach ein Bild an Llama 3.2 Vision und bittet es, den Text zu lesen.
Wie andere LLM-Ausgaben ist es anfällig für Halluzinationen. Denn es liest keine Buchstabenformen aus Pixeln, sondern beurteilt den Text, indem es das Bild auf Basis gelernter Bilder und Captions beschreibt. Gerade wenn etwas schwer lesbar ist, kann es Wörter komplett erfinden.
Sieht cool aus. Ich mache in letzter Zeit viel OCR, daher freue ich mich über neue Tools in diesem Bereich. Der aktuelle Platzhirsch für PDF→Markdown ist vermutlich Facebooks Nougat[1], und ich würde es gern an DSPy anbinden, um zu vergleichen, was bei Philosophiebüchern besser funktioniert.
Das Zerox[2]-Projekt des Startups, auf das dieses Repository verlinkt, sieht ebenfalls gut aus, und zumindest das Marketing ist deutlich geschmeidiger als bei Nougat. Falls hier echte Fachleute vorbeikommen, würde ich mich über Korrekturen oder Ratschläge freuen.
Ich habe zwei Fragen. 1) Was ist Together.ai, und ist dieses Modell Open Source? Die Website wirkt wie ein Hosting-Service, und die Seite „Custom Models“[3] sieht eher nach angepasstem Fine-Tuning als nach Training eigener proprietärer Modelle aus. Es scheint ein HuggingFace-Profil zu geben, aber es ist unklar, ob das wirklich ihres ist: https://huggingface.co/TogetherAI
2) Auf GitHub steht „hosted demo“, aber der gehostete Teil scheint nur eine kleine, saubere WebGUI zu sein. Bedeutet das, dass diese Funktion jetzt und auch künftig nur per API-Aufruf nutzbar ist?
P.S.: Im Desktop-Browser ist der Header-Link kaputt, und onClick wird nicht ausgelöst.
[1] https://facebookresearch.github.io/nougat/
[2] https://github.com/getomni-ai/zerox
[3] https://www.together.ai/products#custom-models
Mir ist etwas Merkwürdiges aufgefallen. Ich habe als Beispiel einen Webcomic hochgeladen; alle Dialoge waren in Großbuchstaben, aber die Ausgabe mischte je nach Panel uneinheitlich Satzschreibung und Titel-Großschreibung.
Ich habe auch ein Problem getestet, für das ich OCR tatsächlich einsetzen möchte. Ich habe alte Dias, die digitalisiert werden müssen und größtenteils beschriftet sind. Als ich eines hochlud, beschrieb es das Bild als etwas, das wie ein Dia- oder Filmframe-Foto aussieht, alt und vergilbt sei, in der Mitte einen dunklen rechteckigen Ausschnitt habe, der Text laute „Once Upon a Time“ und die Zahl sei „1069“.
Die unnötig repetitive Beschreibung des Dias ist schon ein Problem, aber der tatsächliche Text war nicht einmal kursiv geschrieben und lautete „Once Uniquitous.“, die Zahl war 106g. Es war sehr eindeutig ein „g“, keine „9“.
Interessant daran ist, dass es ein Beispiel für Modell-Bias sein könnte. Es sah das Dia so sehr als Antiquität, dass es einen völlig klischeehaften Titel halluzinierte; das schwarze Rechteck entstand dadurch, dass von vorn Licht darauf fiel, damit der transparente Bereich nicht sichtbar war, und das hat es übersehen.
Außerdem scheint die API selbst undokumentierte Limits für Dateigröße oder Auflösung zu haben.
Ich habe kürzlich llama3.2-vision verwendet, um papierne Gebotsblätter für eine Wohltätigkeitsauktion zu verarbeiten, und es war selbst bei ziemlich schlechter Handschrift recht genau. Ich möchte es beim Event im nächsten Jahr wieder einsetzen.
Ziemlich nervig ist allerdings, dass es schwer ist, eine konsistente CSV-Ausgabe zu erzwingen. ChatGPT und Gemini scheinen in dieser Hinsicht besser zu sein, aber ich habe das noch nicht automatisiert.
Der Umfang liegt bei etwa 100 Seiten Gebotsblättern, daher ist ein gewisser manueller Cleanup okay. Es ist definitiv besser, als Zeit von Freiwilligen zu verbrennen.
https://github.com/philips/paper-bidsheets
Es ist nicht kostenlos, aber die Genauigkeit bei handschriftlichen Dokumenten ist erstklassig. Ich bin als Gründer voreingenommen, aber das aktuelle Genauigkeitsniveau ist wirklich vielversprechend. Bei einem Projekt mit 100 Seiten wären das nur 12 Dollar und könnte Zeit sparen.
Ich habe in letzter Zeit viel OCR gemacht, vor allem um Text in Familienfotos zu digitalisieren. Normale OCR-Modelle waren miserabel, LLMs waren deutlich besser. Unter den getesteten Modellen war Gemini Flash mit Abstand am besten, aber es gab trotzdem noch genug Fehler und Halluzinationen, dass Abtippen von Hand schneller war.
Es ist frustrierend, wenn es sich anfühlt, als wäre es fast so weit, aber dann doch nicht funktioniert. Dieses Tool sieht noch schlechter aus. Mal antwortet es nur mit Text, mal liefert es eine komplette Beschreibung wie „The image is a scanned document with handwritten text...“. Ich hatte gehofft, es gäbe so etwas wie Fine-Tuning, damit es Gemini Flash schlagen kann; das hätte mir viel Zeit sparen können, schade
convert -density 76 input.pdf output-%d.pnghttps://github.com/philips/paper-bidsheets
Flash ist interessant; mich würde auch interessieren, welche LLMs du getestet hast
Es hat enorm geholfen, die Bilder so zuzuschneiden, dass nur die Textbereiche übrig blieben, Ränder zu entfernen und den Kontrast zu erhöhen. Das ist ein Artikel von 2015, passt aber immer noch gut zu GPT: https://www.danvk.org/2015/01/07/finding-blocks-of-text-in-a...
Für GPT war es besser, ihm jeweils nur ein paar Absätze oder weniger zu geben statt eine ganze Seite auf einmal. Je kürzer der Text, desto geringer die Wahrscheinlichkeit von Halluzinationen
Die zuletzt diskutierte OCR war miserabel, und ich hatte gehofft, dass diese hier besser wäre. ChatGPT 4o war gut, wenn ich einzelne Bilder in den Chat eingefügt habe, aber die API habe ich noch nicht ausprobiert. Ich weiß nicht, wie viel es kosten würde, 6500 Fotos zu verarbeiten; viele davon sind zwar leer, aber es gibt auch keine einfache Möglichkeit, sie herauszufiltern
Beim Zurückgeben der Textpositionen ist es noch nicht gut, aber in meinen Tests war die OCR-Leistung enorm
Ich frage mich, ob das wirklich ein „Show HN“-Post sein sollte. Es sieht einfach wie ein Frontend aus, und ich sehe auch keinen Teil, der direkt mit dem Llama im Namen zusammenhängt. together.ai könnte Cloud-Speicher bereitgestellt haben
Ich habe mit einem genetischen Algorithmus 500 Kreise so angeordnet, dass sie einen Satz bilden, und dann den mit echten physischen Kreisen gezeichneten Satz eingegeben.
https://www.instagram.com/marekgibney/p/BiFNyYBhvGr/
Interessanterweise erkennt es die Kreise gut, sieht aber den Satz nicht. Es antwortete sinngemäß: „Das Bild enthält keinen Text oder Elemente, die sich in Markdown darstellen lassen, sondern nur eine visuelle Anordnung von Kreisen; es gibt keine Informationen, die sich in Markdown übersetzen ließen“
Da die Antwort nicht deterministisch ist, habe ich auch das Originalbild mehrfach versucht, aber es hat kein einziges Mal funktioniert. Dagegen funktionierten alle angewendeten Tiefpassfiltereffekte mit hoher Erfolgsquote.
https://imgur.com/q7Zd7fa
Aus der Entfernung ist es leichter zu lesen
Die Art, wie der genetische Algorithmus verwendet wurde, ist ziemlich cool. Ich würde gern den Code sehen oder zumindest die Reward-Funktion
Das war lustig. Ich habe drei Screenshots eines langen Dokuments eingegeben, und es hat sie relativ gut verarbeitet, aber beim Korrekturlesen fiel mir auf, dass die AI Absätze erfunden hatte, die im Original nicht vorkamen.
Vermutlich waren durch die Natur der Screenshots einige Sätze oder Absätze mitten drin abgeschnitten, was die Lückentext-ausfüllen-Tendenz des LLMs getriggert hat. Es konnte unvollendete Absätze nicht einfach unvollendet lassen und fügte sogar einen kurzen Schlussabsatz hinzu, der im Originaldokument überhaupt nicht existierte
Ich habe einen alten Scan des Schaltplans eines Asus-P3B-F-Mainboards von 1997 eingegeben.
Es extrahierte nur einen Teil des Texts im Titelblock, etwa den Projektnamen und das Datum, und verwechselte trotz klarer Schrift sowohl 8/B als auch 1/I.
Die tatsächlich nützlichen Informationen wurden zu etwas wie „Tables / Table 1: [Insert table 1 here] / Other Elements / [Insert other elements here]“.