Pratique de l'OCR on-device : Déploiement natif de PP-OCRv5 sur Android

Description

Cet article de blog :

Couverture : Générée via Google Nano Banana 2, libre de droits.
Code source du projet : Open source sur GitHub, veuillez visiter PPOCRv5-Android pour y accéder.

Déclaration :

L’auteur (Fleey) n’est pas un professionnel du domaine de l’IA, mais un passionné. En cas d’omissions ou d’erreurs dans le texte, j’espère que les lecteurs feront preuve de compréhension et apporteront des corrections rapides !

Introduction

En 2024, Google a renommé TensorFlow Lite en LiteRT. Plus qu’un simple rebranding, cela marque un changement de paradigme de l’IA embarquée, passant du « mobile-first » vers l’« edge-first » ¹. Dans ce contexte, l’OCR (Reconnaissance Optique de Caractères), l’une des applications les plus précieuses de l’IA embarquée, traverse une révolution silencieuse.

L’équipe PaddleOCR de Baidu a publié en 2025 le modèle PP-OCRv5, un modèle OCR unifié prenant en charge plusieurs langues, dont le chinois simplifié, le chinois traditionnel, l’anglais et le japonais ². Sa version mobile ne pèse qu’environ 70 Mo, mais elle est capable de reconnaître 18 383 caractères dans un seul modèle. Derrière ce chiffre se cache la collaboration de deux réseaux de neurones profonds : la détection et la reconnaissance.

Cependant, un problème se pose : PP-OCRv5 est entraîné sur le framework PaddlePaddle, alors que le moteur d’inférence le plus mature sur Android est LiteRT. Comment franchir ce fossé ?

Commençons par la conversion du modèle pour lever progressivement le voile sur l’ingénierie de l’OCR embarqué.

1
flowchart TB
2
    subgraph E2E["Flux OCR de bout en bout"]
3
        direction TB
4

5
        subgraph Input["Entrée"]
6
            IMG[Image originale<br/>Taille arbitraire]
7
        end
8

9
        subgraph Detection["Détection de texte - DBNet"]
10
            DET_PRE[Pré-traitement<br/>Resize 640x640<br/>Normalisation ImageNet]
11
            DET_INF[Inférence DBNet<br/>~45ms GPU]
12
            DET_POST[Post-traitement<br/>Binarisation - Contours - Rectangle orienté]
13
        end
14

15
        subgraph Recognition["Reconnaissance de texte - SVTRv2"]
16
            REC_CROP[Recadrage par transformation perspective<br/>Largeur adaptative 48xW]
17
            REC_INF[Inférence SVTRv2<br/>~15ms/ligne GPU]
18
            REC_CTC[Décodage CTC<br/>Fusion des répétitions + Suppression des blancs]
19
        end
20

21
        subgraph Output["Sortie"]
22
            RES[Résultats OCR<br/>Texte + Confiance + Position]
23
        end
24
    end
25

26
    IMG --> DET_PRE --> DET_INF --> DET_POST
27
    DET_POST -->|N boîtes de texte| REC_CROP
28
    REC_CROP --> REC_INF --> REC_CTC --> RES

Conversion du modèle : Le long voyage de PaddlePaddle vers TFLite

La fragmentation des frameworks de deep learning est un point sensible du secteur. PyTorch, TensorFlow, PaddlePaddle, ONNX : chaque framework possède son propre format de modèle et ses propres implémentations d’opérateurs. ONNX (Open Neural Network Exchange) tente d’être une représentation intermédiaire universelle, mais la réalité est souvent moins idéale que la théorie.

Le chemin de conversion pour PP-OCRv5 est le suivant :

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

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

10
    subgraph Optimization["Optimisation du graphe"]
11
        GS[onnx-graphsurgeon<br/>Décomposition d'opérateurs]
12
    end
13

14
    subgraph TFLite["Format LiteRT"]
15
        TM[model.tflite<br/>Quantifié en FP16]
16
    end
17

18
    PM -->|paddle2onnx| OM
19
    OM -->|Décomposition HardSigmoid<br/>Modif mode Resize| GS
20
    GS -->|onnx2tf| TM

Ce chemin semble simple, mais il recèle des subtilités techniques.

Premier obstacle : Compatibilité des opérateurs de paddle2onnx

paddle2onnx est l’outil de conversion officiel fourni par PaddlePaddle. En théorie, il peut convertir les modèles PaddlePaddle au format ONNX. Cependant, PP-OCRv5 utilise certains opérateurs spécifiques dont le mapping dans ONNX n’est pas direct.

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

Un détail crucial ici : le fichier de modèle de PP-OCRv5 est inference.json au lieu du traditionnel inference.pdmodel. Il s’agit d’un changement de format dans les nouvelles versions de PaddlePaddle, ce qui piège de nombreux développeurs ³.

Deuxième obstacle : HardSigmoid et compatibilité GPU

Le modèle ONNX converti contient l’opérateur HardSigmoid. Cet opérateur est défini mathématiquement comme suit :

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

Où $\alpha = 0.2$ et $\beta = 0.5$ .

Le problème est que le GPU Delegate de LiteRT ne supporte pas HardSigmoid. Lorsqu’un modèle contient un opérateur non supporté, le GPU Delegate fait basculer (fallback) tout le sous-graphe vers le CPU, ce qui entraîne une perte de performance importante.

La solution consiste à décomposer HardSigmoid en opérateurs de base. En utilisant la bibliothèque onnx-graphsurgeon, nous pouvons effectuer une “chirurgie” au niveau du graphe de calcul :

1
import onnx_graphsurgeon as gs
2
import numpy as np
3

4
def decompose_hardsigmoid(graph: gs.Graph) -> gs.Graph:
5
    """
6
    Décompose HardSigmoid en opérateurs de base compatibles GPU
7
    HardSigmoid(x) = max(0, min(1, alpha*x + beta))
8
    Décomposition en : Mul -> Add -> Clip
9
    """
10
    for node in graph.nodes:
11
        if node.op == "HardSigmoid":
12
            # Récupérer les paramètres 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
            # Créer des tenseurs constants
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
            # Créer des variables intermédiaires
30
            mul_out = gs.Variable(name=f"{node.name}_mul_out")
31
            add_out = gs.Variable(name=f"{node.name}_add_out")
32

33
            # Construire le sous-graphe décomposé : 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
            # Remplacer le nœud d'origine
52
            graph.nodes.remove(node)
53
            graph.nodes.extend([mul_node, add_node, clip_node])
54

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

L’intérêt de cette décomposition réside dans le fait que Mul, Add et Clip sont des opérateurs entièrement supportés par le GPU Delegate de LiteRT. Après décomposition, l’ensemble du sous-graphe peut être exécuté en continu sur le GPU, évitant ainsi les coûts de transfert de données entre CPU et GPU.

TIP

Pourquoi ne pas modifier directement le code d’entraînement du modèle ? Parce que le calcul du gradient de HardSigmoid lors de l’entraînement diffère de celui de Clip. La décomposition ne doit être effectuée que lors de la phase d’inférence pour maintenir la stabilité numérique de l’entraînement.

Troisième obstacle : Mode de transformation des coordonnées de l’opérateur Resize

L’opérateur Resize d’ONNX possède un attribut coordinate_transformation_mode qui détermine comment mapper les coordonnées de sortie aux coordonnées d’entrée. PP-OCRv5 utilise le mode half_pixel, mais le support de ce mode par le GPU Delegate de LiteRT est limité.

Le changer en mode asymmetric permet d’obtenir une meilleure compatibilité GPU :

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

WARNING

Cette modification peut entraîner de légères différences numériques. Lors des tests réels, l’impact de cette différence sur la précision de l’OCR est négligeable, mais elle peut nécessiter une évaluation minutieuse pour d’autres tâches.

Dernière étape : onnx2tf et quantification FP16

onnx2tf est un outil permettant de convertir les modèles ONNX au format TFLite. La quantification FP16 (virgule flottante demi-précision) est un choix courant pour le déploiement mobile : elle réduit de moitié la taille du modèle tout en conservant une précision acceptable, et permet d’exploiter les unités de calcul FP16 des GPU mobiles.

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

L’argument -ois spécifie ici la forme statique (static shape) de l’entrée. Les formes statiques sont cruciales pour l’accélération GPU ; les formes dynamiques obligeraient à recompiler le programme GPU à chaque inférence, ce qui nuirait gravement aux performances.

Détection de texte : La binarisation différentiable de DBNet

Le module de détection de PP-OCRv5 est basé sur DBNet (Differentiable Binarization Network) ⁴. Contrairement aux méthodes traditionnelles qui utilisent un seuil fixe pour la binarisation, l’innovation de DBNet consiste à laisser le réseau apprendre lui-même le seuil optimal pour chaque pixel.

1
flowchart TB
2
    subgraph DBNet["Architecture DBNet"]
3
        direction TB
4
        IMG[Image d'entrée<br/>H x W x 3]
5
        BB[Backbone<br/>MobileNetV3]
6
        FPN[Pyramide de caractéristiques FPN<br/>Fusion multi-échelle]
7

8
        subgraph Heads["Sorties à deux branches"]
9
            PH[Carte de probabilité<br/>P: H x W x 1]
10
            TH[Carte de seuil<br/>T: H x W x 1]
11
        end
12

13
        DB["Binarisation différentiable<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

Binarisation standard vs Binarisation différentiable

La binarisation standard est une fonction en escalier :

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

Cette fonction n’est pas dérivable, ce qui empêche un entraînement de bout en bout par rétropropagation. DBNet propose une fonction d’approximation :

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

Où $P$ est la carte de probabilité, $T$ est la carte de seuil (apprise par le réseau), et $k$ est un facteur d’amplification (fixé à 50 lors de l’entraînement).

TIP

Cette formule est essentiellement une fonction Sigmoid, dont l’entrée est devenue $P - T$ . Lorsque $k$ est suffisamment grand, son comportement se rapproche d’une fonction en escalier tout en restant dérivable.

Implémentation technique du flux de post-traitement

Dans le projet PPOCRv5-Android, le flux de post-traitement est implémenté dans postprocess.cpp. Les étapes clés comprennent :

1
flowchart LR
2
    subgraph Input["Sortie du modèle"]
3
        PM[Carte de probabilité P<br/>640 x 640]
4
    end
5

6
    subgraph Binary["Binarisation"]
7
        BT[Filtrage par seuil<br/>seuil=0.1]
8
        BM[Image binaire<br/>640 x 640]
9
    end
10

11
    subgraph Contour["Détection de contours"]
12
        DS[Sous-échantillonnage 4x<br/>160 x 160]
13
        CC[Analyse de composantes connexes<br/>Parcours BFS]
14
        BD[Extraction des points de bordure]
15
    end
16

17
    subgraph Geometry["Calculs géométriques"]
18
        CH[Calcul de l'enveloppe convexe<br/>Graham Scan]
19
        RR[Rotating Calipers<br/>Rectangle englobant min]
20
        UC[Extension Unclip<br/>ratio=1.5]
21
    end
22

23
    subgraph Output["Sortie"]
24
        TB[RotatedRect<br/>centre, taille, angle]
25
    end
26

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

Dans le code réel, la méthode TextDetector::Impl::Detect illustre le flux complet de détection :

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

8
    // 2. Redimensionnement par interpolation bilinéaire vers 640x640
9
    image_utils::ResizeBilinear(image_data, width, height, stride,
10
                                resized_buffer_.data(), kDetInputSize, kDetInputSize);
11

12
    // 3. Normalisation ImageNet
13
    PrepareFloatInput();
14

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

18
    // 5. Binarisation
19
    BinarizeOutput(prob_map, total_pixels);
20

21
    // 6. Détection de contours
22
    auto contours = postprocess::FindContours(binary_map_.data(),
23
                                              kDetInputSize, kDetInputSize);
24

25
    // 7. Rectangle englobant minimum + Unclip
26
    for (const auto &contour : contours) {
27
        RotatedRect rect = postprocess::MinAreaRect(contour);
28
        UnclipBox(rect, kUnclipRatio);
29
        // Mapper les coordonnées vers l'image originale
30
        rect.center_x *= scale_x_;
31
        rect.center_y *= scale_y_;
32
        // ...
33
    }
34
}

Le point crucial de ce flux est le « rectangle englobant minimum orienté ». Contrairement aux boîtes englobantes alignées sur les axes (AABB), les rectangles orientés peuvent épouser étroitement du texte sous n’importe quel angle, ce qui est essentiel pour le texte incliné dans les scènes naturelles.

Unclip : Algorithme de dilatation des boîtes de texte

Les zones de texte produites par DBNet sont généralement légèrement plus petites que le texte réel, car le réseau apprend la « zone centrale » du texte. Pour obtenir les bordures complètes du texte, une opération de dilatation (Unclip) est nécessaire sur les polygones détectés.

Le principe mathématique d’Unclip repose sur l’opération inverse de l’algorithme de clipping de polygones de Vatti. Pour un polygone $P$ et une distance de dilatation $d$ , le polygone dilaté $P'$ satisfait :

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

Où $A$ est l’aire du polygone, $L$ son périmètre, et $r$ le ratio de dilatation (généralement fixé à 1.5).

Dans postprocess.cpp, la fonction UnclipBox implémente cette logique :

1
void UnclipBox(RotatedRect &box, float unclip_ratio) {
2
    // Calculer la distance de dilatation
3
    float area = box.width * box.height;
4
    float perimeter = 2.0f * (box.width + box.height);
5

6
    if (perimeter < 1e-6f) return;  // Éviter la division par zéro
7

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

11
    // Dilatation vers l'extérieur : augmenter largeur et hauteur de 2d
12
    box.width += 2.0f * distance;
13
    box.height += 2.0f * distance;
14
}

Cette version simplifiée suppose que la boîte de texte est un rectangle. Pour des polygones plus complexes, il faudrait utiliser la bibliothèque Clipper complète pour effectuer un décalage (offset) de polygone :

1
// Unclip complet de polygone (via la bibliothèque Clipper)
2
ClipperLib::Path polygon;
3
for (const auto& pt : contour) {
4
    polygon.push_back(ClipperLib::IntPoint(
5
        static_cast<int>(pt.x * 1000),  // Agrandir pour préserver la précision
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);  // Dilatation

NOTE

PPOCRv5-Android a opté pour une dilatation rectangulaire simplifiée plutôt qu’un décalage de polygone complet. Les raisons sont les suivantes :

La plupart des boîtes de texte sont proches de rectangles.
La bibliothèque Clipper complète augmenterait considérablement la taille du binaire.
La version simplifiée offre de meilleures performances.

Reconnaissance de texte : SVTRv2 et décodage CTC

Si la détection consiste à « trouver où se trouve le texte », la reconnaissance consiste à « lire ce qu’est le texte ». Le module de reconnaissance de PP-OCRv5 est basé sur SVTRv2 (Scene Text Recognition with Visual Transformer v2) ⁵.

Innovations architecturales de SVTRv2

SVTRv2 apporte trois améliorations clés par rapport à la génération précédente SVTR :

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

5
        subgraph Encoder["Encodeur visuel"]
6
            PE[Patch Embedding<br/>Convolution 4x4]
7

8
            subgraph Mixing["Blocs d'attention hybride x12"]
9
                LA[Attention locale<br/>Fenêtre 7x7]
10
                GA[Attention globale<br/>Champ récepteur global]
11
                FFN[Feed Forward<br/>MLP]
12
            end
13
        end
14

15
        subgraph Decoder["Décodeur CTC"]
16
            FC[Couche entièrement connectée<br/>D -> 18384]
17
            SM[Softmax]
18
            CTC[Décodage CTC]
19
        end
20
    end
21

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

Mécanisme d’attention hybride : Utilisation alternée de l’attention locale (pour capturer les détails des traits) et de l’attention globale (pour comprendre la structure des caractères). L’attention locale utilise une fenêtre glissante de 7x7, réduisant la complexité de calcul de $O(n^2)$ à $O(n \times 49)$ .
Fusion de caractéristiques multi-échelles : Contrairement à la résolution unique de ViT, SVTRv2 utilise différentes résolutions de cartes de caractéristiques à différentes profondeurs, similaire à une structure pyramidale de CNN.
Module de Guidage Sémantique (Semantic Guidance Module) : Ajout d’une branche sémantique légère à la fin de l’encodeur pour aider le modèle à comprendre les relations sémantiques entre les caractères, au-delà des simples caractéristiques visuelles.

Ces améliorations permettent à SVTRv2 d’atteindre une précision comparable aux méthodes basées sur l’Attention, tout en conservant la simplicité du décodage CTC ⁶.

Pourquoi le CTC plutôt que l’Attention ?

Il existe deux paradigmes dominants pour la reconnaissance de texte :

CTC (Connectionist Temporal Classification) : Considère la reconnaissance comme un problème d’étiquetage de séquence, où la sortie est alignée avec l’entrée.
Décodeur basé sur l’Attention : Utilise un mécanisme d’attention pour générer la sortie caractère par caractère.

Les méthodes basées sur l’Attention sont généralement plus précises, mais les méthodes CTC sont plus simples et plus rapides. La contribution de SVTRv2 est d’améliorer l’encodeur visuel pour permettre aux méthodes CTC d’égaler, voire de dépasser, la précision des méthodes basées sur l’Attention ⁶.

Le cœur du décodage CTC consiste à « fusionner les répétitions » et à « supprimer les blancs » :

1
flowchart LR
2
    subgraph Input["Sortie du modèle"]
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["Fusion répétitions"]
19
        M["blank, H, blank, e, l, o"]
20
    end
21

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

26
    subgraph Output["Sortie"]
27
        O["Helo - Erreur"]
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

Attendez, il y a un problème ici. Si le texte original est “Hello”, les deux ‘l’ ont été fusionnés par erreur. La solution du CTC est d’insérer un jeton “blank” entre les caractères répétés.

1
Encodage correct : [blank, H, e, l, blank, l, o]
2
Résultat du décodage : "Hello"

Décodage CTC optimisé par NEON

Le décodage CTC de PPOCRv5-Android utilise un Argmax optimisé par NEON. Dans 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 scalaire
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
    // Vectorisation NEON : traite 4 float à la fois
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
        // Comparaison vectorisée et sélection conditionnelle
28
        uint32x4_t cmp = vcgtq_f32(v_curr, v_max);
29
        v_max = vbslq_f32(cmp, v_curr, v_max);        // Choisir la plus grande valeur
30
        v_max_idx = vbslq_s32(cmp, v_idx, v_max_idx); // Choisir l'index correspondant
31
    }
32

33
    // Réduction horizontale : trouver le max parmi les 4 candidats
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
    // ... comparaison finale
39
}

Pour un Argmax de 18 384 catégories, l’optimisation NEON peut apporter une accélération d’environ 3 fois.

Principes mathématiques de la fonction de perte CTC et du décodage

L’idée centrale du CTC est la suivante : étant donné une séquence d’entrée $X$ et tous les chemins d’alignement possibles $\pi$ , calculer la probabilité de la séquence cible $Y$ :

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

Où $\mathcal{B}$ est une “fonction de mapping plusieurs-vers-un” qui mappe le chemin $\pi$ à la séquence de sortie $Y$ (en fusionnant les répétitions et en supprimant les blancs).

Lors de l’inférence, nous utilisons le décodage glouton (Greedy Decoding) plutôt qu’un Beam Search complet :

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;  // Utilisé pour fusionner les répétitions
5

6
    for (int t = 0; t < time_steps; ++t) {
7
        // Trouver la catégorie de probabilité maximale pour le pas de temps actuel
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
        // Règles de décodage CTC :
19
        // 1. Ignorer le jeton blank (index 0)
20
        // 2. Fusionner les caractères consécutifs répétés
21
        if (max_idx != 0 && max_idx != prev_idx) {
22
            result += dictionary[max_idx - 1];  // -1 car blank occupe l'index 0
23
        }
24

25
        prev_idx = max_idx;
26
    }
27

28
    return result;
29
}

La complexité temporelle du décodage glouton est $O(T \times C)$ , où $T$ est le nombre de pas de temps et $C$ le nombre de catégories. Pour PP-OCRv5, $T \approx 80$ et $C = 18384$ , chaque décodage nécessite environ 1,5 million de comparaisons. C’est pourquoi l’optimisation NEON est si importante.

TIP

Le Beam Search peut améliorer la précision du décodage, mais sa charge de calcul est $k$ fois supérieure à celle du décodage glouton ( $k$ étant la largeur du faisceau). Sur mobile, le décodage glouton est généralement un meilleur choix.

Dictionnaire de caractères : Le défi des 18 383 caractères

PP-OCRv5 prend en charge 18 383 caractères, incluant :

Caractères chinois simplifiés courants
Caractères chinois traditionnels courants
Lettres anglaises et chiffres
Hiragana et Katakana japonais
Ponctuation courante et caractères spéciaux

Ce dictionnaire est stocké dans le fichier keys_v5.txt, avec un caractère par ligne. Lors du décodage CTC, la forme des logits de sortie du modèle est [1, T, 18384], où T est le nombre de pas de temps, et 18384 = 18383 caractères + 1 jeton blank.

API C++ LiteRT : L’interface moderne après la refactorisation de 2024

PPOCRv5-Android utilise l’API C++ de LiteRT telle qu’elle a été refactorisée en 2024, offrant une conception d’interface plus moderne. Par rapport à l’API C traditionnelle de TFLite, la nouvelle API offre une meilleure sécurité de typage et de meilleures capacités de gestion des ressources.

Comparaison entre l’ancienne et la nouvelle API

La refactorisation de LiteRT en 2024 a apporté des changements significatifs :

Caractéristique	Ancienne API (TFLite)	Nouvelle API (LiteRT)
Espace de noms	`tflite::`	`litert::`
Gestion d’erreurs	Retourne l’énumération `TfLiteStatus`	Retourne le type `Expected<T>`
Gestion mémoire	Manuelle	Automatique via RAII
Configuration Delegate	API dispersées	Classe `Options` unifiée
Accès aux tenseurs	Pointeurs + cast manuel	`TensorBuffer` sécurisé

L’avantage majeur de la nouvelle API réside dans la sécurité du typage et la gestion automatique des ressources. Exemple avec la gestion d’erreurs :

1
// Ancienne API : nécessite de vérifier manuellement chaque valeur de retour
2
TfLiteStatus status = TfLiteInterpreterAllocateTensors(interpreter);
3
if (status != kTfLiteOk) {
4
    // Gestion d'erreur
5
}
6

7
// Nouvelle API : utilise le type Expected, supporte le chaînage d'appels
8
auto model_result = litert::CompiledModel::Create(env, model_path, options);
9
if (!model_result) {
10
    LOGE(TAG, "Erreur : %s", model_result.Error().Message().c_str());
11
    return false;
12
}
13
auto model = std::move(*model_result);  // Gestion automatique du cycle de vie

Environnement et initialisation du modèle

Dans text_detector.cpp, le flux d’initialisation est le suivant :

1
bool Initialize(const std::string &model_path, AcceleratorType accelerator_type) {
2
    // 1. Créer l'environnement LiteRT
3
    auto env_result = litert::Environment::Create({});
4
    if (!env_result) {
5
        LOGE(TAG, "Échec de création de l'environnement LiteRT : %s",
6
             env_result.Error().Message().c_str());
7
        return false;
8
    }
9
    env_ = std::move(*env_result);
10

11
    // 2. Configurer l'accélérateur matériel
12
    auto options_result = litert::Options::Create();
13
    auto hw_accelerator = ToLiteRtAccelerator(accelerator_type);
14
    options.SetHardwareAccelerators(hw_accelerator);
15

16
    // 3. Compiler le modèle
17
    auto model_result = litert::CompiledModel::Create(*env_, model_path, options);
18
    if (!model_result) {
19
        LOGW(TAG, "Échec de création du CompiledModel avec l'accélérateur %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. Ajuster la forme du tenseur d'entrée
27
    std::vector<int> input_dims = {1, kDetInputSize, kDetInputSize, 3};
28
    compiled_model_->ResizeInputTensor(0, absl::MakeConstSpan(input_dims));
29

30
    // 5. Créer des buffers gérés
31
    CreateBuffersWithCApi();
32

33
    return true;
34
}

Managed Tensor Buffer : La clé de l’inférence zéro-copie

Le Managed Tensor Buffer de LiteRT est essentiel pour obtenir une inférence haute performance. Il permet au GPU Delegate d’accéder directement au buffer, sans transfert de données CPU-GPU :

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

5
    // Obtenir les exigences du buffer d'entrée
6
    LiteRtTensorBufferRequirements input_requirements = nullptr;
7
    LiteRtGetCompiledModelInputBufferRequirements(
8
        c_model, /*signature_index=*/0, /*input_index=*/0,
9
        &input_requirements);
10

11
    // Obtenir les informations de type du tenseur
12
    auto input_type = compiled_model_->GetInputTensorType(0, 0);
13
    LiteRtRankedTensorType tensor_type =
14
        static_cast<LiteRtRankedTensorType>(*input_type);
15

16
    // Créer un buffer géré
17
    LiteRtTensorBuffer input_buffer = nullptr;
18
    LiteRtCreateManagedTensorBufferFromRequirements(
19
        c_env, &tensor_type, input_requirements, &input_buffer);
20

21
    // Envelopper dans un objet C++, gestion automatique du cycle de vie
22
    input_buffers_.push_back(
23
        litert::TensorBuffer::WrapCObject(input_buffer,
24
                                          litert::OwnHandle::kYes));
25
    return true;
26
}

Les avantages de cette conception sont :

Inférence zéro-copie : Le GPU Delegate accède directement au buffer.
Gestion automatique de la mémoire : OwnHandle::kYes garantit que le buffer est libéré lors de la destruction de l’objet C++.
Sécurité de typage : Vérification de la correspondance des types de tenseurs à la compilation.

Accélération GPU : Choix et compromis d’OpenCL

LiteRT propose plusieurs options d’accélération matérielle :

1
flowchart TB
2
    subgraph Delegates["Écosystème 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/>Optimisé CPU]
8
    end
9

10
    subgraph Hardware["Mapping matériel"]
11
        direction TB
12
        ADRENO[GPU Adreno<br/>Qualcomm]
13
        MALI[GPU Mali<br/>ARM]
14
        NPU[NPU/DSP<br/>Spécifique constructeur]
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

Accélérateur	Backend	Avantages	Inconvénients
GPU	OpenCL	Large support, bonnes perfs	Pas un composant standard Android
GPU	OpenGL ES	Composant standard Android	Moins performant qu’OpenCL
NPU	NNAPI	Performance maximale	Mauvaise compatibilité appareils
CPU	XNNPACK	Compatibilité universelle	Performance la plus faible

PPOCRv5-Android a choisi OpenCL comme backend d’accélération principal. Google a publié le backend OpenCL pour TFLite en 2020, lequel offre une accélération environ 2 fois supérieure au backend OpenGL ES sur les GPU Adreno ⁷.

Les avantages d’OpenCL proviennent de plusieurs aspects :

Intention de conception : OpenCL a été conçu dès le départ pour le calcul généraliste, tandis qu’OpenGL est une API de rendu graphique à laquelle le support des compute shaders a été ajouté plus tard.
Mémoire constante : La mémoire constante d’OpenCL est très efficace pour l’accès aux poids des réseaux de neurones.
Support FP16 : OpenCL supporte nativement la virgule flottante demi-précision, alors que le support d’OpenGL est arrivé plus tard.

Cependant, OpenCL présente un défaut majeur : il n’est pas un composant standard d’Android. La qualité des implémentations OpenCL varie selon les constructeurs, et certains appareils ne le supportent pas du tout.

OpenCL vs OpenGL ES : Comparaison approfondie des performances

Pour comprendre l’avantage d’OpenCL, il faut descendre au niveau de l’architecture GPU. Prenons l’exemple du Qualcomm Adreno 640 :

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

5
        subgraph SP["Shader Processors x2"]
6
            ALU1[Tableau ALU<br/>256 FP32 / 512 FP16]
7
            ALU2[Tableau ALU<br/>256 FP32 / 512 FP16]
8
        end
9

10
        subgraph Memory["Hiérarchie mémoire"]
11
            L1[Cache L1<br/>16KB par SP]
12
            L2[Cache L2<br/>1MB partagé]
13
            GMEM[Mémoire globale<br/>LPDDR4X]
14
        end
15

16
        subgraph Special["Unités dédiées"]
17
            TMU[Unité de texture<br/>Interpolation bilinéaire]
18
            CONST[Cache constante<br/>Accélération des poids]
19
        end
20
    end
21

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

L’avantage de performance d’OpenCL provient de :

Caractéristique	OpenCL	OpenGL ES Compute
Mémoire constante	Support natif, accélération matérielle	Nécessite une simulation via UBO
Taille du groupe de travail	Configuration flexible	Limitée par le modèle de shader
Barrière mémoire	Contrôle fin	Grain grossier
Calcul FP16	Extension `cl_khr_fp16`	Nécessite la précision `mediump`
Outils de débogage	Snapdragon Profiler	Support limité

Dans les opérations de convolution, les poids sont généralement constants. OpenCL peut placer les poids en mémoire constante, bénéficiant ainsi d’optimisations de diffusion (broadcast) au niveau matériel. OpenGL ES doit passer les poids comme des Uniform Buffer Objects (UBO), ce qui augmente la charge d’accès mémoire.

NOTE

Google a restreint le chargement direct des bibliothèques OpenCL par les applications depuis Android 7.0. Cependant, le GPU Delegate de LiteRT contourne cette restriction en utilisant dlopen pour charger dynamiquement l’implémentation OpenCL du système. C’est pourquoi le GPU Delegate doit détecter la disponibilité d’OpenCL au moment de l’exécution.

Stratégie de dégradation gracieuse (Fallback)

PPOCRv5-Android implémente une stratégie de repli :

1
constexpr AcceleratorType kFallbackChain[] = {
2
    AcceleratorType::kGpu,  // Premier choix : GPU
3
    AcceleratorType::kCpu,  // Repli : 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
}

Cette stratégie garantit que l’application fonctionne sur n’importe quel appareil, seules les performances varient.

Couche native : Optimisations C++ et NEON

Pourquoi utiliser le C++ plutôt que Kotlin ?

La réponse est simple : la performance. Le pré-traitement d’image implique de nombreuses opérations au niveau du pixel, dont le coût sur la JVM est inacceptable. Plus important encore, le C++ permet d’utiliser directement les instructions SIMD ARM NEON pour réaliser des calculs vectorisés.

NEON : Le jeu d’instructions SIMD d’ARM

NEON est une extension SIMD (Single Instruction, Multiple Data) des processeurs ARM. Elle permet à une seule instruction de traiter simultanément plusieurs éléments de données.

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

9
    subgraph Operations["Opérations vectorisées"]
10
        direction TB
11
        LD["vld1q_f32<br/>Charger 4 float"]
12
        SUB["vsubq_f32<br/>Soustraction parallèle 4 voies"]
13
        MUL["vmulq_f32<br/>Multiplication parallèle 4 voies"]
14
        ST["vst1q_f32<br/>Stocker 4 float"]
15
    end
16

17
    subgraph Speedup["Gain de performance"]
18
        S1["Scalaire : 4 instructions"]
19
        S2["NEON : 1 instruction"]
20
        S3["Accélération théorique : 4x"]
21
    end
22

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

PPOCRv5-Android utilise l’optimisation NEON dans plusieurs chemins critiques. Exemple avec la binarisation (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
        // Traiter 16 pixels à la fois
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
        // Comparaison vectorisée
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
        // Réduction vers uint8
22
        uint16x4_t n0 = vmovn_u32(cmp0);
23
        uint16x4_t n1 = vmovn_u32(cmp1);
24
        uint16x8_t n01 = vcombine_u16(n0, n1);
25
        // ... fusion et stockage
26
    }
27
    // Fallback scalaire pour les pixels restants
28
    for (; i < total_pixels; ++i) {
29
        binary_map_[i] = (prob_map[i] > kBinaryThreshold) ? 255 : 0;
30
    }
31
#else
32
    // Implémentation purement scalaire
33
    for (int i = 0; i < total_pixels; ++i) {
34
        binary_map_[i] = (prob_map[i] > kBinaryThreshold) ? 255 : 0;
35
    }
36
#endif
37
}

Points clés d’optimisation de ce code :

Chargement par lots : vld1q_f32 charge 4 float à la fois, réduisant le nombre d’accès mémoire.
Comparaison vectorisée : vcgtq_f32 compare 4 valeurs simultanément et génère un masque.
Réduction de type : vmovn_u32 compresse les résultats 32 bits en 16 bits, puis finalement en 8 bits.

Par rapport à une implémentation scalaire, l’optimisation NEON peut apporter une accélération de 3 à 4 fois ⁸.

Implémentation NEON de la normalisation ImageNet

La normalisation de l’image est une étape clé du pré-traitement. La standardisation ImageNet utilise la formule suivante :

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

Où $\mu = [0.485, 0.456, 0.406]$ et $\sigma = [0.229, 0.224, 0.225]$ (canaux RGB).

Dans image_utils.cpp, l’implémentation de la normalisation optimisée par NEON est la suivante :

1
void NormalizeImageNet(const uint8_t* src, int width, int height, int stride,
2
                       float* dst) {
3
    // Paramètres de normalisation 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
    // Pré-calcul : (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
    // Pré-calcul : -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
            // Charger 4 pixels RGBA (16 octets)
29
            uint8x16_t rgba = vld1q_u8(row + x * 4);
30

31
            // Dé-entrelacement : 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
            // Normalisation : (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
            // Stockage entrelacé : 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
        // Traitement scalaire des pixels restants
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
    // Implémentation scalaire (omise)
64
#endif
65
}

Techniques d’optimisation clés de ce code :

Pré-calcul des constantes : Transformer (x - mean) / std en x * scale + bias pour réduire les divisions à l’exécution.
Fused Multiply-Add : vmlaq_f32 effectue une multiplication et une addition en une seule instruction.
Chargement dé-entrelacé : vld4q_u8 sépare automatiquement le RGBA en quatre canaux.
Stockage entrelacé : vst3q_f32 écrit les trois canaux RGB de manière entrelacée en mémoire.

Zéro dépendance OpenCV

De nombreux projets OCR dépendent d’OpenCV pour le pré-traitement d’image. OpenCV est puissant, mais il alourdit considérablement la taille du paquet (plus de 10 Mo sur Android).

PPOCRv5-Android a choisi la voie du « zéro dépendance OpenCV ». Toutes les opérations de pré-traitement d’image sont implémentées en C++ pur dans image_utils.cpp :

Redimensionnement par interpolation bilinéaire : Implémenté à la main, supportant l’optimisation NEON.
Normalisation : Standardisation ImageNet et normalisation de reconnaissance.
Transformation perspective : Recadrage de zones de texte sous n’importe quel angle à partir de l’image originale.

Implémentation NEON de l’interpolation bilinéaire

L’interpolation bilinéaire est l’algorithme central du redimensionnement d’image. Étant donné les coordonnées $(x, y)$ de l’image source, l’interpolation bilinéaire calcule la valeur du pixel cible :

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

Où $\alpha = x - \lfloor x \rfloor$ , $\beta = y - \lfloor y \rfloor$ , et $f_{ij}$ sont les valeurs des quatre pixels voisins.

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 : traite 4 pixels cibles à la fois
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
            // Calculer 4 coordonnées sources
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
            // Charger les poids 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
            // Effectuer l'interpolation bilinéaire pour chaque canal
41
            for (int c = 0; c < 4; ++c) {  // RGBA
42
                float32x4_t f00, f10, f01, f11;
43

44
                // Collecter les valeurs voisines de 4 pixels
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 similaires
50

51
                // Formule d'interpolation bilinéaire
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
                // Reconvertir en uint8 et stocker
69
                uint32x4_t result_u32 = vcvtq_u32_f32(result);
70
                // ... stockage
71
            }
72
        }
73
#endif
74
        // Traitement scalaire des pixels restants (omis)
75
    }
76
}

TIP

L’optimisation NEON de l’interpolation bilinéaire est complexe car les adresses des quatre pixels voisins ne sont pas contiguës. Une méthode plus efficace consiste à utiliser l’interpolation bilinéaire séparable : d’abord horizontalement, puis verticalement. Cela permet de mieux exploiter la localité du cache.

Ce choix a nécessité plus de travail de développement, mais les bénéfices sont notables :

Réduction de la taille de l’APK d’environ 10 Mo.
Contrôle total sur la logique de pré-traitement, facilitant l’optimisation.
Évitement des problèmes de compatibilité de versions d’OpenCV.

Transformation perspective : Du rectangle orienté à la ligne de texte standard

Les modèles de reconnaissance de texte attendent en entrée des images de lignes de texte horizontales. Cependant, les boîtes de texte détectées peuvent être des rectangles orientés sous n’importe quel angle. La transformation perspective se charge de « redresser » ces zones rectangulaires.

Dans text_recognizer.cpp, la méthode CropAndRotate implémente cette fonctionnalité :

1
void CropAndRotate(const uint8_t *__restrict__ image_data,
2
                   int width, int height, int stride,
3
                   const RotatedRect &box, int &target_width) {
4
    // Calculer les quatre coins du rectangle orienté
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];  // Coordonnées (x, y) des 4 coins
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
    // ... calculer les autres coins
14

15
    // Largeur cible adaptative : préserver le ratio d'aspect
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
    // Matrice de transformation affine
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
    // Échantillonnage par interpolation bilinéaire + normalisation (optimisé 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
}

Optimisations clés de cette implémentation :

Largeur adaptative : Ajuster dynamiquement la largeur de sortie selon le ratio d’aspect de la boîte de texte pour éviter tout étirement ou compression excessifs.
Approximation par transformation affine : Pour les boîtes de texte proches d’un parallélogramme, utiliser une transformation affine au lieu d’une transformation perspective pour réduire les calculs.
Interpolation bilinéaire NEON : L’échantillonnage et la normalisation sont effectués en une seule passe, réduisant les accès mémoire.

JNI : Le pont entre Kotlin et C++

Le JNI (Java Native Interface) est le pont de communication entre Kotlin/Java et le C++. Cependant, les appels JNI ont un coût ; des appels fréquents entre les langages peuvent gravement nuire aux performances.

Le principe de conception de PPOCRv5-Android est de minimiser le nombre d’appels JNI. Tout le flux OCR ne nécessite qu’un seul appel JNI :

1
sequenceDiagram
2
    participant K as Couche Kotlin
3
    participant J as Pont JNI
4
    participant N as Couche Native
5
    participant G as GPU
6

7
    K->>J: process(bitmap)
8
    J->>N: Passer le pointeur RGBA
9

10
    Note over N,G: La couche native effectue tout le travail
11

12
    N->>N: Pré-traitement d'image NEON
13
    N->>G: Inférence détection de texte
14
    G-->>N: Carte de probabilité
15
    N->>N: Post-traitement détection contours
16

17
    loop Chaque boîte de texte
18
        N->>N: Recadrage transformation perspective
19
        N->>G: Inférence reconnaissance de texte
20
        G-->>N: logits
21
        N->>N: Décodage CTC
22
    end
23

24
    N-->>J: Résultats OCR
25
    J-->>K: List OcrResult

Dans ppocrv5_jni.cpp, la fonction centrale nativeProcess illustre cette conception :

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
    // Verrouiller les pixels du Bitmap
8
    void *pixels = nullptr;
9
    AndroidBitmap_lockPixels(env, bitmap, &pixels);
10

11
    // Un seul appel JNI pour tout le travail 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
    // Construire et retourner le tableau d'objets Java
21
    // ...
22
}

Cette conception évite le coût des allers-retours de données entre la détection et la reconnaissance.

Conception architecturale : Modularité et testabilité

L’architecture de PPOCRv5-Android suit le principe de « séparation des préoccupations » (SoC) :

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

9
    subgraph VM["Couche ViewModel"]
10
        OVM[OCRViewModel<br/>Gestion d'état]
11
    end
12

13
    subgraph Native["Couche Native - C++"]
14
        OE[OcrEngine<br/>Orchestration]
15

16
        subgraph Detection["Détection de texte"]
17
            TD[TextDetector]
18
            DB[DBNet FP16]
19
        end
20

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

26
        subgraph Preprocessing["Pré-traitement d'image"]
27
            IP[ImagePreprocessor<br/>Optimisé NEON]
28
            PP[PostProcessor<br/>Détection de contours]
29
        end
30

31
        subgraph Runtime["Runtime LiteRT"]
32
            GPU[GPU Delegate<br/>OpenCL]
33
            CPU[Fallback CPU<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

Les avantages de cette architecture multicouche sont :

Couche UI : En Kotlin/Compose pur, dédiée à l’interaction utilisateur.
Couche ViewModel : Gère l’état et la logique métier.
Couche Native : Calcul haute performance, totalement découplée de l’UI.

Chaque couche peut être testée indépendamment. La couche native peut être testée unitairement avec Google Test, et la couche ViewModel avec JUnit + MockK.

Encapsulation de la couche Kotlin

Dans OcrEngine.kt, la couche Kotlin offre une API concise :

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("Échec de création du moteur OCR natif")
27
            }
28

29
            OcrEngine(handle)
30
        }
31
    }
32

33
    fun process(bitmap: Bitmap): List<OcrResult> {
34
        check(nativeHandle != 0L) { "OcrEngine a été fermé" }
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
}

Avantages de cette conception :

Utilisation du type Result pour gérer les erreurs d’initialisation.
Implémentation de l’interface Closeable, supportant les blocs use pour la libération automatique des ressources.
Copie automatique des fichiers de modèles depuis les assets vers le répertoire de cache.

Optimisation du démarrage à froid

La première inférence (démarrage à froid) est généralement beaucoup plus lente que les suivantes (démarrage à chaud). Cela est dû à :

Le GPU Delegate doit compiler les programmes OpenCL.
Les poids du modèle doivent être transférés de la mémoire CPU vers la mémoire GPU.
Divers caches doivent être préchauffés.

PPOCRv5-Android atténue ce problème via un mécanisme de Warm-up :

1
void OcrEngine::WarmUp() {
2
    LOGD(TAG, "Démarrage du warm-up (%d itérations)...", kWarmupIterations);
3

4
    // Créer une petite image de test
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
    // Exécuter quelques inférences pour préchauffer
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 terminé (accélérateur : %s)", AcceleratorName(active_accelerator_));
21
}

Optimisation de l’alignement mémoire

Dans TextDetector::Impl, tous les buffers pré-alloués utilisent un alignement de 64 octets :

1
// Buffers pré-alloués avec alignement sur la ligne de cache
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_;

L’alignement sur 64 octets correspond à la taille de la ligne de cache des processeurs ARM modernes. Un accès mémoire aligné évite le fractionnement des lignes de cache et améliore l’efficacité de l’accès mémoire.

Pool de mémoire et réutilisation d’objets

Les allocations et libérations fréquentes de mémoire sont des tueurs de performance. PPOCRv5-Android utilise une stratégie de pré-allocation, allouant toute la mémoire nécessaire en une seule fois lors de l’initialisation :

1
class TextDetector::Impl {
2
    // Buffers pré-alloués, cycle de vie identique à 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
        // Allocation unique pour éviter les malloc à l'exécution
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
};

Avantages de cette conception :

Évitement de la fragmentation mémoire : Tous les grands blocs de mémoire sont alloués au démarrage.
Réduction des appels système : malloc peut déclencher des appels système, la pré-allocation évite ce surcoût.
Respect du cache : La mémoire allouée de manière contiguë a plus de chances d’être physiquement contiguë, améliorant le taux de réussite du cache.

Optimisation de la prédiction de branche

Les processeurs modernes utilisent la prédiction de branche pour améliorer l’efficacité du pipeline. Une mauvaise prédiction entraîne un vidage du pipeline, coûtant 10 à 20 cycles d’horloge.

Sur les chemins critiques (hot paths), nous utilisons __builtin_expect pour donner des indices au compilateur :

1
// La plupart des pixels ne dépasseront pas le seuil
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) indique au compilateur que la valeur de expr est très probablement val. Le compilateur ajuste alors la disposition du code pour placer les branches « peu probables » loin du chemin principal.

Déroulage de boucle et pipeline logiciel

Pour les boucles intensives en calcul, le déroulage manuel peut réduire le surcoût de la boucle et exposer davantage de parallélisme au niveau des instructions :

1
// Version non déroulée
2
for (int i = 0; i < n; ++i) {
3
    dst[i] = src[i] * scale + bias;
4
}
5

6
// Version déroulée 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
}

Après déroulage, le CPU peut exécuter simultanément plusieurs instructions de multiplication-addition indépendantes, exploitant pleinement les multiples unités d’exécution de l’architecture superscalaire.

Optimisation Prefetch

Dans la boucle interne de la transformation perspective, utilisez __builtin_prefetch pour charger à l’avance les données de la ligne suivante :

1
for (int dy = 0; dy < kRecInputHeight; ++dy) {
2
    // Précharger les données de la ligne suivante
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
    // ... traiter la ligne actuelle
11
}

Cette optimisation permet de masquer la latence mémoire : pendant le traitement de la ligne actuelle, les données de la ligne suivante sont déjà chargées dans le cache L1.

Détails d’ingénierie du post-traitement

Analyse de composantes connexes et détection de contours

Dans postprocess.cpp, la fonction FindContours implémente une analyse efficace des composantes connexes :

1
std::vector<std::vector<Point>> FindContours(const uint8_t *binary_map,
2
                                             int width, int height) {
3
    // 1. Sous-échantillonnage 4x pour réduire la charge de calcul
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. Parcours BFS des composantes connexes
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
                    // Détecter les pixels de bordure
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
                    // Extension 4-voisinage
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
}

Points d’optimisation clés :

Sous-échantillonnage 4x : Réduire l’image binaire de 640x640 à 160x160, divisant par 16 la charge de calcul.
Détection de bordure : Ne conserver que les pixels de bordure plutôt que toute la composante connexe.
Limite du nombre maximal de contours : kMaxContours = 100, pour éviter les problèmes de performance dans les cas extrêmes.

Algorithmes d’enveloppe convexe et de Rotating Calipers

Le calcul du rectangle englobant minimum orienté se fait en deux étapes : d’abord calculer l’enveloppe convexe, puis utiliser l’algorithme des Rotating Calipers pour trouver le rectangle englobant d’aire minimale.

Algorithme d’enveloppe convexe Graham Scan

Le Graham Scan est un algorithme classique pour calculer l’enveloppe convexe, avec une complexité de $O(n \log n)$ :

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

4
    // 1. Trouver le point le plus bas (y min, puis x min)
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. Trier par angle polaire
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
                // En cas de colinéarité, le plus proche d'abord
18
                return DistanceSquared(p0, a) < DistanceSquared(p0, b);
19
            }
20
            return cross > 0;  // Sens anti-horaire
21
        });
22

23
    // 3. Construire l'enveloppe
24
    std::vector<Point> hull;
25
    for (const auto& p : points) {
26
        // Retirer les points provoquant un virage horaire
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
// Produit en croix : déterminer la direction du virage
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
}

Algorithme des Rotating Calipers

L’algorithme des Rotating Calipers parcourt chaque arête de l’enveloppe convexe pour calculer l’aire du rectangle englobant basé sur cette arête :

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;  // Positions des trois "calipers"
9

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

13
        // Vecteur direction de l'arête actuelle
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
        // Vecteur unitaire
19
        float ux = edge_x / edge_len;
20
        float uy = edge_y / edge_len;
21

22
        // Direction perpendiculaire
23
        float vx = -uy;
24
        float vy = ux;
25

26
        // Trouver le point le plus à droite (projection max le long de l'arête)
27
        while (Dot(hull[(right + 1) % n], ux, uy) > Dot(hull[right], ux, uy)) {
28
            right = (right + 1) % n;
29
        }
30

31
        // Trouver le point le plus haut (projection max perpendiculaire)
32
        while (Dot(hull[(top + 1) % n], vx, vy) > Dot(hull[top], vx, vy)) {
33
            top = (top + 1) % n;
34
        }
35

36
        // Trouver le point le plus à gauche
37
        while (Dot(hull[(left + 1) % n], ux, uy) < Dot(hull[left], ux, uy)) {
38
            left = (left + 1) % n;
39
        }
40

41
        // Calculer les dimensions du rectangle
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
            // Mettre à jour les paramètres du meilleur rectangle
49
            best_rect.width = width;
50
            best_rect.height = height;
51
            best_rect.angle = std::atan2(uy, ux) * 180.0f / M_PI;
52
            // Calculer le centre...
53
        }
54
    }
55

56
    return best_rect;
57
}

L’intuition clé des Rotating Calipers est que lorsque l’arête de base tourne, les trois « calipers » (points les plus à droite, en haut et à gauche) ne font qu’avancer de manière monotone. Ainsi, la complexité totale est $O(n)$ et non $O(n^2)$ .

Rectangle englobant minimum orienté

La fonction MinAreaRect utilise l’algorithme des Rotating Calipers pour calculer le rectangle englobant minimum orienté :

1
RotatedRect MinAreaRect(const std::vector<Point> &contour) {
2
    // 1. Sous-échantillonnage pour réduire le nombre de points
3
    std::vector<Point> points = subsample_points(contour, kMaxBoundaryPoints);
4

5
    // 2. Chemin rapide : utiliser l'AABB pour les boîtes de texte à ratio élevé
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
        // Retourner directement la boîte englobante alignée sur les axes
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. Calcul de l'enveloppe convexe
20
    std::vector<Point> hull = convex_hull(std::vector<Point>(points));
21

22
    // 4. Rotating Calipers : parcourir chaque arête de l'enveloppe
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
        // Calculer le rectangle englobant basé sur l'arête actuelle
28
        float edge_x = hull[j].x - hull[i].x;
29
        float edge_y = hull[j].y - hull[i].y;
30

31
        // Projeter tous les points sur la direction de l'arête et la direction perpendiculaire
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
            // Mettre à jour le meilleur rectangle
39
        }
40
    }
41

42
    return best_rect;
43
}

La complexité temporelle de cet algorithme est $O(n \log n)$ (calcul de l’enveloppe convexe) + $O(n)$ (Rotating Calipers), où $n$ est le nombre de points de bordure. En limitant $n$ à moins de 200 via le sous-échantillonnage, on garantit des performances en temps réel.

OCR caméra en temps réel : CameraX et analyse de trames

Le défi de l’OCR en temps réel est de traiter chaque trame le plus rapidement possible tout en maintenant une prévisualisation fluide.

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["Flux d'analyse de trame"]
10
        direction TB
11
        IP[ImageProxy<br/>YUV_420_888]
12
        BM[Conversion Bitmap<br/>RGBA_8888]
13
        JNI[Appel JNI<br/>Appel unique]
14
    end
15

16
    subgraph Native["OCR Natif"]
17
        direction TB
18
        DET[TextDetector<br/>~45ms GPU]
19
        REC[TextRecognizer<br/>~15ms/ligne]
20
        RES[Résultats OCR]
21
    end
22

23
    subgraph UI["Mise à jour UI"]
24
        direction TB
25
        VM[ViewModel<br/>StateFlow]
26
        OV[ResultOverlay<br/>Dessin 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 est la bibliothèque de caméra de Jetpack Android. Elle fournit le cas d’utilisation ImageAnalysis, qui nous permet d’analyser les trames de la caméra en temps réel :

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
    // Mettre à jour l'UI
10
    imageProxy.close()
11
}

La configuration clé est STRATEGY_KEEP_ONLY_LATEST : si la vitesse de traitement de l’analyseur ne suit pas la cadence de la caméra, les anciennes trames sont abandonnées pour ne conserver que la plus récente. Cela garantit la pertinence temporelle des résultats OCR.

Équilibre entre cadence et latence

Sur les appareils avec accélération GPU (bien que mon Snapdragon 870 actuel semble avoir des soucis pour déléguer la majorité des calculs au GPU), PPOCRv5-Android peut théoriquement atteindre des vitesses de traitement élevées. Cependant, cela ne signifie pas que nous devions traiter chaque trame.

Considérons ce scénario : l’utilisateur pointe la caméra vers un texte qui ne change pas à court terme. Effectuer un OCR complet à chaque trame gaspillerait d’énormes ressources de calcul.

Une stratégie d’optimisation est la « détection de changement » : déclencher l’OCR uniquement lorsque l’image change de manière significative. Cela peut être réalisé en comparant les histogrammes ou les points caractéristiques des trames successives.

Perspectives d’avenir : NPU et quantification

L’avenir de l’IA embarquée réside dans les NPU (Neural Processing Unit). Par rapport aux GPU, les NPU sont conçus spécifiquement pour l’inférence de réseaux de neurones et offrent une meilleure efficacité énergétique.

Cependant, le défi des NPU réside dans leur fragmentation. Chaque fabricant de puces possède sa propre architecture NPU et son propre SDK :

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

L’API NNAPI (Neural Networks API) d’Android tente de fournir une couche d’abstraction unifiée, mais les résultats réels sont inégaux. De nombreuses fonctionnalités NPU ne sont pas exposées via NNAPI, obligeant les développeurs à utiliser des SDK spécifiques aux constructeurs.

Quantification INT8 : Une bataille inachevée

La quantification FP16 est un choix conservateur qui ne perd presque aucune précision. Mais pour une performance extrême, la quantification INT8 est l’étape suivante.

La quantification INT8 compresse les poids et les activations de 32 bits flottants vers des entiers de 8 bits, ce qui peut théoriquement apporter :

Une compression du modèle par 4.
Une accélération de l’inférence par 2 à 4 (selon le matériel).
Une accélération de plus de 10 fois sur le DSP Qualcomm Hexagon.

La tentation était trop forte. J’ai donc entamé un long voyage vers la quantification INT8.

Première tentative : Calibration avec données synthétiques

La quantification INT8 nécessite un ensemble de données de calibration pour déterminer les paramètres de quantification (Scale et Zero Point). Au début, par paresse, j’ai utilisé des images « pseudo-texte » générées aléatoirement :

1
# Mauvaise pratique : utiliser du bruit aléatoire pour la calibration
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

Le résultat fut désastreux. Le modèle ne sortait que des zéros :

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

L’outil de quantification a calculé des paramètres erronés basés sur le bruit aléatoire, provoquant la troncature des valeurs d’activation des images réelles.

Deuxième tentative : Calibration avec images réelles

Je suis passé à de vraies images de jeux de données OCR : ICDAR2015, TextOCR, et des exemples officiels de PaddleOCR. J’ai également implémenté un pré-traitement Letterbox pour m’assurer que la distribution des images lors de la calibration soit identique à celle de l’inférence :

1
def letterbox_image(image, target_size):
2
    """Redimensionner en gardant le ratio, remplir le reste en gris"""
3
    ih, iw = image.shape[:2]
4
    h, w = target_size
5
    scale = min(w / iw, h / ih)
6
    # ... coller au centre

Le modèle ne sortait plus de zéros, mais les résultats de reconnaissance restaient illisibles.

Troisième tentative : Correction de la gestion des types côté C++

J’ai découvert que le code C++ gérait mal les entrées INT8. Les modèles INT8 attendent des valeurs de pixels brutes (0-255), alors que je faisais encore la normalisation ImageNet (soustraction de la moyenne et division par l’écart-type).

1
if (input_is_int8_) {
2
    // Modèle INT8 : entrée directe des pixels bruts, normalisation fusionnée dans la 1ère couche
3
    dst[i * 3 + 0] = static_cast<int8_t>(src[i * 4 + 0] ^ 0x80);
4
} else {
5
    // Modèle FP32 : normalisation manuelle requise
6
    // (pixel - moyenne) / std
7
}

Parallèlement, j’ai implémenté une logique de lecture dynamique des paramètres de quantification au lieu de les coder en dur :

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

Résultat final : Le compromis

Après plusieurs jours de débogage, le modèle INT8 ne fonctionnait toujours pas correctement. Les causes possibles sont :

L’implémentation de la quantification d’onnx2tf : PP-OCRv5 utilise des combinaisons d’opérateurs spécifiques qu’onnx2tf n’a peut-être pas traitées correctement lors de la quantification.
Les caractéristiques de sortie de DBNet : DBNet produit des cartes de probabilité avec des valeurs entre 0 et 1. La quantification INT8 est particulièrement sensible à ces petites plages de valeurs.
Accumulation d’erreurs dans un modèle multi-étapes : La détection et la reconnaissance sont deux modèles en série ; les erreurs de quantification s’accumulent et s’amplifient.

Analysons plus en détail le deuxième point. La sortie de DBNet passe par une activation Sigmoid, compressant les valeurs dans [0, 1]. La formule de quantification INT8 est la suivante :

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

Pour des valeurs dans [0, 1], si le scale est mal défini, les valeurs quantifiées n’occuperont qu’une infime partie de la plage INT8 [-128, 127], entraînant une grave perte de précision.

1
# Supposons scale = 0.00784 (1/127), zero_point = 0
2
# Entrée 0.5 -> round(0.5 / 0.00784) + 0 = 64
3
# Entrée 0.1 -> round(0.1 / 0.00784) + 0 = 13
4
# Entrée 0.01 -> round(0.01 / 0.00784) + 0 = 1
5
# Entrée 0.001 -> round(0.001 / 0.00784) + 0 = 0  # Perte de précision !

Le seuil de DBNet est généralement fixé entre 0,1 et 0,3, ce qui signifie qu’une grande quantité de valeurs de probabilité significatives (0,1-0,3) ne sont représentées que par 25 entiers (de 13 à 38) après quantification, une résolution largement insuffisante.

WARNING

La quantification INT8 de PP-OCRv5 est un défi connu. Si vous essayez également, je vous suggère de vérifier d’abord que le modèle FP32 fonctionne normalement avant de traquer les problèmes de quantification. Sinon, envisagez d’utiliser le framework officiel Paddle Lite de PaddlePaddle, qui offre un meilleur support pour PaddleOCR.

Quantization-Aware Training : La solution correcte

S’il est impératif d’utiliser la quantification INT8, la méthode correcte est le Quantization-Aware Training (QAT), plutôt que la Post-Training Quantization (PTQ).

Le QAT simule les erreurs de quantification pendant l’entraînement, permettant au modèle d’apprendre à s’adapter aux représentations de basse précision :

1
# Exemple QAT 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
# Entraînement normal, mais avec des nœuds de pseudo-quantification insérés
9
for epoch in range(num_epochs):
10
    for images, labels in dataloader:
11
        outputs = model_prepared(images)  # Contient la simulation de quantification
12
        loss = criterion(outputs, labels)
13
        loss.backward()
14
        optimizer.step()
15

16
# Convertir en véritable modèle quantifié
17
model_quantized = quant.convert(model_prepared)

Malheureusement, l’équipe officielle de PP-OCRv5 n’a pas fourni de modèle entraîné avec QAT. Cela signifie que pour obtenir un modèle INT8 de haute qualité, il faudrait effectuer un entraînement QAT à partir de zéro, ce qui dépasse le cadre de ce projet.

Finalement, j’ai choisi un compromis : utiliser la quantification FP16 + accélération GPU, plutôt que l’INT8 + DSP.

Le prix de cette décision est :

Une taille de modèle 2 fois supérieure à l’INT8.
L’impossibilité d’exploiter la très basse consommation du DSP Hexagon.
Une vitesse d’inférence 2 à 3 fois plus lente que l’optimum théorique.

Mais les bénéfices sont :

Une précision du modèle presque identique au FP32.
Un cycle de développement considérablement raccourci.
Une complexité du code réduite.

L’essence de l’ingénierie est le compromis. Parfois, le « assez bien » est plus important que l’« optimum théorique ».

Conclusion

De PaddlePaddle à LiteRT, de DBNet à SVTRv2, d’OpenCL à NEON, la pratique de l’ingénierie OCR embarquée implique des connaissances dans de nombreux domaines : deep learning, compilateurs, programmation GPU, développement mobile, etc.

La leçon principale de ce projet est que l’IA embarquée ne consiste pas seulement à « mettre un modèle sur un téléphone ». Elle nécessite :

Une compréhension approfondie de l’architecture du modèle pour une conversion correcte.
Une connaissance des caractéristiques matérielles pour exploiter pleinement les accélérateurs.
Une maîtrise de la programmation système pour implémenter du code natif haute performance.
Une attention portée à l’expérience utilisateur pour trouver l’équilibre entre performance et consommation d’énergie.

PPOCRv5-Android est un projet open source qui montre comment déployer des modèles OCR modernes dans des applications mobiles réelles. J’espère que cet article servira de référence aux développeurs ayant des besoins similaires.

Comme l’a dit Google lors du lancement de LiteRT : « Maximum performance, simplified. » ⁹ L’objectif de l’IA embarquée n’est pas la complexité, mais de rendre le complexe simple.

Post-scriptum

Pour être honnête, je me suis éloigné d’Android (tant dans mon travail que dans mes loisirs) depuis au moins deux ans. C’est la première fois que je publie une bibliothèque relativement mature sur mon compte GitHub secondaire (j’ai déjà confié mon compte principal à des collègues pour marquer ma détermination à partir).

Ces dernières années, mon travail ne s’est pas concentré sur le domaine Android. Je ne peux pas en dire plus pour le moment, mais j’en parlerai peut-être plus tard si l’occasion se présente. Quoi qu’il en soit, il me sera peut-être difficile de contribuer davantage à l’écosystème Android à l’avenir.

La publication de ce projet est née de ma passion personnelle, alors que je construisais un outil précoce basé sur Android — dont l’OCR n’est qu’une petite partie de la couche inférieure. Le code complet sera ouvert prochainement (très bientôt, normalement), mais je ne peux pas en révéler plus pour l’instant.

Bref, merci d’avoir lu jusqu’ici, et j’espère que vous donnerez une étoile (Star) à mon dépôt. Merci !

Références

Google AI Edge. “LiteRT: Maximum performance, simplified.” 2024. https://developers.googleblog.com/litert-maximum-performance-simplified/ ↩
Équipe PaddleOCR. “PaddleOCR 3.0 Technical Report.” arXiv:2507.05595, 2025. https://arxiv.org/abs/2507.05595 ↩
Discussion GitHub. “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 ↩ ↩²
Blog TensorFlow. “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.” Documentation ARM, 2024. https://developer.arm.com/documentation/101964/latest/ ↩
Google AI Edge. “Documentation LiteRT.” 2024. https://ai.google.dev/edge/litert ↩

mobile/ppocrv5-android.md

# Pratique de l'OCR on-device : Déploiement natif de PP-OCRv5 sur Android

Description

Introduction

Conversion du modèle : Le long voyage de PaddlePaddle vers TFLite

Premier obstacle : Compatibilité des opérateurs de paddle2onnx

Deuxième obstacle : HardSigmoid et compatibilité GPU

Troisième obstacle : Mode de transformation des coordonnées de l’opérateur Resize

Dernière étape : onnx2tf et quantification FP16

Détection de texte : La binarisation différentiable de DBNet

Binarisation standard vs Binarisation différentiable

Implémentation technique du flux de post-traitement

Unclip : Algorithme de dilatation des boîtes de texte

Reconnaissance de texte : SVTRv2 et décodage CTC

Innovations architecturales de SVTRv2

Pourquoi le CTC plutôt que l’Attention ?

Décodage CTC optimisé par NEON

Principes mathématiques de la fonction de perte CTC et du décodage

Dictionnaire de caractères : Le défi des 18 383 caractères

API C++ LiteRT : L’interface moderne après la refactorisation de 2024

Comparaison entre l’ancienne et la nouvelle API

Environnement et initialisation du modèle

Managed Tensor Buffer : La clé de l’inférence zéro-copie

Accélération GPU : Choix et compromis d’OpenCL

OpenCL vs OpenGL ES : Comparaison approfondie des performances

Stratégie de dégradation gracieuse (Fallback)

Couche native : Optimisations C++ et NEON

NEON : Le jeu d’instructions SIMD d’ARM

Implémentation NEON de la normalisation ImageNet

Zéro dépendance OpenCV

Implémentation NEON de l’interpolation bilinéaire

Transformation perspective : Du rectangle orienté à la ligne de texte standard

JNI : Le pont entre Kotlin et C++

Conception architecturale : Modularité et testabilité

Encapsulation de la couche Kotlin

Optimisation du démarrage à froid

Optimisation de l’alignement mémoire

Pool de mémoire et réutilisation d’objets

Optimisation de la prédiction de branche

Déroulage de boucle et pipeline logiciel

Optimisation Prefetch

Détails d’ingénierie du post-traitement

Analyse de composantes connexes et détection de contours

Algorithmes d’enveloppe convexe et de Rotating Calipers

Algorithme d’enveloppe convexe Graham Scan

Algorithme des Rotating Calipers

Rectangle englobant minimum orienté

OCR caméra en temps réel : CameraX et analyse de trames

ImageAnalysis de CameraX

Équilibre entre cadence et latence

Perspectives d’avenir : NPU et quantification

Quantification INT8 : Une bataille inachevée

Première tentative : Calibration avec données synthétiques

Deuxième tentative : Calibration avec images réelles

Troisième tentative : Correction de la gestion des types côté C++

Résultat final : Le compromis

Quantization-Aware Training : La solution correcte

Conclusion

Post-scriptum

Références

Footnotes