Control of unpaper¶
unpaper to provide the implementation of the
provides a variety of image processing filters to improve images.
By default, OCRmyPDF uses only
unpaper arguments that were found to
be safe to use on almost all files without having to inspect every page
of the file afterwards. This is particularly true when only
is used, since that instructs OCRmyPDF to only clean the image before
OCR and not the final image.
However, if you wish to use the more aggressive options in
you may use
--unpaper-args '...' to override the OCRmyPDF’s defaults
and forward other arguments to unpaper. This option will forward
unpaper without any knowledge of what that program
considers to be valid arguments. The string of arguments must be quoted
as shown in the examples below. No filename arguments may be included.
OCRmyPDF will assume it can append input and output filename of
intermediate images to the
In this example, we tell
unpaper to expect two pages of text on a
sheet (image), such as occurs when two facing pages of a book are
unpaper uses this information to deskew each independently
and clean up the margins of both.
ocrmypdf --clean --clean-final --unpaper-args '--layout double' input.pdf output.pdf ocrmypdf --clean --clean-final --unpaper-args '--layout double --no-noisefilter' input.pdf output.pdf
unpaper features will reposition text within the image.
--clean-final is recommended to avoid this issue.
unpaper features cause multiple input or output files to be
consumed or produced. OCRmyPDF requires
unpaper to consume one
file and produce one file; errors will result if this assumption is not
unpaper uses uncompressed PBM/PGM/PPM files for its intermediate
files. For large images or documents, it can take a lot of temporary
Control of OCR options¶
OCRmyPDF provides many features to control the behavior of the OCR engine, Tesseract.
When OCR is skipped¶
If a page in a PDF seems to have text, by default OCRmyPDF will exit without modifying the PDF. This is to ensure that PDFs that were previously OCRed or were “born digital” rather than scanned are not processed.
--skip-text is issued, then no image processing or OCR will be
performed on pages that already have text. The page will be copied to
the output. This may be useful for documents that contain both “born
digital” and scanned content, or to use OCRmyPDF to normalize and
convert to PDF/A regardless of their contents.
--redo-ocr is issued, then a detailed text analysis is performed.
Text is categorized as either visible or invisible. Invisible text (OCR)
is stripped out. Then an image of each page is created with visible text
masked out. The page image is sent for OCR, and any additional text is
inserted as OCR. If a file contains a mix of text and bitmap images that
contain text, OCRmyPDF will locate the additional text in images without
disrupting the existing text. Some PDF OCR solutions render text as
technically printable or visible in some way, perhaps by drawing it and
then painting over it. OCRmyPDF cannot distinguish this type of OCR
text from real text, so it will not be “redone”.
--force-ocr is issued, then all pages will be rasterized to
images, discarding any hidden OCR text, rasterizing any printable
text, and flattening form fields or interactive objects into their visual
representation. This is useful for redoing OCR, for fixing OCR text
with a damaged character map (text is selectable but not searchable),
and destroying redacted information.
Time and image size limits¶
By default, OCRmyPDF permits tesseract to run for three minutes (180 seconds) per page. This is usually more than enough time to find all text on a reasonably sized page with modern hardware.
If a page is skipped, it will be inserted without OCR. If preprocessing was requested, the preprocessed image layer will be inserted.
If you want to adjust the amount of time spent on OCR, change
--tesseract-timeout. You can also automatically skip images that
exceed a certain number of megapixels with
--skip-big. (A 300 DPI,
8.5×11” page image is 8.4 megapixels.)
# Allow 300 seconds for OCR; skip any page larger than 50 megapixels ocrmypdf --tesseract-timeout 300 --skip-big 50 bigfile.pdf output.pdf
OCR for huge images¶
Tesseract has internal limits on the size
of images it will process. If you issue
--tesseract-downsample-large-images, OCRmyPDF will downsample images
to fit Tesseract limits. (The limits are usually entered only for scanned
images of oversized media, such as large maps or blueprints exceeding
110 cm or 43 inches in either dimension, and at high DPI.)
--tesseract-downsample-above Npixels adjusts the threshold at which images
will be downsampled. By default, only images that exceed any of Tesseract’s
internal limits are downsampled.
You will also need to set
--tesseract-timeout high enough to allow
Only the image sent for OCR is downsampled. The original image is preserved.
# Allow 600 seconds for OCR on huge images ocrmypdf --tesseract-timeout 600 \ --tesseract-downsample-large-images \ bigfile.pdf output.pdf # Downsample images above 5000 pixels on the longest dimension to # 5000 pixels ocrmypdf --tesseract-timeout 120 \ --tesseract-downsample-large-images \ --tesseract-downsample-above 5000 \ bigfile.pdf output_downsampled_ocr.pdf
Overriding default tesseract¶
OCRmyPDF checks the system
PATH for the
Some relevant environment variables that influence Tesseract’s behavior include:
Overrides the path to Tesseract’s data files. This can allow simultaneous installation of the “best” and “fast” training data sets. OCRmyPDF does not manage this environment variable.
Controls the number of threads Tesseract will use. OCRmyPDF will manage this environment variable if it is not already set.
For example, if you have a development build of Tesseract don’t wish to use the system installation, you can launch OCRmyPDF as follows:
env \ PATH=/home/user/src/tesseract/api:$PATH \ TESSDATA_PREFIX=/home/user/src/tesseract \ ocrmypdf input.pdf output.pdf
In this example
TESSDATA_PREFIX is required to redirect Tesseract to
an alternate folder for its “tessdata” files.
Overriding other support programs¶
In addition to tesseract, OCRmyPDF uses the following external binaries:
In each case OCRmyPDF will search the
PATH environment variable to
locate the binaries. By modifying the
PATH environment variable, you
can override the binaries that OCRmyPDF uses.
Changing Tesseract configuration variables¶
You can override Tesseract’s default control parameters with a configuration file.
As an example, this configuration will disable Tesseract’s dictionary for current language. Normally the dictionary is helpful for interpolating words that are unclear, but it may interfere with OCR if the document does not contain many words (for example, a list of part numbers).
Create a file named “no-dict.cfg” with these contents:
load_system_dawg 0 language_model_penalty_non_dict_word 0 language_model_penalty_non_freq_dict_word 0
then run ocrmypdf as follows (along with any other desired arguments):
ocrmypdf --tesseract-config no-dict.cfg input.pdf output.pdf
Some combinations of control parameters will break Tesseract or break assumptions that OCRmyPDF makes about Tesseract’s output.
Changing the PDF renderer¶
- Converting a PDF to an image for display.
- Creating a new PDF from other data (such as an existing PDF).
OCRmyPDF has these PDF renderers:
renderer may be selected using
--pdf-renderer. The default is
auto which lets OCRmyPDF select the renderer to use. Currently,
auto always selects
sandwich renderer uses Tesseract’s new text-only PDF feature,
which produces a PDF page that lays out the OCR in invisible text. This
page is then “sandwiched” onto the original PDF page, allowing lossless
application of OCR even to PDF pages that contain other vector objects.
Currently this is the best renderer for most uses, however it is implemented in Tesseract so OCRmyPDF cannot influence it. Currently some problematic PDF viewers like Mozilla PDF.js and macOS Preview have problems with segmenting its text output, and mightrunseveralwordstogether.
When image preprocessing features like
--deskew are used, the
original PDF will be rendered as a full page and the OCR layer will be
placed on top.
hocr renderer works with older versions of Tesseract. The image
layer is copied from the original PDF page if possible, avoiding
potentially lossy transcoding or loss of other PDF information. If
preprocessing is specified, then the image layer is a new PDF. (You may
need to disable PDF/A conversion nad optimization to eliminate all
sandwich this renderer is implemented within OCRmyPDF; anyone
looking to customize how OCR is presented should look here. A major
disadvantage of this renderer is it not capable of correctly handling
text outside the Latin alphabet (specifically, it supports the ISO 8859-1
character set). Pull requests to improve the situation are welcome.
Currently, this renderer has the best compatibility with Mozilla’s PDF.js viewer.
This works in all versions of Tesseract.
Rendering and rasterizing options¶
New in version 14.3.0.
--continue-on-soft-render-error option allows OCRmyPDF to
proceed if a page cannot be rasterized/rendered. This is useful if you are
trying to get the best possible OCR from a PDF that is not well-formed,
and you are willing to accept some pages that may not visually match the
input, and that may not OCR well.
Color conversion strategy¶
New in version 15.0.0.
OCRmyPDF uses Ghostscript to convert PDF to PDF/A. In some cases, this
conversion requires color conversion. The default strategy is to convert
LeaveColorUnchanged strategy, which preserves the original
color space wherever possible (some rare color spaces might still be
Usually document scanners produce PDFs in the sRGB color space, and do not need to be converted, so the default strategy is appropriate.
Suppose that you have a document that was prepared for professional
printing in a Separation or CMYK color space, and text was converted to
curves. In this case, you may want to use a different color conversion
--color-conversion-strategy option allows you to select a
different strategy, such as
Return code policy¶
OCRmyPDF writes all messages to
stdout is reserved for
piping output files.
stdin is reserved for piping input files.
The return codes generated by the OCRmyPDF are considered part of the
stable user interface. They may be imported from
||Everything worked as expected.|
||Invalid arguments, exited with an error.|
||The input file does not seem to be a valid PDF.|
||An external program required by OCRmyPDF is missing.|
||An output file was created, but it does not seem to be a valid PDF. The file will be available.|
||The user running OCRmyPDF does not have sufficient permissions to read the input file and write the output file.|
||The file already appears to contain text so it may not need OCR. See output message.|
||An error occurred in an external program (child process) and OCRmyPDF cannot continue.|
||The input PDF is encrypted. OCRmyPDF does not read encrypted PDFs. Use another program such as
||A custom configuration file was forwarded to Tesseract using
||A valid PDF was created, PDF/A conversion failed. The file will be available.|
||Some other error occurred.|
||The program was interrupted by pressing Ctrl+C.|
Changing temporary storage location¶
OCRmyPDF generates many temporary files during processing.
To change where temporary files are stored, change the
environment variable for ocrmypdf’s environment. (Python’s
tempfile.gettempdir() returns the root directory in which temporary
files will be stored.) For example, one could redirect
TMPDIR to a
large RAM disk to avoid wear on HDD/SSD and potentially improve
On Windows, the
TEMP environment variable is used instead.
Debugging the intermediate files¶
OCRmyPDF normally saves its intermediate results to a temporary folder and deletes this folder when it exits, whether it succeeded or failed.
-k`) argument is issued on the
command line, OCRmyPDF will keep the temporary folder and print the location,
whether it succeeded or failed. An example message is:
Temporary working files retained at: /tmp/ocrmypdf.io.u20wpz07
The organization of this folder is an implementation detail and subject to change between releases. However the general organization is that working files on a per page basis have the page number as a prefix (starting with page 1), an infix indicates the processing stage, and a suffix indicates the file type. Some important files include:
_rasterize.png- what the input page looks like
_ocr.png- the file that is sent to Tesseract for OCR; depending on arguments this may differ from the presentation image
_pp_deskew.png- the image, after deskewing
_pp_clean.png- the image, after cleaning with unpaper
_ocr_tess.pdf- the OCR file; appears as a blank page with invisible text embedded
_ocr_tess.txt- the OCR text (not necessarily all text on the page, if the page is mixed format)
fix_docinfo.pdf- a temporary file created to fix the PDF DocumentInfo data structure
graft_layers.pdf- the rendered PDF with OCR layers grafted on
graft_layers.pdfafter conversion to PDF/A
pdfa.ps- a PostScript file used by Ghostscript for PDF/A conversion
optimize.pdf- the PDF generated before optimization
optimize.out.pdf- the PDF generated by optimization
origin- the input file
origin.pdf- the input file or the input image converted to PDF
images/*- images extracted during the optimization process; here the prefix indicates a PDF object ID not a page number