Batch Processing in ScanTailor Advanced: Set It Once, Process the Whole Book

The Core Pattern: Tune, Apply, Run

Every stage of the pipeline supports the same three moves:

1. Tune on a representative page. Not the first page — a typical one, plus the worst one you know about. Settings that satisfy both will satisfy the book.
2. Propagate with “Apply to…”. The dialog scopes a setting beyond the current page: all pages, this page and the following ones, every other page (respecting even/odd), or a selected set of pages. This is the mechanism behind almost every project-wide decision — orientation, division type, margins, deskew nudges, output settings.
3. Run the stage’s batch button (the play-style arrow on the stage). The stage then processes the remaining pages using their current settings, while you watch thumbnails fill in.

A question mark on a thumbnail means that page has not passed the current stage yet — or no longer has, because an earlier stage changed underneath it. After touching an early stage, expect to re-run the later stages for affected pages; the dependency chain is the price of the pipeline’s consistency, and the batch button is how you pay it quickly.

Multi-Threading: Faster Runs, More Memory

ScanTailor Advanced supports multi-threaded batch processing — inherited from the Universal branch and listed among its headline features. The README’s statement is qualitative and worth quoting in spirit: it significantly increases processing speed, the number of threads can be adjusted while processing is running, and there is an explicit warning attached — more threads require more memory, so avoid configurations that overflow it.

Practical reading of that warning, without inventing numbers you can’t verify on your own machine: each worker thread holds page images in memory, and pages from a 600 DPI book scan are large. If a threaded run starts swapping or stalling, reduce the thread count rather than abandoning the batch — the adjustment can be made mid-run. On a machine that handles it comfortably, leave the threads alone and let the run finish; throughput is an empirical property of your hardware and your scans, so measure it on your first book rather than trusting anyone’s figures.

Keeping a Long Run Honest

Deviation highlighting: your exception report

Batch processing’s risk is a systematic error applied 400 times. The counterweight is the deviation system: pages that disagree with the project are flagged per stage — skew values that stand out at Deskew, content sizes that differ at Select Content, layouts that don’t match at Page Layout — and in ScanTailor Advanced they can be marked in the thumbnail panel (red asterisks) and sorted by decreasing deviation. The efficient QA loop for a big book is: batch a stage, sort by deviation, inspect only the top of the list, fix, re-apply. You review exceptions, not every page.

Default-parameter profiles: consistency across books

If you process many books the same way, the defaults system saves re-tuning: default filter settings can be stored per stage in profiles. The program ships two — “Default” (the standard settings) and “Source” (settings that pass the source through unchanged) — and you can create your own, for example a house standard for margins. New projects then start from your standard instead of the factory one.

Auto-save

Enable the “auto-save project” option in Settings for long projects: the project file saves itself as you work, including during batch processing — provided the project has been saved once manually first. Combined with v1.1.1’s relative project paths, a project folder can also be moved between machines (say, captured on a laptop, processed on a workstation) without relinking every image.

Project Organization That Survives Contact with Reality

• One folder per book, originals untouched. Input folder holds the raw scans; output lands in the out folder the program creates beside it by default. Never process into the input folder — you want to be able to re-run Output with different settings without rescanning, and that only works if the originals are pristine.
• Let the file order be the page order. ScanTailor works through the images in the order the project lists them; consistent zero-padded filenames from the scanner keep that order equal to reading order. Check it at Split Pages, where order mistakes are cheapest to fix.
• Split giant projects by volume, not by chapter. A project holds one book comfortably. Splitting mid-book across projects reintroduces exactly the inconsistency — margins, sizes, thresholds — that the pipeline exists to eliminate. Splitting a multi-volume set at volume boundaries keeps each volume internally consistent.
• Change settings at the stage that owns them. Mid-run discoveries (a mis-split spread, a crooked section) get fixed at their own stage and re-run forward from there, rather than patched at Output where the fix won’t survive the next re-render.

Costs of the batch approach, honestly stated: a wrong setting propagated by Apply To is wrong everywhere at once, and an early-stage edit invalidates later stages for the affected pages. Both are managed by the same discipline — tune on the worst page first, propagate second, inspect the deviation list third.

← Previous: Binarization Next: Scanning DPI Guide →

Frequently Asked Questions

What does “Apply to…” actually apply to?

It propagates the current stage setting beyond the current page. The scopes are: all pages, this page and the following ones, every other page (respecting even/odd), and — when pages are selected in the thumbnails — the selected pages or every other selected page. Not everything is applicable: the split dividing line, for example, is deliberately per-page only.

How many threads should I use for batch processing?

There is no universal number, and the documentation gives the governing rule instead: more threads process faster but use more memory, and the count can be adjusted while a run is in progress. Start with the default, watch memory on your first large book, and lower the count if the machine starts swapping — large 600 DPI pages make each thread expensive.

Do I have to re-run later stages after changing an early one?

For the affected pages, yes. A question mark on a thumbnail marks a page that has not passed the current stage or whose earlier-stage change invalidated it. Re-running is cheap: the stage’s batch button reprocesses everything outstanding with the current settings.