quality of recognition of customer invoices

A Nederpelt

unread,

Sep 21, 2023, 9:07:48 AM9/21/23

to tesseract-ocr

Hi.

I am trying to use the tesseract engine instead of the nuance engine.

When i currently use tesseract.exe the image it returns a few strange characters.

2x OO instead of 00

"uw BTW nummer:: NLOO7900000B01"

instead of

"uw BTW nummer:: NL007900000B01"

and

"Tel £01"

instead of

"Tel : 01"

but "Tel : 0168-452452" is recognized ok.

I see no optimization using https://github.com/tesseract-ocr/tessdoc/blob/main/ImproveQuality.md because it are really clean documents.

Am i missing some parameters ? Like a second run, or more accurate run etc.

Maybe compile tesseract.exe myself with different more quality parameters ?

Thanks,

Alwin

Lambregts0001 - cleaned.txt.txt

Lambregts0001 - cleaned.jpg

Dellu Bw

unread,

Sep 21, 2023, 4:25:12 PM9/21/23

to tesser...@googlegroups.com

White list the digits so that the O will not confuse it.

You can also try --psm 13 if all of your texts are single line.

--
You received this message because you are subscribed to the Google Groups "tesseract-ocr" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tesseract-oc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tesseract-ocr/6f5f957e-4f33-419f-aba6-2e8a3f6f8d92n%40googlegroups.com.

A Nederpelt

unread,

Sep 22, 2023, 2:43:02 AM9/22/23

to tesseract-ocr

Using --psm 13 nothing is returned (except 2 letters)

The whitelist seem to be in "C:\Program Files\Tesseract-OCR\tessdata\configs\digits".

Does it use this file by default then ?

Op donderdag 21 september 2023 om 22:25:12 UTC+2 schreef elvi...@gmail.com:

A Nederpelt

unread,

Sep 22, 2023, 2:43:51 AM9/22/23

to tesseract-ocr

I found the parameters

"C:\Program Files\Tesseract-OCR\tesseract.exe" "..\Lambregts0001 - cleaned.jpg" "Lambregts0001 - cleaned.txt" -c tessedit_char_whitelist="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 :@."
It is not working. "uw BTW nummer:: NLOO7900000B01"

Any other ideas ?

Op donderdag 21 september 2023 om 22:25:12 UTC+2 schreef elvi...@gmail.com:

White list the digits so that the O will not confuse it.

Des Bw

unread,

Sep 22, 2023, 7:23:39 AM9/22/23

to tesseract-ocr

The difference between zero and O is deeply problematic, for the human eye. Some fonts make it even harder.

You can try the method used here: https://pyimagesearch.com/2021/09/06/whitelisting-and-blacklisting-characters-with-tesseract-and-python/

if that helps.

Des Bw

unread,

Sep 22, 2023, 7:25:21 AM9/22/23

to tesseract-ocr

Apparently, version 4 doesn't support white listing. https://groups.google.com/g/tesseract-ocr/c/IBbQIQpdSpE

That is not good.

A Nederpelt

unread,

Sep 22, 2023, 7:50:50 AM9/22/23

to tesseract-ocr

Well, the problem is that why it chooses for:

NLOO7900000B01

2 times character O and 5 times a 0 (ZERO)

Google vision result: "NL007900000B01"

Nuance / OMNIPage: "NL007900000B01"

Leadtools demo: "NL007900000B01"

I want too use Tesseract, but i guess i need things like "second pass" or "preprocessing", no dictionary etc.etc.etc

So, i more like a CPU usage of 99,99% and not superspeed.

Can somebody help me ?

Op vrijdag 22 september 2023 om 13:25:21 UTC+2 schreef desal...@gmail.com:

Des Bw

unread,

Sep 22, 2023, 8:03:53 AM9/22/23

to tesseract-ocr

The CPU usage is unusual. I have pretty old mac (from 2011); have been running Tesseract quite fine.

But, as to the accuracy, if your project is limited in scale, the commercial tools would definitely perform better for you. But, if you have long lasting, and extensive projects, Tesseract is worth spending your time and developing (training) it.

A Nederpelt

unread,

Sep 22, 2023, 8:24:52 AM9/22/23

to tesseract-ocr

Well i have approximatelly 3000 customers at the moment for our software. We are using lots of invoices to OCR i.e. 1 customer uses approx 10.000 documents a month.

So opensource is worth it. I want tesseract, sinds it is free to use.

I believe opensource is the future.

So, can somebody help me optimize it.

With lots of CPU usage i mean when it needs to use more CPU for some parameter like "super quality". I want to use that parameter.

Op vrijdag 22 september 2023 om 14:03:53 UTC+2 schreef desal...@gmail.com:

Des Bw

unread,

Sep 22, 2023, 9:07:12 AM9/22/23

to tesseract-ocr

If you have income source, you might be able to give some compensation for his/her time; and an experienced user or even developer might help you to fine tune the software for your needs. You ask Shree if he/she will be interested.

Des Bw

unread,

Sep 22, 2023, 9:10:43 AM9/22/23

to tesseract-ocr

Shree is one of the most experienced; and definitely the most helpful member of this group. I have also seen Zdenko answering some questions. You might have a good luck with either of them.

Zdenko Podobny

unread,

Sep 22, 2023, 10:39:13 AM9/22/23

to tesser...@googlegroups.com

I know there are (were) people at the forum that implemented Tesseract as part of invoice processing - but as a commercial solution.

It is not as easy as it looks: there is a need for a custom solution for text detection (e.g. skipping logos and other graphics, possible handwriting). As far as I remember they created a new engine for amount recognition - this is the most critical part of invoice processing.

A few years ago I had a discussion with a professional provider of such services in Europe (they did not use Tesseract) and they informed me they try to avoid data extraction from invoices and they insist on invoice data exchange because it is cheaper and more reliable...

Just my 2 cents - what you can expect or what problems you will need to solve.

Zdenko

pi 22. 9. 2023 o 14:24 A Nederpelt <powe...@gmail.com> napísal(a):

To view this discussion on the web visit https://groups.google.com/d/msgid/tesseract-ocr/5aa9548f-a539-46d1-94a1-fc25850d5982n%40googlegroups.com.

Art Rhyno

unread,

Sep 24, 2023, 8:18:30 AM9/24/23

to tesser...@googlegroups.com

It is not a “super quality” parameter, but one possible approach to critical numbers and other types of content where a dictionary is not helpful is to target individual characters. Tesseract will provide individual characters and probabilities of accuracy for each, either using the API or in hocr with "-c hocr_char_boxes=1". With the glyph coordinates and something like a range between 90 and 98 percent probability, it might be possible to get closer to 99 per cent by extracting individual glyphs and using single character recognition (PSM 10). This, of course, adds a lot more overhead but it can help with tricky recognition, like distinguishing between "O" and "0".

art

From: tesser...@googlegroups.com <tesser...@googlegroups.com> On Behalf Of A Nederpelt
Sent: Friday, September 22, 2023 8:25 AM
To: tesseract-ocr <tesser...@googlegroups.com>
Subject: Re: [tesseract-ocr] quality of recognition of customer invoices

Well i have approximatelly 3000 customers at the moment for our software. We are using lots of invoices to OCR i.e. 1 customer uses approx 10.000 documents a month.

So opensource is worth it. I want tesseract, sinds it is free to use.

I believe opensource is the future.

So, can somebody help me optimize it.

With lots of CPU usage i mean when it needs to use more CPU for some parameter like "super quality". I want to use that parameter.

Op vrijdag 22 september 2023 om 14:03:53 UTC+2 schreef desal...@gmail.com:

The CPU usage is unusual. I have pretty old mac (from 2011); have been running Tesseract quite fine.

But, as to the accuracy, if your project is limited in scale, the commercial tools would definitely perform better for you. But, if you have long lasting, and extensive projects, Tesseract is worth spending your time and developing (training) it.

On Friday, September 22, 2023 at 2:50:50 PM UTC+3 powe...@gmail.com wrote:

Well, the problem is that why it chooses for:

NLOO7900000B01

To view this discussion on the web visit https://groups.google.com/d/msgid/tesseract-ocr/5aa9548f-a539-46d1-94a1-fc25850d5982n%40googlegroups.com.

A Nederpelt

unread,

Sep 25, 2023, 3:46:06 AM9/25/23

to tesseract-ocr

Well the strange effect is, that hocr shows different characters.

"C:\Program Files\Tesseract-OCR\tesseract.exe" "..\Lambregts0001 - cleaned.jpg" "Lambregts0001 - cleaned" -c hocr_char_boxes=1 hocr

result 2 times a character 'O' and the rest is '0' zero.

N
L
O
O
7
9
0
0
0
0
0
B
0
1

But in the picture they all look 100% the same as shown before.

And then i converted the painting to black and white, and copy/pasted the signs on the pdf

(I still see no differences). I copied the red-sign to the orange-signs...

"C:\Program Files\Tesseract-OCR\tesseract.exe" "..\Lambregts0001 - cleaned - bw 2.jpg" "Lambregts0001 - cleaned - bw 2" -c hocr_char_boxes=1 hocr

N
L
O
O
7
9
0
0
0
0
0
B
0
1

The x_conf changes from 98 to 97 & 96

Any ideas ?

Op zondag 24 september 2023 om 14:18:30 UTC+2 schreef Art Rhyno:

Ger Hobbelt

unread,

Sep 25, 2023, 6:58:31 AM9/25/23

to tesser...@googlegroups.com

One more other thing to test is disabling the dictionary used to help evaluate character recognition. I haven't checked this myself, so YMMV -- I know the behaviour is quite different for classic tesseract (v3) engine and LSTM engine (v4/v5 addition); IIRC the `dawg` ones only affect the v3 engine, f.e.

(Which reminds me: you might want to check v3 (`--oem 0` IIRC) output as well as LSTM output for BTW/VAT numbers specifically.)

Anyway:

python - Pytesseract disable dictionary (multiple configuration arguments) - Stack Overflow

extra parameters mentioned here:

Disable dictionary-assisted OCR in tesseract C++ API - Stack Overflow

these parameters can be set via the CLI by using the `-c <PARAM>=<VALUE>` command line option. One param per `-c`, hence like this `-c PARAM1=0 -c PARAM2=0 ...`

However, keep in mind the very(!) valid remark of Zdenko: 'O', 'o' and '0' are already *hard* to differentiate for humans and classically this was solved by printing zeroes with a slash (Slashed zero - Wikipedia), so DO NOT expect perfect results any time.

Your Dutch VAT ("BTW") codes can (and should!) be validated/corrected-in-post as they follow a very specific template (/NL[0-9]{9}B[0-9]{2}/) (Using and verifying VAT numbers | Business.gov.nl & Netherlands VAT Guide for Global Business - Rates & Compliance Requirements (fonoa.com) ) and your software should be able to disambiguate the [Oo0] set at each position in "post": while almost everyone is focusing on *pre*processing (image processing to improve tesseract OCR accuracy - Stack Overflow, Improving the quality of the output | tessdoc (tesseract-ocr.github.io), et al), yours is a very *domain specific* issue as you are trying to read non-human text elements, such as VAT codes, for which *OCR postprocessing* the (HOCR or similar) tesseract output might be used: this way one can improve OCR-ing credit card "numbers" and the like, such as VAT codes: anything that's restricted by its format but not well suited for human-language dictionary- or Markov-chain-based 'grading' (I **assume** (haven't checked tesseract internals about this) you're getting 'NLOO' instead of 'NL00' because in human languages, one would expect more alphabetic characters to show up in a "word" with far higher probability than *numerical digits* -- this is why it might help to fiddle with the settings in the parameters mentioned in the second SO link above -- and when that doesn't work for you, there's always the blunt 'replace O by 0(zero) and revalidate VAT number' approach. :-) )

NEVER assume you'll get a 100% hit rate with OCR, though. OCR-A and OCR-B fonts were once developed to get much closer to that number, but ultimately, any pixels-to-text approach is bound to fail, if only ultimately by Murphy's Law. Plenty of opportunity for that one along the way in your scenario. Caveat emptor.

(On a side note: I see quite a few folks trying this same thing (OCR-ing invoices and bills) the last few years; all the companies I have worked at or be in contact with require B2B electronic data exchange (in TEXT format; often as XML, some as (text-carrying) PDF/A) for the above reason (<100% success rate over time, ergo human inspection/correction required at random time intervals --> obnoxious process) when they are processing invoices in sufficient numbers to make human handling [deemed] too costly. Curiously this gap between manual single entry and electronic data exchange for invoices still is a business opportunity today, apparently.)

(On another side note: observe the particular typography used for the numerals in the BTW codes as displayed at the Dutch governmental gov.nl web site page (linked above): they clearly made a very conscious choice to use "lowercase digits" (typography - How to construct "lowercase digits" (i.e. text figures)? - Graphic Design Stack Exchange) for the numeric parts. This, however, would not *solve* the readability issue either as now 'o' (lowercase Oh) and 0(digit zero) are confused by human readers instead. Bottom line: always expect confusion, also by your OCR machine, so second-guessing, i.e. "post processing" is in order. If only for flagging any "BTW nummer" (VAT code) that turns up as being invalid. Heck, you'll need that anyway as a first-line defense against (basic) VAT fraud anyway! ;-)) )

If you really want to dig further beyond tesseract `-c` parameter tweaking & experimentation, there's the source code itself to tweak to provide you with a more abundant output, along the lines of https://github.com/sirfz/tesserocr/issues/166, https://github.com/tesseract-ocr/tesseract/issues/1465, et al. The key thought here is: your application of OCR might actually benefit (as it requires POST-processing) from being able to feed your postprocessor with a *set of choices per character* to help the postprocessor decide what's best in your particular (domain specific) case, i.e. almost walk in the other direction where "fixing diplopia" took tesseract till today. Would be an interesting research project, I'm sure.

Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: g...@hobbelt.com
mobile: +31-6-11 120 978
--------------------------------------------------

To view this discussion on the web visit https://groups.google.com/d/msgid/tesseract-ocr/3801b871-aa3f-4ddc-85c0-6df1f9063180n%40googlegroups.com.

Art Rhyno

unread,

Sep 25, 2023, 9:15:02 AM9/25/23

to tesser...@googlegroups.com

Not sure I am following, hocr is just an output format, the results should be the same. The trick would be to use the coordinates to extract the glyphs for problem characters, like the two Os below, and then use single character mode on the resulting images. I put a simple demo of this approach here [1], you would probably want to test if the approach consistently caught problem characters and then use the API to get better performance in production.

art

---

1. https://github.com/OurDigitalWorld/tesschar

From: tesser...@googlegroups.com <tesser...@googlegroups.com> On Behalf Of A Nederpelt
Sent: Monday, September 25, 2023 3:46 AM
To: tesseract-ocr <tesser...@googlegroups.com>
Subject: Re: [tesseract-ocr] quality of recognition of customer invoices

Well the strange effect is, that hocr shows different characters.

To view this discussion on the web visit https://groups.google.com/d/msgid/tesseract-ocr/3801b871-aa3f-4ddc-85c0-6df1f9063180n%40googlegroups.com.

A Nederpelt

unread,

Sep 25, 2023, 11:13:34 AM9/25/23

to tesseract-ocr

After removing the "L" from the picture, everything is OCR'd as zero: "uw BTW nummer:: N 007900000B01"

Is there any "extra" quality of Tesseract i want to disable ?

It looks like Tesseract "thinks" as "Is the 'sign' zero or "O"...... hmmmmm..... there is text before the 'sign' so, it would rather be "O" than zero"

Looking at the "x_conf" ENTRY:

2 boxes:

N


0
0
7
9
0
0
0
0
0
B
0
1

1 box (previous mail)

N
L
O
O
7
9
0
0
0
0
0
B
0
1

As for the VAT number, changing it afterwards is no problem at all, but i want the OCR engine to recognize this in advance. The quality of the picture is 100%.

I am looking for settings, and don't want to dig into the source code. So has anybody got any idea's ?

Op maandag 25 september 2023 om 12:58:31 UTC+2 schreef g...@hobbelt.com:

Reply all

Reply to author

Forward