{"slug": "you-really-can-scan-a-book-quickly-with-high-res-video-and-no-special-hardware", "title": "You Really Can Scan a Book Quickly With High-Res Video and No Special Hardware", "summary": "A developer demonstrated that a 400-page bound book can be digitized in about 30 minutes by shooting 4K video of pages being turned on an iPhone, then processing it with a Python command-line tool built with Claude Code that uses RapidOCR and Claude to produce a single Markdown file. The tool detects held pages via low-motion frames, saves the three sharpest stills per page, and cuts out figures, with processing taking a couple of hours on a desktop; raising capture from 1080p to 4K lifted mean OCR line confidence from 0.94 to 0.98 and cut illegible words from 17 per thousand to about one.", "body_md": "# You Really Can Scan a Book Quickly With High-Res Video and No Special Hardware\n\nYes, you can scan an old, bound book by simply shooting a high-resolution video of yourself turning its pages, then doing some post-processing with OCR and AI to digitize it: one Markdown text file of all the content, with the photographs captured, deskewed and linked. It doesn’t require any special hardware.\n\nI do have the source code, written with Claude Code, that does all of this. You could probably make the same project by giving this article as a prompt. I’m not trying to add to the half-baked code repos we’re all seeing on Hacker News and other sites.\n\nI didn’t expect this to actually work. It doesn’t need a big specialized book scanner; it uses the iPhone in my pocket. It seems like the minimum time I need to spend with an old book in my possession to digitize it, without making it a 40-hour project or cutting the binding.\n\nUsing video to scan and OCR a book does have issues:\n\n- Set the resolution to 4K and make sure you have good lighting.\n- You don’t get immediate feedback if you blocked a page with your hand or had some other problem.\n- You are not guaranteed a flat scanning surface, so page skew and page curl must be dealt with.\n- Several stills can be taken of each page, then compared and processed when problems are found.\n- An AI model can combine the stills of the same page and find a consensus.\n\nIt took about 30 minutes to scan a 400-page book, pausing for a second or so between pages. The pause is also the trigger for the processing to take a still of the page for OCR. Processing took a couple of hours on a desktop: local OCR first, then Claude merging the reads of each page.\n\nFor the rest of this, I’ll have Claude add the technical details.\n\n## The process, in four stages\n\nIt is a small Python command-line tool. Give it one or more video clips and it writes a folder for\nthe run: the stills it pulled, the OCR of each, the cut-out figures, and `book.md` at the end. Each\nstage caches its work, so a crash or a change to one stage only reruns that stage.\n\n### 1. Finding the held moments\n\nThe video is read once. Each frame is shrunk to 480 pixels wide and converted to grey before Python sees it, because decoding 4K in OpenCV is slow. Two numbers are kept per frame: motion (mean difference from the previous frame) and sharpness (variance of the Laplacian). A run of low-motion frames means a page is being held still. The three sharpest frames of each run are saved as full-resolution stills.\n\nSo the pause between pages is the trigger. There is no button. Hold the page for a second and it gets captured. Flick past it and it doesn’t.\n\nEach clip can be rotated differently, depending on how the phone was held for that take. The tool OCRs a sharp frame all four ways round and keeps whichever reads best.\n\n### 2. Local OCR\n\nEach still goes through RapidOCR (the PP-OCR models on onnxruntime, CPU only). The lines come back with boxes and a confidence score. Then they have to be put in reading order. The gutter is found as the dark shadow between the pages, the lines on each page are clustered into columns by their left edge, and paragraph breaks come from vertical gaps.\n\nResolution matters more than anything else here. At 1080p the body type is about 8 pixels high and the OCR misreads a lot of it. At 4K it is about 16 pixels and mean line confidence went from 0.94 to 0.98. On the first test book that was the difference between 17 illegible words per thousand and about one. iPhones record 1080p unless you change it under Settings > Camera > Record Video.\n\n### 3. Cutting out the figures\n\nA photograph on a page is a large block that is dark or halftone-textured where paper would be blank. The OCR line boxes are blanked out first so a column of text can’t be mistaken for one. The four corners come from the convex hull, the figure is deskewed with a perspective warp, saved as its own JPEG and linked from the transcript ahead of its caption. A second pass looks for line drawings and maps, which are mostly white, by keeping long straight dark strokes and the closed rectangles they form.\n\nThis is the most fragile stage. On a typescript with no pictures at all it found 31 “figures”, all wrong: typed text blocks, bleed-through from a thin sheet, and in one case a shoe. There is a flag to skip it.\n\n### 4. Merging the reads with Claude\n\nThe same page is usually held still more than once, and each still has its own problems: blur, a hand, curl near the binding, a reflection. Consecutive stills are grouped into one page when their OCR text matches. A looser check, based on shared three-word runs, lets a hand-covered read of a page join the clean read of that page.\n\nFor each page, Claude gets the best still from each held moment (left and right page crops), the\nraw OCR text of each, and a system prompt: transcribe every word, use the other photos where one is\nunclear, join hyphenated line breaks, write `[illegible]` for a word unreadable in every photo, and\nnever invent text. The output is the page as Markdown.\n\nThe call goes through the `claude` command-line tool in headless mode, with only the Read tool\nallowed so the model can open the image files. That means it runs on the Claude subscription rather\nthan a metered API key. Two models split the work. Sonnet handles a page whose OCR reads agree with\neach other. Opus gets a page whose reads disagree, which is where the photos are poor and there is\nactual work to do. About a third of the pages of the test book went to Opus. A page takes around\n30 seconds either way.\n\n## Knowing what you missed\n\nWhat you give up with video is feedback. With a flatbed you see each page as it comes. Here you find\nout two hours later. So the tool reads the printed page numbers back out of the transcription and\nprints a report: pages with illegible words, numbers that never turned up, numbers that turned up\ntwice. A missing page gets a `*[page 357 not captured]*` marker in the body text where it belongs.\n\nA missing page was usually held, just not quite still enough. So a rescue pass goes back to the video for whatever the first pass got wrong. For a missing page it searches the frames between the pages on either side with the motion limit loosened. For a page with illegible words it pulls up to six more frames from the time that page was on screen and merges the page again with more photos. Each round only costs the problem pages.\n\nWhatever is still wrong after that was not in the footage. For those, a short second video of just the problem pages, or a handful of photos, goes through the same pipeline and the pages are merged into place by number. For the last few dozen illegible words the tool listed each one with the sentence around it, to be filled in by hand against the book.\n\n## How the 400-page book went\n\n| Video | four clips, 34 minutes in total, mostly 4K at 24 fps | \n| Stills pulled | about 3,200 | \n| Pages in the transcript | 414 | \n| Words | about 139,000 | \n| Illegible words after the first pass | 232, about 1.7 per thousand | \n| After the rescue pass, a short re-shoot and eight photos | a few dozen, answered by hand | \n| Figures | none; it was a typescript, so the figures stage was skipped | \n\nFrame analysis and OCR took under an hour for all four clips on a 16-core desktop. The Claude merge is the slow part, at half a minute a page.\n\n## Advice for trying it\n\n- **Shoot 4K.** It is the biggest improvement available and it costs nothing.\n- **Light from beside or behind the camera.** The illegible words on the first test book were almost\nall on a page that curled toward a window and reflected it. Nothing downstream can recover a\nreflection.\n- **Hold each page a full second** , or rest the phone on something. The held moments are what the\ntool keys on.\n- **Hold the page by its margin.** A hand over the text in every still of a page is gone for good. A\nhand in one of three is fine.\n- **Film in clips of fifty pages or so.** A mistake then costs one clip. The clips are given to the\ntool in order as one book.\n- **Keep the video.** It is the source. The processing can be redone anywhere, with a better OCR\nmodel or a better prompt, long after the book has gone back on the shelf.", "url": "https://wpnews.pro/news/you-really-can-scan-a-book-quickly-with-high-res-video-and-no-special-hardware", "canonical_source": "https://orner.com/posts/scan-book-with-video/", "published_at": "2026-10-13 00:00:00+00:00", "updated_at": "2026-10-15 18:56:30.088225+00:00", "lang": "en", "topics": ["ai-tools", "computer-vision", "generative-ai", "ai-products"], "entities": ["Claude Code", "RapidOCR", "OpenCV", "iPhone", "Hacker News", "Python"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/you-really-can-scan-a-book-quickly-with-high-res-video-and-no-special-hardware", "markdown": "https://wpnews.pro/news/you-really-can-scan-a-book-quickly-with-high-res-video-and-no-special-hardware.md", "text": "https://wpnews.pro/news/you-really-can-scan-a-book-quickly-with-high-res-video-and-no-special-hardware.txt", "jsonld": "https://wpnews.pro/news/you-really-can-scan-a-book-quickly-with-high-res-video-and-no-special-hardware.jsonld"}}