Now that I understand better what this is, I can interpret my results more accurately. And I see that this actually adds *a lot* of overhead. Even for a perfectly clean non-searchable PDF. Does this match your expectation?
Looking at the code, it appears that ApplyRotation is *only* done if enableImageProcessing is True. Is this correct? From: Peter Kronenberg <[email protected]> Sent: Monday, January 11, 2021 5:30 PM To: [email protected]; [email protected] Subject: RE: Turning off ImageProcessing This email was sent from outside your organisation, yet is displaying the name of someone from your organisation. This often happens in phishing attempts. Please only interact with this email if you know its source and that the content is safe. I see the Tika default for this is off or FALSE. How much overhead is involved with this? Would it make sense to default to TRUE? From: Peter Kronenberg <[email protected]<mailto:[email protected]>> Sent: Monday, January 11, 2021 5:25 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: Turning off ImageProcessing This email was sent from outside your organisation, yet is displaying the name of someone from your organisation. This often happens in phishing attempts. Please only interact with this email if you know its source and that the content is safe. Ah, ok. That’s a bit confusing. Perhaps for 2.0? So what exactly does it mean if it’s off? There is already a flag for ApplyRotation. Exactly what pre-processing is done? From: Tim Allison <[email protected]<mailto:[email protected]>> Sent: Monday, January 11, 2021 3:38 PM To: [email protected]<mailto:[email protected]> Subject: Re: Turning off ImageProcessing We should change "enableImageProcessing" to "enableImagePreprocessing". That flag covers the rotation.py and ImageMagick preprocessing, NOT ocr. As for the warnings...I'm trying to figure out how to push those further towards the time of executing tesseract so that people who run tesseract get the warning, but those whose files never go down that path don't get the warning. On Mon, Jan 11, 2021 at 12:50 PM Peter Kronenberg <[email protected]<mailto:[email protected]>> wrote: Is the EnableImageProcessing flag in TesseractOCRConfig honored? It seems to always do OCR. And in fact, as long as it finds it in the path, I get this message [main] WARN org.apache.tika.parser.ocr.TesseractOCRParser - Tesseract OCR is installed and will be automatically applied to image files unless you've excluded the TesseractOCRParser from the default parser. Tesseract may dramatically slow down content extraction (TIKA-2359). As of Tika 1.15 (and prior versions), Tesseract is automatically called. In future versions of Tika, users may need to turn the TesseractOCRParser on via TikaConfig. Is the only way to turn off image processing to remove the OCR parser? Can I enable/disable it programmatically? The easiest way I found to disable it is to provide a bogus path (thanks to the hint in TesseractOCRParser#checkInitialization), but that still issues the above message (not sure why it can’t check first if the path is valid) Is there a better way to do this?
