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

admin-mrrm commented

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

Owner

Ziel

Alle On-Device-Komponenten zu einer vollständigen OCR-Pipeline zusammenführen und nahtlos in den bestehenden Flow integrieren. Server bleibt als Fallback für iOS und ältere Android-Geräte.

Abhängigkeiten

Setzt #79 (ONNX Build), #80 (Tokenizer) und #81 (Preprocessing) voraus.

Architektur

handleCameraPress(model)
  └─ canRunOnDevice()  ──yes──▶ runOnDeviceOcr(file, model)
       │                              └─ preprocessImage()
       │                              └─ splitLines()
       │                              └─ für jede Zeile:
       │                                   encoder.run(pixelValues)
       │                                   decoder.run(encoderOutput)
       │                                   tokenizer.decode(ids)
       no
       └─▶ uploadToServer(file, model)  [bisheriger Flow]

Aufgaben

OCR-Hook erweitern

useParseShoppingListImage – erkennt automatisch ob On-Device möglich
canRunOnDevice(): boolean – prüft Android + ONNX-Modell vorhanden
runOnDeviceOcr(file, model) – führt die lokale Pipeline aus
Gleiches Rückgabeformat wie Server: { items, preprocessedImage }

Modellauswahl

On-Device: nur Handschrift-Modelle anbieten (kein Druck-Modell bundlen)
Modell-Selector im UI: On-Device-Modelle mit ⚡-Symbol markieren

Fehlerbehandlung

On-Device-Fehler → automatischer Fallback auf Server mit Hinweis an den User
Modell noch nicht geladen → Download-Dialog

Performance

Inferenzzeit pro Zeile und gesamt loggen
Vergleich Server vs. On-Device im Debug-Modus anzeigen

Akzeptanzkriterien

Auf Pixel 8 Pro läuft OCR vollständig ohne Netzwerk
Auf iOS und alten Android-Geräten wird der Server genutzt
Erkennungsqualität ≥ Server (gemessen an 10 Test-Fotos)
Gesamtlaufzeit auf Pixel 8 Pro < 15 s für eine 10-zeilige Liste

## Ziel Alle On-Device-Komponenten zu einer vollständigen OCR-Pipeline zusammenführen und nahtlos in den bestehenden Flow integrieren. Server bleibt als Fallback für iOS und ältere Android-Geräte. ## Abhängigkeiten Setzt #79 (ONNX Build), #80 (Tokenizer) und #81 (Preprocessing) voraus. ## Architektur ``` handleCameraPress(model) └─ canRunOnDevice() ──yes──▶ runOnDeviceOcr(file, model) │ └─ preprocessImage() │ └─ splitLines() │ └─ für jede Zeile: │ encoder.run(pixelValues) │ decoder.run(encoderOutput) │ tokenizer.decode(ids) no └─▶ uploadToServer(file, model) [bisheriger Flow] ``` ## Aufgaben ### OCR-Hook erweitern - [ ] `useParseShoppingListImage` – erkennt automatisch ob On-Device möglich - [ ] `canRunOnDevice(): boolean` – prüft Android + ONNX-Modell vorhanden - [ ] `runOnDeviceOcr(file, model)` – führt die lokale Pipeline aus - [ ] Gleiches Rückgabeformat wie Server: `{ items, preprocessedImage }` ### Modellauswahl - [ ] On-Device: nur Handschrift-Modelle anbieten (kein Druck-Modell bundlen) - [ ] Modell-Selector im UI: On-Device-Modelle mit ⚡-Symbol markieren ### Fehlerbehandlung - [ ] On-Device-Fehler → automatischer Fallback auf Server mit Hinweis an den User - [ ] Modell noch nicht geladen → Download-Dialog ### Performance - [ ] Inferenzzeit pro Zeile und gesamt loggen - [ ] Vergleich Server vs. On-Device im Debug-Modus anzeigen ## Akzeptanzkriterien - [ ] Auf Pixel 8 Pro läuft OCR vollständig ohne Netzwerk - [ ] Auf iOS und alten Android-Geräten wird der Server genutzt - [ ] Erkennungsqualität ≥ Server (gemessen an 10 Test-Fotos) - [ ] Gesamtlaufzeit auf Pixel 8 Pro < 15 s für eine 10-zeilige Liste

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

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

admin-mrrm added the

app/einkaufslisten

area/mobile

type/feature

labels

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

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 referenced this issue

2026-05-28 06:39:38 +02:00

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

pm-bot referenced this issue

2026-05-28 06:39:39 +02:00

feat(mobile): TrOCR-Re-Evaluation auf echten /training_data-Crops #416

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:52 +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:53 +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