How we made our OCR code more accurate
41–50 of 50 posts
Re: How we made our OCR code more accurate
#42I can't say I've ever wanted to transcribe code from an image. That seems super niche. Perhaps the specific idea is to harvest coding textbooks as training data for LLMs?
Re: How we made our OCR code more accurate
#43I can't say I've ever wanted to transcribe code from an image. That seems super niche. Perhaps the specific idea is to harvest coding textbooks as training data for LLMs?
This is nightmare for endpoint protection. Imagine rogue employees snapping pics of your proprietary codebase and then using this to reassemble it.
Re: How we made our OCR code more accurate
#44Earlier quoted context omitted.
5.5.0 released November last year. Still a very active project as far as I can tell and runs on CPU. Even compared to best open source GPU option it is still pretty good. VLMs work very differently and don't work as well for everything. Why is it out of date?
I don't know that that is true: https://researchify.io/blog/comparing-pytesseract-paddleocr-... Using Surya gets you significantly better results and makes almost all the work detailed in the article largely unnecessary.
Re: How we made our OCR code more accurate
#45Earlier quoted context omitted.
Quite simply, you’re completely wrong. Modern tesseract versions include a modern LSTM AI. It can very affordably be deployed on CPU, yet its performance is competitive with much more expensive large GPU-based models. Especially if you handle a high volume of scans, chances are that tesseract will have the best bang per buck.
My company probably spent close to 6 figures overall creating Tesseract 5 custom models for various languages. Surya beats them all and is open source (and quite faster).
Their training code and data is closed source. They are barely open weight and only inference is open source.
Re: How we made our OCR code more accurate
#46Re: How we made our OCR code more accurate
#47Tesseract OCR was created by digital (DEC) in 19_8_5 (yes, 40 not four YEARs ago). Now go back and read the article and ROFL with me.
Unix was created in _1971_ and here we are still running processes and shells like it’s the 70s. Why not just have an LLM dream up the output?
NeXTStep was real UNIX, but macOS is not.
BTW, I was taught to program in C by one of the original core Unix team members and I worked for DEC long before I could have discussed TesseractOCR with people who didn't. Keep those ignorant downvotes commin'
Re: How we made our OCR code more accurate
#48Earlier quoted context omitted.
It's still 40. Why not use Ollama-OCR?
> It's still 40. Is it, though? If the important parts of the code are new, does it matter that other parts are older or derived from older code? (Of course, I think this whole line of thought is pointless; what matters is not age, but how well it works, and tesseract generally does seem to work.)
Maybe try OpenAI GPT-4o or Google's Document AI https://cloud.google.com/document-ai
Re: How we made our OCR code more accurate
#49Tesseract OCR was created by digital (DEC) in 19_8_5 (yes, 40 not four YEARs ago). Now go back and read the article and ROFL with me.
What is this argument? Much software we use today was created in the 80s.
Re: How we made our OCR code more accurate
#50Earlier quoted context omitted.
I don't know that that is true: https://researchify.io/blog/comparing-pytesseract-paddleocr-... Using Surya gets you significantly better results and makes almost all the work detailed in the article largely unnecessary.
Surya weights for the models are licensed cc-by-nc-sa-4.0 so not free for commercial usage. Also, as far as I know, the training data is 100% unavailable. Given they use well trained, but standard models, it isn't really open source and barely, maybe, open weight. I kinda hate how their repo says gpl cause that is only true for the inference code. The training code is closed source.