The output PDF is corrupted by ocrmypdf. Specifically, the image in
the output PDF is tiled redundantly and the text appears to have color
added. An error is printed to the terminal during processing which may
be related:

  $ convert sample_from_gimp.tif sample_gimp→im.pdf
  $ ocrmypdf --force-ocr --tesseract-timeout 1800 -l eng sample_gimp→im.pdf sample_gimp→im→ocr.pdf
  Scanning contents: 100%|███████████████████████████████████████████████████████████████████████████████████| 1/1 [00:00<00:00, 115.21page/s]
  Using Tesseract OpenMP thread limit 2
      1 page already has text! - rasterizing text and running OCR anyway
      1    **** Error: ICCbased space /N value does not match the ICC profile.
                   Using the number of channels from the profile.
                   Output may be incorrect.

The source image was produced by saving a TIFF image in gimp then
using ImageMagick to convert it to a PDF. The PDF produced by
ImageMagick renders just fine in evince. But then it is fed to
ocrmypdf- the output of which is corrupt.

Attached is a non-corrupted sample source TIFF file from gimp. Ideally
I would have attached the sample_gimp→im.pdf file but it’s 25mb!  So
to reproduce this developers will need to convert the attached TIFF
file to PDF using ImageMagick, then run ocrmypdf on that.

Alternative bug reproducer:

Instead of using ImageMagick-convert to go from TIFF to PDF, there is
also tiff2pdf from the libtiff-tools package which I ran as follows:

  $ tiff2pdf -o sample_gimp→t2p.pdf sample_from_gimp.tif
  $ ocrmypdf --force-ocr --tesseract-timeout 1800 -l eng sample_gimp→t2p.pdf sample_gimp→t2p→ocr.pdf

The PDF produced by tiff2pdf is /much/ smaller (~1mb), so it is
attached. Whether the TIFF is converted by imagemagick or tiff2pdf,
the input PDF is good but ocrmypdf corrupts it similarly (but
differently) in both cases.

Note that according to qpdf neither the input file nor the output file
are corrupt, thus the corruption must be visually verified:

  $ qpdf --check sample_gimp→im.pdf
  checking sample_gimp→im.pdf
  PDF Version: 1.7
  File is not encrypted
  File is not linearized
  No syntax or stream encoding errors found; the file may still contain
  errors that qpdf cannot detect

  $ qpdf --check sample_gimp→im→ocr.pdf
  checking sample_gimp→im→ocr.pdf
  PDF Version: 1.7
  File is not encrypted
  File is linearized
  No syntax or stream encoding errors found; the file may still contain
  errors that qpdf cannot detect

By the way, I inspected the changelog here:

https://metadata.ftp-master.debian.org/changelogs//main/o/ocrmypdf/ocrmypdf_14.0.1+dfsg1-1_changelog

to look for any release notes that might indicate that this bug has
been fixed. No fixes between my version and the latest appeared
related, but many of the logs contained “New upstream release.”  This
means I had to try to track down the upstream change log, which I
could not find. Ideally the upstream change logs would be copied into
the debian change logs.