notimp
Pirat
- Registriert
- 25 Dezember 2024
- Beiträge
- 13
- Erhaltene Likes
- 14
Es hilft trotzdem zu verstehen was im Hintergrund läuft, und wo die Flaschenhälse sind. Wenn jeder nur postiliert meine App ist eine Magische blackbock und trotzdem keine Raketenwissenschaft...
Also - es in schritte Aufzusplitten - zuerst digitalisieren und sich dann ums weitere zu kümmern, ... Ist ja ok. Aber wenn der workflow nicht so ganz segmentiert, sondern ein wenig integrierter ist, ist das auch toll.
Also, was sind hier einige der Unterchiede von denen wir reden.
Wenn die Smartphone app, oder SagIT OCR verwenden, dann wahrscheinlich nicht OCR AIs, sondern noch konventionelle Software auf der Basis von Tesseract oder ähnlich.
Warum - weil die OCR Models lokal noch mehr als einen Snapdragon Elite voraussetzen. Und die Entwickler dieser Apps gerne ihre App verkaufen wollen - und dafür auch auf nen Markt abstellen müssen bei dem user keine High end Smartphones haben. Die Wahrscheinlichkeit dass ich beides übersehen habe - dh, AI Models die kleiner sind als die State of the Art Modelle die ich genannt habe, und die auf Smartphones laufen, weil sie jemand bereits Integriert hat - ist sehr gering. Wir sprechen davon, dass auf LocalLLAMA gerade mal die ersten Leute mit Kokoro TTS auf Snapdragon Elite Chips experimentieren, um das in Echtzeit lokal laufen zu lassen. Gute OCR AI ist in etwa zehn mal rechenintensiver.
Das Problem lässt sich irrsinnig leicht umschiffen, wenn du APIs, dh Modelle verwendest die auf nem Server laufen. Das Problem ist, dass du dann als App entwickler laufende Kosten hast und den User zuerst in ein Abomodell zwängen musst, bevor du ihm Zugang gewähren kannst. Das werden auch die wenigsten machen.
(Es sei denn für Snag it tut sich irgendwo ein usecase zum Datensammeln und verkaufe auf, der die Kosten deckt. Aber keiner hier konnte bisher artikulieren was seine Software verwendet, also geh ich mal nicht davon aus.)
Dann sind wir wieder bei "wir verwenden Tesseract". Weil Open source, und konventionell.
Und tesseract auf Manuell gescannte Seiten loszulassen ist für automatisierte eBook Erstellung nicht up to the task. Wars noch nie. Wirds nie sein.
Abby Finereader, war immer besser (Fehlerquote), und das mit nem besseren Korrekturinterface on top. Aber ich hab App ist solange praktisch, bis du dir das Problem mal an einem 300 Seiten Buch angeschaut hast.
Dass es bei der pdf die hier eingestellt wurde (anstatt dass sich die Leute die epub geladen haben) mit Adobe Acrobat, oder Tesseract "super funktioniert hat" - ist auch kein Wunder. Da die aus einem Illustrator oder Word Dokument heraus erstellt wurde.
Das sind die schönstn pdfs. Mit den exaktesten x/y Textblock-Koordinaten, ohne jegliche optische Verzrrungen. Bei perfektem Kontrast, ohne tatsächlichen Lichteinfluss, ... Kurzum, ja - tesseract funktioniert bei diesen Dokumenten -- "es is ja keine Hexerei".
Und hier ist was passiert, wenn wir eure workflows anwenden:
Handyfoto. Perspektivkorrektur klappt super, autoenhancing klappt super. Nahe dem Buchfalz ist die Seite gewölbt. Das deskewing funktioniert nur zweidimensioneal. Leichte Schattenbildung am Falz. Tesserakt mit einer Fehlerquote von 5%.
OCR AIs (Mistral OCR, und Deepseek OCR getestet) kommen mit "langgezogenen" Buchstaben (optisches Artefakt) in Falznähe besser zurecht. Du weißt zwar immer noch nicht, wann sie beginnen Worte zu erfinden. Aber Erfahrungsgemäß, als jemand der das schon einmal mit state of the art Modellen gemacht hat, liegen wir hier bei einer Fehlerquote von 3-5 Wörter Pro Kapitel - ohne manuelle Nachkorrektur. Dh. deutlich unter 5% der Worte.
Dafür ist es schwerer (bei API use) zu identifizieren, wo die AI ein Wort erfunde/anders interpretiert hat, als bei konventionellem OCR, wo dann einfach nur Textsalat mit )8,1% etc rausfällt.
Wenns darum geht das zu minimieren, vergleichst du OCR Engines. tesseract < Adobe < Finereader (Vergleich vor drei Jahren, ich nehm nicht an, dass sich im konventionellen OCR bereich so viel geändert hat). Warum? Weil jede Prozent das du nicht manuell nachkorregieren musst deinen Arbeitsaufwand deutlich senkt.
Gehts auch mit Tesseract? Ja - wenn die Input Qualität sehr gut ist.
Ist sie das bei Handy Photos? Nein.
Und ich verkauf hier keine Apps ich kenn die Limitationen aus eigener Erfahrung.
Jetzt zum Silbentrennungsproblem.
Wie macht ihr TTS?
Mit LLMs, oder ohne? Mit App, oder? Also - LLM basierte TTS hat ne höhere (menschenähnlicher) Sprachqualität. Wenn ihr da einen Text mit Silbentrennungs- auslassungen reinwerft. Wird das spassig. Also filterst du die vorher.
Problem - wie filterst du die?
Wenn du ne pdf engine bist, kein reines OCR, aber ne pdf engine - schreiben einige Davon eine Routine, die lines of text anhand exakter Koordinaten in Textblöcke einteilen, und so einen Begriff davon bekommen, das ein Zeilenende innerhalb eines Textblocks ist, die können dann Silbentrennungen effektiv entfernen, weil sie einen Begriff davon haben, was der Anfang der nächsten Zeile ist. Adobe Acrobat hat das vor drei Jahren noch nicht gemacht. Infix PDF Reader schon vor fünf Jahren.
Problem -- wenn sich die Silbentrennung am Seitenende befindet - hast du da meist eine Seitenzahl dazwischen, und mehr Whitespace, und das OCR macht was...? Meine App kann das, oder?
Zweite Möglichkeit. Du machst das mit nem Vorgeschalteten Wörterbuch. Des Silbentrennung beinhaltet, und die Worte basierend darauf wieder zusammenfügt. Problem die Tendenz der heutschen Sprache zu Hauptwortketten, die davor noch nie ein Mensch gebildet hat, und die deutsche Sprache selbst.
Welcher App Entwickler achtet darauf Automatische Spracherkennung zu machen, ein gemeinfreies Wörterbuch auf deutsch zu laden, und dann die Silbentrennungen mit einer Heuristik abzuarbeiten.
Genau - keiner. Und aus Erfahrung. Auf Buchlänge - wird das nichts, wenn du nicht exakt abfragst, ob eine Silbentrennung wahrscheinlich notwendig wird, weil der Satz davor keine Überschrift war, und noch kein Satzzeichen hatte (dazu verwendest du Regex). Und selbst dann - Silbentrennung bei Eigennamen. Silbentrennung bei "Hust-keuch -- schnaufte Peter, old-reads über Ali's Krämer-Laden?"? Heuristiken auf Wörterbuchbasis - haben da ne hohe Fehlerquote.
Aber meine App kann das.
Möglich - wenn du davor noch einen AI pass hast der dir den Text cleaned. Ganze Bücher durch AI zu jagen zwecks "nimm mir die ggf problmatische formatierungen raus"? Schlechte idee. Das segmentiert zu machen (weniger Kontext Window der AI notwendig), bessere Idee, aber immer noch eine Schlechte Idee.
Wie kommt also jetzt die TTS AI zu nem Text ohne Silbentrennungsfehler?
Denn die sind meist Multi Lingual.
Ich brauch darauf keine Antwort - aber einfach kurzum -- du greifst zur epub, und nicht zum pdf. Wenn beide vorliegen. Im ePub gibts die Probleme nicht.
Und noch ein Kurzes wort zu "in meiner OCR App kann ich auch auf anderes Format > txt" gehen! Super. Hat dir das das Marketing verraten?
Erneut, ziemlich sicher läuft da tesseract dahinter um den Text rauszuholen. Wenn das pdf ein Handyfoto ist, bricht die Textblock Erkennung (verlangt sehr genaue x/y line placements), dh du schaltest dann noch ein Wörterbuch vor? In deiner App?
Oder du verwendest eine TTS engine, deren Sprache fixiert ist und die dir silben vorher wieder zusammenbaut? Weil die TTS engine Sprachspezifisch ist, und das irgendjemand so hardgecoded hat? (Mir ist keine Bekannt bei der das der Fall wäre, und ich verwende Ivona seit release) die TTS AIs machen das unter garantie nicht, weil die Multilingual sind.
Ich mein, ich bin ja für Informationen dankbar wie das wo damit korrekt funktioniert.
Aber wenn jemand mit verwende Buxtehude PDF super Pro, oder einfach Snag-IT, oder Adobe am PC ankommt --
sag ich dir
tesseract, oder Abomodell im Hintergrund
linebased Silbenentfernung nur bei exakter Textblock Erkennung
und state of the art TTS modelle (und seis auch nur Kokoro), liefern dir weder Adobe, noch Apple (und die liefern dir bereits gute).
Und dann hörst du dieser TTS stimme drei bis Fünf Stunden zu.
Ich nehme zur Kenntnis, dass das alles nicht Magie ist.
Trotzdem ist es nicht möglich ein Komplettes Buch in ne LLM zu stecken und ihr zu sagen "fix mal".
Ich kann nen Handyphotos zu epub workflow aufstellen, wenn ich mit mit den Limitationen von OCR Modellen auseinandergesetzt habe - und weiß, welches Modell mir wo wieviel kompensiert, wenn ich mit suboptimaler Bildqualität reingeh.
Wenn mir dazu die Sprache fehlt, weil ich nicht weiß, was hinter den Produktn steht die ich kaufe. Wirds schwierig.
Ich sag dann Fehlerquote, und du sagst: Marke Adobe.
Ich sag edge cases, und du sagst meine App hat auch dropdown "exportiere als .txt".
Toll, aber bei Methode Finereader kann ich mir einen Korrekturpass sparen, und bei Handyphotos > Camscanner > Mistral OCR hab ich fünf falsch erkannt Worte pro Kapitel.... die ich mit tesseract im Hintergrund nie erreiche, entgegnest du dann.... Hier Appstore link.
Und ja, ich denke mein Problem ist wirklich meine Antiquierte Sprache, und dass ich wie ein Arschloch wirke, nicht?
*ungr*
Raketenwissenschaft ist es nicht. Aber kenn die Limitationen.
Und wenn du einen Text bereits als ePub bekommst, - wie im beispiel der hier angefragten deutschen Version dieses spezifischen Buches, umschiffst du alle diese Probleme.
Also - es in schritte Aufzusplitten - zuerst digitalisieren und sich dann ums weitere zu kümmern, ... Ist ja ok. Aber wenn der workflow nicht so ganz segmentiert, sondern ein wenig integrierter ist, ist das auch toll.
Also, was sind hier einige der Unterchiede von denen wir reden.
Wenn die Smartphone app, oder SagIT OCR verwenden, dann wahrscheinlich nicht OCR AIs, sondern noch konventionelle Software auf der Basis von Tesseract oder ähnlich.
Warum - weil die OCR Models lokal noch mehr als einen Snapdragon Elite voraussetzen. Und die Entwickler dieser Apps gerne ihre App verkaufen wollen - und dafür auch auf nen Markt abstellen müssen bei dem user keine High end Smartphones haben. Die Wahrscheinlichkeit dass ich beides übersehen habe - dh, AI Models die kleiner sind als die State of the Art Modelle die ich genannt habe, und die auf Smartphones laufen, weil sie jemand bereits Integriert hat - ist sehr gering. Wir sprechen davon, dass auf LocalLLAMA gerade mal die ersten Leute mit Kokoro TTS auf Snapdragon Elite Chips experimentieren, um das in Echtzeit lokal laufen zu lassen. Gute OCR AI ist in etwa zehn mal rechenintensiver.
Das Problem lässt sich irrsinnig leicht umschiffen, wenn du APIs, dh Modelle verwendest die auf nem Server laufen. Das Problem ist, dass du dann als App entwickler laufende Kosten hast und den User zuerst in ein Abomodell zwängen musst, bevor du ihm Zugang gewähren kannst. Das werden auch die wenigsten machen.
(Es sei denn für Snag it tut sich irgendwo ein usecase zum Datensammeln und verkaufe auf, der die Kosten deckt. Aber keiner hier konnte bisher artikulieren was seine Software verwendet, also geh ich mal nicht davon aus.)
Dann sind wir wieder bei "wir verwenden Tesseract". Weil Open source, und konventionell.
Und tesseract auf Manuell gescannte Seiten loszulassen ist für automatisierte eBook Erstellung nicht up to the task. Wars noch nie. Wirds nie sein.
Abby Finereader, war immer besser (Fehlerquote), und das mit nem besseren Korrekturinterface on top. Aber ich hab App ist solange praktisch, bis du dir das Problem mal an einem 300 Seiten Buch angeschaut hast.
Dass es bei der pdf die hier eingestellt wurde (anstatt dass sich die Leute die epub geladen haben) mit Adobe Acrobat, oder Tesseract "super funktioniert hat" - ist auch kein Wunder. Da die aus einem Illustrator oder Word Dokument heraus erstellt wurde.
Das sind die schönstn pdfs. Mit den exaktesten x/y Textblock-Koordinaten, ohne jegliche optische Verzrrungen. Bei perfektem Kontrast, ohne tatsächlichen Lichteinfluss, ... Kurzum, ja - tesseract funktioniert bei diesen Dokumenten -- "es is ja keine Hexerei".
Und hier ist was passiert, wenn wir eure workflows anwenden:
Handyfoto. Perspektivkorrektur klappt super, autoenhancing klappt super. Nahe dem Buchfalz ist die Seite gewölbt. Das deskewing funktioniert nur zweidimensioneal. Leichte Schattenbildung am Falz. Tesserakt mit einer Fehlerquote von 5%.
OCR AIs (Mistral OCR, und Deepseek OCR getestet) kommen mit "langgezogenen" Buchstaben (optisches Artefakt) in Falznähe besser zurecht. Du weißt zwar immer noch nicht, wann sie beginnen Worte zu erfinden. Aber Erfahrungsgemäß, als jemand der das schon einmal mit state of the art Modellen gemacht hat, liegen wir hier bei einer Fehlerquote von 3-5 Wörter Pro Kapitel - ohne manuelle Nachkorrektur. Dh. deutlich unter 5% der Worte.
Dafür ist es schwerer (bei API use) zu identifizieren, wo die AI ein Wort erfunde/anders interpretiert hat, als bei konventionellem OCR, wo dann einfach nur Textsalat mit )8,1% etc rausfällt.
Wenns darum geht das zu minimieren, vergleichst du OCR Engines. tesseract < Adobe < Finereader (Vergleich vor drei Jahren, ich nehm nicht an, dass sich im konventionellen OCR bereich so viel geändert hat). Warum? Weil jede Prozent das du nicht manuell nachkorregieren musst deinen Arbeitsaufwand deutlich senkt.
Gehts auch mit Tesseract? Ja - wenn die Input Qualität sehr gut ist.
Ist sie das bei Handy Photos? Nein.
Und ich verkauf hier keine Apps ich kenn die Limitationen aus eigener Erfahrung.
Jetzt zum Silbentrennungsproblem.
Wie macht ihr TTS?
Mit LLMs, oder ohne? Mit App, oder? Also - LLM basierte TTS hat ne höhere (menschenähnlicher) Sprachqualität. Wenn ihr da einen Text mit Silbentrennungs- auslassungen reinwerft. Wird das spassig. Also filterst du die vorher.
Problem - wie filterst du die?
Wenn du ne pdf engine bist, kein reines OCR, aber ne pdf engine - schreiben einige Davon eine Routine, die lines of text anhand exakter Koordinaten in Textblöcke einteilen, und so einen Begriff davon bekommen, das ein Zeilenende innerhalb eines Textblocks ist, die können dann Silbentrennungen effektiv entfernen, weil sie einen Begriff davon haben, was der Anfang der nächsten Zeile ist. Adobe Acrobat hat das vor drei Jahren noch nicht gemacht. Infix PDF Reader schon vor fünf Jahren.
Problem -- wenn sich die Silbentrennung am Seitenende befindet - hast du da meist eine Seitenzahl dazwischen, und mehr Whitespace, und das OCR macht was...? Meine App kann das, oder?
Zweite Möglichkeit. Du machst das mit nem Vorgeschalteten Wörterbuch. Des Silbentrennung beinhaltet, und die Worte basierend darauf wieder zusammenfügt. Problem die Tendenz der heutschen Sprache zu Hauptwortketten, die davor noch nie ein Mensch gebildet hat, und die deutsche Sprache selbst.
Welcher App Entwickler achtet darauf Automatische Spracherkennung zu machen, ein gemeinfreies Wörterbuch auf deutsch zu laden, und dann die Silbentrennungen mit einer Heuristik abzuarbeiten.
Genau - keiner. Und aus Erfahrung. Auf Buchlänge - wird das nichts, wenn du nicht exakt abfragst, ob eine Silbentrennung wahrscheinlich notwendig wird, weil der Satz davor keine Überschrift war, und noch kein Satzzeichen hatte (dazu verwendest du Regex). Und selbst dann - Silbentrennung bei Eigennamen. Silbentrennung bei "Hust-keuch -- schnaufte Peter, old-reads über Ali's Krämer-Laden?"? Heuristiken auf Wörterbuchbasis - haben da ne hohe Fehlerquote.
Aber meine App kann das.
Möglich - wenn du davor noch einen AI pass hast der dir den Text cleaned. Ganze Bücher durch AI zu jagen zwecks "nimm mir die ggf problmatische formatierungen raus"? Schlechte idee. Das segmentiert zu machen (weniger Kontext Window der AI notwendig), bessere Idee, aber immer noch eine Schlechte Idee.
Wie kommt also jetzt die TTS AI zu nem Text ohne Silbentrennungsfehler?
Denn die sind meist Multi Lingual.
Ich brauch darauf keine Antwort - aber einfach kurzum -- du greifst zur epub, und nicht zum pdf. Wenn beide vorliegen. Im ePub gibts die Probleme nicht.
Und noch ein Kurzes wort zu "in meiner OCR App kann ich auch auf anderes Format > txt" gehen! Super. Hat dir das das Marketing verraten?
Erneut, ziemlich sicher läuft da tesseract dahinter um den Text rauszuholen. Wenn das pdf ein Handyfoto ist, bricht die Textblock Erkennung (verlangt sehr genaue x/y line placements), dh du schaltest dann noch ein Wörterbuch vor? In deiner App?
Oder du verwendest eine TTS engine, deren Sprache fixiert ist und die dir silben vorher wieder zusammenbaut? Weil die TTS engine Sprachspezifisch ist, und das irgendjemand so hardgecoded hat? (Mir ist keine Bekannt bei der das der Fall wäre, und ich verwende Ivona seit release) die TTS AIs machen das unter garantie nicht, weil die Multilingual sind.
Ich mein, ich bin ja für Informationen dankbar wie das wo damit korrekt funktioniert.
Aber wenn jemand mit verwende Buxtehude PDF super Pro, oder einfach Snag-IT, oder Adobe am PC ankommt --
sag ich dir
tesseract, oder Abomodell im Hintergrund
linebased Silbenentfernung nur bei exakter Textblock Erkennung
und state of the art TTS modelle (und seis auch nur Kokoro), liefern dir weder Adobe, noch Apple (und die liefern dir bereits gute).
Und dann hörst du dieser TTS stimme drei bis Fünf Stunden zu.
Ich nehme zur Kenntnis, dass das alles nicht Magie ist.
Trotzdem ist es nicht möglich ein Komplettes Buch in ne LLM zu stecken und ihr zu sagen "fix mal".
Ich kann nen Handyphotos zu epub workflow aufstellen, wenn ich mit mit den Limitationen von OCR Modellen auseinandergesetzt habe - und weiß, welches Modell mir wo wieviel kompensiert, wenn ich mit suboptimaler Bildqualität reingeh.
Wenn mir dazu die Sprache fehlt, weil ich nicht weiß, was hinter den Produktn steht die ich kaufe. Wirds schwierig.
Ich sag dann Fehlerquote, und du sagst: Marke Adobe.
Ich sag edge cases, und du sagst meine App hat auch dropdown "exportiere als .txt".
Toll, aber bei Methode Finereader kann ich mir einen Korrekturpass sparen, und bei Handyphotos > Camscanner > Mistral OCR hab ich fünf falsch erkannt Worte pro Kapitel.... die ich mit tesseract im Hintergrund nie erreiche, entgegnest du dann.... Hier Appstore link.
Und ja, ich denke mein Problem ist wirklich meine Antiquierte Sprache, und dass ich wie ein Arschloch wirke, nicht?
*ungr*
Raketenwissenschaft ist es nicht. Aber kenn die Limitationen.
Und wenn du einen Text bereits als ePub bekommst, - wie im beispiel der hier angefragten deutschen Version dieses spezifischen Buches, umschiffst du alle diese Probleme.
Zuletzt bearbeitet:
