Oh… Hmm… when it comes to OCR, words like “hell” and “nightmare” somehow feel appropriate:
My direct answer would be: I would not treat this primarily as a “find one OCR model” problem, and I would not start by training a model.
What you described appears to contain several separate tasks:
- locating the best available source scan;
- detecting and cropping the physical page;
- correcting yellow or uneven backgrounds;
- distinguishing shadows, page curvature, folds, stains, and bleed-through;
- preserving small text, line art, screenshots, and halftones;
- optionally adding an OCR text layer;
- preparing a cover for printing, including trim and bleed.
The closest public general-purpose model I found is DocRes. It supports appearance, dewarping, deshadowing, deblurring, binarization, and end2end restoration.
However, even DocRes expects you to select the task. It does not automatically determine whether a dark area is a scan border, a shadow, a stain, bleed-through, or missing content.
The default route I would try
- Find the least-processed, highest-quality source available.
- Keep that source unchanged.
- Use simple page detection, crop, and deskew before restoration models.
- Apply one restoration operation at a time.
- Keep OCR, visual restoration, and print preparation as separate outputs.
- Handle the cover and bleed only after the trim-size artwork is stable.
- Train something only if the remaining failure is repeated and well-defined.
A small first comparison could be:
| Variant |
Processing |
| A |
Untouched source |
| B |
Page detection and crop only |
| C |
B + deskew |
| D |
C + light background normalization |
| E |
D + DocRes appearance |
| F |
Only where needed: deshadowing or dewarping |
| G |
Cover restoration and bleed as a separate workflow |
I would test this on only a few representative pages:
- a normal body-text page;
- a strongly yellow or uneven page;
- a page with a dark edge;
- a page with a suspected bend, fold, or shadow;
- a page with color artwork or halftones;
- a sparse title page;
- the front or back cover.
The most useful starting material would be one untouched full-resolution page and one untouched full-resolution cover. A screenshot or viewer export may already include resizing, compression, crop decisions, annotations, or a black viewer background, so it is difficult to identify the real defect from that alone.
Quick routing guide
| What is visible |
First route to try |
| Black area outside the paper |
Page detection and crop |
| Straight text, but one edge is dark |
Shadow or illumination correction |
| Curved text lines or rules |
Dewarping |
| Uniform yellow cast |
Color/background normalization |
| Faint mirrored text from the reverse side |
Bleed-through handling |
| Irregular local brown or black marks |
Stain/damage restoration |
| Moiré or visible print dots |
Descreening test |
| Missing exterior cover artwork |
Prepress extension, then constrained outpainting only if necessary |
A better OCR result, a cleaner-looking page, and a more faithful printable reproduction are three different claims. I would evaluate them separately.
1. Why this is several different problems rather than one OCR task
OCR is often used as a label for the whole document-processing pipeline, but recognition is only one stage.
The OCR-D workflow guide separates document processing into operations such as:
- image enhancement;
- binarization;
- cropping;
- deskewing;
- dewarping;
- region and line segmentation;
- recognition;
- post-correction;
- evaluation.
Not every page needs every stage.
The Tesseract image-quality guide similarly treats borders, skew, resolution, character thickness, and page segmentation as separate variables. It specifically notes that dark scan borders may be interpreted as characters.
That gives a useful first decision tree:
If the dark region is outside the physical sheet:
crop or mask it.
If the text remains straight but brightness changes:
test illumination correction or deshadowing.
If the text lines and rules are curved:
test dewarping.
If the mark is irregular and local:
investigate stains or physical damage.
If faint reverse-side text is visible:
treat it as bleed-through.
If the page contains halftone artwork:
do not process it as ordinary text-only noise.
Similar appearances can have different causes
| Observation |
Possible cause |
Useful first check |
| Solid black band beside the page |
Scanner bed, viewer background, export padding |
Inspect the original image dimensions and page boundary |
| Smooth dark gradient near the gutter |
Illumination or page-edge shadow |
Check whether text baselines remain straight |
| Curved text and horizontal rules |
Physical page curvature |
Compare multiple lines across the page |
| Yellow cast across every page |
Scanner/profile shift or paper color |
Compare several pages and neutral regions |
| Yellowing that changes across one page |
Uneven illumination, shadow, aging, curvature |
Inspect the direction and smoothness of the gradient |
| Faint mirrored letters behind the text |
Bleed-through/show-through |
Compare with the reverse side |
| Irregular brown or black patches |
Stains or physical damage |
Inspect at 100–200% |
| Periodic dots or colored waves |
Halftone/scanner interference |
Compare raw and descreened scans |
The point is not that all these branches require different neural networks. Several may be solved more safely by crop, masking, local normalization, or manual correction.
2. Source quality, raw scans, and separate output copies
Before trying to reconstruct a poor scan, I would first check whether a better scan of the exact same manual already exists.
Some preservation projects provide several versions of one item:
- untouched raw scans;
- cleaned or leveled images;
- descreened images;
- ordinary PDFs;
- searchable PDFs;
- heavily compressed derivatives.
For example, this Gradius manual archive item distinguishes raw scans from processed JPEG and PDF derivatives. A Super Jinsei Game 2 archive item similarly provides high-resolution raw PNG files and processed outputs.
This matters because the most convenient PDF is not necessarily the best restoration source.
A derivative may already have been:
- resized;
- descreened;
- auto-leveled;
- compressed;
- converted to another color space;
- partially binarized;
- rasterized more than once.
For Internet Archive books, the BookReader documentation explains that raw images, cropped or deskewed JPEG 2000 files, scandata.xml, and browser-rendered page images can be separate resources.
Other archives may use different pipelines, but the general principle remains useful:
Prefer the least-processed source, not merely the file that looks largest in a PDF viewer.
A useful source-selection order is:
- exact game title;
- region and language;
- catalog or product code;
- revision or edition;
- raw or “untouched” scan;
- processed full-resolution image;
- lossless or lightly compressed derivative;
- searchable PDF;
- viewer screenshot only as a last resort.
Keep separate output copies
I would keep at least these copies:
| Copy |
Purpose |
| Original/master |
Untouched source for comparison and rollback |
| Restored/access copy |
Visually cleaned version for human reading |
| OCR working copy |
Stronger processing allowed for recognition |
| Print/prepress copy |
Physical dimensions, color preparation, trim, and bleed |
The FADGI digitization guidelines distinguish master files from processed access derivatives.
Those guidelines are intended for cultural-heritage programs, so they do not have to be treated as mandatory rules for a personal collection. The practical idea is simply to preserve the version that still contains the original evidence.
OCRmyPDF provides a similar implementation-level distinction:
--clean modifies the image used for OCR but not the final visible page;--clean-final inserts the cleaned page into the final output.
Its documentation warns that cleanup and background removal can remove desirable content or create visual artifacts, and recommends visually reviewing the output.
This separation is particularly useful here because an OCR-optimized page may be too aggressively processed for faithful reprinting.
3. Processing branches and relevant projects
Page boundary, black borders, crop, and deskew
For page splitting, content boxes, margins, crop, and deskew, a non-generative tool such as ScanTailor Advanced is a useful baseline.
Its purpose is to turn raw scans into pages suitable for document assembly or printing. OCR and generative content reconstruction are deliberately outside its scope.
That makes it useful for answering a basic question:
Does this page actually require a restoration model, or is most of the problem page detection and crop?
An older OCRmyPDF issue about black scan edges shows a similar visible problem. It involved specific historical versions and settings, so it should not be treated as evidence that the same tool or cause applies here. It is simply a useful example of the class of problem.
Automatic cleanup should also be tested on sparse pages. One unpaper issue reports a case where processing that behaved reasonably on text-heavy pages removed part of a nearly empty high-resolution page.
That is one report rather than a universal limitation, but it suggests including title pages and nearly blank pages in the test set.
General appearance and yellow backgrounds
For a flat page with mostly correct geometry, DocRes appearance is a reasonable learned baseline.
I would compare it with light deterministic background normalization rather than assume that stronger restoration is automatically better.
“Yellow” could represent:
- the original paper color;
- aging;
- scanner white-balance error;
- uneven illumination;
- edge shadow;
- bleed-through;
- a previous JPEG or PDF conversion.
A nearby research problem is descanning.
The DESCAN-18K dataset contains 18,360 paired real scanned/original images and explicitly includes mixed effects such as:
- color distortion;
- bleed-through;
- halftone changes;
- surface or paper texture;
- scanner noise.
This is unusually relevant to scanned manuals because it includes text, layouts, and graphics.
Its limitation is equally important: the target is the original digital page before printing and scanning. That may not be the same as a faithful restoration of an aged physical manual.
I would therefore treat descanning as:
- a useful search term;
- a useful dataset-design example;
- a possible model family;
but not as proof that one descanning model will produce the desired aesthetic or archival target.
Shadow versus page curvature
A useful distinction is:
Straight text + changing brightness:
likely illumination or shadow.
Curved text or rules:
likely geometry.
Dark region outside the paper:
likely page boundary or crop.
For shadow-specific comparison, DocShadow-SD7K provides a large-scale high-resolution document-shadow dataset, code, and model.
It is designed to remove document shadows while retaining high-frequency text and edge detail.
It is not intended as a general solution for:
- scanner-bed borders;
- viewer backgrounds;
- stains;
- bleed-through;
- printed dark artwork.
For geometry, DocTr separates geometric unwarping and illumination correction. DocTr++ extends document rectification to less constrained inputs.
These are useful when the content itself is geometrically distorted. They are unnecessary if the text remains straight and the problem is only illumination.
Stains and localized physical damage
If the marks are actual stains, StainRestorer and the StainDoc dataset are more directly relevant than a general OCR or dewarping model.
However, “dark mark” is not automatically “stain.”
| Appearance |
More likely first route |
| Solid region outside page |
Crop/page mask |
| Smooth edge gradient |
Deshadowing |
| Irregular localized patch |
Stain restoration |
| Mirrored text pattern |
Bleed-through handling |
| Thin fold line |
Conservative local correction |
| Missing content |
Verified replacement from another source, or tightly constrained repair |
For local repair, risk depends on where the defect is:
- empty paper background: relatively low risk;
- line art or halftone: moderate risk;
- text, logos, or legal/copyright lines: high risk.
A visually plausible generated replacement is not evidence that it matches the original print.
Bleed-through and show-through
If text from the reverse side is visible, ordinary whitening may remove both the unwanted reverse-side signal and legitimate faint foreground printing.
If scans of both sides exist, comparing recto and verso is useful.
A Marker issue about bleed-through OCR provides a practical example where OCR output that initially looked nonexistent corresponded to faint reverse-side printing.
That does not establish a general Marker failure. It illustrates a useful QA rule:
If OCR returns text that is not obvious in the foreground, check the raw image for bleed-through before treating it as a language-model hallucination.
Higher resolution may reveal more desired foreground ink and more undesired reverse-side ink. More pixels do not automatically separate them.
4. Text, graphics, halftones, and covers should not share one pipeline
A typical game manual may contain:
- ordinary body text;
- screenshots;
- sprites or pixel art;
- line drawings;
- maps;
- tables;
- halftone photographs;
- colored headings;
- logos;
- very small copyright text;
- cover artwork.
These content types react differently to cleanup.
Text-heavy pages
A conservative text-page route would be:
- detect and crop the page;
- deskew if needed;
- apply light local background normalization;
- create a separate OCR working copy;
- keep the print/restored copy less aggressively processed.
Graphics and halftones
Descreening can reduce moiré, but may also soften:
- small glyphs;
- thin rules;
- pixel-art edges;
- line art;
- halftone structure.
A scanner manufacturer’s descreening documentation, for example, explicitly notes a sharpness trade-off.
The specific settings are scanner-dependent, so one manufacturer’s values should not be copied blindly. The useful general test is:
A. raw scan
B. scanner-side descreening
C. post-processing descreening
Compare all three at:
- 100% view;
- 200% control crops;
- intended physical print size.
LayeredDoc offers a useful architectural idea: separate coarse graphic information from machine-printed text before restoration.
That does not demonstrate that LayeredDoc is the best model for retro manuals. It supports the broader design principle that text and graphics may require different processing.
A possible conceptual split is:
Text:
local background normalization
OCR-oriented contrast
conservative sharpening
Graphics and halftones:
color preservation
moiré control
conservative denoising
Cover:
separate color and prepress workflow
Covers
The cover should not be passed through a body-text binarization pipeline.
Cover priorities include:
- correct physical dimensions;
- color fidelity;
- logos and small text;
- front/back/spine alignment;
- trim box;
- bleed box;
- safe area;
- halftone behavior in print.
5. Cover bleed and print preparation
Bleed is not an OCR task.
Adobe defines bleed as artwork extending beyond the crop or trim boundary so that cutting variation does not leave an unintended white edge.
The printer or print service should determine the required dimensions and marks.
The order I would use is:
- Restore the intended trim-size cover.
- Confirm physical width and height.
- If it is a wraparound cover, confirm front, back, spine, and fold geometry.
- Obtain the printer’s bleed and safe-area specification.
- Extend only the area outside the trim box.
- Keep original text and logos inside the trim area unchanged.
- Produce a physical proof before processing the full collection.
For simple backgrounds, I would try these in order:
- solid-color extension;
- gradient continuation;
- edge replication;
- mirrored padding;
- content-aware or manual extension;
- constrained outpainting only when simpler extension is insufficient.
If generative outpainting is needed, protect the original trim region with a mask.
The Diffusers outpainting guide demonstrates the general idea of extending the canvas while preserving the original image region.
A particularly safe pattern is:
1. Create the exterior extension.
2. Keep or restore the original trim-size image unchanged.
3. Composite the original image back over the generated result.
4. Use only the generated exterior as bleed.
The important distinction is:
Bleed is primarily a trim and prepress geometry requirement. It becomes an image-generation problem only when exterior artwork cannot be extended safely by deterministic methods.
6. A small validation matrix
I would avoid evaluating the entire pipeline with one score.
Representative pages
| Page type |
Why include it |
| Ordinary dense text |
Main production case |
| Strong yellow or uneven background |
Appearance stress case |
| Dark edge or gutter |
Crop-versus-shadow branch |
| Curved or creased page |
Geometry/damage branch |
| Color or halftone page |
Detail-preservation stress case |
| Sparse title page |
Auto-crop failure case |
| Cover |
Separate color/prepress case |
Processing variants
| ID |
Operation |
| A |
Original |
| B |
Crop/page mask |
| C |
B + deskew |
| D |
C + light background normalization |
| E |
D + DocRes appearance |
| F |
D + shadow-specific model, where appropriate |
| G |
D + dewarping, where appropriate |
| H |
Limited local repair away from text |
| I |
Cover-only bleed preparation |
Fixed control regions
Inspect the same areas in every result:
- smallest printed text;
I, l, and 1;- punctuation;
- page numbers;
- dot leaders;
- thin rules;
- copyright text;
- logo edges;
- pale colors;
- halftone dots;
- screenshot or sprite edges;
- text adjacent to shadows or stains.
Separate evaluation claims
| Claim |
Evidence |
| OCR improved |
CER/WER, especially names, numbers, and commands |
| Crop improved |
Correct page boundary with no content loss |
| Geometry improved |
Straighter baselines without stretching |
| Background improved |
More uniform background without deleting pale content |
| Graphics survived |
Stable line art, colors, and halftones |
| Restoration is faithful |
No newly invented or changed characters |
| Print is usable |
Correct physical dimensions, trim, bleed, and proof |
| Workflow is practical |
Acceptable time, compute, and manual correction |
The OCR-D quality-assurance documentation is helpful because it separates text accuracy from layout and reading-order quality.
OCR can also be used as a control rather than the final goal:
- compare recognition before and after processing;
- inspect where OCR confidence decreases;
- verify game-specific names and numbers manually;
- overlay OCR boxes on the source;
- do not allow language-model correction to silently alter proper nouns or codes.
7. If training or fine-tuning eventually becomes necessary
Being able to create training and validation examples is valuable, but I would first identify the repeated residual problem.
The initial question is not “how many examples?” It is:
What exact transformation should the model learn?
Possible targets include:
- faithful aged-paper scan;
- easier-to-read restored page;
- OCR-optimized page;
- white-background reprint;
- reconstruction of the original digital design;
- print-ready cover with bleed.
Those targets are not interchangeable.
Separate targets by operation
| Task |
Target or annotation |
| Appearance correction |
Paired input and color-corrected target |
| Shadow removal |
Shadow/shadow-free pair |
| Dewarping |
Correct geometry or backward deformation map |
| Page extraction |
Page mask or crop coordinates |
| Stain removal |
Stained/clean pair, preferably with a stain mask |
| Bleed-through |
Clean foreground, or recto/verso information |
| Cover bleed |
Supervision outside the trim box |
| OCR |
Verified text and preferably layout regions |
I would avoid a single “clean” target that simultaneously changes:
- crop;
- geometry;
- paper color;
- contrast;
- shadow;
- stains;
- sharpness;
- text appearance;
- exterior cover artwork.
If everything changes at once, it becomes difficult to determine what the model learned or which operation caused a failure.
Split by source rather than only random patches
Useful hold-out groups include:
- complete manual or game title;
- scanner model;
- archive source;
- edition or region;
- page-content class;
- physical copy.
The DESCAN-18K dataset evaluates on scanner models not seen during training.
That does not prescribe the only correct split here, but it demonstrates the value of testing whether a model learned the restoration task rather than one scanner profile.
I would consider training only after finding a repeatable residual problem, for example:
- one recurring scanner color cast across hundreds of pages;
- one stable gutter-shadow pattern;
- one consistent paper/background domain;
- one repeated class of stains;
- one defined exterior-cover extension task.
If the remaining problems are heterogeneous and occur on only a few pages, manual or rule-based correction may be cheaper and more reliable than building a training set.
8. Failure modes worth checking explicitly
Over-whitening
Background removal may also erase:
- pale gray rules;
- yellow artwork;
- light text;
- dot leaders;
- legitimate background tint;
- halftone detail.
A pure-white background is not automatically a more faithful restoration.
Descreening and denoising
These may remove moiré while softening:
- small glyphs;
- line art;
- pixel-art edges;
- copyright text;
- printed dot structure.
Auto-crop and deskew
Test them on:
- sparse pages;
- title pages;
- black artwork touching the edge;
- foldouts;
- irregular page sizes;
- nearly blank pages.
Downsampling
Check the model’s actual internal inference resolution.
A system may accept a large input file but internally resize it enough to lose:
- small text;
- punctuation;
- thin rules;
- halftone structure.
If tiling is used, inspect:
- tile seams;
- inconsistent background brightness;
- clipped or duplicated characters;
- loss of global page geometry.
Generative alterations
Check for:
- invented characters;
- changed punctuation;
- altered logos;
- modified copyright text;
- plausible but false texture;
- edits outside the requested region.
OCRGenBench evaluates generative models across text generation, text editing, and OCR-related image-to-image tasks, including difficult dense-text and document cases.
It does not imply that every generative model will fail on every page. It provides a reason to evaluate text fidelity separately from visual plausibility.
Semantic OCR correction
Language-model post-correction may improve ordinary prose while corrupting:
- game-specific names;
- item names;
- button combinations;
- passwords;
- product codes;
- phone numbers;
- copyright lines.
Keep the raw OCR result and any corrected transcript as separate artifacts.
PDF and export damage
A good restored image can still be degraded by:
- rasterization;
- JPEG recompression;
- PDF/A conversion;
- rescaling;
- color-profile conversion;
- changed page boxes;
- loss of physical-size metadata.
The current OCRmyPDF documentation explicitly warns that image processing and PDF conversion may introduce rasterization or lossy transformations.
Fit-to-window inspection
Some failures disappear when the page is displayed small.
Check:
- 100% view;
- 200% control crops;
- intended physical print size;
- a real proof print.
Practical decision map
If the main problem is a black outside edge:
begin with page detection and crop.
If the page is flat but yellow or uneven:
compare light normalization with DocRes appearance.
If the text baselines are curved:
test dewarping separately.
If the text is straight but the edge is dark:
test deshadowing separately.
If the mark is irregular and local:
investigate stain or damage restoration.
If reverse-side text is visible:
use a bleed-through branch.
If the page contains color art or halftones:
keep it out of a text-only binarization pipeline.
For the cover:
restore to trim size first, then add bleed as a separate prepress step.
My default starting stack would therefore be:
- Source: the raw or least-processed scan;
- Deterministic baseline: ScanTailor Advanced, or equivalent crop/page-mask/deskew processing;
- General learned baseline: DocRes, starting with
appearance rather than automatically using end2end;
- Conditional branches: DocShadow-SD7K, DocTr, or StainRestorer, depending on the observed defect;
- OCR/QA: a separate working copy with page-level controls;
- Cover: trim and bleed preparation after restoration.
One untouched full-resolution body page and one untouched full-resolution cover would already make the first comparison much less speculative.
