Práctica de OCR en el dispositivo: Despliegue nativo de PP-OCRv5 en Android

Notas

Esta entrada de blog:

Portada: Generada con Google Nano Banana 2, sin derechos de autor.
Código fuente del proyecto: Código abierto en GitHub, visite PPOCRv5-Android para obtenerlo.

Descargo de responsabilidad:

El autor (Fleey) no es un profesional del campo de la IA, esto es puramente por interés personal. Si hay omisiones o errores en el texto, espero que los lectores lo comprendan y me corrijan a tiempo.

Introducción

En 2024, Google cambió el nombre de TensorFlow Lite a LiteRT. Esto no es solo un cambio de marca, sino que marca una transición de paradigma en la IA en el dispositivo (on-device AI) de “móvil primero” a “borde primero” (edge-first) ¹. En este contexto, el OCR (Reconocimiento Óptico de Caracteres), como una de las aplicaciones de IA en el dispositivo más valiosas, está experimentando una revolución silenciosa.

El equipo de PaddleOCR de Baidu lanzó en 2025 el PP-OCRv5, un modelo de OCR unificado que admite múltiples idiomas, incluidos chino simplificado, chino tradicional, inglés y japonés ². Su versión móvil pesa solo unos 70 MB, pero puede realizar el reconocimiento de 18,383 caracteres en un solo modelo. Detrás de esta cifra se encuentra el trabajo coordinado de dos redes neuronales profundas: detección y reconocimiento.

Pero el problema es: PP-OCRv5 se entrena basándose en el framework PaddlePaddle, mientras que el motor de inferencia más maduro en dispositivos Android es LiteRT. ¿Cómo cruzar esta brecha?

Comencemos con la conversión del modelo para desvelar paso a paso la ingeniería detrás del OCR en el dispositivo.

1
flowchart TB
2
    subgraph E2E["Flujo OCR de extremo a extremo"]
3
        direction TB
4

5
        subgraph Input["Entrada"]
6
            IMG[Imagen original<br/>Cualquier tamaño]
7
        end
8

9
        subgraph Detection["Detección de texto - DBNet"]
10
            DET_PRE[Preprocesamiento<br/>Resize 640x640<br/>Normalización ImageNet]
11
            DET_INF[Inferencia DBNet<br/>~45ms GPU]
12
            DET_POST[Post-procesamiento<br/>Binarización - Contornos - Rectángulo rotado]
13
        end
14

15
        subgraph Recognition["Reconocimiento de texto - SVTRv2"]
16
            REC_CROP[Recorte por transformación de perspectiva<br/>48xW ancho adaptativo]
17
            REC_INF[Inferencia SVTRv2<br/>~15ms/línea GPU]
18
            REC_CTC[Decodificación CTC<br/>Combinar repetidos + Eliminar espacios]
19
        end
20

21
        subgraph Output["Salida"]
22
            RES[Resultados OCR<br/>Texto + Confianza + Posición]
23
        end
24
    end
25

26
    IMG --> DET_PRE --> DET_INF --> DET_POST
27
    DET_POST -->|N cuadros de texto| REC_CROP
28
    REC_CROP --> REC_INF --> REC_CTC --> RES

Conversión de modelos: El largo viaje de PaddlePaddle a TFLite

La fragmentación de los frameworks de aprendizaje profundo es un punto de dolor en la industria. PyTorch, TensorFlow, PaddlePaddle, ONNX; cada framework tiene su propio formato de modelo e implementación de operadores. ONNX (Open Neural Network Exchange) intenta ser una representación intermedia universal, pero la realidad suele ser más cruda que el ideal.

La ruta de conversión del modelo PP-OCRv5 es la siguiente:

1
flowchart LR
2
    subgraph PaddlePaddle["Framework PaddlePaddle"]
3
        PM[inference.json<br/>inference.pdiparams]
4
    end
5

6
    subgraph ONNX["Intermedio ONNX"]
7
        OM[model.onnx<br/>opset 14]
8
    end
9

10
    subgraph Optimization["Optimización de grafo"]
11
        GS[onnx-graphsurgeon<br/>Descomposición de operadores]
12
    end
13

14
    subgraph TFLite["Formato LiteRT"]
15
        TM[model.tflite<br/>Cuantización FP16]
16
    end
17

18
    PM -->|paddle2onnx| OM
19
    OM -->|Descomposición HardSigmoid<br/>Modificación modo Resize| GS
20
    GS -->|onnx2tf| TM

Este camino parece sencillo, pero esconde varios desafíos.

El primer obstáculo: Compatibilidad de operadores de paddle2onnx

paddle2onnx es la herramienta oficial de conversión de modelos proporcionada por PaddlePaddle. En teoría, puede convertir modelos de PaddlePaddle al formato ONNX. Sin embargo, PP-OCRv5 utiliza algunos operadores especiales cuyo mapeo en ONNX no es uno a uno.

paddle2onnx --model_dir PP-OCRv5_mobile_det \
  --model_filename inference.json \
  --params_filename inference.pdiparams \
  --save_file ocr_det_v5.onnx \
  --opset_version 14

Aquí hay un detalle clave: el nombre del archivo del modelo PP-OCRv5 es inference.json en lugar del tradicional inference.pdmodel. Este es un cambio en el formato de modelo de las nuevas versiones de PaddlePaddle que ha causado confusión a muchos desarrolladores ³.

El segundo obstáculo: HardSigmoid y compatibilidad con GPU

El modelo ONNX convertido contiene el operador HardSigmoid. Este operador se define matemáticamente como:

\text{HardSigmoid}(x) = \max(0, \min(1, \alpha x + \beta))

Donde $\alpha = 0.2$ y $\beta = 0.5$ .

El problema es que el GPU Delegate de LiteRT no admite HardSigmoid. Cuando un modelo contiene operadores no compatibles, el GPU Delegate realiza un “fallback” de todo el subgrafo a la CPU, lo que provoca una pérdida grave de rendimiento.

La solución es descomponer HardSigmoid en operadores básicos. Usando la librería onnx-graphsurgeon, podemos realizar una “cirugía” a nivel de grafo de computación:

1
import onnx_graphsurgeon as gs
2
import numpy as np
3

4
def decompose_hardsigmoid(graph: gs.Graph) -> gs.Graph:
5
    """
6
    Descompone HardSigmoid en operadores básicos amigables para GPU
7
    HardSigmoid(x) = max(0, min(1, alpha*x + beta))
8
    Descompuesto en: Mul -> Add -> Clip
9
    """
10
    for node in graph.nodes:
11
        if node.op == "HardSigmoid":
12
            # Obtener parámetros de HardSigmoid
13
            alpha = node.attrs.get("alpha", 0.2)
14
            beta = node.attrs.get("beta", 0.5)
15

16
            input_tensor = node.inputs[0]
17
            output_tensor = node.outputs[0]
18

19
            # Crear tensores constantes
20
            alpha_const = gs.Constant(
21
                name=f"{node.name}_alpha",
22
                values=np.array([alpha], dtype=np.float32)
23
            )
24
            beta_const = gs.Constant(
25
                name=f"{node.name}_beta",
26
                values=np.array([beta], dtype=np.float32)
27
            )
28

29
            # Crear variables intermedias
30
            mul_out = gs.Variable(name=f"{node.name}_mul_out")
31
            add_out = gs.Variable(name=f"{node.name}_add_out")
32

33
            # Construir subgrafo descompuesto: x -> Mul(alpha) -> Add(beta) -> Clip(0,1)
34
            mul_node = gs.Node(
35
                op="Mul",
36
                inputs=[input_tensor, alpha_const],
37
                outputs=[mul_out]
38
            )
39
            add_node = gs.Node(
40
                op="Add",
41
                inputs=[mul_out, beta_const],
42
                outputs=[add_out]
43
            )
44
            clip_node = gs.Node(
45
                op="Clip",
46
                inputs=[add_out],
47
                outputs=[output_tensor],
48
                attrs={"min": 0.0, "max": 1.0}
49
            )
50

51
            # Reemplazar nodo original
52
            graph.nodes.remove(node)
53
            graph.nodes.extend([mul_node, add_node, clip_node])
54

55
    graph.cleanup().toposort()
56
    return graph

La clave de esta descomposición es que Mul, Add y Clip son operadores totalmente compatibles con el GPU Delegate de LiteRT. Tras la descomposición, todo el subgrafo puede ejecutarse de forma continua en la GPU, evitando el coste de transferencia de datos entre CPU y GPU.

TIP

¿Por qué no modificar directamente el código de entrenamiento del modelo? Porque el cálculo del gradiente de HardSigmoid durante el entrenamiento es diferente al de Clip. La descomposición solo debe realizarse en la etapa de inferencia para mantener la estabilidad numérica del entrenamiento.

El tercer obstáculo: Modo de transformación de coordenadas del operador Resize

El operador Resize de ONNX tiene un atributo coordinate_transformation_mode, que determina cómo se mapean las coordenadas de salida a las de entrada. PP-OCRv5 utiliza el modo half_pixel, pero el soporte del GPU Delegate de LiteRT para este modo es limitado.

Cambiarlo al modo asymmetric puede mejorar la compatibilidad con la GPU:

1
for node in graph.nodes:
2
    if node.op == "Resize":
3
        node.attrs["coordinate_transformation_mode"] = "asymmetric"

WARNING

Esta modificación puede causar pequeñas diferencias numéricas. En pruebas reales, el impacto de esta diferencia en la precisión del OCR es insignificante, pero en otras tareas podría requerir una evaluación cuidadosa.

Paso final: onnx2tf y cuantización FP16

onnx2tf es una herramienta para convertir modelos ONNX al formato TFLite. La cuantización FP16 (punto flotante de media precisión) es una opción común para el despliegue en dispositivos móviles; reduce el tamaño del modelo a la mitad con una pérdida de precisión aceptable y aprovecha las unidades de cálculo FP16 de las GPU móviles.

onnx2tf -i ocr_det_v5_fixed.onnx -o converted_det \
  -b 1 -ois x:1,3,640,640 -n

El parámetro -ois especifica la forma estática de la entrada. Las formas estáticas son cruciales para la aceleración por GPU, ya que las formas dinámicas obligarían a recompilar el programa de la GPU en cada inferencia, afectando gravemente al rendimiento.

Detección de texto: Binarización Diferenciable de DBNet

El módulo de detección de PP-OCRv5 se basa en DBNet (Differentiable Binarization Network) ⁴. Los métodos tradicionales de detección de texto utilizan un umbral fijo para la binarización, mientras que la innovación de DBNet consiste en permitir que la red aprenda por sí misma el umbral óptimo para cada píxel.

1
flowchart TB
2
    subgraph DBNet["Arquitectura DBNet"]
3
        direction TB
4
        IMG[Imagen de entrada<br/>H x W x 3]
5
        BB[Backbone<br/>MobileNetV3]
6
        FPN[Pirámide de características FPN<br/>Fusión multiescala]
7

8
        subgraph Heads["Salida de doble rama"]
9
            PH[Rama de mapa de probabilidad<br/>P: H x W x 1]
10
            TH[Rama de mapa de umbral<br/>T: H x W x 1]
11
        end
12

13
        DB["Binarización Diferenciable<br/>B = sigmoid k * P-T"]
14
    end
15

16
    IMG --> BB --> FPN
17
    FPN --> PH
18
    FPN --> TH
19
    PH --> DB
20
    TH --> DB

Binarización estándar vs. Binarización Diferenciable

La binarización estándar es una función escalón:

B_{i,j} = \begin{cases} 1 & \text{if } P_{i,j} \geq t \\ 0 & \text{otherwise} \end{cases}

Esta función no es diferenciable, por lo que no se puede entrenar de extremo a extremo mediante retropropagación. DBNet propone una función aproximada:

\hat{B}_{i,j} = \frac{1}{1 + e^{-k(P_{i,j} - T_{i,j})}}

Donde $P$ es el mapa de probabilidad, $T$ es el mapa de umbral (aprendido por la red) y $k$ es un factor de amplificación (establecido en 50 durante el entrenamiento).

TIP

Esta fórmula es esencialmente una función Sigmoid, solo que la entrada es $P - T$ . Cuando $k$ es lo suficientemente grande, su comportamiento se aproxima a la función escalón, pero mantiene la diferenciabilidad.

Implementación de ingeniería del flujo de post-procesamiento

En el proyecto PPOCRv5-Android, el flujo de post-procesamiento se implementa en postprocess.cpp. El flujo principal incluye:

1
flowchart LR
2
    subgraph Input["Salida del modelo"]
3
        PM[Mapa de probabilidad P<br/>640 x 640]
4
    end
5

6
    subgraph Binary["Binarización"]
7
        BT[Filtrado por umbral<br/>threshold=0.1]
8
        BM[Mapa binario<br/>640 x 640]
9
    end
10

11
    subgraph Contour["Detección de contornos"]
12
        DS[Submuestreo 4x<br/>160 x 160]
13
        CC[Análisis de componentes conectados<br/>Recorrido BFS]
14
        BD[Extracción de puntos de borde]
15
    end
16

17
    subgraph Geometry["Cálculo geométrico"]
18
        CH[Cálculo de envolvente convexa<br/>Graham Scan]
19
        RR[Rotating Calipers<br/>Rectángulo delimitador mínimo]
20
        UC[Expansión Unclip<br/>ratio=1.5]
21
    end
22

23
    subgraph Output["Salida"]
24
        TB[RotatedRect<br/>centro, tamaño, ángulo]
25
    end
26

27
    PM --> BT --> BM
28
    BM --> DS --> CC --> BD
29
    BD --> CH --> RR --> UC --> TB

En el código real, el método TextDetector::Impl::Detect muestra el proceso de detección completo:

1
std::vector<RotatedRect> Detect(const uint8_t *image_data,
2
                                int width, int height, int stride,
3
                                float *detection_time_ms) {
4
    // 1. Calcular ratio de escala
5
    scale_x_ = static_cast<float>(width) / kDetInputSize;
6
    scale_y_ = static_cast<float>(height) / kDetInputSize;
7

8
    // 2. Redimensionar a 640x640 mediante interpolación bilineal
9
    image_utils::ResizeBilinear(image_data, width, height, stride,
10
                                resized_buffer_.data(), kDetInputSize, kDetInputSize);
11

12
    // 3. Normalización ImageNet
13
    PrepareFloatInput();
14

15
    // 4. Inferencia
16
    auto run_result = compiled_model_->Run(input_buffers_, output_buffers_);
17

18
    // 5. Binarización
19
    BinarizeOutput(prob_map, total_pixels);
20

21
    // 6. Detección de contornos
22
    auto contours = postprocess::FindContours(binary_map_.data(),
23
                                              kDetInputSize, kDetInputSize);
24

25
    // 7. Rectángulo delimitador mínimo + Unclip
26
    for (const auto &contour : contours) {
27
        RotatedRect rect = postprocess::MinAreaRect(contour);
28
        UnclipBox(rect, kUnclipRatio);
29
        // Mapear coordenadas de vuelta a la imagen original
30
        rect.center_x *= scale_x_;
31
        rect.center_y *= scale_y_;
32
        // ...
33
    }
34
}

La clave de este proceso es el “rectángulo rotado delimitador mínimo”. A diferencia de los cuadros delimitadores alineados con los ejes, los rectángulos rotados pueden ajustarse estrechamente a texto en cualquier ángulo, lo cual es vital para el texto inclinado en escenas naturales.

Unclip: Algoritmo de expansión de cuadros de texto

Las áreas de texto detectadas por DBNet suelen ser ligeramente más pequeñas que el texto real, ya que la red aprende la “región central” del texto. Para obtener los límites completos del texto, es necesario realizar una operación de expansión (Unclip) sobre el polígono detectado.

El principio matemático de Unclip se basa en la operación inversa del algoritmo de recorte de polígonos de Vatti. Dado un polígono $P$ y una distancia de expansión $d$ , el polígono expandido $P'$ cumple:

$d = \frac{A \times r}{L}$

Donde $A$ es el área del polígono, $L$ es el perímetro y $r$ es el ratio de expansión (normalmente establecido en 1.5).

En postprocess.cpp, la función UnclipBox implementa esta lógica:

1
void UnclipBox(RotatedRect &box, float unclip_ratio) {
2
    // Calcular distancia de expansión
3
    float area = box.width * box.height;
4
    float perimeter = 2.0f * (box.width + box.height);
5

6
    if (perimeter < 1e-6f) return;  // Prevenir división por cero
7

8
    // d = A * r / L
9
    float distance = area * unclip_ratio / perimeter;
10

11
    // Expandir hacia afuera: aumentar ancho y alto en 2d
12
    box.width += 2.0f * distance;
13
    box.height += 2.0f * distance;
14
}

Esta versión simplificada asume que el cuadro de texto es un rectángulo. Para polígonos más complejos, se requeriría usar la librería Clipper completa para realizar el desplazamiento del polígono:

1
// Unclip de polígono completo (usando la librería Clipper)
2
ClipperLib::Path polygon;
3
for (const auto& pt : contour) {
4
    polygon.push_back(ClipperLib::IntPoint(
5
        static_cast<int>(pt.x * 1000),  // Escalar para mantener precisión
6
        static_cast<int>(pt.y * 1000)
7
    ));
8
}
9

10
ClipperLib::ClipperOffset offset;
11
offset.AddPath(polygon, ClipperLib::jtRound, ClipperLib::etClosedPolygon);
12

13
ClipperLib::Paths solution;
14
offset.Execute(solution, distance * 1000);  // Expansión

NOTE

PPOCRv5-Android optó por la expansión rectangular simplificada en lugar del desplazamiento de polígono completo. Esto se debe a que:

La mayoría de los cuadros de texto son casi rectangulares.
La librería Clipper completa aumentaría considerablemente el tamaño del binario.
El rendimiento de la versión simplificada es mejor.

Reconocimiento de texto: SVTRv2 y decodificación CTC

Si la detección es “encontrar dónde está el texto”, el reconocimiento es “leer qué dice el texto”. El módulo de reconocimiento de PP-OCRv5 se basa en SVTRv2 (Scene Text Recognition with Visual Transformer v2) ⁵.

Innovaciones en la arquitectura de SVTRv2

SVTRv2 presenta tres mejoras clave respecto a su predecesor SVTR:

1
flowchart TB
2
    subgraph SVTRv2["Arquitectura SVTRv2"]
3
        direction TB
4

5
        subgraph Encoder["Codificador visual"]
6
            PE[Patch Embedding<br/>Convolución 4x4]
7

8
            subgraph Mixing["Bloques de atención híbrida x12"]
9
                LA[Atención local<br/>Ventana 7x7]
10
                GA[Atención global<br/>Campo receptivo global]
11
                FFN[Feed Forward<br/>MLP]
12
            end
13
        end
14

15
        subgraph Decoder["Decodificador CTC"]
16
            FC[Capa totalmente conectada<br/>D -> 18384]
17
            SM[Softmax]
18
            CTC[Decodificación CTC]
19
        end
20
    end
21

22
    PE --> LA --> GA --> FFN
23
    FFN --> FC --> SM --> CTC

Mecanismo de atención híbrida: Alterna entre atención local (para capturar detalles de los trazos) y atención global (para entender la estructura de los caracteres). La atención local utiliza una ventana deslizante de 7x7, reduciendo la complejidad computacional de $O(n^2)$ a $O(n \times 49)$ .
Fusión de características multiescala: A diferencia de la resolución única de ViT, SVTRv2 utiliza diferentes resoluciones de mapas de características a distintas profundidades, similar a la estructura piramidal de las CNN.
Módulo de guía semántica (Semantic Guidance Module): Añade una rama semántica ligera al final del codificador para ayudar al modelo a entender las relaciones semánticas entre caracteres, más allá de las características visuales.

Estas mejoras permiten que SVTRv2 alcance una precisión comparable a los métodos basados en Atención, manteniendo la simplicidad de la decodificación CTC ⁶.

¿Por qué CTC en lugar de Atención?

Existen dos paradigmas principales para el reconocimiento de texto:

CTC (Connectionist Temporal Classification): Trata el reconocimiento como un problema de etiquetado de secuencias, alineando la salida con la entrada.
Decodificador basado en Atención: Utiliza un mecanismo de atención para generar la salida carácter por carácter.

Los métodos de Atención suelen ser más precisos, pero los de CTC son más simples y rápidos. La contribución de SVTRv2 es que, al mejorar el codificador visual, permite que el método CTC alcance o incluso supere la precisión de los métodos de Atención ⁶.

El núcleo de la decodificación CTC es “combinar repetidos” y “eliminar espacios”:

1
flowchart LR
2
    subgraph Input["Salida del modelo"]
3
        L["Logits<br/>[T, 18384]"]
4
    end
5

6
    subgraph Argmax["Argmax NEON"]
7
        A1["t=0: blank"]
8
        A2["t=1: H"]
9
        A3["t=2: H"]
10
        A4["t=3: blank"]
11
        A5["t=4: e"]
12
        A6["t=5: l"]
13
        A7["t=6: l"]
14
        A8["t=7: l"]
15
        A9["t=8: o"]
16
    end
17

18
    subgraph Merge["Combinar repetidos"]
19
        M["blank, H, blank, e, l, o"]
20
    end
21

22
    subgraph Remove["Eliminar espacios"]
23
        R["H, e, l, o"]
24
    end
25

26
    subgraph Output["Salida"]
27
        O["Helo - Error"]
28
    end
29

30
    L --> A1 & A2 & A3 & A4 & A5 & A6 & A7 & A8 & A9
31
    A1 & A2 & A3 & A4 & A5 & A6 & A7 & A8 & A9 --> Merge --> Remove --> Output

Un momento, aquí hay un problema. Si el texto original es “Hello”, las dos ‘l’ se han combinado erróneamente. La solución de CTC es insertar un token “blank” entre caracteres repetidos.

1
Codificación correcta: [blank, H, e, l, blank, l, o]
2
Resultado decodificado: "Hello"

Decodificación CTC optimizada con NEON

La decodificación CTC de PPOCRv5-Android utiliza Argmax optimizado con NEON. En text_recognizer.cpp:

1
inline void ArgmaxNeon8(const float *__restrict__ data, int size,
2
                        int &max_idx, float &max_val) {
3
    if (size < 16) {
4
        // Fallback escalar
5
        max_idx = 0;
6
        max_val = data[0];
7
        for (int i = 1; i < size; ++i) {
8
            if (data[i] > max_val) {
9
                max_val = data[i];
10
                max_idx = i;
11
            }
12
        }
13
        return;
14
    }
15

16
    // Vectorización NEON: procesa 4 floats a la vez
17
    float32x4_t v_max = vld1q_f32(data);
18
    int32x4_t v_idx = {0, 1, 2, 3};
19
    int32x4_t v_max_idx = v_idx;
20
    const int32x4_t v_four = vdupq_n_s32(4);
21

22
    int i = 4;
23
    for (; i + 4 <= size; i += 4) {
24
        float32x4_t v_curr = vld1q_f32(data + i);
25
        v_idx = vaddq_s32(v_idx, v_four);
26

27
        // Comparación vectorizada y selección condicional
28
        uint32x4_t cmp = vcgtq_f32(v_curr, v_max);
29
        v_max = vbslq_f32(cmp, v_curr, v_max);        // Seleccionar valor mayor
30
        v_max_idx = vbslq_s32(cmp, v_idx, v_max_idx); // Seleccionar índice correspondiente
31
    }
32

33
    // Reducción horizontal: encontrar el máximo entre los 4 candidatos
34
    float max_vals[4];
35
    int32_t max_idxs[4];
36
    vst1q_f32(max_vals, v_max);
37
    vst1q_s32(max_idxs, v_max_idx);
38
    // ... comparación final
39
}

Para un Argmax de 18,384 categorías, la optimización NEON puede aportar una aceleración de aproximadamente 3 veces.

Principios matemáticos de la pérdida CTC y la decodificación

La idea central de CTC es: dada una secuencia de entrada $X$ y todas las posibles rutas de alineación $\pi$ , calcular la probabilidad de la secuencia objetivo $Y$ :

P(Y|X) = \sum_{\pi \in \mathcal{B}^{-1}(Y)} P(\pi|X)

Donde $\mathcal{B}$ es la “función de mapeo de muchos a uno”, que mapea la ruta $\pi$ a la secuencia de salida $Y$ (mediante la combinación de repetidos y la eliminación de espacios).

En la inferencia, utilizamos decodificación greedy (codiciosa) en lugar de un Beam Search completo:

1
std::string CTCGreedyDecode(const float* logits, int time_steps, int num_classes,
2
                            const std::vector<std::string>& dictionary) {
3
    std::string result;
4
    int prev_idx = -1;  // Para combinar repetidos
5

6
    for (int t = 0; t < time_steps; ++t) {
7
        // Encontrar la categoría con mayor probabilidad en el paso de tiempo actual
8
        int max_idx = 0;
9
        float max_val = logits[t * num_classes];
10

11
        for (int c = 1; c < num_classes; ++c) {
12
            if (logits[t * num_classes + c] > max_val) {
13
                max_val = logits[t * num_classes + c];
14
                max_idx = c;
15
            }
16
        }
17

18
        // Reglas de decodificación CTC:
19
        // 1. Omitir token blank (índice 0)
20
        // 2. Combinar caracteres repetidos consecutivos
21
        if (max_idx != 0 && max_idx != prev_idx) {
22
            result += dictionary[max_idx - 1];  // -1 porque blank ocupa el índice 0
23
        }
24

25
        prev_idx = max_idx;
26
    }
27

28
    return result;
29
}

La complejidad temporal de la decodificación greedy es $O(T \times C)$ , donde $T$ es el número de pasos de tiempo y $C$ es el número de categorías. Para PP-OCRv5, $T \approx 80$ y $C = 18384$ , lo que requiere unos 1.5 millones de comparaciones por decodificación. Por eso la optimización NEON es tan importante.

TIP

Beam Search puede mejorar la precisión de la decodificación, pero su carga computacional es $k$ veces mayor que la decodificación greedy ( $k$ es el ancho del beam). En dispositivos móviles, la decodificación greedy suele ser la mejor opción.

Diccionario de caracteres: El reto de los 18,383 caracteres

PP-OCRv5 admite 18,383 caracteres, incluyendo:

Caracteres comunes del chino simplificado.
Caracteres comunes del chino tradicional.
Letras inglesas y números.
Hiragana y Katakana japoneses.
Signos de puntuación comunes y caracteres especiales.

Este diccionario se almacena en el archivo keys_v5.txt, con un carácter por línea. Durante la decodificación CTC, la forma de los logits de salida del modelo es [1, T, 18384], donde T es el número de pasos de tiempo y 18384 = 18383 caracteres + 1 token blank.

LiteRT C++ API: La interfaz moderna tras la refactorización de 2024

PPOCRv5-Android utiliza la API de C++ de LiteRT tras su refactorización en 2024, la cual ofrece un diseño de interfaz más moderno. En comparación con la API tradicional de C de TFLite, la nueva API ofrece una mejor seguridad de tipos y capacidades de gestión de recursos.

Comparativa entre la API antigua y la nueva

La refactorización de LiteRT en 2024 trajo cambios significativos en la API:

Característica	API antigua (TFLite)	API nueva (LiteRT)
Espacio de nombres	`tflite::`	`litert::`
Manejo de errores	Devuelve enumeración `TfLiteStatus`	Devuelve tipo `Expected<T>`
Gestión de memoria	Manual	Automática mediante RAII
Configuración de Delegate	APIs dispersas	Clase `Options` unificada
Acceso a tensores	Punteros + conversión manual	`TensorBuffer` con seguridad de tipos

La principal ventaja de la nueva API es la seguridad de tipos y la gestión automática de recursos. Tomando como ejemplo el manejo de errores:

1
// API antigua: requiere comprobación manual de cada valor de retorno
2
TfLiteStatus status = TfLiteInterpreterAllocateTensors(interpreter);
3
if (status != kTfLiteOk) {
4
    // Manejo de errores
5
}
6

7
// API nueva: usa el tipo Expected, permite llamadas encadenadas
8
auto model_result = litert::CompiledModel::Create(env, model_path, options);
9
if (!model_result) {
10
    LOGE(TAG, "Error: %s", model_result.Error().Message().c_str());
11
    return false;
12
}
13
auto model = std::move(*model_result);  // Gestión automática del ciclo de vida

Inicialización del entorno y del modelo

En text_detector.cpp, el flujo de inicialización es el siguiente:

1
bool Initialize(const std::string &model_path, AcceleratorType accelerator_type) {
2
    // 1. Crear entorno LiteRT
3
    auto env_result = litert::Environment::Create({});
4
    if (!env_result) {
5
        LOGE(TAG, "Failed to create LiteRT environment: %s",
6
             env_result.Error().Message().c_str());
7
        return false;
8
    }
9
    env_ = std::move(*env_result);
10

11
    // 2. Configurar acelerador de hardware
12
    auto options_result = litert::Options::Create();
13
    auto hw_accelerator = ToLiteRtAccelerator(accelerator_type);
14
    options.SetHardwareAccelerators(hw_accelerator);
15

16
    // 3. Compilar modelo
17
    auto model_result = litert::CompiledModel::Create(*env_, model_path, options);
18
    if (!model_result) {
19
        LOGW(TAG, "Failed to create CompiledModel with accelerator %d: %s",
20
             static_cast<int>(accelerator_type),
21
             model_result.Error().Message().c_str());
22
        return false;
23
    }
24
    compiled_model_ = std::move(*model_result);
25

26
    // 4. Ajustar forma del tensor de entrada
27
    std::vector<int> input_dims = {1, kDetInputSize, kDetInputSize, 3};
28
    compiled_model_->ResizeInputTensor(0, absl::MakeConstSpan(input_dims));
29

30
    // 5. Crear Buffer gestionado
31
    CreateBuffersWithCApi();
32

33
    return true;
34
}

Managed Tensor Buffer: La clave para la inferencia cero copia

El Managed Tensor Buffer de LiteRT es fundamental para lograr una inferencia de alto rendimiento. Permite que el GPU Delegate acceda directamente al Buffer, eliminando la necesidad de transferencia de datos entre CPU y GPU:

1
bool CreateBuffersWithCApi() {
2
    LiteRtCompiledModel c_model = compiled_model_->Get();
3
    LiteRtEnvironment c_env = env_->Get();
4

5
    // Obtener requisitos del Buffer de entrada
6
    LiteRtTensorBufferRequirements input_requirements = nullptr;
7
    LiteRtGetCompiledModelInputBufferRequirements(
8
        c_model, /*signature_index=*/0, /*input_index=*/0,
9
        &input_requirements);
10

11
    // Obtener información del tipo de tensor
12
    auto input_type = compiled_model_->GetInputTensorType(0, 0);
13
    LiteRtRankedTensorType tensor_type =
14
        static_cast<LiteRtRankedTensorType>(*input_type);
15

16
    // Crear Buffer gestionado
17
    LiteRtTensorBuffer input_buffer = nullptr;
18
    LiteRtCreateManagedTensorBufferFromRequirements(
19
        c_env, &tensor_type, input_requirements, &input_buffer);
20

21
    // Envolver como objeto C++, gestión automática del ciclo de vida
22
    input_buffers_.push_back(
23
        litert::TensorBuffer::WrapCObject(input_buffer,
24
                                          litert::OwnHandle::kYes));
25
    return true;
26
}

Las ventajas de este diseño son:

Inferencia cero copia: El GPU Delegate puede acceder directamente al Buffer.
Gestión automática de memoria: OwnHandle::kYes asegura que el Buffer se libere automáticamente al destruir el objeto C++.
Seguridad de tipos: Comprobación en tiempo de compilación de la coincidencia de tipos de tensores.

Aceleración por GPU: Elección y equilibrio de OpenCL

LiteRT ofrece varias opciones de aceleración de hardware:

1
flowchart TB
2
    subgraph Delegates["Ecosistema LiteRT Delegate"]
3
        direction TB
4
        GPU_CL[GPU Delegate<br/>Backend OpenCL]
5
        GPU_GL[GPU Delegate<br/>Backend OpenGL ES]
6
        NNAPI[NNAPI Delegate<br/>Android HAL]
7
        XNN[XNNPACK Delegate<br/>Optimizado para CPU]
8
    end
9

10
    subgraph Hardware["Mapeo de hardware"]
11
        direction TB
12
        ADRENO[GPU Adreno<br/>Qualcomm]
13
        MALI[GPU Mali<br/>ARM]
14
        NPU[NPU/DSP<br/>Específico del fabricante]
15
        CPU[CPU ARM<br/>NEON]
16
    end
17

18
    GPU_CL --> ADRENO
19
    GPU_CL --> MALI
20
    GPU_GL --> ADRENO
21
    GPU_GL --> MALI
22
    NNAPI --> NPU
23
    XNN --> CPU

Acelerador	Backend	Ventajas	Desventajas
GPU	OpenCL	Amplio soporte, buen rendimiento	No es un componente estándar de Android
GPU	OpenGL ES	Componente estándar de Android	Rendimiento inferior a OpenCL
NPU	NNAPI	Máximo rendimiento	Mala compatibilidad entre dispositivos
CPU	XNNPACK	Compatibilidad más amplia	Rendimiento más bajo

PPOCRv5-Android eligió OpenCL como backend de aceleración principal. Google lanzó el backend OpenCL para TFLite en 2020, logrando una aceleración de aproximadamente 2 veces en GPUs Adreno en comparación con el backend OpenGL ES ⁷.

La ventaja de OpenCL proviene de varios aspectos:

Propósito de diseño: OpenCL fue diseñado desde el principio para computación de propósito general, mientras que OpenGL es una API de renderizado gráfico que añadió soporte para shaders de computación más tarde.
Memoria constante: La memoria constante de OpenCL es muy eficiente para el acceso a los pesos de las redes neuronales.
Soporte FP16: OpenCL admite nativamente punto flotante de media precisión, mientras que el soporte en OpenGL llegó más tarde.

Sin embargo, OpenCL tiene un defecto fatal: no es un componente estándar de Android. La calidad de las implementaciones de OpenCL varía entre fabricantes, y algunos dispositivos ni siquiera lo admiten.

OpenCL vs. OpenGL ES: Comparativa profunda de rendimiento

Para entender la ventaja de OpenCL, debemos profundizar en la arquitectura de la GPU. Tomando como ejemplo la Adreno 640 de Qualcomm:

1
flowchart TB
2
    subgraph Adreno["Arquitectura Adreno 640"]
3
        direction TB
4

5
        subgraph SP["Procesadores de Shaders x2"]
6
            ALU1[Array ALU<br/>256 FP32 / 512 FP16]
7
            ALU2[Array ALU<br/>256 FP32 / 512 FP16]
8
        end
9

10
        subgraph Memory["Jerarquía de memoria"]
11
            L1[Caché L1<br/>16KB por SP]
12
            L2[Caché L2<br/>1MB Compartida]
13
            GMEM[Memoria Global<br/>LPDDR4X]
14
        end
15

16
        subgraph Special["Unidades especiales"]
17
            TMU[Unidad de Textura<br/>Interpolación bilineal]
18
            CONST[Caché de Constantes<br/>Aceleración de pesos]
19
        end
20
    end
21

22
    ALU1 --> L1
23
    ALU2 --> L1
24
    L1 --> L2 --> GMEM
25
    TMU --> L1
26
    CONST --> ALU1 & ALU2

La ventaja de rendimiento de OpenCL proviene de:

Característica	OpenCL	OpenGL ES Compute
Memoria constante	Soporte nativo, aceleración por hardware	Requiere simulación mediante UBO
Tamaño del grupo de trabajo	Configuración flexible	Limitado por el modelo de shader
Barreras de memoria	Control de grano fino	Grano grueso
Cálculo FP16	Extensión `cl_khr_fp16`	Requiere precisión `mediump`
Herramientas de depuración	Snapdragon Profiler	Soporte limitado

En las operaciones de convolución, los pesos suelen ser constantes. OpenCL puede colocar los pesos en la memoria constante, disfrutando de optimizaciones de difusión a nivel de hardware. OpenGL ES, en cambio, necesita pasar los pesos como Uniform Buffer Objects (UBO), lo que aumenta el coste de acceso a memoria.

NOTE

Google restringió la carga directa de librerías OpenCL por parte de las aplicaciones a partir de Android 7.0. Sin embargo, el GPU Delegate de LiteRT sortea esta restricción cargando dinámicamente la implementación de OpenCL del sistema mediante dlopen. Por esta razón, el GPU Delegate necesita detectar la disponibilidad de OpenCL en tiempo de ejecución.

Estrategia de degradación elegante

PPOCRv5-Android implementa una estrategia de degradación elegante (fallback):

1
constexpr AcceleratorType kFallbackChain[] = {
2
    AcceleratorType::kGpu,  // Preferencia: GPU
3
    AcceleratorType::kCpu,  // Fallback: CPU
4
};
5

6
std::unique_ptr<OcrEngine> OcrEngine::Create(
7
        const std::string &det_model_path,
8
        const std::string &rec_model_path,
9
        const std::string &keys_path,
10
        AcceleratorType accelerator_type) {
11

12
    auto engine = std::unique_ptr<OcrEngine>(new OcrEngine());
13
    int start_index = GetFallbackStartIndex(accelerator_type);
14

15
    for (int i = start_index; i < kFallbackChainSize; ++i) {
16
        AcceleratorType current = kFallbackChain[i];
17

18
        auto detector = TextDetector::Create(det_model_path, current);
19
        if (!detector) continue;
20

21
        auto recognizer = TextRecognizer::Create(rec_model_path, keys_path, current);
22
        if (!recognizer) continue;
23

24
        engine->detector_ = std::move(detector);
25
        engine->recognizer_ = std::move(recognizer);
26
        engine->active_accelerator_ = current;
27

28
        engine->WarmUp();
29
        return engine;
30
    }
31
    return nullptr;
32
}

Esta estrategia asegura que la aplicación funcione en cualquier dispositivo, variando únicamente el rendimiento.

Capa nativa: C++ y optimización NEON

¿Por qué usar C++ en lugar de Kotlin?

La respuesta es simple: rendimiento. El preprocesamiento de imágenes implica una gran cantidad de operaciones a nivel de píxel, cuyo coste en la JVM es inaceptable. Más importante aún, C++ permite el uso directo de las instrucciones ARM NEON SIMD para realizar cálculos vectorizados.

NEON: El conjunto de instrucciones SIMD de ARM

NEON es una extensión SIMD (Single Instruction, Multiple Data) para procesadores ARM. Permite que una sola instrucción procese múltiples elementos de datos simultáneamente.

1
flowchart LR
2
    subgraph NEON["Registro NEON de 128 bits"]
3
        direction TB
4
        F4["4x float32"]
5
        I8["8x int16"]
6
        B16["16x int8"]
7
    end
8

9
    subgraph Operations["Operaciones vectorizadas"]
10
        direction TB
11
        LD["vld1q_f32<br/>Cargar 4 floats"]
12
        SUB["vsubq_f32<br/>Resta paralela de 4 vías"]
13
        MUL["vmulq_f32<br/>Multiplicación paralela de 4 vías"]
14
        ST["vst1q_f32<br/>Almacenar 4 floats"]
15
    end
16

17
    subgraph Speedup["Mejora de rendimiento"]
18
        S1["Escalar: 4 instrucciones"]
19
        S2["NEON: 1 instrucción"]
20
        S3["Aceleración teórica: 4x"]
21
    end
22

23
    F4 --> LD
24
    LD --> SUB --> MUL --> ST
25
    ST --> S3

PPOCRv5-Android utiliza optimizaciones NEON en varias rutas críticas. Tomando como ejemplo la binarización (text_detector.cpp):

1
void BinarizeOutput(const float *prob_map, int total_pixels) {
2
#if defined(__ARM_NEON) || defined(__ARM_NEON__)
3
    const float32x4_t v_threshold = vdupq_n_f32(kBinaryThreshold);
4
    const uint8x16_t v_255 = vdupq_n_u8(255);
5
    const uint8x16_t v_0 = vdupq_n_u8(0);
6

7
    int i = 0;
8
    for (; i + 16 <= total_pixels; i += 16) {
9
        // Procesa 16 píxeles a la vez
10
        float32x4_t f0 = vld1q_f32(prob_map + i);
11
        float32x4_t f1 = vld1q_f32(prob_map + i + 4);
12
        float32x4_t f2 = vld1q_f32(prob_map + i + 8);
13
        float32x4_t f3 = vld1q_f32(prob_map + i + 12);
14

15
        // Comparación vectorizada
16
        uint32x4_t cmp0 = vcgtq_f32(f0, v_threshold);
17
        uint32x4_t cmp1 = vcgtq_f32(f1, v_threshold);
18
        uint32x4_t cmp2 = vcgtq_f32(f2, v_threshold);
19
        uint32x4_t cmp3 = vcgtq_f32(f3, v_threshold);
20

21
        // Estrechar a uint8
22
        uint16x4_t n0 = vmovn_u32(cmp0);
23
        uint16x4_t n1 = vmovn_u32(cmp1);
24
        uint16x8_t n01 = vcombine_u16(n0, n1);
25
        // ... combinar y almacenar
26
    }
27
    // Fallback escalar para los píxeles restantes
28
    for (; i < total_pixels; ++i) {
29
        binary_map_[i] = (prob_map[i] > kBinaryThreshold) ? 255 : 0;
30
    }
31
#else
32
    // Implementación puramente escalar
33
    for (int i = 0; i < total_pixels; ++i) {
34
        binary_map_[i] = (prob_map[i] > kBinaryThreshold) ? 255 : 0;
35
    }
36
#endif
37
}

Puntos clave de optimización en este código:

Carga por lotes: vld1q_f32 carga 4 floats a la vez, reduciendo el número de accesos a memoria.
Comparación vectorizada: vcgtq_f32 compara 4 valores simultáneamente, generando una máscara.
Estrechamiento de tipos: vmovn_u32 comprime los resultados de 32 bits a 16 bits, y finalmente a 8 bits.

En comparación con la implementación escalar, la optimización NEON puede aportar una aceleración de 3 a 4 veces ⁸.

Implementación NEON de la normalización ImageNet

La normalización de imágenes es un paso crucial en el preprocesamiento. El estándar ImageNet utiliza la siguiente fórmula:

x_{normalized} = \frac{x - \mu}{\sigma}

Donde $\mu = [0.485, 0.456, 0.406]$ y $\sigma = [0.229, 0.224, 0.225]$ (canales RGB).

En image_utils.cpp, la implementación de la normalización optimizada con NEON es la siguiente:

1
void NormalizeImageNet(const uint8_t* src, int width, int height, int stride,
2
                       float* dst) {
3
    // Parámetros de normalización ImageNet
4
    constexpr float kMeanR = 0.485f, kMeanG = 0.456f, kMeanB = 0.406f;
5
    constexpr float kStdR = 0.229f, kStdG = 0.224f, kStdB = 0.225f;
6
    constexpr float kInvStdR = 1.0f / kStdR;
7
    constexpr float kInvStdG = 1.0f / kStdG;
8
    constexpr float kInvStdB = 1.0f / kStdB;
9
    constexpr float kScale = 1.0f / 255.0f;
10

11
#if defined(__ARM_NEON) || defined(__ARM_NEON__)
12
    // Precálculo: (1/255) / std = 1 / (255 * std)
13
    const float32x4_t v_scale_r = vdupq_n_f32(kScale * kInvStdR);
14
    const float32x4_t v_scale_g = vdupq_n_f32(kScale * kInvStdG);
15
    const float32x4_t v_scale_b = vdupq_n_f32(kScale * kInvStdB);
16

17
    // Precálculo: -mean / std
18
    const float32x4_t v_bias_r = vdupq_n_f32(-kMeanR * kInvStdR);
19
    const float32x4_t v_bias_g = vdupq_n_f32(-kMeanG * kInvStdG);
20
    const float32x4_t v_bias_b = vdupq_n_f32(-kMeanB * kInvStdB);
21

22
    for (int y = 0; y < height; ++y) {
23
        const uint8_t* row = src + y * stride;
24
        float* dst_row = dst + y * width * 3;
25

26
        int x = 0;
27
        for (; x + 4 <= width; x += 4) {
28
            // Cargar 4 píxeles RGBA (16 bytes)
29
            uint8x16_t rgba = vld1q_u8(row + x * 4);
30

31
            // Desentrelazado: RGBARGBARGBARGBA -> RRRR, GGGG, BBBB, AAAA
32
            uint8x16x4_t channels = vld4q_u8(row + x * 4);
33

34
            // uint8 -> uint16 -> uint32 -> float32
35
            uint16x8_t r16 = vmovl_u8(vget_low_u8(channels.val[0]));
36
            uint16x8_t g16 = vmovl_u8(vget_low_u8(channels.val[1]));
37
            uint16x8_t b16 = vmovl_u8(vget_low_u8(channels.val[2]));
38

39
            float32x4_t r_f = vcvtq_f32_u32(vmovl_u16(vget_low_u16(r16)));
40
            float32x4_t g_f = vcvtq_f32_u32(vmovl_u16(vget_low_u16(g16)));
41
            float32x4_t b_f = vcvtq_f32_u32(vmovl_u16(vget_low_u16(b16)));
42

43
            // Normalización: (x / 255 - mean) / std = x * (1/255/std) + (-mean/std)
44
            r_f = vmlaq_f32(v_bias_r, r_f, v_scale_r);  // fused multiply-add
45
            g_f = vmlaq_f32(v_bias_g, g_f, v_scale_g);
46
            b_f = vmlaq_f32(v_bias_b, b_f, v_scale_b);
47

48
            // Almacenamiento entrelazado: RRRR, GGGG, BBBB -> RGBRGBRGBRGB
49
            float32x4x3_t rgb = {r_f, g_f, b_f};
50
            vst3q_f32(dst_row + x * 3, rgb);
51
        }
52

53
        // Procesamiento escalar para los píxeles restantes
54
        for (; x < width; ++x) {
55
            const uint8_t* px = row + x * 4;
56
            float* dst_px = dst_row + x * 3;
57
            dst_px[0] = (px[0] * kScale - kMeanR) * kInvStdR;
58
            dst_px[1] = (px[1] * kScale - kMeanG) * kInvStdG;
59
            dst_px[2] = (px[2] * kScale - kMeanB) * kInvStdB;
60
        }
61
    }
62
#else
63
    // Implementación escalar (omitida)
64
#endif
65
}

Técnicas clave de optimización en este código:

Precálculo de constantes: Se transforma (x - mean) / std en x * scale + bias, eliminando divisiones en tiempo de ejecución.
Fused Multiply-Add: vmlaq_f32 realiza la multiplicación y la suma en una sola instrucción.
Carga desentrelazada: vld4q_u8 separa automáticamente RGBA en cuatro canales.
Almacenamiento entrelazado: vst3q_f32 escribe los tres canales RGB entrelazados en memoria.

Cero dependencia de OpenCV

Muchos proyectos de OCR dependen de OpenCV para el preprocesamiento de imágenes. OpenCV es potente, pero conlleva un tamaño de binario enorme; la librería OpenCV para Android suele superar los 10 MB.

PPOCRv5-Android optó por la ruta de “cero dependencia de OpenCV”. Todas las operaciones de preprocesamiento de imágenes se implementan en C++ puro en image_utils.cpp:

Redimensionamiento por interpolación bilineal: Implementación manual con soporte para optimización NEON.
Normalización: Normalización ImageNet y normalización para reconocimiento.
Transformación de perspectiva: Recorte de áreas de texto en cualquier ángulo desde la imagen original.

Implementación NEON de la interpolación bilineal

La interpolación bilineal es el algoritmo central para el redimensionamiento de imágenes. Dadas las coordenadas $(x, y)$ de la imagen de origen, la interpolación bilineal calcula el valor del píxel objetivo:

f(x, y) = (1-\alpha)(1-\beta)f_{00} + \alpha(1-\beta)f_{10} + (1-\alpha)\beta f_{01} + \alpha\beta f_{11}

Donde $\alpha = x - \lfloor x \rfloor$ , $\beta = y - \lfloor y \rfloor$ y $f_{ij}$ son los valores de los cuatro píxeles vecinos.

1
void ResizeBilinear(const uint8_t* src, int src_w, int src_h, int src_stride,
2
                    uint8_t* dst, int dst_w, int dst_h) {
3
    const float scale_x = static_cast<float>(src_w) / dst_w;
4
    const float scale_y = static_cast<float>(src_h) / dst_h;
5

6
    for (int dy = 0; dy < dst_h; ++dy) {
7
        const float sy = (dy + 0.5f) * scale_y - 0.5f;
8
        const int y0 = std::max(0, static_cast<int>(std::floor(sy)));
9
        const int y1 = std::min(src_h - 1, y0 + 1);
10
        const float beta = sy - y0;
11
        const float inv_beta = 1.0f - beta;
12

13
        const uint8_t* row0 = src + y0 * src_stride;
14
        const uint8_t* row1 = src + y1 * src_stride;
15
        uint8_t* dst_row = dst + dy * dst_w * 4;
16

17
#if defined(__ARM_NEON) || defined(__ARM_NEON__)
18
        // NEON: procesa 4 píxeles objetivo a la vez
19
        const float32x4_t v_beta = vdupq_n_f32(beta);
20
        const float32x4_t v_inv_beta = vdupq_n_f32(inv_beta);
21

22
        int dx = 0;
23
        for (; dx + 4 <= dst_w; dx += 4) {
24
            // Calcular 4 coordenadas de origen
25
            float sx[4];
26
            for (int i = 0; i < 4; ++i) {
27
                sx[i] = ((dx + i) + 0.5f) * scale_x - 0.5f;
28
            }
29

30
            // Cargar pesos alpha
31
            float alpha[4], inv_alpha[4];
32
            int x0[4], x1[4];
33
            for (int i = 0; i < 4; ++i) {
34
                x0[i] = std::max(0, static_cast<int>(std::floor(sx[i])));
35
                x1[i] = std::min(src_w - 1, x0[i] + 1);
36
                alpha[i] = sx[i] - x0[i];
37
                inv_alpha[i] = 1.0f - alpha[i];
38
            }
39

40
            // Realizar interpolación bilineal para cada canal
41
            for (int c = 0; c < 4; ++c) {  // RGBA
42
                float32x4_t f00, f10, f01, f11;
43

44
                // Recolectar valores vecinos de 4 píxeles
45
                f00 = vsetq_lane_f32(row0[x0[0] * 4 + c], f00, 0);
46
                f00 = vsetq_lane_f32(row0[x0[1] * 4 + c], f00, 1);
47
                f00 = vsetq_lane_f32(row0[x0[2] * 4 + c], f00, 2);
48
                f00 = vsetq_lane_f32(row0[x0[3] * 4 + c], f00, 3);
49
                // ... f10, f01, f11 similar
50

51
                // Fórmula de interpolación bilineal
52
                float32x4_t v_alpha = vld1q_f32(alpha);
53
                float32x4_t v_inv_alpha = vld1q_f32(inv_alpha);
54

55
                float32x4_t top = vmlaq_f32(
56
                    vmulq_f32(f00, v_inv_alpha),
57
                    f10, v_alpha
58
                );
59
                float32x4_t bottom = vmlaq_f32(
60
                    vmulq_f32(f01, v_inv_alpha),
61
                    f11, v_alpha
62
                );
63
                float32x4_t result = vmlaq_f32(
64
                    vmulq_f32(top, v_inv_beta),
65
                    bottom, v_beta
66
                );
67

68
                // Convertir de vuelta a uint8 y almacenar
69
                uint32x4_t result_u32 = vcvtq_u32_f32(result);
70
                // ... almacenar
71
            }
72
        }
73
#endif
74
        // Procesamiento escalar para los píxeles restantes (omitido)
75
    }
76
}

TIP

La optimización NEON de la interpolación bilineal es compleja porque las direcciones de los cuatro píxeles vecinos no son contiguas. Un método más eficiente es usar la interpolación bilineal separable: primero interpolar en dirección horizontal y luego en vertical. Esto aprovecha mejor la localidad de la caché.

Esta elección conlleva más trabajo de desarrollo, pero los beneficios son notables:

Reducción del tamaño del APK en unos 10 MB.
Control total sobre la lógica de preprocesamiento, facilitando la optimización.
Evita problemas de compatibilidad de versiones de OpenCV.

Transformación de perspectiva: Del rectángulo rotado a la línea de texto estándar

El modelo de reconocimiento de texto espera como entrada imágenes de líneas de texto horizontales. Sin embargo, los cuadros de texto detectados pueden ser rectángulos rotados en cualquier ángulo. La transformación de perspectiva se encarga de “enderezar” estas regiones.

En text_recognizer.cpp, el método CropAndRotate implementa esta función:

1
void CropAndRotate(const uint8_t *__restrict__ image_data,
2
                   int width, int height, int stride,
3
                   const RotatedRect &box, int &target_width) {
4
    // Calcular las cuatro esquinas del rectángulo rotado
5
    const float cos_angle = std::cos(box.angle * M_PI / 180.0f);
6
    const float sin_angle = std::sin(box.angle * M_PI / 180.0f);
7
    const float half_w = box.width / 2.0f;
8
    const float half_h = box.height / 2.0f;
9

10
    float corners[8];  // Coordenadas (x, y) de las 4 esquinas
11
    corners[0] = box.center_x + (-half_w * cos_angle - (-half_h) * sin_angle);
12
    corners[1] = box.center_y + (-half_w * sin_angle + (-half_h) * cos_angle);
13
    // ... calcular otras esquinas
14

15
    // Ancho adaptativo del objetivo: mantener relación de aspecto
16
    const float aspect_ratio = src_width / std::max(src_height, 1.0f);
17
    target_width = static_cast<int>(kRecInputHeight * aspect_ratio);
18
    target_width = std::clamp(target_width, 1, kRecInputWidth);  // 48x[1, 320]
19

20
    // Matriz de transformación afín
21
    const float a00 = (x1 - x0) * inv_dst_w;
22
    const float a01 = (x3 - x0) * inv_dst_h;
23
    const float a10 = (y1 - y0) * inv_dst_w;
24
    const float a11 = (y3 - y0) * inv_dst_h;
25

26
    // Muestreo por interpolación bilineal + normalización (optimización NEON)
27
    for (int dy = 0; dy < kRecInputHeight; ++dy) {
28
        for (int dx = 0; dx < target_width; ++dx) {
29
            float sx = base_sx + a00 * dx;
30
            float sy = base_sy + a10 * dx;
31
            BilinearSampleNeon(image_data, stride, sx, sy, dst_row + dx * 3);
32
        }
33
    }
34
}

Optimizaciones clave de esta implementación:

Ancho adaptativo: Ajusta dinámicamente el ancho de salida según la relación de aspecto del cuadro de texto, evitando estiramientos o compresiones excesivas.
Aproximación por transformación afín: Para cuadros de texto que son casi paralelogramos, se usa la transformación afín en lugar de la de perspectiva para reducir el cálculo.
Interpolación bilineal NEON: El muestreo y la normalización se realizan en una sola pasada, reduciendo los accesos a memoria.

JNI: El puente entre Kotlin y C++

JNI (Java Native Interface) es el puente de comunicación entre Kotlin/Java y C++. Sin embargo, las llamadas JNI tienen un coste; las llamadas frecuentes entre lenguajes pueden afectar seriamente al rendimiento.

El principio de diseño de PPOCRv5-Android es: minimizar el número de llamadas JNI. Todo el flujo de OCR solo requiere una llamada JNI:

1
sequenceDiagram
2
    participant K as Capa Kotlin
3
    participant J as Puente JNI
4
    participant N as Capa Nativa
5
    participant G as GPU
6

7
    K->>J: process(bitmap)
8
    J->>N: Pasar puntero RGBA
9

10
    Note over N,G: La capa nativa realiza todo el trabajo
11

12
    N->>N: Preprocesamiento de imagen NEON
13
    N->>G: Inferencia de detección de texto
14
    G-->>N: Mapa de probabilidad
15
    N->>N: Post-procesamiento Detección de contornos
16

17
    loop Cada cuadro de texto
18
        N->>N: Recorte por transformación de perspectiva
19
        N->>G: Inferencia de reconocimiento de texto
20
        G-->>N: logits
21
        N->>N: Decodificación CTC
22
    end
23

24
    N-->>J: Resultados OCR
25
    J-->>K: List OcrResult

En ppocrv5_jni.cpp, la función central nativeProcess muestra este diseño:

1
JNIEXPORT jobjectArray JNICALL
2
Java_me_fleey_ppocrv5_ocr_OcrEngine_nativeProcess(
3
        JNIEnv *env, jobject thiz, jlong handle, jobject bitmap) {
4

5
    auto *engine = reinterpret_cast<ppocrv5::OcrEngine *>(handle);
6

7
    // Bloquear píxeles del Bitmap
8
    void *pixels = nullptr;
9
    AndroidBitmap_lockPixels(env, bitmap, &pixels);
10

11
    // Una sola llamada JNI completa todo el trabajo de OCR
12
    auto results = engine->Process(
13
            static_cast<const uint8_t *>(pixels),
14
            static_cast<int>(bitmap_info.width),
15
            static_cast<int>(bitmap_info.height),
16
            static_cast<int>(bitmap_info.stride));
17

18
    AndroidBitmap_unlockPixels(env, bitmap);
19

20
    // Construir y devolver array de objetos Java
21
    // ...
22
}

Este diseño evita el coste de pasar datos de ida y vuelta entre la detección y el reconocimiento.

Diseño de arquitectura: Modularidad y testabilidad

La arquitectura de PPOCRv5-Android sigue el principio de “separación de preocupaciones”:

1
flowchart TB
2
    subgraph UI["Capa UI Jetpack Compose"]
3
        direction LR
4
        CP[CameraPreview]
5
        GP[GalleryPicker]
6
        RO[ResultOverlay]
7
    end
8

9
    subgraph VM["Capa ViewModel"]
10
        OVM[OCRViewModel<br/>Gestión de estado]
11
    end
12

13
    subgraph Native["Capa Nativa - C++"]
14
        OE[OcrEngine<br/>Orquestación]
15

16
        subgraph Detection["Detección de texto"]
17
            TD[TextDetector]
18
            DB[DBNet FP16]
19
        end
20

21
        subgraph Recognition["Reconocimiento de texto"]
22
            TR[TextRecognizer]
23
            SVTR[SVTRv2 + CTC]
24
        end
25

26
        subgraph Preprocessing["Procesamiento de imagen"]
27
            IP[ImagePreprocessor<br/>Optimizado con NEON]
28
            PP[PostProcessor<br/>Detección de contornos]
29
        end
30

31
        subgraph Runtime["Runtime LiteRT"]
32
            GPU[GPU Delegate<br/>OpenCL]
33
            CPU[CPU Fallback<br/>XNNPACK]
34
        end
35
    end
36

37
    CP --> OVM
38
    GP --> OVM
39
    OVM --> RO
40
    OVM <-->|JNI| OE
41
    OE --> TD
42
    OE --> TR
43
    TD --> DB
44
    TR --> SVTR
45
    TD --> IP
46
    TR --> IP
47
    DB --> PP
48
    DB --> GPU
49
    SVTR --> GPU
50
    GPU -.->|Fallback| CPU

Los beneficios de esta arquitectura por capas son:

Capa UI: Kotlin/Compose puro, enfocada en la interacción del usuario.
Capa ViewModel: Gestiona el estado y la lógica de negocio.
Capa Nativa: Computación de alto rendimiento, totalmente desacoplada de la UI.

Cada capa puede probarse de forma independiente. La capa nativa puede usar Google Test para pruebas unitarias, y la capa ViewModel puede usar JUnit + MockK.

Encapsulamiento en la capa Kotlin

En OcrEngine.kt, la capa Kotlin ofrece una API concisa:

1
class OcrEngine private constructor(
2
    private var nativeHandle: Long,
3
) : Closeable {
4

5
    companion object {
6
        init {
7
            System.loadLibrary("ppocrv5_jni")
8
        }
9

10
        fun create(
11
            context: Context,
12
            acceleratorType: AcceleratorType = AcceleratorType.GPU,
13
        ): Result<OcrEngine> = runCatching {
14
            initializeCache(context)
15

16
            val detModelPath = copyAssetToCache(context, "$MODELS_DIR/$DET_MODEL_FILE")
17
            val recModelPath = copyAssetToCache(context, "$MODELS_DIR/$REC_MODEL_FILE")
18
            val keysPath = copyAssetToCache(context, "$MODELS_DIR/$KEYS_FILE")
19

20
            val handle = OcrEngine(0).nativeCreate(
21
                detModelPath, recModelPath, keysPath,
22
                acceleratorType.value,
23
            )
24

25
            if (handle == 0L) {
26
                throw OcrException("Failed to create native OCR engine")
27
            }
28

29
            OcrEngine(handle)
30
        }
31
    }
32

33
    fun process(bitmap: Bitmap): List<OcrResult> {
34
        check(nativeHandle != 0L) { "OcrEngine has been closed" }
35
        return nativeProcess(nativeHandle, bitmap)?.toList() ?: emptyList()
36
    }
37

38
    override fun close() {
39
        if (nativeHandle != 0L) {
40
            nativeDestroy(nativeHandle)
41
            nativeHandle = 0
42
        }
43
    }
44
}

Ventajas de este diseño:

Uso del tipo Result para manejar errores de inicialización.
Implementación de la interfaz Closeable, permitiendo el uso de bloques use para liberar recursos automáticamente.
Los archivos de modelo se copian automáticamente desde assets al directorio de caché.

Optimización del arranque en frío

La primera inferencia (arranque en frío) suele ser mucho más lenta que las siguientes (arranque en caliente). Esto se debe a que:

El GPU Delegate necesita compilar el programa OpenCL.
Los pesos del modelo deben transferirse de la memoria CPU a la memoria GPU.
Es necesario precalentar varias cachés.

PPOCRv5-Android mitiga el problema del arranque en frío mediante un mecanismo de Warm-up:

1
void OcrEngine::WarmUp() {
2
    LOGD(TAG, "Starting warm-up (%d iterations)...", kWarmupIterations);
3

4
    // Crear una pequeña imagen de prueba
5
    std::vector<uint8_t> dummy_image(kWarmupImageSize * kWarmupImageSize * 4, 128);
6
    for (int i = 0; i < kWarmupImageSize * kWarmupImageSize; ++i) {
7
        dummy_image[i * 4 + 0] = static_cast<uint8_t>((i * 7) % 256);
8
        dummy_image[i * 4 + 1] = static_cast<uint8_t>((i * 11) % 256);
9
        dummy_image[i * 4 + 2] = static_cast<uint8_t>((i * 13) % 256);
10
        dummy_image[i * 4 + 3] = 255;
11
    }
12

13
    // Ejecutar varias inferencias para precalentar
14
    for (int iter = 0; iter < kWarmupIterations; ++iter) {
15
        float detection_time_ms = 0.0f;
16
        detector_->Detect(dummy_image.data(), kWarmupImageSize, kWarmupImageSize,
17
                          kWarmupImageSize * 4, &detection_time_ms);
18
    }
19

20
    LOGD(TAG, "Warm-up completed (accelerator: %s)", AcceleratorName(active_accelerator_));
21
}

Optimización de la alineación de memoria

En TextDetector::Impl, todos los buffers preasignados utilizan una alineación de 64 bytes:

1
// Buffers preasignados con alineación de línea de caché
2
alignas(64) std::vector<uint8_t> resized_buffer_;
3
alignas(64) std::vector<float> normalized_buffer_;
4
alignas(64) std::vector<uint8_t> binary_map_;
5
alignas(64) std::vector<float> prob_map_;

La alineación de 64 bytes corresponde al tamaño de la línea de caché de los procesadores ARM modernos. El acceso a memoria alineada evita la división de líneas de caché, mejorando la eficiencia del acceso a memoria.

Pool de memoria y reutilización de objetos

La asignación y liberación frecuente de memoria es un asesino del rendimiento. PPOCRv5-Android utiliza una estrategia de preasignación, reservando toda la memoria necesaria de una vez durante la inicialización:

1
class TextDetector::Impl {
2
    // Buffers preasignados, ciclo de vida igual a Impl
3
    alignas(64) std::vector<uint8_t> resized_buffer_;      // 640 * 640 * 4 = 1.6MB
4
    alignas(64) std::vector<float> normalized_buffer_;     // 640 * 640 * 3 * 4 = 4.9MB
5
    alignas(64) std::vector<uint8_t> binary_map_;          // 640 * 640 = 0.4MB
6
    alignas(64) std::vector<float> prob_map_;              // 640 * 640 * 4 = 1.6MB
7

8
    bool Initialize(...) {
9
        // Asignación única, evita malloc en tiempo de ejecución
10
        resized_buffer_.resize(kDetInputSize * kDetInputSize * 4);
11
        normalized_buffer_.resize(kDetInputSize * kDetInputSize * 3);
12
        binary_map_.resize(kDetInputSize * kDetInputSize);
13
        prob_map_.resize(kDetInputSize * kDetInputSize);
14
        return true;
15
    }
16
};

Beneficios de este diseño:

Evita la fragmentación de memoria: Todos los bloques grandes se asignan al inicio, sin generar fragmentación durante la ejecución.
Reduce las llamadas al sistema: malloc puede disparar llamadas al sistema; la preasignación evita este coste.
Amigable con la caché: La memoria asignada de forma contigua tiene más probabilidades de ser físicamente contigua, mejorando la tasa de aciertos de la caché.

Optimización de la predicción de saltos

Los CPUs modernos utilizan la predicción de saltos (branch prediction) para mejorar la eficiencia del pipeline. Una predicción errónea puede causar un vaciado del pipeline, perdiendo entre 10 y 20 ciclos de reloj.

En las rutas críticas (hot paths), utilizamos __builtin_expect para dar pistas al compilador:

1
// La mayoría de los píxeles no superarán el umbral
2
if (__builtin_expect(prob_map[i] > kBinaryThreshold, 0)) {
3
    binary_map_[i] = 255;
4
} else {
5
    binary_map_[i] = 0;
6
}

__builtin_expect(expr, val) indica al compilador que es muy probable que el valor de expr sea val. El compilador ajusta el diseño del código en consecuencia, colocando las ramas “poco probables” lejos de la ruta principal.

Desenrollado de bucles y software pipelining

Para bucles con carga computacional intensiva, el desenrollado manual puede reducir el coste del bucle y exponer más paralelismo a nivel de instrucción:

1
// Versión sin desenrollar
2
for (int i = 0; i < n; ++i) {
3
    dst[i] = src[i] * scale + bias;
4
}
5

6
// Versión desenrollada 4x
7
int i = 0;
8
for (; i + 4 <= n; i += 4) {
9
    dst[i + 0] = src[i + 0] * scale + bias;
10
    dst[i + 1] = src[i + 1] * scale + bias;
11
    dst[i + 2] = src[i + 2] * scale + bias;
12
    dst[i + 3] = src[i + 3] * scale + bias;
13
}
14
for (; i < n; ++i) {
15
    dst[i] = src[i] * scale + bias;
16
}

Tras el desenrollado, el CPU puede ejecutar múltiples instrucciones de multiplicación y suma independientes simultáneamente, aprovechando al máximo las múltiples unidades de ejecución de las arquitecturas superescalares.

Optimización de Prefetch

En el bucle interno de la transformación de perspectiva, utilizamos __builtin_prefetch para cargar anticipadamente los datos de la siguiente línea:

1
for (int dy = 0; dy < kRecInputHeight; ++dy) {
2
    // Prefetch de los datos de la siguiente línea
3
    if (dy + 1 < kRecInputHeight) {
4
        const float next_sy = y0 + a11 * (dy + 1);
5
        const int next_y = static_cast<int>(next_sy);
6
        if (next_y >= 0 && next_y < height) {
7
            __builtin_prefetch(image_data + next_y * stride, 0, 1);
8
        }
9
    }
10
    // ... procesar línea actual
11
}

Esta optimización puede ocultar la latencia de memoria; mientras se procesa la línea actual, los datos de la siguiente ya están en la caché L1.

Detalles de ingeniería del post-procesamiento

Análisis de componentes conectados y detección de contornos

En postprocess.cpp, la función FindContours implementa un análisis eficiente de componentes conectados:

1
std::vector<std::vector<Point>> FindContours(const uint8_t *binary_map,
2
                                             int width, int height) {
3
    // 1. Submuestreo 4x para reducir la carga computacional
4
    int ds_width = (width + kDownsampleFactor - 1) / kDownsampleFactor;
5
    int ds_height = (height + kDownsampleFactor - 1) / kDownsampleFactor;
6

7
    std::vector<uint8_t> ds_map(ds_width * ds_height);
8
    downsample_binary_map(binary_map, width, height,
9
                          ds_map.data(), ds_width, ds_height, kDownsampleFactor);
10

11
    // 2. Recorrido BFS de componentes conectados
12
    std::vector<int> labels(ds_width * ds_height, 0);
13
    int current_label = 0;
14

15
    for (int y = 0; y < ds_height; ++y) {
16
        for (int x = 0; x < ds_width; ++x) {
17
            if (pixel_at(ds_map.data(), x, y, ds_width) > 0 &&
18
                labels[y * ds_width + x] == 0) {
19
                current_label++;
20
                std::vector<Point> boundary;
21
                std::queue<std::pair<int, int>> queue;
22
                queue.push({x, y});
23

24
                while (!queue.empty()) {
25
                    auto [cx, cy] = queue.front();
26
                    queue.pop();
27

28
                    // Detectar píxeles de borde
29
                    if (is_boundary_pixel(ds_map.data(), cx, cy, ds_width, ds_height)) {
30
                        boundary.push_back({
31
                            static_cast<float>(cx * kDownsampleFactor + kDownsampleFactor / 2),
32
                            static_cast<float>(cy * kDownsampleFactor + kDownsampleFactor / 2)
33
                        });
34
                    }
35

36
                    // Expansión de 4 vecindades
37
                    for (int d = 0; d < 4; ++d) {
38
                        int nx = cx + kNeighborDx4[d];
39
                        int ny = cy + kNeighborDy4[d];
40
                        // ...
41
                    }
42
                }
43

44
                if (boundary.size() >= 4) {
45
                    contours.push_back(std::move(boundary));
46
                }
47
            }
48
        }
49
    }
50
    return contours;
51
}

Puntos clave de optimización:

Submuestreo 4x: Reduce el mapa binario de 640x640 a 160x160, disminuyendo la carga computacional en 16 veces.
Detección de bordes: Solo se conservan los píxeles de borde, no todo el componente conectado.
Límite máximo de contornos: kMaxContours = 100, para evitar problemas de rendimiento en casos extremos.

Algoritmos de envolvente convexa y Rotating Calipers

El cálculo del rectángulo rotado delimitador mínimo se divide en dos pasos: primero se calcula la envolvente convexa y luego se utiliza el algoritmo de Rotating Calipers para encontrar el rectángulo delimitador de área mínima.

Algoritmo de envolvente convexa Graham Scan

Graham Scan es un algoritmo clásico para calcular la envolvente convexa con una complejidad temporal de $O(n \log n)$ :

1
std::vector<Point> ConvexHull(std::vector<Point> points) {
2
    if (points.size() < 3) return points;
3

4
    // 1. Encontrar el punto más bajo (y mínimo, x mínimo)
5
    auto pivot = std::min_element(points.begin(), points.end(),
6
        [](const Point& a, const Point& b) {
7
            return a.y < b.y || (a.y == b.y && a.x < b.x);
8
        });
9
    std::swap(points[0], *pivot);
10
    Point p0 = points[0];
11

12
    // 2. Ordenar por ángulo polar
13
    std::sort(points.begin() + 1, points.end(),
14
        [&p0](const Point& a, const Point& b) {
15
            float cross = CrossProduct(p0, a, b);
16
            if (std::abs(cross) < 1e-6f) {
17
                // Si son colineales, el más cercano va primero
18
                return DistanceSquared(p0, a) < DistanceSquared(p0, b);
19
            }
20
            return cross > 0;  // Sentido antihorario
21
        });
22

23
    // 3. Construir la envolvente
24
    std::vector<Point> hull;
25
    for (const auto& p : points) {
26
        // Eliminar puntos que causen un giro en sentido horario
27
        while (hull.size() > 1 &&
28
               CrossProduct(hull[hull.size()-2], hull[hull.size()-1], p) <= 0) {
29
            hull.pop_back();
30
        }
31
        hull.push_back(p);
32
    }
33

34
    return hull;
35
}
36

37
// Producto cruzado: para determinar la dirección del giro
38
float CrossProduct(const Point& o, const Point& a, const Point& b) {
39
    return (a.x - o.x) * (b.y - o.y) - (a.y - o.y) * (b.x - o.x);
40
}

Algoritmo Rotating Calipers

El algoritmo de Rotating Calipers recorre cada arista de la envolvente convexa y calcula el área del rectángulo delimitador que tiene esa arista como base:

1
RotatedRect MinAreaRect(const std::vector<Point>& hull) {
2
    if (hull.size() < 3) return {};
3

4
    float min_area = std::numeric_limits<float>::max();
5
    RotatedRect best_rect;
6

7
    int n = hull.size();
8
    int right = 1, top = 1, left = 1;  // Posiciones de los tres "calipers"
9

10
    for (int i = 0; i < n; ++i) {
11
        int j = (i + 1) % n;
12

13
        // Vector de dirección de la arista actual
14
        float edge_x = hull[j].x - hull[i].x;
15
        float edge_y = hull[j].y - hull[i].y;
16
        float edge_len = std::sqrt(edge_x * edge_x + edge_y * edge_y);
17

18
        // Vector unitario
19
        float ux = edge_x / edge_len;
20
        float uy = edge_y / edge_len;
21

22
        // Dirección perpendicular
23
        float vx = -uy;
24
        float vy = ux;
25

26
        // Encontrar el punto más a la derecha (proyección máxima en dirección de la arista)
27
        while (Dot(hull[(right + 1) % n], ux, uy) > Dot(hull[right], ux, uy)) {
28
            right = (right + 1) % n;
29
        }
30

31
        // Encontrar el punto más arriba (proyección máxima en dirección perpendicular)
32
        while (Dot(hull[(top + 1) % n], vx, vy) > Dot(hull[top], vx, vy)) {
33
            top = (top + 1) % n;
34
        }
35

36
        // Encontrar el punto más a la izquierda
37
        while (Dot(hull[(left + 1) % n], ux, uy) < Dot(hull[left], ux, uy)) {
38
            left = (left + 1) % n;
39
        }
40

41
        // Calcular dimensiones del rectángulo
42
        float width = Dot(hull[right], ux, uy) - Dot(hull[left], ux, uy);
43
        float height = Dot(hull[top], vx, vy) - Dot(hull[i], vx, vy);
44
        float area = width * height;
45

46
        if (area < min_area) {
47
            min_area = area;
48
            // Actualizar parámetros del mejor rectángulo
49
            best_rect.width = width;
50
            best_rect.height = height;
51
            best_rect.angle = std::atan2(uy, ux) * 180.0f / M_PI;
52
            // Calcular punto central...
53
        }
54
    }
55

56
    return best_rect;
57
}

La idea clave de Rotating Calipers es que, al rotar la base, los tres “calipers” (puntos más a la derecha, arriba e izquierda) solo avanzan de forma monótona, nunca retroceden. Por lo tanto, la complejidad total es $O(n)$ , no $O(n^2)$ .

Rectángulo rotado delimitador mínimo

La función MinAreaRect utiliza el algoritmo de Rotating Calipers para calcular el rectángulo rotado delimitador mínimo:

1
RotatedRect MinAreaRect(const std::vector<Point> &contour) {
2
    // 1. Submuestreo para reducir el número de puntos
3
    std::vector<Point> points = subsample_points(contour, kMaxBoundaryPoints);
4

5
    // 2. Ruta rápida: para cuadros de texto con alta relación de aspecto, usar AABB directamente
6
    float aspect = std::max(aabb_width, aabb_height) /
7
                   std::max(1.0f, std::min(aabb_width, aabb_height));
8
    if (aspect > 2.0f && points.size() > 50) {
9
        // Devolver cuadro delimitador alineado con los ejes
10
        RotatedRect rect;
11
        rect.center_x = (min_x + max_x) / 2.0f;
12
        rect.center_y = (min_y + max_y) / 2.0f;
13
        rect.width = aabb_width;
14
        rect.height = aabb_height;
15
        rect.angle = 0.0f;
16
        return rect;
17
    }
18

19
    // 3. Cálculo de envolvente convexa
20
    std::vector<Point> hull = convex_hull(std::vector<Point>(points));
21

22
    // 4. Rotating Calipers: recorrer cada arista de la envolvente
23
    float min_area = std::numeric_limits<float>::max();
24
    RotatedRect best_rect;
25

26
    for (size_t i = 0; i < hull.size(); ++i) {
27
        // Calcular rectángulo delimitador basándose en la arista actual
28
        float edge_x = hull[j].x - hull[i].x;
29
        float edge_y = hull[j].y - hull[i].y;
30

31
        // Proyectar todos los puntos en la dirección de la arista y en la perpendicular
32
        project_points_onto_axis(hull, axis1_x, axis1_y, min1, max1);
33
        project_points_onto_axis(hull, axis2_x, axis2_y, min2, max2);
34

35
        float area = (max1 - min1) * (max2 - min2);
36
        if (area < min_area) {
37
            min_area = area;
38
            // Actualizar el mejor rectángulo
39
        }
40
    }
41

42
    return best_rect;
43
}

La complejidad temporal de este algoritmo es $O(n \log n)$ (cálculo de envolvente) + $O(n)$ (Rotating Calipers), donde $n$ es el número de puntos del borde. Al limitar $n$ a 200 mediante submuestreo, se asegura el rendimiento en tiempo real.

OCR de cámara en tiempo real: CameraX y análisis de frames

El reto del OCR en tiempo real es: ¿cómo procesar cada frame lo más rápido posible manteniendo una vista previa fluida?

1
flowchart TB
2
    subgraph Camera["Pipeline CameraX"]
3
        direction TB
4
        CP[CameraProvider]
5
        PV[UseCase Preview<br/>30 FPS]
6
        IA[UseCase ImageAnalysis<br/>STRATEGY_KEEP_ONLY_LATEST]
7
    end
8

9
    subgraph Analysis["Flujo de análisis de frames"]
10
        direction TB
11
        IP[ImageProxy<br/>YUV_420_888]
12
        BM[Conversión a Bitmap<br/>RGBA_8888]
13
        JNI[Llamada JNI<br/>Única entre lenguajes]
14
    end
15

16
    subgraph Native["OCR Nativo"]
17
        direction TB
18
        DET[TextDetector<br/>~45ms GPU]
19
        REC[TextRecognizer<br/>~15ms/línea]
20
        RES[Resultados OCR]
21
    end
22

23
    subgraph UI["Actualización UI"]
24
        direction TB
25
        VM[ViewModel<br/>StateFlow]
26
        OV[ResultOverlay<br/>Dibujo en Canvas]
27
    end
28

29
    CP --> PV
30
    CP --> IA
31
    IA --> IP --> BM --> JNI
32
    JNI --> DET --> REC --> RES
33
    RES --> VM --> OV

ImageAnalysis de CameraX

CameraX es la librería de cámara de Android Jetpack, que proporciona el caso de uso ImageAnalysis, permitiéndonos analizar los frames de la cámara en tiempo real:

1
val imageAnalysis = ImageAnalysis.Builder()
2
    .setTargetResolution(Size(1280, 720))
3
    .setBackpressureStrategy(ImageAnalysis.STRATEGY_KEEP_ONLY_LATEST)
4
    .build()
5

6
imageAnalysis.setAnalyzer(executor) { imageProxy ->
7
    val bitmap = imageProxy.toBitmap()
8
    val result = ocrEngine.process(bitmap)
9
    // Actualizar UI
10
    imageProxy.close()
11
}

La configuración clave es STRATEGY_KEEP_ONLY_LATEST: cuando la velocidad de procesamiento del analizador no puede seguir el ritmo de los frames de la cámara, se descartan los frames antiguos y solo se conserva el más reciente. Esto garantiza la actualidad de los resultados del OCR.

Equilibrio entre FPS y latencia

En dispositivos con aceleración por GPU (parece que mi Snapdragon 870 actual tiene problemas y no logra delegar la mayor parte del cálculo a la GPU), PPOCRv5-Android teóricamente puede alcanzar velocidades de procesamiento elevadas. Pero esto no significa que debamos procesar cada frame.

Consideremos este escenario: el usuario apunta la cámara a un texto; el contenido del texto no cambiará en un corto periodo de tiempo. Si realizamos un OCR completo en cada frame, desperdiciaremos una gran cantidad de recursos computacionales.

Una estrategia de optimización es la “detección de cambios”: solo se dispara el OCR cuando la imagen cambia significativamente. Esto puede lograrse comparando histogramas o puntos característicos de frames consecutivos.

Perspectivas futuras: NPU y cuantización

El futuro de la IA en el dispositivo reside en las NPU (Neural Processing Unit). En comparación con las GPU, las NPU están diseñadas específicamente para la inferencia de redes neuronales y ofrecen una mejor eficiencia energética.

Sin embargo, el reto de las NPU es la fragmentación. Cada fabricante de chips tiene su propia arquitectura de NPU y SDK:

Qualcomm: Hexagon DSP + AI Engine.
MediaTek: APU.
Samsung: Exynos NPU.
Google: Tensor TPU.

La NNAPI (Neural Networks API) de Android intenta proporcionar una capa de abstracción unificada, pero los resultados reales son irregulares. Muchas funciones de las NPU no se exponen a través de NNAPI, obligando a los desarrolladores a usar SDKs específicos de los fabricantes.

Cuantización INT8: Una batalla inacabada

La cuantización FP16 es una opción conservadora que apenas pierde precisión. Pero si se busca el rendimiento extremo, la cuantización INT8 es el siguiente paso.

La cuantización INT8 comprime los pesos y activaciones de punto flotante de 32 bits a enteros de 8 bits, lo que teóricamente puede aportar:

Reducción del tamaño del modelo en 4 veces.
Aceleración de la inferencia de 2 a 4 veces (dependiendo del hardware).
En el DSP Hexagon de Qualcomm, se puede lograr una aceleración de más de 10 veces.

La tentación era demasiado grande, así que comencé un largo viaje por la cuantización INT8.

Primer intento: Calibración con datos sintéticos

La cuantización INT8 requiere un conjunto de datos de calibración para determinar los parámetros de cuantización (Scale y Zero Point). Inicialmente, por pereza, utilicé imágenes generadas aleatoriamente que “parecían” texto:

1
# Error: usar ruido aleatorio para la calibración
2
img = np.ones((h, w, 3), dtype=np.float32) * 0.9
3
for _ in range(num_lines):
4
    gray_val = np.random.uniform(0.05, 0.3)
5
    img[y:y+line_h, x:x+line_w] = gray_val

El resultado fue desastroso. El modelo solo devolvía ceros:

Raw FLOAT32 output range: min=0.0000, max=0.0000
Prob map stats: min=0.0000, max=0.0000, mean=0.000000

La herramienta de cuantización calculó parámetros erróneos basados en el ruido aleatorio, provocando que los valores de activación de las imágenes reales fueran truncados.

Segundo intento: Calibración con imágenes reales

Cambié a imágenes reales de conjuntos de datos de OCR: ICDAR2015, TextOCR y ejemplos oficiales de PaddleOCR. Al mismo tiempo, implementé el preprocesamiento Letterbox para asegurar que la distribución de las imágenes durante la calibración fuera consistente con la de la inferencia:

1
def letterbox_image(image, target_size):
2
    """Escalar manteniendo relación de aspecto, rellenar con gris el resto"""
3
    ih, iw = image.shape[:2]
4
    h, w = target_size
5
    scale = min(w / iw, h / ih)
6
    # ... pegar centrado

El modelo dejó de devolver solo ceros, pero los resultados del reconocimiento seguían siendo basura.

Tercer intento: Corregir el manejo de tipos en C++

Descubrí que el código C++ tenía problemas al manejar entradas INT8. El modelo INT8 espera valores de píxel originales (0-255), mientras que yo seguía realizando la normalización ImageNet (restar media y dividir por desviación).

1
if (input_is_int8_) {
2
    // Modelo INT8: entrada directa de píxeles originales, normalización integrada en la primera capa
3
    dst[i * 3 + 0] = static_cast<int8_t>(src[i * 4 + 0] ^ 0x80);
4
} else {
5
    // Modelo FP32: requiere normalización manual
6
    // (pixel - mean) / std
7
}

Además, implementé la lógica para leer dinámicamente los parámetros de cuantización en lugar de codificarlos a fuego:

1
bool GetQuantizationParams(LiteRtTensor tensor, float* scale, int32_t* zero_point) {
2
    LiteRtQuantization quant;
3
    LiteRtGetTensorQuantization(tensor, &quant);
4
    // ...
5
}

Resultado final: Compromiso

Tras varios días de depuración, el modelo INT8 seguía sin funcionar correctamente. El problema podría deberse a:

Implementación de cuantización de onnx2tf: PP-OCRv5 usa combinaciones de operadores especiales que onnx2tf podría no haber manejado correctamente durante la cuantización.
Características de salida de DBNet: DBNet devuelve un mapa de probabilidad con valores entre 0 y 1; la cuantización INT8 es especialmente sensible a este rango pequeño de valores.
Acumulación de errores en modelos multietapa: Al encadenar los modelos de detección y reconocimiento, los errores de cuantización se acumulan y amplifican.

Analicemos el segundo punto. La salida de DBNet pasa por una activación Sigmoid, comprimiendo el rango a [0, 1]. La cuantización INT8 usa la fórmula:

x_{quantized} = \text{round}\left(\frac{x_{float}}{scale}\right) + zero\_point

Para valores en el rango [0, 1], si el scale no se ajusta adecuadamente, los valores cuantizados podrían ocupar solo una pequeña parte del rango INT8 [-128, 127], causando una pérdida grave de precisión.

1
# Asumiendo scale = 0.00784 (1/127), zero_point = 0
2
# Entrada 0.5 -> round(0.5 / 0.00784) + 0 = 64
3
# Entrada 0.1 -> round(0.1 / 0.00784) + 0 = 13
4
# Entrada 0.01 -> round(0.01 / 0.00784) + 0 = 1
5
# Entrada 0.001 -> round(0.001 / 0.00784) + 0 = 0  # ¡Pérdida de precisión!

El umbral de DBNet suele fijarse entre 0.1 y 0.3, lo que significa que una gran cantidad de valores de probabilidad significativos (0.1-0.3) solo pueden representarse con 25 enteros (del 13 al 38) tras la cuantización, lo que resulta en una resolución insuficiente.

WARNING

La cuantización INT8 de PP-OCRv5 es un reto conocido. Si lo estás intentando, te sugiero confirmar primero que el modelo FP32 funciona correctamente antes de investigar problemas de cuantización. Alternativamente, considera usar el framework oficial Paddle Lite de PaddlePaddle, que ofrece mejor soporte para PaddleOCR.

Entrenamiento consciente de la cuantización: La solución correcta

Si es imprescindible usar cuantización INT8, el método correcto es el entrenamiento consciente de la cuantización (Quantization-Aware Training, QAT), en lugar de la cuantización post-entrenamiento (Post-Training Quantization, PTQ).

QAT simula los errores de cuantización durante el entrenamiento, permitiendo que el modelo aprenda a adaptarse a representaciones de baja precisión:

1
# Ejemplo de QAT en PyTorch
2
import torch.quantization as quant
3

4
model = DBNet()
5
model.qconfig = quant.get_default_qat_qconfig('fbgemm')
6
model_prepared = quant.prepare_qat(model)
7

8
# Entrenamiento normal, pero con nodos de pseudo-cuantización insertados en el forward pass
9
for epoch in range(num_epochs):
10
    for images, labels in dataloader:
11
        outputs = model_prepared(images)  # Incluye simulación de cuantización
12
        loss = criterion(outputs, labels)
13
        loss.backward()
14
        optimizer.step()
15

16
# Convertir al modelo cuantizado real
17
model_quantized = quant.convert(model_prepared)

Lamentablemente, el equipo oficial de PP-OCRv5 no ha proporcionado modelos entrenados con QAT. Esto significa que para obtener un modelo INT8 de alta calidad, habría que realizar el entrenamiento QAT desde cero, lo cual queda fuera del alcance de este proyecto.

Finalmente, opté por un compromiso: usar cuantización FP16 + aceleración por GPU, en lugar de INT8 + DSP.

El coste de esta decisión es:

El tamaño del modelo es el doble que en INT8.
No se puede aprovechar el consumo ultrabajo del DSP Hexagon.
La velocidad de inferencia es 2-3 veces más lenta que el óptimo teórico.

Pero el beneficio es:

La precisión del modelo es casi idéntica a la de FP32.
El ciclo de desarrollo se acorta drásticamente.
La complejidad del código disminuye.

La esencia de la ingeniería es el equilibrio. A veces, “suficientemente bueno” es más importante que “teóricamente óptimo”.

Conclusión

De PaddlePaddle a TFLite, de DBNet a SVTRv2, de OpenCL a NEON, la práctica de ingeniería del OCR en el dispositivo involucra conocimientos de múltiples campos como el aprendizaje profundo, compiladores, programación de GPU y desarrollo móvil.

La lección central de este proyecto es que la IA en el dispositivo no es simplemente “poner el modelo en el móvil”. Requiere:

Entender profundamente la arquitectura del modelo para realizar una conversión correcta.
Conocer las características del hardware para aprovechar plenamente los aceleradores.
Dominar la programación de sistemas para implementar código nativo de alto rendimiento.
Centrarse en la experiencia del usuario para encontrar el equilibrio entre rendimiento y consumo de energía.

PPOCRv5-Android es un proyecto de código abierto que muestra cómo desplegar modelos modernos de OCR en aplicaciones móviles reales. Espero que este artículo sirva de referencia para desarrolladores con necesidades similares.

Como dijo Google en el lanzamiento de LiteRT: “Maximum performance, simplified.” ⁹ El objetivo de la IA en el dispositivo no es la complejidad, sino simplificar lo complejo.

Epílogo

Para ser sincero, me he alejado de Android (tanto en el ámbito laboral como personal) durante al menos dos años, y esta es la primera vez que publico una librería relativamente madura en mi cuenta secundaria de GitHub (le entregué mi cuenta principal a un colega para demostrar mi determinación de marcharme).

En estos años, mi enfoque laboral no ha estado en el campo de Android; no es conveniente revelar los detalles, pero tendré oportunidad de hablar de ello en el futuro. En resumen, quizás me sea difícil volver a hacer grandes contribuciones en Android.

El lanzamiento de este proyecto nace de mi interés personal, mientras construyo una herramienta temprana basada en Android en el dispositivo, de la cual el OCR es solo una pequeña parte de la capa inferior. Más adelante (debería ser pronto) también abriré el código fuente completo, aunque por ahora no es conveniente dar detalles.

En fin, gracias por llegar hasta aquí, y espero que puedas darle una estrella (Star) a mi repositorio. ¡Gracias!

Referencias

Google AI Edge. “LiteRT: Maximum performance, simplified.” 2024. https://developers.googleblog.com/litert-maximum-performance-simplified/ ↩
PaddleOCR Team. “PaddleOCR 3.0 Technical Report.” arXiv:2507.05595, 2025. https://arxiv.org/abs/2507.05595 ↩
GitHub Discussion. “Problem while deploying the newest official PP-OCRv5.” PaddleOCR #16100, 2025. https://github.com/PaddlePaddle/PaddleOCR/discussions/16100 ↩
Liao, M., et al. “Real-time Scene Text Detection with Differentiable Binarization.” Proceedings of the AAAI Conference on Artificial Intelligence, 2020. https://arxiv.org/abs/1911.08947 ↩
Du, Y., et al. “SVTR: Scene Text Recognition with a Single Visual Model.” IJCAI, 2022. https://arxiv.org/abs/2205.00159 ↩
Du, Y., et al. “SVTRv2: CTC Beats Encoder-Decoder Models in Scene Text Recognition.” ICCV, 2025. https://arxiv.org/abs/2411.15858 ↩ ↩²
TensorFlow Blog. “Even Faster Mobile GPU Inference with OpenCL.” 2020. https://blog.tensorflow.org/2020/08/faster-mobile-gpu-inference-with-opencl.html ↩
ARM Developer. “Neon Intrinsics on Android.” ARM Documentation, 2024. https://developer.arm.com/documentation/101964/latest/ ↩
Google AI Edge. “LiteRT Documentation.” 2024. https://ai.google.dev/edge/litert ↩

mobile/ppocrv5-android.md

# Práctica de OCR en el dispositivo: Despliegue nativo de PP-OCRv5 en Android

Notas

Introducción

Conversión de modelos: El largo viaje de PaddlePaddle a TFLite

El primer obstáculo: Compatibilidad de operadores de paddle2onnx

El segundo obstáculo: HardSigmoid y compatibilidad con GPU

El tercer obstáculo: Modo de transformación de coordenadas del operador Resize

Paso final: onnx2tf y cuantización FP16

Detección de texto: Binarización Diferenciable de DBNet

Binarización estándar vs. Binarización Diferenciable

Implementación de ingeniería del flujo de post-procesamiento

Unclip: Algoritmo de expansión de cuadros de texto

Reconocimiento de texto: SVTRv2 y decodificación CTC

Innovaciones en la arquitectura de SVTRv2

¿Por qué CTC en lugar de Atención?

Decodificación CTC optimizada con NEON

Principios matemáticos de la pérdida CTC y la decodificación

Diccionario de caracteres: El reto de los 18,383 caracteres

LiteRT C++ API: La interfaz moderna tras la refactorización de 2024

Comparativa entre la API antigua y la nueva

Inicialización del entorno y del modelo

Managed Tensor Buffer: La clave para la inferencia cero copia

Aceleración por GPU: Elección y equilibrio de OpenCL

OpenCL vs. OpenGL ES: Comparativa profunda de rendimiento

Estrategia de degradación elegante

Capa nativa: C++ y optimización NEON

NEON: El conjunto de instrucciones SIMD de ARM

Implementación NEON de la normalización ImageNet

Cero dependencia de OpenCV

Implementación NEON de la interpolación bilineal

Transformación de perspectiva: Del rectángulo rotado a la línea de texto estándar

JNI: El puente entre Kotlin y C++

Diseño de arquitectura: Modularidad y testabilidad

Encapsulamiento en la capa Kotlin

Optimización del arranque en frío

Optimización de la alineación de memoria

Pool de memoria y reutilización de objetos

Optimización de la predicción de saltos

Desenrollado de bucles y software pipelining

Optimización de Prefetch

Detalles de ingeniería del post-procesamiento

Análisis de componentes conectados y detección de contornos

Algoritmos de envolvente convexa y Rotating Calipers

Algoritmo de envolvente convexa Graham Scan

Algoritmo Rotating Calipers

Rectángulo rotado delimitador mínimo

OCR de cámara en tiempo real: CameraX y análisis de frames

ImageAnalysis de CameraX

Equilibrio entre FPS y latencia

Perspectivas futuras: NPU y cuantización

Cuantización INT8: Una batalla inacabada

Primer intento: Calibración con datos sintéticos

Segundo intento: Calibración con imágenes reales

Tercer intento: Corregir el manejo de tipos en C++

Resultado final: Compromiso

Entrenamiento consciente de la cuantización: La solución correcta

Conclusión

Epílogo

Referencias

Footnotes