[
https://issues.apache.org/jira/browse/TIKA-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16811963#comment-16811963
]
Ross Johnson commented on TIKA-2749:
------------------------------------
[[email protected]]
First, to make sure we're on the same page regarding nomenclature -
I believe that "inline images" used in earlier comments refers to images that
are rendered in the document (i.e. not file attachments) and not necessarily
what the PDF spec refers to as "inline images". Use of "inline images" in the
PDF spec refers specifically to images that are defined in the content stream
using {{/BI}} & {{/EI}} operators, as opposed to images that are defined in a
separate {{XObject}} and are drawn with the {{/Do}} operator. Both of these
image rendering methods will render an image on the page, and should probably
be treated as equivalent operations by an OCR heuristic. I'll continue to use
"inline image" to refer to either draw operation.
In general, in order to know the size / orientation of inline images, it's
necessary to iterate through the content stream, aggregating any transforms and
looking for image draw operations (I believe that PDFBox has a
{{PDFStreamParser}} class to help with this). Knowing the cumulative transform
of each drawn image will let you determine if any images are drawn flipped or
rotated, as well as let you detect any image overlap and determine the overall
image coverage of the page.
As for that compression scheme that uses background & foreground images, I
believe that whenever I've seen this, at least one of the images has had a
{{Mask}} entry, or one of them has {{ImageMask = true}}.
Personally, I would consider running OCR on extracted images (as opposed to the
rendered page) if the following conditions are met:
1) given all of the drawn images, there is only 1 that is close to the overall
page size
2) this image's cumulative transform only has normal scaling and positioning
(no rotation or flipping)
3) the image has no mask and is itself not a mask
If there is only one image, and it meets these criteria, the page very likely
represents a straight forward image scan, or perhaps a photograph. If there is
one such image, and there are other relatively small images near the corners,
then it's probably a basic scan that has had a watermark or image stamp placed
over the page. These extra images likely don't have much relevant text content,
so could be ignored.
A couple other notes I thought about:
- If a page has existing hidden text, it has likely been OCRd previously. That
hidden text could be used as-is, or OCR could be re-ran. If re-running OCR,
probably best to discard the existing hidden text in the output.
- It's very common to have pages of text scans that have actual drawn text as
well, such as a Bates stamp. You mentioned a 10 word cutoff earlier, Whatever
it is, it should probably be configurable because as soon as it's set you'll
get a PDF of scans with an 11 word stamp on every page :P
- If rendering whole pages for OCR, it would be possible to first strip out
this "real" text to save some OCR effort and avoid double-output of the text.
- I've run into some large-format pages, such as large CAD drawing images, that
seem to leave Tesseract spinning for hours. Probably best to have some page or
image size max above which you don't run OCR.
One final thought - often I'll see rotated scans that provide garbage OCR text
output. Would be cool to re-run such images rotated 90, 180, or 270 degrees to
see if one gives more reasonable words, as a way of auto-detecting / correcting
page orientation.
Source - experience dealing with legal documents as e-discovery SaaS vendor
> OCR on PDFs should "just work" out of the box
> ---------------------------------------------
>
> Key: TIKA-2749
> URL: https://issues.apache.org/jira/browse/TIKA-2749
> Project: Tika
> Issue Type: Task
> Reporter: Tim Allison
> Priority: Major
>
> There are now two different ways (with various parameters) to trigger OCR on
> inline images within PDFs. The user has to 1) understand that these are
> available and then 2) elect to turn one of those on.
> I think we should make OCR'ing on PDFs "just work" perhaps with a hybrid
> strategy between the 2 options. Users should still be allowed to configure
> as they wish, of course.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
