You’ve probably run into this at work: you capture chat threads and web pages as screenshots for later reference, only to discover that the text inside those images is not searchable when you actually need it. Or an important signed and stamped contract has to be scanned into a PDF to preserve the original record, but when you need to look something up or quote a passage, you can’t search within it, can’t copy from it, and are left paging through the document and retyping it by hand.
That’s the problem Gety’s built-in OCR is meant to solve.
To see how well it does that, we ran Gety’s built-in OCR against the local OCR options people are most likely to use: PaddleOCR (PP-OCRv6), the strongest open-source contender; Tesseract, the long-standing baseline; and the OCR built into macOS and Windows. The test uses document images from two public datasets, MDPBench and OmniDocBench.
Cloud OCR services and cloud models such as Gemini are not included here. They require an upload, an API call, an internet connection, and often usage-based pricing. That makes them a different category from OCR that runs locally on your own machine.
The results show two clear advantages for Gety’s built-in OCR:
- Among local, on-device OCR engines, Gety ranks first in multilingual accuracy, with the strongest overall result across 17 languages.
- It uses roughly one-fifth the memory of comparable on-device models, making long-running background OCR and real-time indexing practical.
1. Multilingual: where Gety pulls furthest ahead
Many OCR engines handle Latin-script languages such as English and French well enough. The trouble starts when the script changes. Switch to Korean, Russian, Thai, or Hindi and many scores fall from above 0.9 to 0.2 or even 0.1, low enough that the output stops being useful. Here’s how the field does across the 17 languages, using the document images from MDPBench:
| Language / Metric | Gety OCR (built-in) | Apple Vision (built-in) | PP-OCRv6(small) | PP-OCRv6(tiny) | Windows OCR | Tesseract |
|---|---|---|---|---|---|---|
| Overall (F1) | 0.903 | 0.881 | 0.724 | 0.686 | 0.609 | 0.541 |
| Latin scripts (avg.) | 0.966 | 0.940 | 0.967 | 0.957 | 0.847 | 0.901 |
| English | 0.978 | 0.962 | 0.972 | 0.972 | 0.882 | 0.919 |
| German | 0.959 | 0.967 | 0.992 | 0.991 | 0.923 | 0.962 |
| French | 0.947 | 0.799 | 0.982 | 0.977 | 0.795 | 0.940 |
| Spanish | 0.920 | 0.923 | 0.927 | 0.923 | 0.819 | 0.872 |
| Italian | 0.980 | 0.976 | 0.985 | 0.979 | 0.887 | 0.932 |
| Portuguese | 0.978 | 0.983 | 0.980 | 0.972 | 0.797 | 0.840 |
| Dutch | 0.994 | 0.924 | 0.995 | 0.995 | 0.967 | 0.974 |
| Indonesian | 0.974 | 0.966 | 0.987 | 0.987 | 0.892 | 0.959 |
| Vietnamese | 0.967 | 0.958 | 0.884 | 0.814 | 0.661 | 0.716 |
| Non-Latin scripts (avg.) | 0.832 | 0.814 | 0.452 | 0.382 | 0.343 | 0.136 |
| Chinese (Simplified) | 0.946 | 0.912 | 0.965 | 0.957 | 0.800 | 0.180 |
| Chinese (Traditional) | 0.924 | 0.805 | 0.939 | 0.862 | 0.853 | 0.142 |
| Japanese | 0.916 | 0.804 | 0.924 | 0.525 | 0.454 | 0.173 |
| Korean | 0.970 | 0.961 | 0.276 | 0.248 | 0.211 | 0.190 |
| Russian | 0.954 | 0.960 | 0.155 | 0.106 | 0.096 | 0.102 |
| Thai | 0.951 | 0.974 | 0.155 | 0.137 | 0.150 | 0.125 |
| Hindi | 0.958 | 0.136 | 0.191 | 0.178 | 0.140 | 0.147 |
| Arabic | 0.039 | 0.962 | 0.011 | 0.046 | 0.037 | 0.031 |
The row to watch is the non-Latin average. While many local engines drop into the 0.1 to 0.4 range, Gety holds at 0.832. In practice, that means documents with Chinese, Japanese, Korean, or Russian text are much less likely to become invisible to search simply because the script changed.
Photographed documents are a harder problem. When the input is a photo of a document rather than a clean digital file, with blur, skew, or glare, every model struggles:
| Model | Digital-Born (F1) | Photographed (F1) |
|---|---|---|
| Gety OCR (built-in) | 0.903 | 0.322 |
| Apple Vision (built-in) | 0.881 | 0.421 |
| PP-OCRv6(small) | 0.724 | 0.301 |
| PP-OCRv6(tiny) | 0.686 | 0.289 |
| PP-OCRv5 mobile | 0.707 | 0.278 |
| PaddleOCR (PP-OCRv4) | 0.630 | 0.172 |
| Windows OCR | 0.609 | 0.185 |
| Tesseract | 0.541 | 0.192 |
No model is strong here yet. Scores fall from the 0.9 range into the 0.2 to 0.4 band across the board. Apple Vision leads this case at 0.421, while Gety is slightly ahead of the open-source models. For everyday search, though, the left column matters more: most files people expect to search are clean screenshots and scans, not crooked photos of documents.
2. Complex layouts: in the same top tier as the best open-source model
Language is one axis. Layout is the other. Multi-column pages, tables, headers, footers, and mixed document structures are where weaker models start dropping lines or scrambling their order. OmniDocBench is built to stress exactly that:
| Model | Layout accuracy (F1) |
|---|---|
| Gety OCR (built-in) | 0.963 |
| PP-OCRv6(small) | 0.968 |
| PP-OCRv6(tiny) | 0.963 |
| Apple Vision (built-in) | 0.948 |
| Windows OCR | 0.855 |
| Tesseract | 0.538 |
Gety’s 0.963 is only half a percentage point behind PP-OCRv6 small at 0.968, a gap users are unlikely to feel in practice. Both sit in the top tier, clearly ahead of the built-in system OCR options.
3. The same accuracy, a fraction of the footprint
Reading well is one thing. Reading well cheaply enough to leave running all day is another. On the same machine, with the same inputs, on CPU:
| Model | Multilingual accuracy (F1) | Median time per page | Peak memory per page |
|---|---|---|---|
| Gety OCR (built-in) | 0.903 | 862 ms | 908 MB |
| PP-OCRv6(tiny) | 0.686 | 607 ms | 4736 MB |
| PP-OCRv6(small) | 0.724 | 2594 ms | 6304 MB |
Gety needs about 908 MB per page. PP-OCRv6’s tiny and small builds need 4.7 GB and 6.3 GB, five to seven times more. That’s the difference between a model that can stay resident and one better suited to on-demand jobs. Because Gety is light, it can keep running in the background, catch new files as they arrive, and index them without you lifting a finger.
(Apple Vision and Windows OCR run inside their own platform stacks, so a memory or speed comparison would not be apples to apples. They appear in the accuracy tables only.)
4. What we tested on, and against
The datasets
We used document images from two public datasets, each answering a different question:
| Dataset | The question it answers |
|---|---|
| MDPBench | Does accuracy hold up across 17 languages, on both clean and photographed pages? |
| OmniDocBench | Does it stay accurate when the layout gets complicated? |
The two datasets measure different things, so we report them separately rather than blending them into one score. To be clear about what this is: we used these datasets as a source of document images. The evaluation method, the metrics, and the set of models are our own, and differ from the official evaluations published by the dataset authors.
How we score
We score OCR output with a layout-agnostic, character-level F1. It measures only whether the text was recognized correctly, not layout, line breaks, paragraph structure, or where the text sits on the page.
We keep it layout-agnostic because for the uses that matter (search, copy, indexing), what counts is whether every character was read correctly, not whether the layout was reconstructed. Text that’s all correct but in a different order or with different line breaks shouldn’t be penalized. This is an OCR test, not a layout test.
For each page, we compare the OCR output against the hand-labeled text and compute:
Before scoring, the ground truth and the OCR output both go through the same normalization: Unicode normalization, stripping invisible characters, unifying whitespace, and removing page furniture such as headers, footers, and page numbers.
Character matching uses multiset counting: a character that appears several times is counted each time. This keeps differences in reading order, line breaks, and paragraph splits from affecting the score, so the metric stays focused on whether the OCR read the page’s characters correctly.
Final figures are F1 per page, macro-averaged across languages and data groups; the full report also gives a bootstrap 95% confidence interval.
What we compared against
For the comparison set, we tried to cover the mainstream options users are likely to encounter in real-world workflows:
- PaddleOCR (PP-OCRv6), the strongest open-source OCR option today. It ships in tiny, small, and medium; we ran the two on-device builds, tiny and small. Medium is a 34.5M-parameter model meant for server GPUs, and dropping it into an on-device CPU test would be comparing the wrong things.
- Tesseract, the long-standing open-source engine, widely installed and familiar as a baseline.
- Apple Vision and Windows OCR, the OCR you already have if you install nothing at all.
5. Accuracy is the baseline. Usability is the point.
The numbers show that Gety reads accurately. But accuracy is not the finish line; it is the baseline for a useful OCR experience.
The usual OCR workflow looks something like this:
Find the image -> Open or drag it into an OCR tool -> Start recognition manually -> Wait for the result -> Get usable textMost of the time, that chain never starts. Screenshots and scans become blind spots the moment they land on your computer, and they stay invisible to search until you remember to process them.
That gap is the problem Gety set out to close. OCR runs in the background, so the moment an image file lands, Gety can recognize and index it automatically. Nothing to convert, nothing to click. When you need it, you type into the global search box and the text inside the image is there.
Accuracy decides the quality of recognition. Resource use decides whether that recognition can be always on. We did not set out to ship one more OCR engine; we set out to make “the words in this image aren’t searchable” a problem that stops happening on your computer.
These are our own internal results. We used the document images from the public datasets MDPBench and OmniDocBench as test material, but the evaluation method and metrics are our own and differ from the official evaluations published by the dataset authors. Each dataset carries its own license and usage terms, some research-only; we’re reporting findings here, not redistributing any samples.