patrick
9a24ea29e1
Git-Repository für bestehenden archivdms-Code initialisiert, Branch-/Commit-Konvention (feature/<ticket>-<slug>-Branches, Ticket-Prefix in Commit-Nachricht) etabliert.
2.0 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| project_deskew_preprocessing | Deskew-Vorverarbeitungsschritt (ImageMagick) gegen Schräglage in der OCR-Pipeline, ergänzend zum OSD-90°-Rotationsfix |
|
Am 2026-07-16 wurde deskewImage() in internal/ocr/ocr.go ergänzt: convert <src> -deskew 40% <dst> läuft in runTesseract() VOR der bestehenden OSD-basierten 90°/180°-Rotationskorrektur (rotateForOSD). Grund: Tesseract-OSD erkennt nur 90°-Schritte, keine Feinneigung (wenige Grad Schräglage bei Scans/Handyfotos).
Server-Paket-Falle: imagemagick-7-common war auf 192.168.1.204 bereits installiert, lieferte aber KEINE convert/magick-Binary — nur Infrastruktur/Metapaket. Die echte Binary kommt erst mit dem Paket imagemagick (zieht imagemagick-7.q16, netpbm, libnetpbm11t64 als Abhängigkeiten). Bei zukünftigen "convert nicht gefunden"-Diagnosen zuerst dpkg -l | grep imagemagick prüfen, nicht nur which convert.
Threshold-Wahl: 40% manuell gegen dms doc ids 2/7/8 verifiziert (deutliche Verbesserung, besonders doc 7). 80% probeweise getestet — überrotierte einen kontrastarmen Beleg (doc 8) und verschlechterte das Ergebnis. Bei neuen Problemfällen mit 40% starten, nur bei Bedarf pro Dokumenttyp anpassen, nicht pauschal erhöhen.
Muster: best-effort wie rotateForOSD — eigene deskewImage()-Methode mit (dstPath string, cleanup func(), ok bool)-Signatur, Fehler/Timeout/fehlende Binary führen zu ok=false, Original-Datei wird ohne Deskew weiterverwendet, kein Abbruch der OCR-Pipeline.
Why: Nutzer meldete nach dem OSD-Fix, dass das eigentliche verbleibende Problem Schräglage ist, nicht 90°-Rotation — OSD kann das strukturell nicht lösen.
How to apply: Bei weiteren OCR-Qualitätsproblemen mit schräg liegendem Text zuerst prüfen ob deskewThreshold (aktuell 40%, Konstante in ocr.go) für den konkreten Dokumenttyp passt, bevor neue Sidecars (unpaper etc.) vorgeschlagen werden — feedback_scope_code_and_deploy_only gilt auch hier, keine Übertechnisierung ohne nachgewiesenen Bedarf.