Before an extraction pipeline can produce useful output from a scanned government record, the document image has to be in a state where OCR can actually read it. For many documents in a county permit archive, that starting state is not great. The image quality problems are real and they are common: not edge cases that affect a small fraction of the archive, but typical conditions that appear throughout.
This article goes through the main categories of image quality problem, why each one causes specific OCR failures, and what preprocessing approaches address them. This is not a theoretical survey. It describes what we actually encounter in county permit archives and what we do about it.
Low scan resolution
The most common image quality problem in legacy county archives is scan resolution that was adequate for document storage but not for reliable OCR. County batch scanning projects from the 1990s and early 2000s frequently used 150 or 200 DPI, which produces files that are visually legible to a human but present real difficulty for OCR engines at small font sizes.
The threshold at which OCR accuracy degrades meaningfully is approximately 200 DPI for standard printed text in common fonts. Below 200 DPI, characters that differ by only a few pixels in their distinctive features begin to become ambiguous. The digits 1, 4, 7, and 9 are frequently confused. The letters O, 0, D, and Q conflate. In a parcel APN where digits matter precisely, an 8% error rate on individual characters can mean that a double-digit percentage of full APN values are incorrect.
The direct remediation for low-resolution scans is upscaling before OCR, but not simple pixel doubling. Bicubic or bilinear upscaling from 150 to 300 DPI blurs edges and typically makes OCR worse, not better. What works is super-resolution image processing, which reconstructs high-frequency detail from the upsampled image rather than just interpolating. Several open-source and commercial tools provide this capability. The results on 150 DPI input are not as good as a native 300 DPI scan, but they are measurably better than either raw 150 DPI input or naively upsampled input. For a backlog of documents that cannot be rescanned, this is the best available option.
For archives where rescanning is possible, specifying a minimum of 300 DPI (and 400 DPI for documents with significant handwritten content) is a straightforward improvement. The file size increase from 150 to 300 DPI is approximately 4x for grayscale, which may require storage budget review but is the correct tradeoff when the documents will be processed for structured extraction.
Duplex bleed-through
Many government permit forms are printed double-sided. When those forms are scanned on a flatbed scanner or sheet-feed scanner without a black backing, the ink from the reverse side bleeds through as a faint ghost image on the scanned page. For forms with dense printed text on both sides, this bleed-through creates a background noise layer that OCR engines read as additional character marks, producing spurious output mixed in with the real content.
Bleed-through is most damaging when the ghost text appears in or near form fields where the extracted value will be read. A field value of "2847" with bleed-through from the reverse that partially overlaps the "4" may be read as "2847" (correct, if OCR ignores the noise) or as something else depending on how the ghost strokes interact with the character geometry.
The standard preprocessing approach for bleed-through is background subtraction combined with adaptive thresholding. The assumption is that the bleed-through text is lower contrast than the primary content (because it is showing through a page rather than being directly scanned). An adaptive threshold that is set based on local pixel intensity rather than a global threshold value will preferentially suppress low-contrast noise while preserving high-contrast primary content. This does not eliminate bleed-through entirely, but it reduces it enough to significantly improve OCR accuracy on affected documents. The threshold parameters need to be calibrated per document type and era, since the paper stock and ink characteristics vary.
Skew and rotation
Documents that were placed on a flatbed scanner by hand are rarely perfectly aligned. A document that is a few degrees off-axis produces a scanned image where the text lines are not horizontal. Most OCR engines handle small amounts of skew (under 2 degrees) adequately, but larger rotation angles degrade accuracy on the affected lines, particularly near the edges of the page where the rotation causes the most displacement.
Some county archives contain documents that are rotated 90 degrees, typically because they were scanned in portrait orientation when the form was designed for landscape, or because a large-format document was folded and scanned in two halves at different orientations. A 90-degree rotation is obvious when the image is displayed, but batch processing pipelines need to detect and correct these automatically without human review of every page.
Deskewing is a well-solved problem at the preprocessing stage. Hough transform-based deskew detection identifies the dominant line orientation in the image and corrects for it. This works reliably for documents where there is sufficient printed structure (form borders, horizontal rules, text baselines) for the algorithm to detect. For very sparse documents with little printed content, deskew detection can fail or produce incorrect corrections. The 90-degree rotation case requires separate detection, typically based on image aspect ratio analysis combined with text line direction detection.
Stamp and seal overlays
Government documents are stamped extensively. "RECEIVED," "APPROVED," "VOID," "FILE COPY," date stamps, inspector stamps, notary seals, and department stamps all appear in county permit archives. These stamps are applied in ink after the form was completed, often in red or blue, sometimes in black, and they frequently land on top of field values rather than in designated stamp areas.
A red rubber stamp reading "APPROVED 03/14/2011" placed across the parcel APN field creates a serious OCR problem. The stamp text and the field text overlap visually, and an OCR engine without explicit stamp detection will attempt to read both together, producing a merged result that matches neither. The same applies to notary seals, which are embossed with an inked impression and produce a pattern that looks like character noise to an OCR engine.
The mitigation depends on stamp type. Red and blue stamps can often be separated from black printed and handwritten content using color channel separation on grayscale documents scanned at appropriate bit depth. This does not work on black stamps overlapping black text. For black stamps, the approach is to detect the stamp boundary (stamps typically have a distinct rectangular or circular border), identify the region it occupies, and flag the field values within that region for human review. The stamped content cannot be automatically recovered in the general case; what can be done is to ensure that compromised fields are not silently assigned incorrect values.
Handwritten margin annotations
Permit forms are annotated in the margins. Planners and clerks add notes, cross-references, correction marks, and status indicators. These annotations are not part of the original form structure. They can appear anywhere on the page, including inside or adjacent to form fields, and they are in the handwriting of multiple different people.
The extraction problem with margin annotations is not primarily that they are hard to read (though they often are). It is that they can be misidentified as field values. An annotation of "see also 2743" written in the margin near the parcel APN field might be read as belonging to that field. A correction mark striking through a typed value and writing a new value above it requires the extraction system to determine which value is the authoritative one.
Margin annotation handling requires identifying annotation regions as distinct from form field regions. Form fields have defined boundaries (cell borders, underlines) that separate them from the surrounding page area. Annotations that fall outside those boundaries should be extracted to a separate annotation field rather than substituted for the in-field content. When a correction mark and new value are detected inside a field boundary, both the original value and the correction should be captured, with a flag indicating that human review is needed to determine the final authoritative value.
Inconsistent page orientation within a batch
Batch scanning of multi-page documents sometimes produces results where individual pages are rotated relative to the others. This happens when documents were inserted into a sheet-feed scanner in inconsistent orientations, or when the scanner misidentified the page orientation for certain pages. In a multi-page permit application, page 1 might be correctly oriented, page 2 rotated 180 degrees, and page 3 correctly oriented again.
The symptoms in batch processing are failed OCR on the affected pages and (in some cases) field values extracted from the wrong page because the field location detection is position-based and the field positions shift when the page is rotated. This type of error can produce incorrect permit data that looks plausible: a date from one field might land in another field's position when the page is upside down, and the extracted value might pass format validation while being semantically incorrect.
Per-page orientation detection and correction before any field extraction is the standard defense here. Each page is assessed independently for orientation before the field extraction schema is applied. This adds processing time but prevents the silent errors that orientation mismatches produce. It is one of the preprocessing steps that is easy to skip when building a pipeline under time pressure, and it becomes very visible when it is absent.
What preprocessing cannot fix
Not all image quality problems are recoverable through preprocessing. A document scanned at 96 DPI, with heavy duplex bleed-through, on yellowed paper where the ink has faded to near-paper-color, represents a set of compounding quality problems that no preprocessing chain will fully recover. The practical question for an extraction pipeline is not whether perfect recovery is possible, but where the confidence thresholds should be set so that low-quality recoveries route to human review instead of being published with false high confidence.
We do not apply a binary pass-fail filter based on image quality. Instead, quality assessment is continuous: each page receives a quality score based on estimated resolution, contrast, skew, and noise level, and that quality score is factored into the confidence scoring for extracted fields. A high-quality image with a high-confidence field extraction produces a record ready for automatic publishing. A low-quality image with a medium-confidence extraction routes to human review. A low-quality image with low-confidence extraction routes to a separate queue for image quality escalation, where the decision is whether the source document should be physically retrieved and rescanned before processing.
That last category, documents that need physical retrieval for rescanning, is where the pipeline intersects with the physical archive. For a county that still has the original paper records, this is a real option. For a county where the original paper was destroyed after scanning, it is a permanent data quality gap. Knowing which situation applies, and flagging affected records accordingly, is a piece of archive metadata that should be collected during the initial pilot setup.