tesseract-ocr

An old manual can look readable yet be impossible to search. Tesseract turns page images into text. Useful when you're hunting for one detail in a long scan. The output still needs checking. tesseract-ocr/tesseract

Tesseract OCR: renderer failures used to exit with code 0. Every script downstream believed a failed render had succeeded. Fixed and merged by the lead maintainer. Neovim. curl. Tesseract: three upstream fixes in six days. PR: tesseract#4669

Your Screenshots Have a Memory. So Why Can't You Find Them? This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine. What I Built There is a particular kind of digital ghost that every developer knows. You capture a screenshot of an error you just fixed. Maybe it contains a PostgreSQL query, a useful command, a UI reference, an invoice, or an important piece of documentation. You promise yourself that you'll find it when you need it. A few weeks later, you have hundreds of screenshots scattered across your computer. Their names tell you almost nothing: - Screenshot_20261012_184205.png - Screenshot_20261014_102134.png - Screenshot_20261018_230512.png The information is still there. You just can't find it. For Hacktoberfest's final challenge, Ghost in the Machine, I wanted to build something that brings these forgotten digital memories back to life. That idea became SiftShot. SiftShot is a privacy-first, local-first screenshot management application for Windows. Its central idea is simple: Search screenshots by what they contain, not just by what they're named. Instead of uploading screenshots to a cloud service or manually opening hundreds of files, SiftShot uses locally executed neural LSTM OCR to extract readable text and make screenshot collections searchable. What can SiftShot do? - Recursively discover screenshots in configured directories. - Extract text locally using Tesseract's neural LSTM OCR. - Store screenshot metadata and extracted text in SQLite. - Search screenshots by OCR text and filenames. - Browse screenshots in a modern dashboard. - Preview original images and inspect extracted text. - Avoid unnecessarily reprocessing unchanged files. - Restrict image access to configured directories. Original screenshots are never silently renamed, moved or deleted. SiftShot in action Dashboard overview !SiftShot dashboard The dashboard provides an overview of indexed screenshots, OCR availability, processing statistics and the screenshot collection. Screenshot gallery !SiftShot screenshot gallery Browse discovered screenshots with their filenames, thumbnails, file sizes and OCR status. OCR preview !SiftShot OCR preview Inspect the original image alongside its locally extracted text and filesystem metadata. Search by screenshot contents !SiftShot OCR text search Search for a phrase contained inside an image and retrieve the screenshot without remembering its original filename. Demo Watch the SiftShot walkthrough: ▶ Watch SiftShot on YouTube The 81-second demonstration covers the actual application workflow: 1. Open the SiftShot dashboard. 2. Scan a configured screenshot directory. 3. Browse the discovered screenshots. 4. Open a screenshot and inspect its extracted OCR text. 5. Search for a phrase contained inside an image. 6. Open the matching screenshot preview. The demonstration uses synthetic screenshots processed by the actual local Tesseract installation. There is no mocked frontend data. Code GitHub repository: adarsh-singh106/SiftShot SiftShot uses a modular architecture: SiftShot/ ├── apps/ │ └── desktop/ │ └── React + TypeScript │ ├── engine/ │ └── src/siftshot/ │ ├── domain/ │ ├── config/ │ ├── ingestion/ │ ├── ocr/ │ ├── storage/ │ └── api/ │ ├── docs/ │ ├── ARCHITECTURE.md │ ├── SETUP-GUIDE.md │ ├── DEMO-SCRIPT.md │ └── FINAL-RELEASE-REPORT.md │ └── README.md The repository includes the project architecture, dependency lockfiles, automated tests, setup instructions, security documentation and contribution guidelines. How I Built It I didn't want SiftShot to be another OCR script with a frontend attached. I wanted independent, understandable components that could be tested and maintained. 1. Screenshot discovery The Python ingestion engine recursively scans configured directories using standard filesystem APIs. It handles: - Multiple watch directories. - Overlapping directory paths. - Case-insensitive extension matching. - Duplicate path prevention. - Metadata extraction. - Symbolic-link restrictions. - Missing and inaccessible files. The discovery process does not load entire image files into memory. 2. Local neural LSTM OCR This is the intelligence layer of SiftShot. I chose Tesseract OCR, an open-source OCR engine with an LSTM-based neural recognition architecture. The final implementation explicitly selects the LSTM engine: cmd = [ str(binary), str(target), "stdout", "--oem", "1", ] The engine runs locally through a controlled subprocess invocation. It uses: - Explicit command arguments. - shell=False. - A 10-second default execution timeout. - Structured success and failure results. - Text normalization. - Graceful handling when Tesseract is unavailable. The application does not send screenshot contents to an external OCR API. 3. SQLite persistence Extracted text and screenshot metadata are stored locally using SQLite. The repository layer handles: - Transactional persistence. - Parameterized SQL queries. - Write-Ahead Logging (WAL). - Duplicate path prevention. - Updating changed screenshots. - Reusing OCR results for unchanged files. - Case-insensitive substring search across OCR text and filenames. Image binaries remain ordinary files on the user's filesystem. 4. API and desktop dashboard The backend uses FastAPI and communicates through a loopback-only HTTP service. The frontend uses React, TypeScript and Vite. The dashboard provides: - Screenshot statistics. - Scanning controls. - Screenshot gallery. - OCR status indicators. - Search results. - Full-resolution image previews. - Extracted text inspection. The current release uses a browser-hosted dashboard connected to the local FastAPI service. Native Tauri packaging remains a future milestone. 5. Privacy and security A screenshot can contain much more than a picture. It can contain source code, database information, receipts, personal documents or internal application data. SiftShot therefore follows several safety principles: - Local screenshot processing. - Loopback-only API binding. - Restricted CORS origins. - Canonical path validation. - Protection against path traversal. - No unrestricted image-serving endpoint. - Parameterized database queries. - Subprocess execution without shell commands. - OCR execution timeouts. - No automatic modification of original images. The project has automated security tests, but has not undergone a formal third-party penetration test. 6. Engineering and testing One of the most interesting parts of building SiftShot was its development workflow. I coordinated six AI coding instances: | Instance | Responsibility | |---|---| | 0 | Architecture and integration | | 1 | OCR engine | | 2 | SQLite storage | | 3 | FastAPI and security | | 4 | React frontend | | 5 | Documentation | The five specialist instances worked in isolated Git worktrees and feature branches. Their changes were integrated and reviewed by the engineering lead. The final release verification recorded: - 225 passing backend tests. - Clean Ruff linting. - 49 files passing the formatting check. - No mypy errors across 25 source files. - Successful TypeScript compilation. - Successful Vite production build. - A real Windows OCR and search integration test. - SQLite persistence verified after a backend restart. - SHA-256 confirmation that the synthetic test image remained unchanged. One issue discovered during final Windows verification was UTF-8 BOM handling in TOML configuration files. Some Windows tools save UTF-8 files with a Byte Order Mark, which initially caused configuration parsing failures. I fixed the loader and added a regression test. This was a useful reminder that production-minded software is not just about making the happy path work. It is also about handling the environments in which real users run it. Why Does Open Innovation Matter? This is the most important design decision behind SiftShot. Screenshots often contain information people wouldn't casually upload to an external service. Using a closed, cloud-hosted OCR API would introduce an unnecessary dependency for a problem that can be solved locally. With open-source Tesseract and local inference: Privacy: Screenshots can be processed without sending their contents to an external OCR provider. Offline capability: Once the application, Tesseract and compatible language data are installed, the core processing workflow can run without an internet connection. Transparency: The recognition engine and its invocation are inspectable. Its behavior is not hidden behind an inaccessible hosted service. Cost: There are no per-image cloud inference charges or mandatory API subscriptions. Control: The OCR engine can be replaced or extended without redesigning the entire application. Open innovation gives users more control over their data and software dependencies. There are limitations. OCR accuracy depends on image resolution, typography, language data and hardware. During our LSTM verification, the engine correctly recognized most of a synthetic technical screenshot but confused a few similar-looking characters and punctuation marks. SiftShot currently provides OCR substring search, not semantic vector search or visual reasoning. I deliberately chose an open-source neural OCR engine that solves the actual problem rather than adding a generative model simply to call the project an AI application. The Spirit of It A screenshot is often a tiny record of a moment. A bug we solved. A command we needed. A design that inspired us. A receipt we might need months later. But when those fragments disappear into folders, their usefulness disappears with them. The idea behind SiftShot is to give those forgotten fragments an afterlife. The machine already has the memories. We just needed to make them searchable. SiftShot: Capture less chaos. Find anything. Thank you to everyone building, maintaining and contributing to open-source software this Hacktoberfest.

Some handwriting only a neural net could love. Tesseract OCR turns stubborn notebooks into text you can actually search—just proofread the important stuff. tesseract-ocr/tesseract t.co

Choose a parser before feeding PDFs to AI | 6 open-source choices Bad parsing can ruin good AI answers. Six options, with different use cases and adoption checks. Docling, PaddleOCR, olmOCR, Tesseract, EasyOCR, Unstructured. Explore the original cards: channel profile → AI Open Source Radar → Collections. Choose the collection for this task and inspect the project cards. useaistation.com Sources checked 23 Oct 2026. This is a project-selection guide, not hands-on testing or a live ranking. These are different choices, not a verified integrated stack. Software licenses, model weights, hardware and external service costs must be checked separately. Community/core and enterprise features may differ. Developer disclosure: we build AI Open Source Radar, not the featured projects. Narration: Microsoft free Aria neural voice. Project and License sources (observed branch references, subject to change): Docling: docling-project/docling License: raw.githubusercontent.com PaddleOCR: PaddlePaddle/PaddleOCR License: raw.githubusercontent.com olmOCR: allenai/olmocr License: raw.githubusercontent.com Tesseract: tesseract-ocr/tesseract License: raw.githubusercontent.com EasyOCR: JaidedAI/EasyOCR License: raw.githubusercontent.com Unstructured: Unstructured-IO/unstructured License: raw.githubusercontent.com #OpenSource #AITools #DocumentAI

圖片文字不用重打？Tesseract 開源文字辨識｜GitHub 開源快報 #Shorts Tesseract 是 OCR 引擎和命令列，不附 GUI，可搭語言 traineddata 輸入 PNG/JPEG/TIFF 等影像並輸出文字／可搜尋 PDF；不是直接讀 PDF 輸入或自動重建原版面。影像歪斜、噪點、解析度與語言影響準確度，手寫和表格不保證，需要人工複查。本片只有軟體介紹，不安裝或處理使用者私密文件。API Apache-2.0，依賴另有授權。README：tesseract-ocr/tesseract 專案：tesseract-ocr/tesseract 資料核對：2026-10-13 GitHub API 與專案 README。星數為當日快照。 畫面含 AI 生成的情境示意圖；GitHub 頁面為實際截圖。旁白為 AI 語音。 訂閱「辰星說Github」，每天兩支，用白話認識開源工具。 #Shorts #GitHub #開源

HacktoberFest Week 2 Challenge LocalLedger AI: A Private Invoice and Receipt Organizer for Freelancers LocalLedger AI: A Private Invoice and Receipt Organizer for Freelancers This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle. What I Built LocalLedger AI is a privacy-first invoice and receipt organizer built for freelancers, consultants, and independent workers. Managing invoices and receipts manually can become frustrating. Financial documents end up scattered across folders, searching for a particular expense takes time, and preparing monthly summaries involves repetitive work. Uploading these documents to cloud-based AI services can also raise privacy concerns. I built LocalLedger AI to make this workflow simpler while keeping documents on the user's computer. Here’s what it does: - Smart data extraction: Extracts vendor names, invoice numbers, dates, currency, subtotal, tax, total, and payment status from invoices and receipts. - Human-reviewed results: Flags missing, ambiguous, or inconsistent fields so users can verify and correct the extracted information. - Duplicate detection: Identifies exact duplicates using file hashes and flags possible duplicates using document details. - Local document organization: Organizes original documents into folders while avoiding filename collisions. - Expense insights: Generates monthly and vendor-wise summaries with CSV export. The potential customers are freelancers and small independent businesses that want less manual bookkeeping without depending on cloud AI services. A paid desktop edition could be a future direction, although I haven't validated pricing or paying customers yet. Demo There isn't a hosted demo or video walkthrough available yet. LocalLedger AI is designed to run on the user's own computer rather than requiring a hosted service. To run it locally: 1. Install Ollama and Tesseract OCR. 2. Download the Qwen2.5 model: ollama pull qwen2.5:3b-instruct 3. Install the Python dependencies: pip install -r requirements.txt 4. Start the application: streamlit run app.py After the required software and model are installed, document processing can run offline. The application also indicates whether Ollama and the selected model are available. Code Check out the source code and implementation here: LocalLedger AI — GitHub Repository Contributions and suggestions for improving local document processing, extraction accuracy, and privacy are welcome! How I Built It I wanted to build around open-source tools and a locally running model instead of depending on a proprietary, cloud-hosted AI API. Here's the technology stack: - Python: Core application logic and document-processing pipeline. - Streamlit: User interface for importing documents, reviewing extracted fields, and exploring expense summaries. - Qwen2.5 Instruct (3B): Open-weight language model used for structured invoice and receipt data extraction. - Ollama: Runs the model locally and provides the interface for local inference. - PyMuPDF: Extracts text from text-based PDF documents. - Tesseract OCR: Extracts text from scanned PDFs and image-based receipts. - SQLite: Stores document metadata and extracted information locally. - Pandas and Plotly: Support data analysis, monthly summaries, and vendor-wise visualizations. - Python hashlib: Generates SHA-256 hashes for exact duplicate detection. The workflow is straightforward: a user imports a document, the application extracts its text, and the local model identifies relevant financial fields. The returned JSON is validated before the results are saved to SQLite. An important design decision was to treat AI-generated results as suggestions rather than unquestionable facts. Missing or uncertain values are flagged for human review. Original files are retained, filenames are made collision-safe, and documents remain available for review even if a model request fails. Why Does Open Innovation Matter? Financial documents can contain sensitive information, including client names, addresses, invoice details, and transaction amounts. Sending this information to an external AI service isn't always desirable, especially for freelancers handling client data. Open-source tooling and local inference make a different approach possible. With LocalLedger AI, users can run the model on their own machines, inspect the processing pipeline, and keep document content within their local workflow. After the initial setup, they can process documents offline without depending on a hosted inference API or paying per-request API charges. Open innovation also gives developers the freedom to experiment with different models, improve extraction and validation, and adapt the application to their own workflows without being locked into a single proprietary AI provider. Of course, local AI has trade-offs. Performance depends on available hardware, OCR quality varies between documents, and model outputs still need verification. That's why human review is an important part of this project rather than an afterthought. For me, this project was an opportunity to explore how open-weight AI can solve a practical problem while keeping privacy at the center of the design. My Agent Session Optional section — add this if you have a saved DevRelay agent session. I used this project to explore an open-source AI workflow for a practical, privacy-focused application. If a shareable DevRelay session becomes available, I'll link it here. Prize Categories Open-Source AI Challenge — Week 2: Side Hustle No partner-specific prize category claimed. The project uses the open-source and locally runnable tools described above. --- Built with Python, local AI, and a focus on keeping financial documents private. Hacktoberfest #Hacktoberfest2026 #BuildForAFriend #OpenSource #DSA #DevTools #JavaScript #NodeJS #WebDevelopment

Letter Decoder: Your AI Friend for Scary Official Letters (Runs 100% Offline) This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle What I Built Letter Decoder — a local-first, open-source app that reads your official letters and explains them in plain language. Tax notices. Fines. Insurance rejections. Bank letters. Landlord warnings. Drop one in as a photo, PDF, screenshot, or pasted text, and get back an answer card: - ✅ A one-line verdict ("you owe X by Y — act soon") - ⏳ A deadline countdown with a .ics calendar export - 🔴 A severity rating - 📋 Three concrete next steps - 📄 A document checklist - ✍️ An editable draft reply Every date and amount links back to the exact line of the original letter it came from. If the model can't verify a claim against the extracted facts, it says so — no confident hallucinations. Who would pay for this? Anyone who has ever frozen looking at a government envelope, hired a solicitor at £150/hour just to be told "this is a routine payment reminder", or simply had a letter in their second language. The realistic addressable market is anyone who receives official correspondence — which is everyone. The letter never leaves your device. No accounts, no cloud, no telemetry. That's the product differentiator and the privacy guarantee rolled into one. --- Demo | | URL | Notes | |---|---|---| | Frontend | letter-decoder.vercel.app | React 19 app, deployed on Vercel | | Public API | letter-decoder-api-qvxs.onrender.com | FastAPI — runs in ENGINE_MODE=mock, replays 14 canonical examples through the full SSE pipeline with realistic delays | > For real decoding with a local model, clone the repo and run with Ollama (see below). The public endpoint intentionally uses mock mode so no real letters are ever uploaded to a server. --- Code {% embed RAMBO-LC/letter-decoder %} Quick start with a real model: # Terminal 1 — start the inference server ollama serve ollama pull qwen2.5:7b # Terminal 2 — start the app git clone https://github.com/RAMBO-LC/letter-decoder.git cd letter-decoder uv sync --all-extras uv run python -m api.main Open http://127.0.0.1:8000 — everything runs fully offline from here. --- How I Built It The core design principle is: code finds facts, the model explains them. The Pipeline [Input] → Preprocess → Extract Text → Deterministic Facts → Classify → Notice Pack → LLM Explain → Verify → Answer 1. Preprocess (engine/preprocess.py) — OpenCV deskew and denoise for photos/scans. 2. Extract text (engine/extract_text.py) — native PDF text extraction, falling back to Tesseract OCR. 3. Deterministic extraction (engine/deterministic_extract.py) — regex + dateparser pull every date, amount, and reference number from the raw text. The LLM never sees a blank slate: facts are pre-extracted before it is invoked. 4. Classify (engine/classifier.py) — keyword and embedding matching identifies the notice type and loads the right notice pack (a YAML file per country/type in notices/). 5. LLM Explain (engine/llm_constrained.py) — Ollama runs locally; the default model is Qwen 2.5 7B (fully open weights). JSON-constrained output means the model can only produce the schema the verifier expects. 6. Verify (engine/verifier.py) — every factual claim in the LLM output is checked against the deterministically extracted facts. A fact the model invented that wasn't in the source text fails verification — you get a clean error, not a confident lie. Open-Source AI Stack | Layer | Tool | License | |---|---|---| | Local inference | Ollama | MIT | | Default model | Qwen 2.5 7B | Apache 2.0 | | OCR | Tesseract | Apache 2.0 | | Image processing | OpenCV | Apache 2.0 | | API framework | FastAPI | MIT | | Frontend | React 19 | MIT | Every layer is open source. You can swap qwen2.5:7b for Gemma, Llama, Mistral, or a fine-tuned checkpoint by changing one environment variable. Contributing is Data, Not Code Most contributions to this project are YAML files, not Python PRs. Adding support for a new country is: # notices/fr/tax_reminder.yaml name: "Avis de rappel fiscal" keywords: ["Trésor public", "DGFIP", "avis d'imposition"] severity_default: act_soon mock_simple: "This is a French tax reminder." That's it. CI validates it against the JSON Schema automatically. --- Why Does Open Innovation Matter? A letter contains income, legal status, financial history, and sometimes your immigration situation. Explaining it with a closed API means uploading it. There is no enterprise tier, privacy toggle, or data-processing agreement that un-does the fact that your letter travelled to someone else's data center. With an open local model: - The letter structurally never leaves the machine. This isn't a policy — it's enforced: tests/test_local_only.py fails the CI build if any code path attempts an outbound network call. - Zero marginal cost. A family that gets ten letters a year pays nothing extra after the initial setup. - Auditability. The verifier that proves "the model never invents a deadline" is code you can read, fork, and run yourself. You don't have to trust a vendor's marketing copy. - Swappability. Communities can fine-tune a small model on their country's letter formats — a GDPR-compliant, locally-hosted specialist — without any API negotiation. Open weights made this project's privacy guarantee credible. A closed API could promise the same guarantee; open weights prove it. --- My Agent Session <!-- Save your session with DevRelay and embed it here using the agent_session Liquid tag, or link to it. --> --- Prize Categories - Hacktoberfest Open-Source AI Challenge — Week 2: Side Hustle

ReceiptRecall: My Groceries Got Expensive, So I Gave My Receipts a Memory --- title: "ReceiptRecall: My Groceries Got Expensive, So I Gave My Receipts a Memory" published: true description: "A local-AI receipt scanner: photograph a receipt, let Tesseract + Gemma draft it, correct it, and keep a price history you can actually use. Built around the one honest truth about small models — they draft, you confirm." tags: devchallenge, hf26challenge, ai, opensource cover_image: dev-to-uploads.s3.us-east-2.amazonaws.com canonical_url: --- <!-- BEFORE PUBLISHING — fill these, then delete this comment: 1. Demo: add the video link, and either a live URL or keep the "run it locally" steps. 2. Make the GitHub repo public and verify the link in an incognito window. 3. Upload banners/devto-cover.png as the DEV cover (a private GitHub raw URL won't render). 4. Prize category: keep "Best Use of Gemma" only — it's genuinely used. 5. No tester session yet, so there is no "My First User" section. Add it only after a real trial with permission to quote. --> This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle. Started as: "what did I pay for milk last time?" Ended as: a local-AI pipeline, one production-only crash, a format war with my own iPhone, and a language model confidently inventing a Big Mac that was never on the receipt. What I Built Somewhere between the cashier and my front door, my brain deletes the price of milk. It keeps song lyrics from 2020. That, apparently, is essential infrastructure. The price of soap from last week? Evicted without notice. That gap is ReceiptRecall: a receipt scanner that turns the slip of paper from the till into something useful after you leave the shop. The loop is deliberately small: photograph a receipt → check the extracted draft → confirm → keep a purchase history you can actually use. No barcode-by-barcode scanning. No spreadsheet guilt. It exists to answer ordinary questions without an archaeological dig through my handbag: - What did I pay for this last time? - Did the brand get pricier, or did the packet quietly get smaller? - Is the cheaper-looking option actually cheaper per litre? - What have I spent this month? The review step is the whole point. OCR misreads faded ink; a small model will cheerfully confuse a row total with a unit price. So you get an editable draft before anything is saved. A confident wrong total is still a wrong total — just better dressed. What's shipped: photo upload (including iPhone HEIC), OCR + AI draft, review-and-correct, atomic confirm, and a spending history. Pantry stock and the shopping list are designed and in the schema, but I deferred them to keep the first version honest about what works today. Who would pay for it? My hypothesis: a household that shops regularly and wants a private receipt archive with real price history — paid value in backup, shared access, or a supported self-hosted install. That's a hypothesis to test, not proof of demand. A subscription button can't tell me whether reviewing a scan actually beats typing. Demo <!--Video walkthrough: ADD YOUR ACTUAL VIDEO LINK --> Run it locally (the flow I verified end to end): git clone https://github.com/CynthiaWahome/receipt-recall && cd receipt-recall npm install ollama pull gemma3:1b # local, open-weight, no API key npm run dev # http://localhost:3000 Then: Scan Receipt → upload a photo → Extract with OCR + AI → correct the rows → Confirm → check History. Code ReceiptRecall on GitHub Stack: Next.js 16 + TypeScript, SQLite (better-sqlite3), Tesseract CLI OCR, Gemma 3 1B via Ollama, Zod, sharp. Receipt images live in private storage, never a public folder; money is stored in integer minor units so no float ever rounds my milk into oblivion. How I Built It The architecture separates reading a receipt from trusting it: Photo → OCR text → structured AI draft → human review → confirmed history. Tesseract turns the picture into text. Gemma 3 1B (open weights, run locally through Ollama) organises that text into fields. Gemma is text-only here — nobody is asking a text model to squint at a JPEG and pray. Output is constrained with Zod + Ollama's JSON Schema format, which enforces shape, not truth. Hence the review step. Then reality showed up, in four acts. 1. The scanner that couldn't scan. The OCR and extraction code existed, got merged, then got reverted — because the one thing it depended on, actually uploading a photo, was never built. So the model had nothing to read and looked broken. Lesson I keep re-learning: build the boring plumbing before the clever part. 2. My iPhone declared format war. Every photo is HEIC, and HEIC hides its pixels behind HEVC compression that sharp's bundled libheif can't decode. It read the metadata fine and then failed on the actual image — the most polite kind of failure. Fix: a pure-JS HEIC→JPEG step before sharp, so it works on my laptop and in Docker without system libraries. Bonus trap: newer iPhones shoot 48MP, which blew past my pixel cap. The cap was guarding against decompression bombs, not punishing people for owning a good camera. 3. The crash that only existed in production. Locally, flawless. Built for deploy, every write died with no such table: receipts. The database schema was loaded from a file via __dirname, which the bundler rewrites to a path that doesn't exist in the server output. Inlined the schema; crash gone. A green local run proves exactly nothing about the bundle. 4. Gemma invented a Big Mac. On a real Pandamart receipt — rope, sponge cloth, towels — the model returned four line items all named "Big Mac," mangled the quantities, and filed the discount as a product. This is not a bug to patch away; it's a 1B model being a 1B model. It's also the entire argument for the review screen. The AI drafts; you confirm. I made the draft schema permissive (so one weird field doesn't nuke the whole extraction) and kept the strictness at confirm, where it belongs. The arithmetic stays in plain code, where it's boring and testable: two 1L packets at 260 total = 130/litre; one 500ml packet at 70 = 140/litre. The smaller sticker loses. Money in integer minor units, row totals kept distinct from unit prices, units and currencies never mixed, confirm wrapped in one idempotent transaction so a double-tap can't buy your milk twice. 39 unit tests guard the maths; I verified the upload→OCR→draft path end to end on a synthetic receipt and a 48MP HEIC, plus duplicate-upload and cross-origin rejection. Why Does Open Innovation Matter? A receipt quietly reveals where you shop, when, and what you buy. I wanted to control where that gets processed. With OCR and inference running locally, extraction can stay on my machine after the initial downloads. Host it on a server instead and the photos travel there — so I say it plainly: self-hosted is not the same as "never leaves your phone." The privacy claim has to match the deployment. Open made three things real: 1. Control over processing — local inference instead of a third-party API per receipt. 2. Room to fix the weak link — I can swap OCR engines or models against the same test receipts without rebuilding the product around one vendor's response format. 3. A different cost curve — no per-token billing. Hardware, power and hosting still cost money, so I won't call it free to run. Credit where due: Tesseract is open-source software; Gemma ships open weights under its own model terms. Different licences, both worth reading. Prize Categories - Best Use of Gemma: Gemma 3 1B (open weights, local via Ollama) is the extraction brain — it turns numbered OCR lines into a structured, schema-validated draft, and its honest roughness is exactly why the human-in-the-loop review is the product, not an afterthought.

아 찾았다 테서렉트입니다 말고 할콘도 써보긴 했는데 이건 애초에 개비싼(몇백하는) 비전 전문 유료 라이브러리라 논외 tesseract-ocr/tesseract