feat(mobile): Bild-Vorverarbeitung und Zeilensegmentierung on-device

admin-mrrm commented

2026-04-26 09:11:35 +02:00

Owner

Ziel

Die Bild-Vorverarbeitung (Deskew, CLAHE, Bilateral-Filter) und Zeilensegmentierung die bisher auf dem Server in Python/OpenCV läuft, auf dem Gerät in JavaScript/nativ implementieren.

Hintergrund

TrOCR erwartet einzelne Zeilenbilder als Input. Auf dem Server übernimmt ocr.py die Segmentierung via OpenCV. On-Device muss das in React Native passieren.

Optionen

Option A: `@techstark/opencv-js` (empfohlen)

OpenCV.js Port für React Native – enthält alle benötigten Funktionen:

cv.threshold (Otsu-Binarisierung)
cv.dilate (Zeilensegmentierung)
cv.findContours
cv.createCLAHE
cv.bilateralFilter

Option B: Expo Image Manipulator + eigene Algorithmen

Nur für einfache Ops (Resize, Rotate) geeignet; Contour-Detection fehlt.

Option C: Native Modul

OpenCV Android/iOS direkt einbinden – maximale Performance, höchster Aufwand.

Aufgaben

@techstark/opencv-js Kompatibilität mit Expo prüfen
preprocessImage(uri: string): Promise<ImageData> implementieren
- Deskew via minAreaRect
- CLAHE auf L-Kanal
- Bilateral-Filter
splitLines(imageData: ImageData): Promise<ImageData[]> implementieren
- Otsu-Binarisierung
- Horizontale Dilation
- Contour-Bounding-Boxes
- Mindestgröße-Filter
Ergebnis visuell mit Python-Server-Output vergleichen (gleiche Zeilen erkannt?)

Akzeptanzkriterien

Für ein Test-Foto werden dieselben (oder mehr) Zeilen erkannt wie auf dem Server
Laufzeit der Segmentierung < 500 ms auf Pixel 8 Pro

## Ziel Die Bild-Vorverarbeitung (Deskew, CLAHE, Bilateral-Filter) und Zeilensegmentierung die bisher auf dem Server in Python/OpenCV läuft, auf dem Gerät in JavaScript/nativ implementieren. ## Hintergrund TrOCR erwartet einzelne Zeilenbilder als Input. Auf dem Server übernimmt `ocr.py` die Segmentierung via OpenCV. On-Device muss das in React Native passieren. ## Optionen ### Option A: `@techstark/opencv-js` (empfohlen) OpenCV.js Port für React Native – enthält alle benötigten Funktionen: - `cv.threshold` (Otsu-Binarisierung) - `cv.dilate` (Zeilensegmentierung) - `cv.findContours` - `cv.createCLAHE` - `cv.bilateralFilter` ### Option B: Expo Image Manipulator + eigene Algorithmen Nur für einfache Ops (Resize, Rotate) geeignet; Contour-Detection fehlt. ### Option C: Native Modul OpenCV Android/iOS direkt einbinden – maximale Performance, höchster Aufwand. ## Aufgaben - [ ] `@techstark/opencv-js` Kompatibilität mit Expo prüfen - [ ] `preprocessImage(uri: string): Promise<ImageData>` implementieren - Deskew via minAreaRect - CLAHE auf L-Kanal - Bilateral-Filter - [ ] `splitLines(imageData: ImageData): Promise<ImageData[]>` implementieren - Otsu-Binarisierung - Horizontale Dilation - Contour-Bounding-Boxes - Mindestgröße-Filter - [ ] Ergebnis visuell mit Python-Server-Output vergleichen (gleiche Zeilen erkannt?) ## Akzeptanzkriterien - [ ] Für ein Test-Foto werden dieselben (oder mehr) Zeilen erkannt wie auf dem Server - [ ] Laufzeit der Segmentierung < 500 ms auf Pixel 8 Pro

admin-mrrm added this to the v0.5 — On-Device OCR + Infra milestone

2026-04-26 09:11:35 +02:00

admin-mrrm referenced this issue

2026-04-26 09:11:54 +02:00

feat(mobile): On-Device OCR-Pipeline zusammenführen + Server-Fallback #82

admin-mrrm added the

app/einkaufslisten

area/mobile

type/feature

labels

2026-04-26 22:59:17 +02:00

admin-mrrm referenced this issue

2026-05-18 08:20:25 +02:00

[Bug] OCR: Zeilensegmentierung teilt einzelne handschriftliche Zeilen in zwei Einträge #325

admin-mrrm referenced this issue

2026-05-18 08:20:26 +02:00

feat(ocr): Vorschau erkannter Zeilen-Boxen mit manueller Korrektur (Split/Merge/Ignore) #327

pm-bot referenced this issue

2026-05-25 22:30:22 +02:00

chore(mobile): On-Device OCR Benchmarking & Qualitätsmessung #83

pm-bot referenced this issue

2026-05-27 22:48:21 +02:00

spike(ocr): TrOCR → ONNX Export & Machbarkeitsnachweis auf Android #77

pm-bot referenced this issue

2026-05-28 06:21:56 +02:00

arch-q: OCR-Integration v0.5 — Bundling, Sync-Modell, Modellwahl, Server-Fallback #413

arch-bot referenced this issue

2026-05-28 06:30:16 +02:00

arch-q: OCR-Integration v0.5 — Bundling, Sync-Modell, Modellwahl, Server-Fallback #413

pm-bot referenced this issue

2026-05-28 06:35:43 +02:00

spike(ocr): TrOCR → ONNX Export & Machbarkeitsnachweis auf Android #77

pm-bot referenced this issue

2026-05-28 06:36:46 +02:00

spike(mobile): CRAFT-Line-Detection on-device — ONNX-Export + RN-Integration #414

pm-bot commented

2026-05-28 06:36:59 +02:00

Collaborator

Story-Split (per Arch-Konsultation #413 + Fact-Sheet #77):\n\n- Pre-req: Neu eröffneter Spike #414 — CRAFT-Line-Detection on-device (ONNX-Export + RN-Integration, analog #77).\n- Dieses Issue (#81): Bleibt offen, blockiert by #414. Scope nach #414-Done: TrOCR-Eingabe-Crops aus CRAFT-Bounding-Boxes erzeugen + Preprocessing-Pipeline (Deskew, Resize, Normalize) auf Mobile bauen.\n\nServer-OCR (apps/ocr/app/ocr.py) hat CRAFT bereits — Mobile braucht das Äquivalent für den Offline-Pfad.

Story-Split (per Arch-Konsultation #413 + Fact-Sheet #77):\n\n- **Pre-req:** Neu eröffneter Spike #414 — CRAFT-Line-Detection on-device (ONNX-Export + RN-Integration, analog #77).\n- **Dieses Issue (#81):** Bleibt offen, blockiert by #414. Scope nach #414-Done: TrOCR-Eingabe-Crops aus CRAFT-Bounding-Boxes erzeugen + Preprocessing-Pipeline (Deskew, Resize, Normalize) auf Mobile bauen.\n\nServer-OCR (`apps/ocr/app/ocr.py`) hat CRAFT bereits — Mobile braucht das Äquivalent für den Offline-Pfad.

pm-bot referenced this issue

2026-05-28 06:48:27 +02:00

Portfolio-Status KW 2026-W22 #412

pm-bot commented

2026-05-28 12:22:53 +02:00

Collaborator

Closed — v0.5-OCR pivotet weg von On-Device

Privacy-Klarstellung des Stakeholders: Eigener Server = trusted compute zone für nicht-sensible Daten (Einkaufszettel zählen dazu). Damit fällt der zentrale Argumentations-Treiber für On-Device-OCR weg.

Was übrig bliebe für On-Device:

Offline-Fähigkeit: Nice-to-have, aber nicht workflow-blockierend
Latency: 449 ms vs. ~2 s Server-Roundtrip — nicht das Problem
Kosten: 76 MB Bundle (TrOCR allein, ohne CRAFT)

→ Kosten/Nutzen rechtfertigt On-Device-Pipeline nicht.

Was stattdessen passiert: v0.5-OCR-Hauptdeliverable wird #415 Fuzzy-Match server-side. Roh-OCR-Qualität (Server CER 0.67, TrOCR 0.51 — siehe #416) wird über Sortiments-Lookup für den User nutzbar gemacht.

Spike-Investitionen nicht verloren: #77-Code (ORT-RN-Integration, KV-cache-Decode, Asset-Bundling) bleibt im Repo als Reference für ein hypothetisches künftiges On-Device-Comeback.

## Closed — v0.5-OCR pivotet weg von On-Device **Privacy-Klarstellung des Stakeholders:** Eigener Server = trusted compute zone für nicht-sensible Daten (Einkaufszettel zählen dazu). Damit fällt der zentrale Argumentations-Treiber für On-Device-OCR weg. **Was übrig bliebe für On-Device:** - Offline-Fähigkeit: Nice-to-have, aber nicht workflow-blockierend - Latency: 449 ms vs. ~2 s Server-Roundtrip — nicht das Problem - Kosten: 76 MB Bundle (TrOCR allein, ohne CRAFT) → Kosten/Nutzen rechtfertigt On-Device-Pipeline nicht. **Was stattdessen passiert:** v0.5-OCR-Hauptdeliverable wird #415 Fuzzy-Match server-side. Roh-OCR-Qualität (Server CER 0.67, TrOCR 0.51 — siehe #416) wird über Sortiments-Lookup für den User nutzbar gemacht. **Spike-Investitionen nicht verloren:** #77-Code (ORT-RN-Integration, KV-cache-Decode, Asset-Bundling) bleibt im Repo als Reference für ein hypothetisches künftiges On-Device-Comeback.

pm-bot closed this issue

2026-05-28 12:22:55 +02:00

pm-bot referenced this issue

2026-05-28 12:23:31 +02:00

spike(ocr): TrOCR → ONNX Export & Machbarkeitsnachweis auf Android #77

pm-bot referenced this issue

2026-05-28 12:23:56 +02:00

feat(api): Fuzzy-Match in parseItems gegen Geschäfts-Sortiment-DB #415