Different results than command line version

[ahaberbosch]

I'm using tesseract.js in a node application and when I compare it to a command line version from linux, i get worse results, even though i'm using the same settings and it's working on the same file. Is there some way I can figure out the difference between the two, or does this come down to some libraries that they are built against?

[Balearica]

I added a section on this to the FAQ. See below.

https://github.com/naptha/tesseract.js/blob/master/docs/faq.md#why-am-i-getting-different-results-vs-tesseract-cli

If the explanation in the FAQ does not explain the difference in your case, we would need a reproducible example to say anything further.

[ahaberbosch]

Thanks, I did look for some docs but i don't know why I didn't find the FAQ information. I had already used similar settings but it didn't yield results. I tried to figure out what version of tesseract was in teseract.js but it wasn't clear to me. So I compared the results of tesseract 4.1.1 and tesseract 5.3.2 cli and they were the same. In the end it seemed like it was the traineddata that had been downloaded originally. I swapped out the trained data from 5.3.2 cli and it then worked as expected. It was a difference of about 16MB. Interestingly, i then changed the oem mode to ltsm + legacy, and it appeared to "corrupt" the trainneddata file i just replaced; I got differing results again from then on, regardless of mode, and it added about 1MB. Is there a way to prevent the trainneddata file from being modified?

[Balearica]

Tesseract.js will automatically replace an existing (cached) .traineddata file if (1) you are setting an oem that appears to require Legacy data (0 [legacy] or 2 [lstm + legacy fallback]), (2) the current .traineddata file does not contain Legacy data, and (3) langPath was not set.

To make Tesseract.js always get .traineddata files from a local directory, rather than downloading them from the internet, you should set langPath manually. See this response for details on setting langPath for the Node.js version.

[ahaberbosch]

Thank you for your responses. I did play around with langPath and gzip, I also found that it kept copying the file to the parent folder. To prevent this it seemed like I could either set the cachePath to the same path, or set cacheMethod to readOnly, which is what I ultimately did. Can you think of a reason why this wouldn't be a good idea?

[Balearica]

That should basically work. The cleanest method to achieve what you're going for is to set cacheMethod to none, which disables the caching behavior entirely, and simply reads the file from langPath every time. You are accomplishing almost the same thing by deleting the file and then setting cacheMethod to readOnly, except that the code will first look for the file in cachePath and then fall back to langPath when the file is not found. I doubt the difference is more than a few milliseconds though.

The reason why the file is copied is because langPath is generally a remote server, while cachePath is a local location. Therefore, the file is copied from langPath to cachePath to reduce network usage going forward. In the less common usage where the Node.js version is used and langPath is set to a local file, this just results in a file being copied from one directory to another, which is what you observed.