Tutorial · Capture Settings

Scanning DPI Guide for ScanTailor: 300 or 600 DPI, and Why the Number Must Be True

DPI is decided before ScanTailor Advanced ever opens — at the scanner — yet it shapes everything the pipeline does afterwards: how much detail binarization can judge, how large your files get, and whether the finished page is physically the size the real page was. This guide covers the choice, and the metadata trap behind it.

← Previous: Batch Processing Hardware & Capture Guide

The Project’s Own Rule

The ScanTailor project wiki’s scanning guidance is short and unambiguous, and it has survived every branch of the project:

  • Don’t scan at any lower resolution than 300 DPI; typically scan at 300 or 600.
  • Don’t scan in black-and-white mode — use grayscale, or colour if necessary. A scanner’s own “line art” mode throws away greys that the pipeline’s binarization stage needs to make its own, better decision later.
  • Don’t scan to JPEG. It is lossy, and converting afterwards cannot restore what it discarded. TIFF is the typical choice (beware TIFF files that secretly use JPEG compression), with LZW as the lossless compression; PNG is the guaranteed-lossless fallback. Camera users, who usually cannot avoid JPEG, should use the highest resolution and quality settings available.
  • Avoid the scanner’s “document” mode and enhancement options. Raw capture, processed once inside the project, beats capture-time auto-fixes that cannot be undone. (The full capture checklist lives on our hardware page.)

300 vs 600 DPI: the Actual Trade-Off

DPI is a linear measure, which hides the real cost: doubling DPI quadruples the pixel count of the same page — twice as wide and twice as tall. Everything downstream scales with that: file sizes, memory while processing (remember the multi-threading warning in the batch guide), and time per stage. Against that cost, 600 DPI buys detail:

300 DPI is enough when…

…the material is ordinary book text at normal sizes, cleanly printed. This is the standard working resolution for text digitization: text lines are well resolved, binarization has plenty of signal to judge stroke edges, and a whole book stays manageable in size and processing time.

600 DPI earns its cost when…

…the print is small (footnotes, reference works, dense scholarly apparatus), the page carries fine line art or halftones you intend to keep in Mixed mode, the originals are physically small, or the scans are an archival master you may re-derive editions from for years. Fine detail discarded at capture cannot be invented later; detail captured can always be downscaled at output.

Below 300 DPI…

…don’t. At lower resolutions, thin strokes approach the width where threshold decisions become guesses: serifs vanish, punctuation merges with noise, and despeckling cannot tell a full stop from dust — because at that size, there is no difference left to detect. The wiki’s floor is a floor.

One more asymmetry: an over-resolution scan costs disk and time, but an under-resolution scan costs the book. If you are scanning once and may never handle the physical volume again, err toward 600 and derive lighter working copies; if you are churning through modern paperbacks for reading copies, 300 is the rational default.

Source DPI: Why the Number Must Be True

DPI in ScanTailor is not just a quality dial — it is how the program knows the physical size of your pages. Pixel counts alone say nothing about size; pixels divided by DPI is what turns an image into a page of so many millimetres. Page Layout’s margins are physical (millimetres, centimetres, inches), the common page size pages are equalised to is physical, and output resolution is expressed in the same terms. Corrupt the input DPI and the corruption propagates arithmetically into all of it.

Where wrong values come from:

  • Scanner software that writes nominal rather than actual DPI, or files re-saved by an editor that rewrote the metadata. You set the correct values when creating the project — the project setup asks for the source DPI of all pages for exactly this reason.
  • Camera captures have no scanner DPI at all. The project’s guidance for camera images: measure the physical dimensions of the area photographed and divide the pixel dimensions by them to get the effective DPI. A rough measurement beats a confident wrong default.
  • Mixed sources in one project (part flatbed, part camera) can carry different true DPIs per page.

The tell-tale symptom appears at Page Layout: a page whose physical size is absurd next to its siblings. The fix lives there too — v1.2.0 added inline Source DPI fields in the Margins panel, so the value can be inspected and corrected at the stage where its consequences are visible, instead of sending you back to project setup.

Output DPI is a separate decision

Don’t confuse the two numbers. Source DPI describes what you captured; output resolution is set at the Output stage — the default is 600 DPI (300 in some configurations) — and describes the rendered files. Rendering output above the source’s real resolution adds pixels, not information; its legitimate uses are matching a print specification or a uniform archive standard, not sharpening the book.

← Previous: Batch Processing Back to: Getting Started Tutorials Hub

Frequently Asked Questions

Is 300 DPI enough for book scanning?

For ordinary book text, yes — 300 DPI is the project’s standard working resolution and its documented floor. Choose 600 DPI for small print, footnotes, fine line art, physically small originals, or archival masters you will re-derive editions from. Below 300 DPI, thin strokes become indistinguishable from noise and binarization quality collapses.

Why does ScanTailor ask for the source DPI when I create a project?

Because DPI converts pixels into physical size, and physical size drives margins, the common page size at Page Layout, and output. If the DPI metadata is wrong — common with re-saved files and camera photos — page sizes come out wrong too. v1.2.0 added inline Source DPI fields in the Margins panel so the value can be corrected where the symptom appears.

Can I scan to JPEG to save space?

The project wiki says no for scanner output: JPEG is lossy and no conversion restores what it discarded. Scan to TIFF (LZW for lossless compression) or PNG. Camera users who must use JPEG should use the highest resolution and quality settings. Storage is cheaper than rescanning a book you no longer have.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *