Deployments reachable outside a trusted LAN need some form of access
control. Set FUELISH_API_KEY and the server requires a matching
X-API-Key header on /jobs; unset, behavior is unchanged (no auth).
The Android app gets a matching Settings field. This only checks the
key - TLS termination is left to a reverse proxy in front of the
server, not handled here.
Preprocessing now tries progressively heavier variants per receipt
(plain -> high-pass -> edge-enhance -> both), stopping as soon as a
cheap LLM-free arithmetic check on the OCR text looks plausible, so
the extra processing only applies to receipts that need it. A flat
version of the same heavier processing regressed the full batch by
helping hard receipts but hurting easy ones; the adaptive version
improves date-matching 37/52 -> 40/52 with no regression (see
testing/2026_10_04_gimp_highpass_nlfilter_experiment.md).
Also adds test_ocr.sh and test_single.sh for checking a single
receipt's OCR text or full pipeline result without a batch run.
manual CI publishes
- Settings: prefill an editable example server URL, add a "Test
connection" button
- Front page now shows the receipts list (Overview) with a column
header and an empty-state message
- Add a connection status bar (polls /health) shown on every screen
- Capture: add "Choose from gallery" alongside the camera
- Add an in-app "App log" screen; ApiClient/CaptureViewModel/
OverviewViewModel/ConnectionStatusViewModel now log key events,
including the actual connection-failure reason (not just pass/fail)
- .gitea/workflows/build.yml: publish to dl.ladkau.de on a manual
"Run workflow" dispatch too, not just push
- README.md: document the CI secrets (REGISTRY_USER/PASSWORD,
DL_SFTP_KEY) that must be configured in Gitea, separate from the
local registry.env
- build-image/: Dockerfile bundling JDK 17, the Android SDK, and
Node.js (needed by Gitea's JS-based actions) - the app has no
native code, so no NDK
- build-image.sh/upload-image.sh: extended to also build/push this
image alongside the existing OCR pipeline tools image
- run-image.sh: runs `make android` inside the image against a live
checkout, for a CI-equivalent local build
- Makefile: `make android` builds and versions a release APK into
dist/, from the current git tag
- .gitea/workflows/build.yml: now pulls the custom image and just
runs `make android`, replacing the ad-hoc Node/SDK install steps
- README.md: describes the pipeline, server, app, and build tooling
- registry.env.example: fix REGISTRY_IMAGE to be fully-qualified
(an unqualified name was silently resolving pushes to Docker Hub
instead of the configured registry)
Self-hosted, verifiable pipeline for extracting structured data (station,
date/time, price per litre, litres, discount, total) from German fuel
receipt photos: grayscale + mild bilateral filter + contrast stretch,
Tesseract OCR, then LLM structuring via a small local model (Qwen 2.5,
served by Ollama). Each step is independently runnable and inspectable
through numbered scripts against a shared tooling container.
Ollama runs as its own long-lived container (0_run_ollama.sh), separate
from the stateless per-receipt pipeline steps, so the model stays loaded
in memory between runs. Includes a containerized ground-truth batch test
(test_batch.sh) that reproduces the full pipeline over the test receipts
and reports per-field accuracy.
Targets eventual deployment on a Raspberry Pi 4 k3s cluster.
ml
matthias