Advancing WordArt-Oriented Scene Text Recognition: Datasets and Methods

Recognizing artistic text—often called "WordArt"—is a fundamentally different beast than standard Scene Text Recognition (STR). While typical OCR tasks deal with legible, horizontally aligned characters on signs, WordArt involves highly customized fonts, complex textures, and non-linear layouts.

Current industry standards for STR are optimized for regularity. Most models rely on fixed-template inputs. This means they resize incoming images to a standard aspect ratio before processing. This works for a street sign. However, it destroys the geometry of a curved, stretched, or vertically oriented artistic logo. Because real-world artistic text is rare and expensive to annotate, existing datasets are too small. This leaves a massive performance gap between general-purpose Vision-Language Models (VLMs) and specialized OCR tools.

The breakdown of fixed-template STR

The status quo in STR hits a wall when faced with the visual chaos of WordArt. As shown in, artistic text can embed semantic elements directly into character contours.

This creates heavy visual distractions. Most mainstream models struggle here. Many use Connectionist Temporal Classification (CTC—a method for aligning 2D images to 1D text) or Parallel Decoding (PD—predicting all characters simultaneously for speed). These methods expect a predictable reading order and shape.

The primary bottleneck is twofold: data scarcity and architectural rigidity. Current training sets for artistic text are often tiny. Some provide fewer than 5,000 images. This is insufficient for optimizing large-scale models. Furthermore, the standard practice of resizing images to a fixed shape (e.g., 32x128) causes severe distortion. Even recent attempts at multi-shape resizing require manual template design. Such methods lack the flexibility needed to cover the infinite permutations of artistic typography.

Scaling with dual-pathway synthesis

To solve the data problem, the authors construct WATER-S. This is a 2-million-image synthetic dataset. It is designed to provide both controllability and diversity. Instead of relying on one generation method, they implement two complementary pipelines :

1. Tool-based Rendering (WATER-T): This uses an upgraded engine called SynthWordArt. It leverages a library of 11,250 artistic fonts. It applies explicit layout rules for curved, vertical, and multi-oriented text. This provides high precision and perfect label accuracy. It is essential for teaching a model basic character shapes.
2. Model-based Generation (WATER-Z): To capture the "naturalness" of real designs, the authors use a VLM (Qwen3-VL-8B) to mine fine-grained captions from real artistic text. These captions are expanded into a prompt library. They are then fed into a generative model (Z-Image-Turbo) to synthesize images. This captures the complex interplay between text and background textures.

On the model side, they introduce WATERec. The architecture breaks the fixed-template bottleneck by using a NaViT-like encoder. This encoder employs Rotary Positional Embeddings (RoPE—a method of applying position-dependent rotations to query and key vectors). This supports arbitrary-shaped inputs. By preserving the native aspect ratio, the model avoids geometric distortion .

This is paired with an autoregressive (AR) decoder. This decoder predicts characters step-by-step to better handle non-standard reading orders.

90% accuracy and the VLM gap

The results suggest that specialized architecture and massive synthetic scaling can bridge the gap that general VLMs cannot. The authors report that WATERec achieves 90.40% accuracy on the WordArt-Bench when trained on combined WATER-R (real) and WATER-S (synthetic) datasets. This is the first time a model has crossed the 90% threshold on this benchmark.

Crucially, the paper demonstrates that specialized models still lead massive general-purpose VLMs. On the same WordArt-Bench, the best-performing general VLMs hover around 78.36% accuracy. OCR-specialized VLMs reach 81.54% . Even after supervised fine-tuning (SFT—adjusting a model on specific data) with the new synthetic data, an 8B-parameter VLM only reached 84.78% accuracy. This failed to match the performance of the much smaller (~26M parameter) WATERec.

Regarding computational costs, model-based synthesis (WATER-Z) is significantly more expensive than tool-based rendering (WATER-T). However, the combination is necessary for robustness. For inference, WATERec maintains a competitive profile. It runs at approximately 361.66 FPS on an NVIDIA V100. This shows that moving to an AR-decoder and arbitrary-shape encoder does not cause a massive latency penalty compared to existing Transformer-based STR methods.

Diminishing returns and noise limits

There are two main caveats to consider. First, there is a clear limit to how much synthetic data helps. The authors' ablation studies show a "rise-then-saturate" pattern. Increasing WATER-S from 1M to 2M samples provides consistent gains. However, pushing to 3M samples leads to marginal improvements. In some subsets, it even causes slight regressions. This suggests that once the model covers the stylistic distribution, extra synthetic data introduces noise.

Second, the generative component (WATER-Z) is inherently noisy. Unlike the tool-rendered WATER-T, the generative model cannot guarantee 100% character correctness. The authors found that the error rate for WATER-Z was approximately 12.56% under certain criteria. While they argue that the inclusion of the label-accurate WATER-T mitigates this, practitioners should be aware of this risk. Relying too heavily on purely generative pipelines could introduce label noise into the training loop.

The verdict

If your production requirements involve recognizing logos, stylized brand names, or decorative signage, this paper is a mandatory read. The move toward arbitrary-shape modeling via RoPE is the correct architectural evolution. The most actionable takeaway is the data strategy. Do not rely solely on one synthesis method. The synergy between the "perfect" labels of tool-based rendering and the "realistic" textures of generative models drives the performance jump.

The code and data are reportedly available at https://github.com/YesianRohn/WATER. If you are building a general-purpose OCR engine, the WATERec architecture is likely overkill. However, for any specialized "creative" OCR task, this is the new baseline.

Figures from the paper