--- name: project_deskew_preprocessing description: Deskew-Vorverarbeitungsschritt (ImageMagick) gegen Schräglage in der OCR-Pipeline, ergänzend zum OSD-90°-Rotationsfix metadata: type: project --- Am 2026-07-16 wurde `deskewImage()` in `internal/ocr/ocr.go` ergänzt: `convert -deskew 40% ` 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.