Tesseract Empty Page

[M3ssman]

Environment

• Tesseract Version: tesseract 4.1.1-rc2-21-gf4ef
  leptonica-1.78.0
  libgif 5.1.4 : libjpeg 8d (libjpeg-turbo 1.5.2) : libpng 1.6.34 : libtiff 4.0.9 : zlib 1.2.11 : libwebp 0.6.1 : libopenjp2 2.3.0
  Found AVX2
  Found AVX
  Found FMA
  Found SSE
  Found libarchive 3.2.2 zlib/1.2.11 liblzma/5.2.2 bz2lib/1.0.6 liblz4/1.7.1
• Platform: Ubuntu 18.04 LTS
• Model Configs tested: frk, Fraktur (from tessdata_best), gt4hist_5000k (gt4hist-Model with 5000k Iterations)

Current Behavior:

When using rather large uncompressed TIF-Files (ca. 80 MB) from Project "Digitalisierung historischer deutscher Zeitschriften" for about 5 Pages (or even less) of 1000 Images we get ALTO-Files missing valid OCR-Date.

When run with tesseract 0046.tif 0046 -l frk alto it only alerts Empy Page!! and exits in < 20 seconds.
0046-alto.zip
0046-tif.zip

Generated ALTO-File and TIF-Image included.

Expected Behavior:

Produce ALTO-XML with contents.

Suggested Fix:

No idea.

[M3ssman]

The Link from send.firefox.com is active for 1 day. Afterwards it will disappear.

[zdenop]

Did you tried to follow documentation?

[M3ssman]

@zdenop We're scanning from Microfilms using QuantumScan Software and do Preprocessing with QuantumProcess which does a good job with constrasts and deskewing. Therefore I wonder why 999 Images pass, but some few don't, like this one. Could you already take a closer look at the Image? What additional Preprocessing would you suggest if any?

[stweil]

@M3ssman, the link is already inactive. Please attach a sample image to the issue report here.

[zdenop]

I just made quick test: When I removed black border and header. Then tesseract produced result (tested just with English, as I not have frk at the moment installed).
So pre-processing of such images are must or you need to implement custom layout detection.
So sake of small size this thumbnail of my testing image:

[M3ssman]

@zdenop Yes, many thanks, this works!
But anyway, I wonder why all the other images went fine. They are all born the same way. Never cropped, just plain TIF-files with some tuning for contrast and rotation. Tesseract shouldn't bother with borders, as it is (almost) never does.

[M3ssman]

@stweil Guess what! The original Image works, too, if I scaled it down 1:4!

Sorry, I didn't recognize the link is also off after a single download

-I'm uploading again right now.-

Sorry for the delay, but I run into trouble with uploads from home. Now, from office it is way faster:
0046.zip

[M3ssman]

@stweil Strange indeed.
I cropped only the header of the page and left left, right and bottom margins as they are and this version works fine.
0046-headless.zip

[M3ssman]

@zdenop Since the original image itself looks dark somehow, I called ImageMagick 6.9 to enhance contrast: convert 0046.tif -brightness-contrast 25x50 -compress none -colorspace Gray 0046-convert.tif
This version, without taking care for the borders, makes Tesseract producing not an empty page, but quite reasonable OCR-output.

[zdenop]

I expect that size of 0046-convert.tif is lower. Right?

[M3ssman]

@zdenop This is what exiftool outputs:
original: Megapixels 79.1, Image size 7477x10584, 79151624 Byte filesize
convert: Megapixels 79.1, Image size 7477x10584, 79151434 Byte filesize
So pure filesizes differs slightly.

[M3ssman]

@zdenop Did you run Tesseract also with the original file (without cropping or other types of preprocessing? What was the outcome?
0046-convert.zip

[zdenop]

Original finished quickly with "empty page" message.

[stweil]

The original page triggers bugs which can be shown by adding -c textord_debug_bugs=1. Tesseract creates boxes (bounding_box_) with a right margin which exceeds the image dimensions (error message Made partition with bad right coord). Those boxes are therefore disregarded. With the following hack the boxes are processed, and text is recognized:

diff --git a/src/textord/colpartition.cpp b/src/textord/colpartition.cpp
index 74f1b1d9..465a1f57 100644
--- a/src/textord/colpartition.cpp
+++ b/src/textord/colpartition.cpp
@@ -353,7 +353,7 @@ bool ColPartition::IsLegal() {
       tprintf("Margins invalid\n");
       Print();
     }
-    return false;  // Margins invalid.
+//    return false;  // Margins invalid.
   }
   if (left_key_ > BoxLeftKey() || right_key_ < BoxRightKey()) {
     if (textord_debug_bugs) {

I think that the right solution would have to find out why Tesseract creates bad bounding boxes and fix that.
Maybe it would already help to enforce boxes with valid coordinates.