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

New issue

Closed

opened 2026-05-28 06:36:46 +02:00 by pm-bot · 1 comment

pm-bot commented

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

Collaborator

Spike-Ziel

Analog zu #77 (TrOCR-on-device): CRAFT-Line-Detection-Modell ONNX-exportiert + int8-quantisiert + via onnxruntime-react-native on-device lauffähig.

Pre-Requisite für #81 (Preprocessing + Zeilensegmentierung on-device). Ohne CRAFT-Port muss Mobile entweder (a) Server-OCR für Line-Detection callen → kein Offline-Pfad, oder (b) heuristisches Tiling → schlechtere Qualität als bestehende Pipeline.

Ausgangslage

Server-Seite hat CRAFT bereits in Produktion: apps/ocr/app/ocr.py (EasyOCR-Bundle inkl. CRAFT)
#77 hat TrOCR-Inference auf Mobile bewiesen (449 ms warm, 76 MB Bundle)
ORT-RN-Integration (Polyfills, Asset-Bundling) ist gelöst

Spike-Definition-of-Done

CRAFT-Weights nach ONNX exportiert (int8-quantisiert wo möglich)
Auf Pixel 8a: Inferenz <500 ms für 1280×1280 Eingabe
Bounding-Boxes bit-identisch (oder ≥95% IoU) zur Server-Pipeline auf 20-Crops-Test-Set
Bundle-Größe + Peak-Memory dokumentiert
Go/No-Go-Entscheidung für #81-Integration

Risiko-Punkte

CRAFT-Postprocessing (Score-Map → Bounding-Boxes) ist CPU-heavy in NumPy/OpenCV — JS-Port nötig oder Native-Module
Bundle-Budget: TrOCR 76 MB + CRAFT ~20 MB → 96 MB OCR-Bundle insgesamt, mobile Acceptance check
Falls No-Go: #81/#82 müssen Online-Only-Pfad akzeptieren oder heuristisches Tiling als Plan B

Referenzen

Parent: #77 (TrOCR-Spike)
Downstream: #81 (Preprocessing-Integration), #82 (Pipeline-Zusammenführung)

## Spike-Ziel Analog zu #77 (TrOCR-on-device): CRAFT-Line-Detection-Modell ONNX-exportiert + int8-quantisiert + via `onnxruntime-react-native` on-device lauffähig. Pre-Requisite für #81 (Preprocessing + Zeilensegmentierung on-device). Ohne CRAFT-Port muss Mobile entweder (a) Server-OCR für Line-Detection callen → kein Offline-Pfad, oder (b) heuristisches Tiling → schlechtere Qualität als bestehende Pipeline. ## Ausgangslage - Server-Seite hat CRAFT bereits in Produktion: `apps/ocr/app/ocr.py` (EasyOCR-Bundle inkl. CRAFT) - #77 hat TrOCR-Inference auf Mobile bewiesen (449 ms warm, 76 MB Bundle) - ORT-RN-Integration (Polyfills, Asset-Bundling) ist gelöst ## Spike-Definition-of-Done - [ ] CRAFT-Weights nach ONNX exportiert (int8-quantisiert wo möglich) - [ ] Auf Pixel 8a: Inferenz <500 ms für 1280×1280 Eingabe - [ ] Bounding-Boxes bit-identisch (oder ≥95% IoU) zur Server-Pipeline auf 20-Crops-Test-Set - [ ] Bundle-Größe + Peak-Memory dokumentiert - [ ] Go/No-Go-Entscheidung für #81-Integration ## Risiko-Punkte - CRAFT-Postprocessing (Score-Map → Bounding-Boxes) ist CPU-heavy in NumPy/OpenCV — JS-Port nötig oder Native-Module - Bundle-Budget: TrOCR 76 MB + CRAFT ~20 MB → 96 MB OCR-Bundle insgesamt, mobile Acceptance check - Falls No-Go: #81/#82 müssen Online-Only-Pfad akzeptieren oder heuristisches Tiling als Plan B ## Referenzen - Parent: #77 (TrOCR-Spike) - Downstream: #81 (Preprocessing-Integration), #82 (Pipeline-Zusammenführung)

pm-bot added the

app/einkaufslisten

area/mobile

type/feature

labels

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

pm-bot referenced this issue

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

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

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:55 +02:00

Author

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:56 +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