Launching today
space ocr
OCR that checks its own answers, as an app or an API
41 followers
OCR that checks its own answers, as an app or an API
41 followers
space ocr turns photos of receipts, invoices and forms into a table you can query. Drop them into a folder in the app or send them to the API, and each page becomes a row you can filter and sort. Every value shows where it came from. 100 free pages a month.
Hi Product Hunt,
I made space ocr because I kept not trusting OCR output.
Reading a document is the easy part now. Knowing whether the number you got back is the number actually printed on the paper is not. If you still have to open the image and check by hand, you haven't really automated anything.
There are two ways in, and both run the same pipeline.
If you don't want to write code, you upload photos into a folder and they become a sheet. Hover any cell and the photo beside it lights up on the exact spot that value was read from, zoomed in, so checking a page takes a second instead of a squint. Cells that failed the check are marked, so you know which ones to look at rather than rereading all of them. Fix a value by hand and your correction sticks. Folders, memos and search across everything you have scanned are in there too.
If you do write code, three endpoints give you structured fields, markdown, or plain text, and all of them come back with the same verification data: where each value sits on the page, whether it passed the check, and what still needs a look.
Either way the results stay somewhere you can use, so there is no database to stand up. A folder and a sheet are the storage. Photos land in the sheet as rows of the columns you asked for, and later you can ask that sheet for the rows over an amount, or from one vendor, newest first, a page at a time. That runs on the server, it does not read the images again, and it is not charged. The rows keep the coordinates and the flags they were stored with, so a filtered answer is as checkable as a single scan.
If you would rather have an agent do the filing, there is a hosted MCP server on the same account. You point an MCP client at one URL with your key and it can make the folders and sheets, upload photos into them, and ask for rows later. Deleting is the one thing it cannot do in one step. The first call removes nothing and reports what would go, so it has to come back to you before anything disappears.
The checking itself is the part I care about. The model never produces coordinates. Every value it returns is matched character by character against what the OCR engine actually saw on the page. Values that fail get flagged instead of quietly passing, and the ones it still isn't sure about are cropped out of the image and read a second time.
I measured this on my own regression corpus, 333 hand graded cells from phone photos rather than flat scans. Turning the checking stages off drops accuracy from 93.7% to 91.3%. They fixed 22 cells and broke none. A value marked unverified turns out to be wrong 6.4 times more often than average, so the flag is worth acting on.
100 pages a month are free and failed scans are never billed. Same price whichever way you use it.
What I would really like to hear: what would make you trust OCR output enough to skip the manual check? That is the part I keep getting wrong.
Yongha
The 333 cell corpus and the 3 in 4 flag precision are unusually honest for a launch page. The number I'd want next is the other direction, of the cells that were actually wrong, how many did the check miss. Precision tells me the flags are worth reading, recall tells me whether I can skip the unflagged rows, and skipping is the whole product. If recall is weak then a self check is worse than no check, because it's the thing that stops people looking.
@asadmalik901 Recall is the worse number. 39 of the 333 cells were problems, meaning the value disagreed with the hand transcription or the coordinate did not spell its own value. text_verified: false landed on 8 cells, 6 of them real, so it caught 6 of the 39. needs_review is wider and gets 10 of the 25 coordinate errors. There is no combined figure across all 39, so those are the pieces.
The check compares a value against what the OCR pass read at that spot, so it only sees the two disagreeing. Wrong column, value never returned, both readings wrong the same way. None of that shows up. There is a fourth I did not expect. Most of the silently wrong cells were anchored to the wrong occurrence of a string that is printed on the page, and re-reading the crop passes those, since it checks what was read and not where.
Half agree on the last sentence. Sold as permission to stop looking it would be worse than nothing, and I try not to sell it that way. It sits under schema validation and business rules, not instead of them. The ablation also shows the reading improving before flags come into it, 22 cells corrected and 0 broken, scored cell by cell. So the claim is smaller than skipping the manual check. It cuts down what you look at.
Recall is the next thing to move and the harder half, since what it misses is where both readings agree. Method and per stage tables at space-ocr.com/articles/measuring-ocr-verification
the provenance-per-value thing is the part I'd actually pay for. most OCR tools give you a confident-looking number and no way to tell if it read the receipt correctly or just guessed something plausible from a smudge. what happens when the self-check disagrees with the first pass - does it flag the cell as low-confidence for a human to glance at, or silently pick whichever answer scored higher internally? for invoices specifically the failure mode that costs money is a confident wrong number, not a missing one.
@galdayan It never overwrites. The value the model returned is the value you get, and the re-read only decides what gets said about it. If the crop confirms it, text_verified goes to true. If it disagrees, the cell keeps its original value and carries crop_mismatch as a review reason. If the crop comes back empty it abstains and writes nothing, since an empty read on a single glyph is usually a lack of context rather than evidence of anything. There is no internal score picking a winner behind your back.
So a disagreement always surfaces. review_summary at the top of the response lists the flagged paths, and in the app those cells are coloured and open next to the region of the photo they were read from, which is the part that makes glancing at one cheap.
Agreed on the failure mode, and it is the one this is built around. Worth knowing the edge: the re-read checks what was read, not where it was read. A value that is correct but anchored to the wrong occurrence of the same string on the page passes it. For an invoice total that is usually harmless, but I would rather you hear it from me.