Soviet Cookbook Text Extraction: The Plan
Phase 1 of the soviet.recipes project is done: every page of the cookbook is now captured as a set of 224 high-resolution DSLR images. Now I'm planning how to turn those images into machine-readable text.
1. The Challenge: Converting 224 Soviet Cookbook Images into Text
I have a full photographic capture of The Book of Tasty and Healthy Food: 224 high-resolution images totaling around 191 MB. Now I need to convert them into machine-readable text to enable search, translation, data extraction, and downstream analysis.
The source material has several complexities:
- Cyrillic text throughout
- Aged paper and inconsistent contrast
- Mixed content types: recipes, captions, decorated headings, illustrations
- Non-uniform typography and complex layouts
- Photography artifacts such as glare, shadow, and noise
- Curved text caused by page folds and book curvature
These issues mean simple OCR may not be enough. I need to evaluate a range of modern and traditional methods to find what delivers the best balance of quality and effort.
2. Candidate Approaches for Text Extraction
Five approaches, from manual LLM extraction to fully automated API pipelines. The quality column is my expectation going in, not a measured result. Section 3 is how I'll replace those guesses with real scores.
| Approach | Effort estimate | Cost | Expected quality | Main risk |
|---|---|---|---|---|
| Manual extraction with multimodal LLMs | ~19 hrs | $0–50 | High | Slow, error-prone, not reproducible |
| Docling document pipeline | 6–12 hrs | $0 | Medium–High | OCR alone may not suffice |
| Local vision-enabled LLM (Qwen3-VL) | 8–14 hrs | $0 | Medium | Hardware limits, variable Cyrillic support |
| Traditional OCR (Tesseract, EasyOCR) | 12–25 hrs | $0 | Medium–Low | Heavy preprocessing, weak layout handling |
| Batch against SOTA API models | 8–14 hrs | $20–100 | High | Ongoing cost, rate limits, vendor lock-in |
The manual estimate is the only one I can ground with math: roughly 5 minutes per image to upload, wait, copy, paste, and check, times 224 images, is about 19 hours. The automated ranges are dominated by setup and tuning rather than per-image work, so treat them as rough.
Manual extraction with multimodal LLMs. Upload images one at a time to a commercial multimodal model (ChatGPT, Claude, Gemini, Grok) and copy the text out by hand. Highest expected quality, but it doesn't scale and can't be rerun.
Docling document pipeline. Use the Docling framework to convert images to structured text. It wraps multiple OCR engines, so raw OCR quality is still a risk, but it adds something direct OCR doesn't: reading-order processing. In the example below, the red arrows show the reading direction. It follows natural human reading order rather than the line-by-line behavior of simpler engines.
Local vision-enabled LLM (Qwen3-VL or similar). Run a vision model locally via Ollama or llama.cpp and batch every image through a script. Docling can also drive a vision-language model, so I may be able to reuse its pipeline and swap the model underneath.
Traditional OCR (Tesseract, EasyOCR). Build a preprocessing chain (deskew, denoise, dewarp) feeding a classic OCR engine. Most reproducible of the lot, but weak on layout and sensitive to image quality, so it needs the most tuning.
Batch against SOTA API models. The same local batch harness, but each image goes to a commercial OCR-capable API (OpenAI, Anthropic, xAI). The Docling pipeline could point here too, swapping the local model for an API endpoint. Best expected quality, at an ongoing per-image cost.
3. How I'll Judge the Winner
The quality column above is a guess until I test it. To replace guesses with scores, I'll run each approach against the same pages and grade the output the same way.
I'll start with a random sample of 5–10 pages as a quick filter, then expand anything that survives to 20–30 pages. The sample is weighted toward the hard cases: curved text from folds, low-contrast aged pages, illustrated and captioned layouts, and dense recipe pages with mixed typography.
For each page I score four things: character-level accuracy on the Cyrillic, completeness (is any text missing), layout and structure (are headings, recipes, and captions kept distinct), and reading order (sensible sequence or scrambled). Where a tool reports its own confidence (Docling and the traditional OCR engines do; some models return token probabilities), I'll log that next to my manual scores to catch systematic weak spots. It all goes in one spreadsheet so the approaches sit side by side.
4. Order of Experimentation
I'll go lowest-effort-first, adjusted for cost and expected quality, so I get something usable quickly before sinking time into the heavier options:
- Docling: zero cost, quick to install, purpose-built for documents. The most attractive starting point.
- Local vision LLM: free and similar setup to the API path, but weaker and hardware-bound.
- SOTA API models: best expected accuracy, at a per-image cost.
- Traditional OCR: reproducible but preprocessing-heavy. A fallback if the above disappoint on Cyrillic.
- Manual LLM upload: the quality baseline, and the last resort on effort.
5. Implementation Strategy and Workflow Reusability
A major benefit of this approach order is that the batch-processing harness I build early on will support every method that follows.
5.1 Shared Batch Workflow Architecture
The core workflow (iterate → process → save → retry on failure) stays identical regardless of engine.
5.2 Orchestration
For now a simple Python script is enough. If the pipeline grows, a lightweight orchestrator like Prefect or LangGraph would handle retries and state. Apache Airflow would be overkill at this scale.
6. What’s Next: The Execution Plan
Before building the full workflow, I’ll run quick validation tests:
- Docling Sample Run on 5–10 images
- SOTA LLM Spot Check using ChatGPT or Claude
- Edge Case Testing on the hardest pages (dark pages, curved text, unusual layouts)
If Docling shows promise, I’ll build the batch-processing harness on top of it. If not, I’ll pivot to local LLMs or API-based extraction.
The first two experiments from this plan are written up:
- Testing Docling OCR on a Soviet Cookbook: the Docling proof-of-concept on sample pages.
- Wrapping Docling in a Reusable Text Extraction Pipeline: the batch harness built around it.
See the soviet.recipes project page and the soviet-recipes-project tag for everything related.