Skip to content
← Blog

The Hidden Reason OCR Chokes on Curved and Tilted Text

Based on: 2D Rotary Position Embedding for Scene Text Recognition with Transformers — Zobeir Raisi

Point your phone at a shampoo bottle and try to read the ingredients list wrapping around the curve. Your eyes do it without thinking: they track the letters as they bend, tilt, and shrink toward the edge. Most OCR models don't do this nearly as well, and a new preprint gives a pretty specific explanation of why: the models were never told that images have two dimensions.

That sounds absurd for a system built to process pictures. But the explanation, once you see it, is one of those "of course" moments that makes you wonder how it went unnoticed this long.

curved beverage bottle label text

Why straight lines are a bad assumption for real-world text

Scene Text Recognition, or STR, is the specific job of reading text that lives inside a photo of the real world rather than a clean scan. Street signs, product labels, license plates, restaurant menus photographed under bad lighting. It's a different problem from reading a PDF or a Word document, because the text itself is deformed by the physics of the world: it curves around bottles, it's shot at an angle, it tilts when someone photographs a sign without lining up the camera, and perspective stretches letters that are farther from the lens.

Modern STR systems are mostly Transformers, the same architecture behind large language models. An encoder looks at the image and breaks it into a grid of small patches, then a decoder reads out characters one at a time, the way a language model predicts the next word. This works well for regular, forward-facing text. It gets shaky the moment the text stops behaving like a straight line.

Here's the part that's easy to miss: Transformers don't have any built-in sense of position. If you hand a Transformer a jumbled bag of image patches with no location information, it can't tell top from bottom or left from right. Every Transformer needs some kind of positional encoding bolted on, and it turns out the choice of that encoding matters more than most people assume.

How Transformers know where things are, and where the shortcut breaks

The positional encoding scheme borrowed from language models is called RoPE, short for Rotary Position Embedding. It's used in most modern open language models, including LLaMA. The idea is to rotate each token's vector by an amount tied to its position in the sequence, so that when two tokens are compared during attention, the result naturally reflects how far apart they are. Think of it like a clock hand: rotate it by a set amount per step, and the angle between any two hands tells you the distance between them without needing to store that distance explicitly.

RoPE was designed for 1D sequences: words in a sentence, one after another. Images are 2D, so researchers built an extension called axial 2D-RoPE for vision Transformers, which splits the rotation into two independent pieces: one tracking row position, one tracking column position.

That extension carries two assumptions baked in from the start, and this paper argues both break for scene text.

The first assumption is that images are roughly square. Split your rotation budget evenly between rows and columns, and that's fine for a photo of a face or a landscape. But a cropped word like "STOP" might be four times wider than it is tall. Spend half your positional resolution on height when almost nothing distinctive happens vertically, and you've starved the dimension that actually matters: the one carrying the left-to-right order of the letters.

The second assumption is where the encoding gets applied. Prior 2D-RoPE work only rotated vectors inside the encoder, where image patches attend to each other. But STR models are encoder-decoder: the decoder generates characters one at a time and, at each step, looks back at the encoder's grid of image patches through what's called cross-attention. That's the moment where the model decides "given the letters I've already read, where in the image should I look next?" If the positional math never touches that step, the decoder is navigating a 2D image with no compass. It has to fall back on generic learned position tags that carry no real notion of "up," "down," "left of," or "right of."

Two fixes, no new parameters

The paper's fix addresses both gaps directly, and the part I find genuinely appealing is that neither change adds any new weights to the model. This isn't a bigger network or a new module bolted on. It's a change to how the existing rotation math is configured.

The first fix allocates the rotary dimensions unevenly, matching the aspect ratio of the actual text crop instead of splitting 50/50. A wide, short crop gets more positional resolution along its width and less along its height, matching where the information actually lives.

The second fix extends the same rotational coupling into cross-attention, giving the decoder's queries and the encoder's 2D grid a shared geometric frame of reference. In practice, that means a decoding step can relate "the next character I'm about to predict" to "the patch of image just past the last character, following the curve of the text," instead of treating the whole image as an undifferentiated pile of tokens.

Free lunches this specific are rare in machine learning, so I'd want to see the fix reproduced outside the author's own runs before fully believing in it. But the theory holds together, and it maps onto a failure mode anyone who has actually tried to OCR a real product photo will recognize instantly.

tilted street sign photograph

A protocol built to resist wishful thinking

What sets this paper apart from a typical "our positional encoding gets better numbers" result is the care taken to prove the improvement comes from where the authors claim it comes from, not from some unrelated side effect of retraining.

Three checks do that work. First, a controlled ablation pair: keep the entire model identical and swap out only the positional encoding module, comparing 1D RoPE, 2D sinusoidal encoding, 2D learnable encoding, and their new 2D-RoPE-STR against each other. That isolates the one variable that changed.

Second, an image-level disagreement analysis. Instead of reporting a single aggregate accuracy number (which can hide as much as it reveals, since a flat average can mask big wins on some images canceled out by losses on others), the authors look at which specific images flip from wrong to right, and which flip the other way, between the baseline and the new method. That's a much harder test to game, because it forces the authors to show their gains concentrate somewhere specific rather than being spread thin and uneven.

Third, attention visualization: literally plotting where the encoder's attention weights land during decoding, to check whether the model is visually tracking the curve of the text the way you'd hope, rather than getting lucky on a benchmark.

Where the gains actually show up

The six benchmarks used here, IIIT5K, SVT, ICDAR 2013, ICDAR 2015, CUTE80, and SVTP, are the standard test set for this subfield. The first three are mostly straightforward, frontal, horizontal text. The last three are the ones researchers specifically use to stress-test irregular text: ICDAR 2015 has a lot of tilted and low-quality signage, CUTE80 is full of curved text, and SVTP leans heavily on perspective distortion.

According to the abstract, the improvements concentrate almost entirely on that second, harder group: curved, rotated, and perspective-warped layouts where reading order departs from a straight horizontal line. That's a coherent story, not a scattershot one. It says the fix is doing exactly what the reasoning behind it predicted, rather than nudging every benchmark up by a similar small margin the way a lot of "better position encoding" papers tend to.

I'll flag the obvious caveat: the arXiv abstract doesn't publish the actual accuracy tables, and I couldn't pull specific percentage gains from the listing itself. The paper is currently under review at the International Journal on Document Analysis and Recognition, so treat this as a promising, mechanistically well-argued result rather than a settled one until the full numbers are public and someone outside the original team reproduces them.

What's still unproven

A few things are worth sitting with before getting too excited.

This is a single-author paper still in peer review, not yet accepted. That doesn't make it wrong, but it does mean the usual community scrutiny (replication, adversarial review, someone trying to break it on a different dataset) hasn't happened yet.

The six benchmarks are all academic, English-centric, and were assembled between roughly 2003 and 2016. They're a reasonable proxy for "text in photos," but they're not the same as the wildly varied documents a production OCR pipeline sees: mixed scripts, phone camera noise, low light, motion blur, receipts photographed at 2am on a bad phone. Whether this positional-encoding fix generalizes to that mess is an open question the paper doesn't claim to answer.

It's also worth being precise about scope. This targets the recognition step, reading characters inside a crop that some upstream detector has already identified as containing text. It doesn't touch document layout, table structure, or full-page reading order. If your OCR problem is scanned invoices and contracts, this fix is aimed at a different failure mode than the ones that usually bite you there.

Why it matters for anyone building or choosing OCR

If most of what you're feeding into OCR is clean, frontal documents (invoices, scanned contracts, forms), don't expect this particular fix to move your accuracy much. The paper's own results say the gains cluster on irregular layouts, and clean documents are, almost by definition, not irregular.

But if your product touches photos of the physical world, product labels, street signage, packaging, receipts photographed at an angle on a phone, this targets exactly the failure mode that tends to embarrass OCR systems in demos: text that curves, tilts, or gets stretched by perspective. That's a real and common category of input, and "the model literally has no 2D sense of position" is a satisfying, fixable explanation for why it keeps failing there.

The part that should matter most to anyone evaluating engines is the "no new parameters" claim. If it holds up under independent testing, it means better handling of distorted text doesn't have to come with a bigger, slower, more expensive model bolted on top. That's a genuinely useful property if you're trying to keep inference costs sane while chasing accuracy on messy real-world images. For now, the sensible move is to keep an eye on this line of work rather than act on it: watch for the full paper's tables, watch for independent reproductions, and keep judging OCR engines primarily by how they perform on your own users' actual uploads. Benchmarks tell you where to look. They don't replace testing against the weird, curved, badly lit photos your customers are actually going to send you.