Live data from Hacker News

How we made our OCR code more accurate

pieces.app

41–50 of 50 posts

Re: How we made our OCR code more accurate

#42

I 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?

Pieces is (correction: used to be, prior to the AI slopification) an app for storing code snippets. so i think you can imagine the general idea of, e.g., "cool API usage example from a YouTube video, let me screenshot it!"

Re: How we made our OCR code more accurate

#43

I 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?

> can't say I've ever wanted to transcribe code from an image. That seems super niche.

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

#44
post #38
post #9

Earlier 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.

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.

Re: How we made our OCR code more accurate

#45

Earlier 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).

Surya weights for the models are licensed cc-by-nc-sa-4.0. They have an exception for small companies. If you're company is not small you either need to pay them or use them illegally.

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

#47
post #35
post #17

Tesseract 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?

No son, Linux is not a version of Unix anymore than MINIX is.

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

#48
post #26

Earlier 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.)

Yeah it is, it does (especially with OOP) and "ABBYY" kicked Tesseract's arse a long time ago anyway.

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

#49
post #17

Tesseract 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.

Not the actual implementations heh ...I heard even Linus has dropped support for the 486. Even the infra is finally giving way...did you see the NVLINK SPINE announcement a few days ago? It's going to be deployed in Stargate UAE that was announced Thursday.

Re: How we made our OCR code more accurate

#50
post #44
post #38

Earlier 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.

I did not know that the training code is closed source. That is troubling.
Post reply on HN