DEV Community: DeepLab

Make any scan searchable - locally, no Python, no Ghostscript, no upload

Alexander Pervushen — Mon, 27 Jul 2026 14:24:58 +0000

I had a folder full of scanned PDFs - old contracts, receipts, a couple of books - and none of them were searchable. No Ctrl-F, no copy-paste, just pictures of text. I wanted to fix that. I did not want to upload any of it to a website, and I really did not want to spend an evening installing a toolchain to do it.

That turns out to be a surprisingly awkward corner.

The two usual answers, and what each one costs

OCRmyPDF is the tool everyone points you to, and deservedly - it's excellent, mature, does PDF/A, handles dozens of languages. But "just install it" means Python plus Tesseract plus Ghostscript plus unpaper plus pikepdf. On Windows especially that's a bad afternoon. And Ghostscript is AGPL - a copyleft dependency I'd rather not build a product on top of. Great tool; the install is the tax.

Online OCR sites are the easy path - until you look at what you're uploading. A passport. A signed contract. A medical scan. A tax form. "Drag your sensitive document onto our server" is exactly the thing you shouldn't do with the documents that most need OCR. Ads, limits, watermarks are the least of it.

The third option most people pick is nothing - they just live with PDFs they can't search.

None of these answered the thing I actually wanted: make this scan searchable, on my machine, with one command.

So I built it. It's called DeepOCR.

What it does

$ deepocr scan.pdf -o scan.ocr.pdf
scan.pdf   1 of 1 page(s)   9 words   → scan.ocr.pdf

It takes a scanned PDF (or an image), recognizes the text, and writes a new PDF where the original page image is untouched and an invisible, selectable text layer sits on top, positioned word by word. Open it in any viewer and Ctrl-F just works. The original file is never modified - the result is a separate .ocr.pdf, the same way a good tool should never overwrite your input.

It's a single static Rust binary. No Python, no Tesseract, no Ghostscript. The OCR engine is ocrs - pure Rust - and the recognition model ships inside the release binary, so it runs completely offline. Nothing touches the network, nothing leaves the machine.

A few flags cover the real cases:

deepocr scan.pdf --sidecar           # also drop the recognized text as a .txt
deepocr book.pdf --deskew --rotate auto   # straighten and orient before OCR
deepocr ./scans --recursive -o out/  # a whole folder, tree mirrored
deepocr contract.pdf --optimize      # recompress the page images in the output

Batch skips pages that already have a text layer instead of double-OCR'ing them:

scans/a.pdf  → out/a.ocr.pdf   (12 pages)
scans/c.pdf  ↷ already has text (skipped; use --force)
✓ 2 processed, 1 skipped

The privacy part, said plainly

This is the reason I care about it being local. The documents that most need OCR are the ones you least want to upload: IDs, contracts, financial records, anything medical. DeepOCR never sends them anywhere - the model is on your disk, the work happens in-process, and there's no account, no queue, no "we don't store your files, promise." Because the model is embedded, it works air-gapped, on a machine with the network cable pulled.

Honest about the edges

I'd rather undersell than oversell, so: v0.1 is Latin script only (that's the current limit of the ocrs model), and it produces a normal searchable PDF, not strict archival PDF/A. Other scripts (CJK, more languages via other backends) and PDF/A are on the roadmap behind a backend abstraction that's already in place - but they are not in v0.1, and I'd rather tell you that up front than have you find out on a Cyrillic scan.

Where it fits: the DeepLab loop

DeepOCR is part of a small set of local-first, dependency-light tools I'm building under DeepLab, and it closes a nice loop with its sibling DeepDoc (any document → clean Markdown for RAG). DeepDoc handles born-digital documents - real embedded text - and honestly refuses a scan instead of inventing content. DeepOCR is what turns that scan into something born-digital:

deepocr scan.pdf -o scan.ocr.pdf   # add the text layer
deepdoc scan.ocr.pdf               # now it extracts like any other document
# ### HELLO WORLD
# make scans searchable
# DeepOCR reads Latin text

Same OCR core under both, so an ingestion pipeline can route a text-layerless scan through DeepOCR and back into DeepDoc without a cloud step anywhere in the chain.

Try it

brew install deeplabua/tap/deepocr
# or
cargo install deepocr

It's open source (MIT / Apache), pure Rust, and the whole dependency graph is permissive - no AGPL, no C -sys crates. Repo: https://github.com/deeplabua/deepocr · landing page with all the install options: https://deeplab.tools/products/deepocr/

If you've been living with unsearchable scans, or fighting the OCRmyPDF install, I'd love for you to try it and tell me where it falls short - especially which language or script you'd want next.

Part of DeepLab - small, local-first, dependency-light Rust tools. See also DeepDoc (documents → Markdown) and DeepShrink (fit any video under a size limit).

Parsing documents for air-gapped RAG: no cloud, no JVM, no Python

Alexander Pervushen — Sat, 25 Jul 2026 10:38:45 +0000

I kept running into the same unglamorous wall.

Every time I built something on top of an LLM — a search-over-docs feature, a RAG pipeline, an internal assistant — the first step was the same boring problem: "here's a folder of docx, pdf and pptx files, give me clean text." Not a hard problem. Just one that, somehow, every available tool solved by making me pay a price I didn't want to pay.

And in my case there was an extra constraint that quietly kills half the options: the documents couldn't leave the machine.

The three usual answers, and what each one costs

If you've done document ingestion, you know the shortlist.

Apache Tika is the honest default. It's been the de-facto standard for 15 years, it reads hundreds of formats, and it works. It's also a JVM. That means standing up a JVM, feeding it, watching it, and carrying it around inside every container — which feels deeply out of place in a Rust or Go service. Tika is great. The JVM tax is the part people are trying to get away from.

The Python stacks — unstructured, Docling, MarkItDown — are powerful and popular in every RAG tutorial. But "just parse a document" turns into pip, native wheels, and downloading ML model weights before you get a single line of text. They're heavier and slower to cold-start than the job needs for clean, born-digital files, and the ML paths aren't deterministic. Overkill when the document already has real text in it.

Cloud parsers like LlamaParse are the easiest to start with — until you read the two lines of fine print. You upload your documents to someone else's server, and you pay per page. For anyone in a bank, a hospital, a law firm, or any air-gapped environment, "upload the private documents" is where the conversation ends.

None of them answered the thing I actually wanted: any document → clean Markdown, one binary, on my machine, deterministically.

So I wrote it. It's called DeepDoc.

What I actually wanted

A single static Rust binary. No JVM, no Python, no model downloads, no runtime dependencies at all. Copy it into a scratch Docker layer and go. Nothing touches the network, nothing shells out. Same input, same output, every time — because a RAG index you can't reproduce is a bug waiting to happen.

Here's the whole thing on a real file:

$ deepdoc report.docx

# Q3 Engineering Report

Prepared by the Platform team. This memo covers delivery and headcount for the third quarter.

## Delivery

We shipped the ingestion rewrite and cut p95 latency by 38%.

The nightly batch now runs in under nine minutes.

## Headcount

| Team     | Engineers | Open roles |
| -------- | --------- | ---------- |
| Platform | 9         | 2          |
| Search   | 6         | 1          |
| Data     | 4         | 0          |

That's a Word document — headings, paragraphs, and a real table — coming out as clean Markdown, table intact, in one command. No server, no upload, no warm-up.

How it works (it's boring on purpose)

Every format gets parsed into one neutral Document model — headings, paragraphs, lists, tables, metadata, page markers. Then that model is serialized to Markdown, JSON or plain text by pure functions. That's the whole design, and the boringness is the point: the parser for .docx and the parser for .pptx disagree about almost everything, but once they're in the same shape, "turn this into Markdown" is one code path, tested once.

v0.1 covers the born-digital formats I actually hit in ingestion work: docx, pptx, xlsx, odt, ods, odp, epub, html, rtf, csv, md, txt, and text-based pdf — thirteen formats in one binary. Point it at a folder and it walks the tree in parallel and mirrors the structure:

$ deepdoc ./docs --recursive -o out/
./docs/changelog.txt    → out/changelog.md
./docs/meeting-notes.md → out/meeting-notes.md
./docs/report.docx      → out/report.md
✓ 3 extracted, 0 skipped

The part that matters for RAG: chunking that keeps context

Naive chunkers split on character count and throw away structure. So a chunk about "refunds" stops knowing it lived under Billing → Refunds, and you've thrown away the exact breadcrumb your embedding could have used.

DeepDoc parses structure first, then chunks on block boundaries while carrying the heading path and the byte range for every chunk:

$ deepdoc handbook.pdf --chunk 800 --format json | jq

{
  "chunks": [
    {
      "byte_range": [0, 483],
      "heading_path": ["Employee Handbook"],
      "source": "handbook.pdf",
      "text": "# Employee Handbook\n\n## Remote Work\n\nEmployees may work remotely up to three days per week..."
    },
    { "…": "1 more chunk" }
  ],
  "meta": { "source_format": "pdf", "page_count": 1, "…": "…" }
}

Every chunk knows which section it came from and where in the source it lives. That heading_path goes straight onto the vector as metadata, and the byte_range means you can always trace a retrieved chunk back to the exact offset in the original file.

The honest boundary

I'll be upfront about what DeepDoc is not, because overselling a dev tool is how you lose the people you're trying to reach.

v0.1 is born-digital documents — files with real embedded text. It is not an OCR engine and not a complex-table-from-scans reconstructor. That's genuinely hard, it's ML territory, and tools like Docling and Marker do it well. If you hand DeepDoc a scanned PDF that's really just images, it detects that and exits with a specific code (4) telling you so — instead of confidently emitting garbage into your index. OCR is planned as an optional, feature-gated path later; it is deliberately not bundled into the tiny default binary.

The bet is simple: roughly 80% of the documents in a real ingestion pipeline are born-digital, and for those you don't need a GPU or a model download. You need something fast, deterministic, and local. That's the lane.

It's also a library

The CLI is a thin wrapper. The real entry point is the deepdoc-core crate, so you can embed extraction directly in a Rust service — no subprocess, no FFI, no shelling out:

use deepdoc_core::{extract, to_markdown};

let doc = extract("handbook.pdf")?;
let md  = to_markdown(&doc);

The closest thing in the ecosystem, extractous, is actually Tika under GraalVM native-image — not pure Rust, and not a small binary. DeepDoc is Rust top to bottom, and every dependency in the graph is permissively licensed on purpose, so nothing stops you from wrapping it in whatever you're building.

Try it

brew install deeplabua/tap/deepdoc
# or
cargo install deepdoc

It's open source (MIT / Apache), v0.1, and on GitHub: https://github.com/deeplabua/deepdoc

If you're building document ingestion for a local or compliance-bound RAG system, I'd genuinely love your feedback — especially on which formats or edge cases to prioritize next. And if you've been fighting the JVM/Python/cloud trade-off yourself, tell me what you ended up doing; I want to know if I missed a better option.

DeepDoc is part of a small set of local-first, dependency-light tools I'm building under DeepLab — same idea as DeepShrink, which fits any video under a size limit from one command. Small, honest, no cloud.

Fit any video under the limit: meet DeepShrink, a one-command media compressor

Alexander Pervushen — Tue, 21 Jul 2026 08:40:51 +0000

You have a 300 MB screen recording. Discord wants it under 8 MB. Your email won't take more than 20. So you either google "compress video to 8mb" and land on an ad-riddled web converter that uploads your file to someone else's server and stamps a watermark on it — or you open HandBrake and start guessing at CRF values — or you hand-write an ffmpeg command, recompute the bitrate for the fifth time this month, and forget the audio track again.

None of those answer the actual question: "make this ≤ N MB, without me thinking about it."

That's the whole reason DeepShrink exists.

deepshrink gameplay.mp4 --for discord

  gameplay.mp4   1920x1080  2m14s   312.4 MB
  target         Discord (8 MB)
  plan           H.264 · 456 kbps video · 96 kbps audio · two-pass
  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓  100%   pass 2/2

  ✓ gameplay.shrink.mp4   7.6 MB   (−97.6%)   VMAF 91.2

One command. Local. No upload, no watermark, no guessing. And when you say --target 8MB, the result is guaranteed ≤ 8 MB — not "roughly."

What it actually is

DeepShrink is a small, open-source CLI written in Rust. It doesn't reinvent encoding — it drives ffmpeg for you and does the one thing ffmpeg makes annoying: hitting an exact output size.

Under the hood it probes the file with ffprobe, works out the bitrate budget for your target size (with a little headroom for container overhead), runs a two-pass H.264/H.265 encode for video or picks the right codec bitrate for audio (AAC / Opus / MP3), and can optionally hold a quality floor with VMAF so it never over-compresses. You don't touch any of that. You say how big, it figures out how.

The design goals, in order:

One obvious command solves 80% of cases. deepshrink video.mp4 --target 8MB.
Presets instead of flags. You shouldn't need to know what a bitrate is.
Never wreck the original. Output is a new file (video.shrink.mp4); the source is untouched unless you explicitly pass --overwrite.
Local and private. Your file never leaves your machine.

Scope today is video and audio — one engine, ffmpeg. Images, PDFs, and other formats are a deliberate future step, not a half-baked afterthought.

Installing with Homebrew (recommended on macOS)

This is the frictionless path, and it's the one I'd reach for first:

brew install deeplabua/tap/deepshrink

That's it. Because the formula declares depends_on "ffmpeg", Homebrew pulls ffmpeg in as a dependency automatically — so there are zero manual runtime steps. Install, and it works.

If you'd rather tap first and install by short name (handy if you'll install other tools from the same tap later):

brew tap deeplabua/tap
brew install deepshrink

Verify it landed:

deepshrink --version
deepshrink --help

Updating later is just brew upgrade deepshrink.

Installing with cargo (from crates.io)

If you already live in the Rust toolchain, DeepShrink is on crates.io:

cargo install deepshrink

This compiles from source, so it's slower than the prebuilt Homebrew bottle and you need a Rust toolchain installed. Worth knowing about one difference from the brew path: cargo install does not bring ffmpeg along. DeepShrink expects ffmpeg and ffprobe to be on your PATH, and if they aren't, it exits cleanly (code 3) with a hint rather than crashing.

So on a fresh machine, install ffmpeg alongside it:

# macOS
brew install ffmpeg

# Debian / Ubuntu
sudo apt install ffmpeg

# Windows (Scoop)
scoop install ffmpeg

Then the same check as before:

deepshrink --version

brew vs cargo, quickly

	`brew install deeplabua/tap/deepshrink`	`cargo install deepshrink`
Speed	Prebuilt bottle, instant	Compiles from source
Rust toolchain needed	No	Yes
ffmpeg	Pulled in automatically	You install it yourself
Best for	Most people, especially macOS	Rust devs who already have the toolchain

Prebuilt binaries for macOS, Linux, and Windows are also attached to every GitHub release if you'd rather not use a package manager at all.

Using it

The headline command — fit a file under an absolute size:

deepshrink big.mp4 --target 8MB
deepshrink talk.wav --target 500KB

Don't want to memorize platform limits? Use a destination preset and DeepShrink applies the right cap:

deepshrink clip.mp4 --for discord        # 8 MB
deepshrink clip.mp4 --for email          # 20 MB
deepshrink clip.mp4 --for telegram       # only recompresses for quality

Built-in presets today: discord, discord-nitro, email, telegram, whatsapp, and web.

Prefer a relative cut instead of a hard ceiling?

deepshrink video.mp4 --reduce 70%        # 70% smaller than the source

Audio is a first-class citizen, not an afterthought — great for podcasts, voice memos, and lectures:

deepshrink lecture.wav --target 10MB

  lecture.wav     stereo 48kHz   58m02s   638.1 MB (PCM)
  target          10 MB
  plan            Opus · ~22 kbps · mono (speech)
  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓  100%

  ✓ lecture.shrink.opus   9.4 MB   (−98.5%)

Got a whole folder? Batch it — DeepShrink walks the directory, skips files that are already small or unsupported, and prints a summary instead of dying on the first hiccup:

deepshrink ./recordings --recursive

A few flags worth knowing:

--dry-run — show the plan (chosen bitrate, expected size) without encoding a thing.
--vmaf <n> — hold a quality floor; it won't compress below the VMAF score you ask for.
--codec h265 — smaller files at the same quality, when you don't need maximum compatibility.
--json — machine-readable output, for scripts and CI.
--overwrite — replace the original in place (written atomically via a temp file, so an interrupted run won't corrupt your source).

Why bother, over a web converter?

Because DeepShrink is the intersection people actually want: the precision and privacy of native ffmpeg with the simplicity of a web converter — and none of the downsides of either. Your file stays on your disk. You get an exact size, not an approximation. There are no watermarks, no queues, and no "upload your file to continue." It's one static binary that works offline.

Get it

Homebrew: brew install deeplabua/tap/deepshrink
cargo: cargo install deepshrink
Source & releases: github.com/deeplabua/deepshrink

It's open source and free. If it saves you a trip to a sketchy converter even once, consider dropping a ⭐ on the repo — that's what keeps small tools like this alive.

Try it on that 300 MB file you've been avoiding. --target 8MB. Done.