On-Device OCR in der Praxis: Native Bereitstellung von PP-OCRv5 auf Android

Hinweise

Dieser Blogpost:

Cover: Generiert mit Google Nano Banana 2, urheberrechtsfrei.
Projekt-Quellcode: Open Source auf GitHub verfügbar unter PPOCRv5-Android.

Erklärung:

Der Autor (Fleey) ist kein professioneller KI-Experte, sondern betreibt dies aus reinem Interesse. Sollten sich Fehler oder Auslassungen im Text finden, bitte ich um Nachsicht und zeitnahe Korrekturhinweise!

Einleitung

Im Jahr 2024 benannte Google TensorFlow Lite in LiteRT um. Dies war nicht nur ein Rebranding, sondern markierte einen Paradigmenwechsel der On-Device-KI von „Mobile First“ hin zu „Edge First“¹. In diesem Kontext erlebt OCR (optische Zeichenerkennung) als eine der praktischsten Anwendungen von On-Device-KI eine stille Revolution.

Das PaddleOCR-Team von Baidu veröffentlichte 2025 PP-OCRv5, ein einheitliches OCR-Modell, das mehrere Sprachen wie vereinfachtes Chinesisch, traditionelles Chinesisch, Englisch und Japanisch unterstützt². Die mobile Version ist nur etwa 70 MB groß, kann aber in einem einzigen Modell 18.383 Zeichen erkennen. Hinter dieser Zahl steht das Zusammenspiel zweier tiefer neuronaler Netze: Detektion und Erkennung.

Das Problem ist jedoch: PP-OCRv5 wurde auf dem PaddlePaddle-Framework trainiert, während die ausgereifteste Inferenz-Engine auf Android-Geräten LiteRT ist. Wie überbrückt man diese Kluft?

Beginnen wir mit der Modellkonvertierung und lüften Schritt für Schritt den technischen Schleier von On-Device-OCR.

1
flowchart TB
2
    subgraph E2E["End-to-End OCR Prozess"]
3
        direction TB
4

5
        subgraph Input["Eingabe"]
6
            IMG[Originalbild<br/>Beliebige Größe]
7
        end
8

9
        subgraph Detection["Textdetektion - DBNet"]
10
            DET_PRE[Vorverarbeitung<br/>Resize 640x640<br/>ImageNet Normalize]
11
            DET_INF[DBNet Inferenz<br/>~45ms GPU]
12
            DET_POST[Nachverarbeitung<br/>Binarisierung - Konturen - Rotierte Rechtecke]
13
        end
14

15
        subgraph Recognition["Texterkennung - SVTRv2"]
16
            REC_CROP[Perspektivischer Zuschnitt<br/>48xW Adaptive Breite]
17
            REC_INF[SVTRv2 Inferenz<br/>~15ms/Zeile GPU]
18
            REC_CTC[CTC-Dekodierung<br/>Duplikate zusammenführen + Blanks entfernen]
19
        end
20

21
        subgraph Output["Ausgabe"]
22
            RES[OCR-Ergebnisse<br/>Text + Konfidenz + Position]
23
        end
24
    end
25

26
    IMG --> DET_PRE --> DET_INF --> DET_POST
27
    DET_POST -->|N Textboxen| REC_CROP
28
    REC_CROP --> REC_INF --> REC_CTC --> RES

Modellkonvertierung: Die lange Reise von PaddlePaddle zu TFLite

Die Fragmentierung von Deep-Learning-Frameworks ist ein Schmerzpunkt der Branche. PyTorch, TensorFlow, PaddlePaddle, ONNX – jedes Framework hat sein eigenes Modellformat und seine eigene Operator-Implementierung. ONNX (Open Neural Network Exchange) versucht, eine universelle Zwischenrepräsentation zu sein, aber die Realität ist oft ernüchternder als das Ideal.

Der Pfad der Modellkonvertierung für PP-OCRv5 sieht wie folgt aus:

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

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

10
    subgraph Optimization["Graph Optimization"]
11
        GS[onnx-graphsurgeon<br/>Operator-Zerlegung]
12
    end
13

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

18
    PM -->|paddle2onnx| OM
19
    OM -->|HardSigmoid Zerlegung<br/>Resize-Modus Anpassung| GS
20
    GS -->|onnx2tf| TM

Dieser Pfad scheint einfach, birgt aber Tücken.

Die erste Hürde: Operator-Kompatibilität von paddle2onnx

paddle2onnx ist das offizielle Konvertierungstool von PaddlePaddle. Theoretisch kann es PaddlePaddle-Modelle in das ONNX-Format konvertieren. PP-OCRv5 verwendet jedoch einige spezielle Operatoren, deren Mapping in ONNX nicht eins-zu-eins erfolgt.

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

Ein wichtiges Detail: Der Dateiname des PP-OCRv5-Modells ist inference.json anstelle des traditionellen inference.pdmodel. Dies ist eine Änderung im Modellformat neuerer PaddlePaddle-Versionen, über die viele Entwickler stolpern³.

Die zweite Hürde: HardSigmoid und GPU-Kompatibilität

Das konvertierte ONNX-Modell enthält den HardSigmoid-Operator. Dieser Operator ist mathematisch definiert als:

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

Wobei $\alpha = 0.2$ und $\beta = 0.5$ .

Das Problem: Der GPU Delegate von LiteRT unterstützt HardSigmoid nicht. Wenn ein Modell nicht unterstützte Operatoren enthält, fällt der GPU Delegate für den gesamten Subgraphen auf die CPU zurück (Fallback), was zu massiven Leistungseinbußen führt.

Die Lösung besteht darin, HardSigmoid in Basis-Operatoren zu zerlegen. Mit der Bibliothek onnx-graphsurgeon können wir Operationen auf Ebene des Berechnungsgraphen durchführen:

1
import onnx_graphsurgeon as gs
2
import numpy as np
3

4
def decompose_hardsigmoid(graph: gs.Graph) -> gs.Graph:
5
    """
6
    将 HardSigmoid 分解为 GPU 友好的基本算子
7
    HardSigmoid(x) = max(0, min(1, alpha*x + beta))
8
    分解为: Mul -> Add -> Clip
9
    """
10
    for node in graph.nodes:
11
        if node.op == "HardSigmoid":
12
            # 获取 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
            # 创建常量张量
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
            # 创建中间变量
30
            mul_out = gs.Variable(name=f"{node.name}_mul_out")
31
            add_out = gs.Variable(name=f"{node.name}_add_out")
32

33
            # 构建分解后的子图: 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
            # 替换原节点
52
            graph.nodes.remove(node)
53
            graph.nodes.extend([mul_node, add_node, clip_node])
54

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

Der Schlüssel dieser Zerlegung liegt darin, dass Mul, Add und Clip Operatoren sind, die vom LiteRT GPU Delegate vollständig unterstützt werden. Nach der Zerlegung kann der gesamte Subgraph kontinuierlich auf der GPU ausgeführt werden, wodurch der Overhead für den Datentransfer zwischen CPU und GPU vermieden wird.

TIP

Warum nicht direkt den Trainingscode des Modells ändern? Weil die Gradientenberechnung von HardSigmoid beim Training anders ist als bei Clip. Die Zerlegung sollte nur in der Inferenzphase erfolgen, um die numerische Stabilität während des Trainings zu wahren.

Die dritte Hürde: Koordinatentransformationsmodus des Resize-Operators

Der Resize-Operator in ONNX hat ein Attribut coordinate_transformation_mode, das bestimmt, wie Ausgabekoordinaten auf Eingabekoordinaten abgebildet werden. PP-OCRv5 verwendet den Modus half_pixel, aber die Unterstützung für diesen Modus im LiteRT GPU Delegate ist begrenzt.

Die Änderung auf den Modus asymmetric verbessert die GPU-Kompatibilität:

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

WARNING

Diese Änderung kann zu minimalen numerischen Differenzen führen. In praktischen Tests war der Einfluss auf die OCR-Genauigkeit vernachlässigbar, aber bei anderen Aufgaben sollte dies sorgfältig evaluiert werden.

Der letzte Schritt: onnx2tf und FP16-Quantisierung

onnx2tf ist ein Tool zur Konvertierung von ONNX-Modellen in das TFLite-Format. FP16-Quantisierung (Floating Point mit halber Genauigkeit) ist eine gängige Wahl für On-Device-Deployments. Sie halbiert die Modellgröße bei akzeptablem Genauigkeitsverlust und nutzt die FP16-Recheneinheiten mobiler GPUs.

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

Der Parameter -ois legt die statische Form (Shape) der Eingabe fest. Statische Shapes sind entscheidend für die GPU-Beschleunigung; dynamische Shapes würden dazu führen, dass das GPU-Programm bei jeder Inferenz neu kompiliert werden muss, was die Performance massiv beeinträchtigt.

Textdetektion: Die differenzierbare Binarisierung von DBNet

Das Detektionsmodul von PP-OCRv5 basiert auf DBNet (Differentiable Binarization Network)⁴. Traditionelle Textdetektionsmethoden verwenden einen festen Schwellenwert für die Binarisierung. Die Innovation von DBNet besteht darin, dass das Netzwerk selbst lernt, den optimalen Schwellenwert für jedes Pixel zu bestimmen.

1
flowchart TB
2
    subgraph DBNet["DBNet Architektur"]
3
        direction TB
4
        IMG[Eingabebild<br/>H x W x 3]
5
        BB[Backbone<br/>MobileNetV3]
6
        FPN[FPN Feature Pyramid<br/>Multiskalen-Fusion]
7

8
        subgraph Heads["Zwei-Zweig-Ausgabe"]
9
            PH[Wahrscheinlichkeitskarte<br/>P: H x W x 1]
10
            TH[Schwellenwertkarte<br/>T: H x W x 1]
11
        end
12

13
        DB["Differenzierbare Binarisierung<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

Standard-Binarisierung vs. Differenzierbare Binarisierung

Die Standard-Binarisierung ist eine Sprungfunktion:

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

Diese Funktion ist nicht differenzierbar und kann daher nicht mittels Backpropagation für ein End-to-End-Training genutzt werden. DBNet schlägt eine Approximationsfunktion vor:

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

Wobei $P$ die Wahrscheinlichkeitskarte ist, $T$ die Schwellenwertkarte (vom Netzwerk gelernt) und $k$ ein Verstärkungsfaktor (beim Training auf 50 gesetzt).

TIP

Diese Formel ist im Wesentlichen eine Sigmoid-Funktion, bei der die Eingabe zu $P - T$ wird. Wenn $k$ groß genug ist, nähert sich ihr Verhalten einer Sprungfunktion an, bleibt aber differenzierbar.

Technische Implementierung des Nachverarbeitungsprozesses

Im Projekt PPOCRv5-Android ist der Nachverarbeitungsprozess in postprocess.cpp implementiert. Der Kernprozess umfasst:

1
flowchart LR
2
    subgraph Input["Modellausgabe"]
3
        PM[Wahrscheinlichkeitskarte P<br/>640 x 640]
4
    end
5

6
    subgraph Binary["Binarisierung"]
7
        BT[Schwellenwertfilter<br/>threshold=0.1]
8
        BM[Binärbild<br/>640 x 640]
9
    end
10

11
    subgraph Contour["Konturerkennung"]
12
        DS[4x Downsampling<br/>160 x 160]
13
        CC[Zusammenhangskomponenten-Analyse<br/>BFS-Traversierung]
14
        BD[Extraktion von Grenzpunkten]
15
    end
16

17
    subgraph Geometry["Geometrische Berechnung"]
18
        CH[Konvexe Hülle<br/>Graham Scan]
19
        RR[Rotating Calipers<br/>Kleinstes umschreibendes Rechteck]
20
        UC[Unclip-Erweiterung<br/>ratio=1.5]
21
    end
22

23
    subgraph Output["Ausgabe"]
24
        TB[RotatedRect<br/>center, size, angle]
25
    end
26

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

Im tatsächlichen Code zeigt die Methode TextDetector::Impl::Detect den vollständigen Detektionsprozess:

1
std::vector<RotatedRect> Detect(const uint8_t *image_data,
2
                                int width, int height, int stride,
3
                                float *detection_time_ms) {
4
    // 1. 计算缩放比例
5
    scale_x_ = static_cast<float>(width) / kDetInputSize;
6
    scale_y_ = static_cast<float>(height) / kDetInputSize;
7

8
    // 2. 双线性插值缩放到 640x640
9
    image_utils::ResizeBilinear(image_data, width, height, stride,
10
                                resized_buffer_.data(), kDetInputSize, kDetInputSize);
11

12
    // 3. ImageNet 标准化
13
    PrepareFloatInput();
14

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

18
    // 5. 二值化
19
    BinarizeOutput(prob_map, total_pixels);
20

21
    // 6. 轮廓检测
22
    auto contours = postprocess::FindContours(binary_map_.data(),
23
                                              kDetInputSize, kDetInputSize);
24

25
    // 7. 最小外接矩形 + Unclip
26
    for (const auto &contour : contours) {
27
        RotatedRect rect = postprocess::MinAreaRect(contour);
28
        UnclipBox(rect, kUnclipRatio);
29
        // 坐标映射回原图
30
        rect.center_x *= scale_x_;
31
        rect.center_y *= scale_y_;
32
        // ...
33
    }
34
}

Der Schlüssel dieses Prozesses liegt im „kleinsten umschreibenden rotierten Rechteck“. Im Gegensatz zu achsenparallelen Bounding Boxes können rotierte Rechtecke Text in jedem beliebigen Winkel eng umschließen, was für geneigten Text in natürlichen Szenen entscheidend ist.

Unclip: Der Expansionsalgorithmus für Textboxen

Die von DBNet ausgegebenen Textbereiche sind normalerweise etwas kleiner als der tatsächliche Text, da das Netzwerk den „Kernbereich“ des Textes lernt. Um die vollständigen Textgrenzen zu erhalten, muss eine Expansion (Unclip) auf die erkannten Polygone angewendet werden.

Das mathematische Prinzip von Unclip basiert auf der Umkehroperation des Vatti-Polygon-Clipping-Algorithmus. Für ein gegebenes Polygon $P$ und eine Expansionsdistanz $d$ gilt für das expandierte Polygon $P'$ :

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

Wobei $A$ die Fläche des Polygons ist, $L$ der Umfang und $r$ das Expansionsverhältnis (normalerweise auf 1,5 gesetzt).

In postprocess.cpp implementiert die Funktion UnclipBox diese Logik:

1
void UnclipBox(RotatedRect &box, float unclip_ratio) {
2
    // 计算膨胀距离
3
    float area = box.width * box.height;
4
    float perimeter = 2.0f * (box.width + box.height);
5

6
    if (perimeter < 1e-6f) return;  // 防止除零
7

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

11
    // 向外膨胀：宽高各增加 2d
12
    box.width += 2.0f * distance;
13
    box.height += 2.0f * distance;
14
}

Diese vereinfachte Version geht davon aus, dass die Textbox ein Rechteck ist. Für komplexere Polygone müsste die vollständige Clipper-Bibliothek für Polygon-Offsets verwendet werden:

1
// 完整的多边形 Unclip（使用 Clipper 库）
2
ClipperLib::Path polygon;
3
for (const auto& pt : contour) {
4
    polygon.push_back(ClipperLib::IntPoint(
5
        static_cast<int>(pt.x * 1000),  // 放大以保持精度
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);  // 膨胀

NOTE

PPOCRv5-Android hat sich für die vereinfachte rechteckige Expansion anstelle des vollständigen Polygon-Offsets entschieden. Die Gründe dafür sind:

Die meisten Textboxen sind annähernd rechteckig.
Die vollständige Clipper-Bibliothek würde die Binärgröße erheblich erhöhen.
Die Performance der vereinfachten Version ist besser.

Texterkennung: SVTRv2 und CTC-Dekodierung

Wenn die Detektion bedeutet „zu finden, wo der Text ist“, dann bedeutet die Erkennung „zu lesen, was der Text ist“. Das Erkennungsmodul von PP-OCRv5 basiert auf SVTRv2 (Scene Text Recognition with Visual Transformer v2)⁵.

Architektur-Innovationen von SVTRv2

SVTRv2 weist im Vergleich zum Vorgänger SVTR drei wesentliche Verbesserungen auf:

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

5
        subgraph Encoder["Visueller Encoder"]
6
            PE[Patch Embedding<br/>4x4 Faltung]
7

8
            subgraph Mixing["Mixing Attention Block x12"]
9
                LA[Local Attention<br/>7x7 Fenster]
10
                GA[Global Attention<br/>Globales Rezeptives Feld]
11
                FFN[Feed Forward<br/>MLP]
12
            end
13
        end
14

15
        subgraph Decoder["CTC Decoder"]
16
            FC[Fully Connected Layer<br/>D -> 18384]
17
            SM[Softmax]
18
            CTC[CTC Decode]
19
        end
20
    end
21

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

Hybrid-Attention-Mechanismus: Abwechselnde Nutzung von lokaler Attention (Erfassung von Strichdetails) und globaler Attention (Verständnis der Zeichenstruktur). Die lokale Attention nutzt ein gleitendes 7x7-Fenster, wodurch die Rechenkomplexität von $O(n^2)$ auf $O(n \times 49)$ sinkt.
Multiskalen-Feature-Fusion: Anders als die einheitliche Auflösung von ViT verwendet SVTRv2 unterschiedliche Feature-Map-Auflösungen in verschiedenen Tiefen, ähnlich der Pyramidenstruktur von CNNs.
Semantic Guidance Module: Am Ende des Encoders wurde ein leichtgewichtiger semantischer Zweig hinzugefügt, der dem Modell hilft, semantische Beziehungen zwischen Zeichen zu verstehen, anstatt nur visuelle Merkmale zu nutzen.

Diese Verbesserungen ermöglichen es SVTRv2, bei gleichbleibender Einfachheit der CTC-Dekodierung eine Genauigkeit zu erreichen, die mit Attention-basierten Methoden vergleichbar ist⁶.

Warum CTC statt Attention?

Für die Texterkennung gibt es zwei Hauptparadigmen:

CTC (Connectionist Temporal Classification): Betrachtet die Erkennung als Sequenz-Labeling-Problem, wobei die Ausgabe an der Eingabe ausgerichtet ist.
Attention-based Decoder: Nutzt einen Attention-Mechanismus, um die Ausgabe Zeichen für Zeichen zu generieren.

Attention-Methoden sind oft genauer, aber CTC-Methoden sind einfacher und schneller. Der Beitrag von SVTRv2 besteht darin, durch die Verbesserung des visuellen Encoders die Genauigkeit von CTC-Methoden auf das Niveau von Attention-Methoden zu heben oder diese sogar zu übertreffen⁶.

Der Kern der CTC-Dekodierung ist das „Zusammenführen von Duplikaten“ und das „Entfernen von Blanks“:

1
flowchart LR
2
    subgraph Input["Modellausgabe"]
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["Zusammenführen"]
19
        M["blank, H, blank, e, l, o"]
20
    end
21

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

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

Moment, hier gibt es ein Problem. Wenn der Originaltext „Hello“ lautet, wurden die beiden ‘l’ fälschlicherweise zusammengeführt. Die Lösung von CTC lautet: Einfügen eines Blank-Tokens zwischen identischen Zeichen.

1
Korrekte Kodierung: [blank, H, e, l, blank, l, o]
2
Dekodierungsergebnis: "Hello"

NEON-optimierte CTC-Dekodierung

Die CTC-Dekodierung in PPOCRv5-Android nutzt NEON-optimiertes Argmax. In 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
        // 标量回退
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
    // NEON 向量化：一次处理 4 个 float
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
        // 向量化比较和条件选择
28
        uint32x4_t cmp = vcgtq_f32(v_curr, v_max);
29
        v_max = vbslq_f32(cmp, v_curr, v_max);        // 选择较大值
30
        v_max_idx = vbslq_s32(cmp, v_idx, v_max_idx); // 选择对应索引
31
    }
32

33
    // 水平归约：找到 4 个候选中的最大值
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
    // ... 最终比较
39
}

Für ein Argmax über 18.384 Kategorien bringt die NEON-Optimierung eine etwa 3-fache Beschleunigung.

Mathematisches Prinzip der CTC-Loss-Funktion und Dekodierung

Die Kernidee von CTC ist: Gegeben eine Eingabesequenz $X$ und alle möglichen Ausrichtungspfade $\pi$ , berechne die Wahrscheinlichkeit der Zielsequenz $Y$ :

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

Wobei $\mathcal{B}$ eine „Many-to-One-Mapping-Funktion“ ist, die den Pfad $\pi$ auf die Ausgabesequenz $Y$ abbildet (durch Zusammenführen von Duplikaten und Entfernen von Blanks).

Bei der Inferenz verwenden wir Greedy Decoding anstelle eines vollständigen Beam Search:

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;  // 用于合并重复
5

6
    for (int t = 0; t < time_steps; ++t) {
7
        // 找到当前时间步的最大概率类别
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
        // CTC 解码规则：
19
        // 1. 跳过 blank token (index 0)
20
        // 2. 合并连续重复的字符
21
        if (max_idx != 0 && max_idx != prev_idx) {
22
            result += dictionary[max_idx - 1];  // -1 因为 blank 占用了 index 0
23
        }
24

25
        prev_idx = max_idx;
26
    }
27

28
    return result;
29
}

Die Zeitkomplexität des Greedy Decoding beträgt $O(T \times C)$ , wobei $T$ die Anzahl der Zeitschritte und $C$ die Anzahl der Kategorien ist. Für PP-OCRv5 gilt $T \approx 80$ und $C = 18384$ , was etwa 1,5 Millionen Vergleiche pro Dekodierung bedeutet. Deshalb ist die NEON-Optimierung so wichtig.

TIP

Beam Search kann die Dekodierungsgenauigkeit erhöhen, aber der Rechenaufwand ist um den Faktor $k$ höher (wobei $k$ die Beam-Breite ist). Auf mobilen Geräten ist Greedy Decoding meist die bessere Wahl.

Das Zeichenlexikon: Die Herausforderung von 18.383 Zeichen

PP-OCRv5 unterstützt 18.383 Zeichen, darunter:

Häufige Zeichen in vereinfachtem Chinesisch
Häufige Zeichen in traditionellem Chinesisch
Englische Buchstaben und Zahlen
Japanische Hiragana und Katakana
Gängige Satzzeichen und Sonderzeichen

Dieses Lexikon ist in der Datei keys_v5.txt gespeichert, ein Zeichen pro Zeile. Bei der CTC-Dekodierung haben die vom Modell ausgegebenen Logits die Form [1, T, 18384], wobei T die Anzahl der Zeitschritte ist und 18384 = 18383 Zeichen + 1 Blank-Token.

LiteRT C++ API: Die moderne Schnittstelle nach dem Refactoring 2024

PPOCRv5-Android nutzt die nach dem Refactoring 2024 eingeführte C++ API von LiteRT, die ein moderneres Interface-Design bietet. Im Vergleich zur traditionellen TFLite C API bietet die neue API eine bessere Typsicherheit und Ressourcenverwaltung.

Vergleich: Alte vs. Neue API

Das LiteRT-Refactoring 2024 brachte signifikante Änderungen an der API:

Feature	Alte API (TFLite)	Neue API (LiteRT)
Namespace	`tflite::`	`litert::`
Fehlerbehandlung	Rückgabe von `TfLiteStatus` Enum	Rückgabe vom Typ `Expected<T>`
Speicherverwaltung	Manuell	Automatisch via RAII
Delegate-Konfiguration	Verteilte APIs	Einheitliche `Options`-Klasse
Tensor-Zugriff	Pointer + manueller Cast	Typsicherer `TensorBuffer`

Der Hauptvorteil der neuen API liegt in der Typsicherheit und der automatischen Ressourcenverwaltung. Beispiel Fehlerbehandlung:

1
// 旧 API：需要手动检查每个返回值
2
TfLiteStatus status = TfLiteInterpreterAllocateTensors(interpreter);
3
if (status != kTfLiteOk) {
4
    // 错误处理
5
}
6

7
// 新 API：使用 Expected 类型，支持链式调用
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);  // 自动管理生命周期

Umgebung und Modellinitialisierung

In text_detector.cpp sieht der Initialisierungsprozess wie folgt aus:

1
bool Initialize(const std::string &model_path, AcceleratorType accelerator_type) {
2
    // 1. 创建 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. 配置硬件加速器
12
    auto options_result = litert::Options::Create();
13
    auto hw_accelerator = ToLiteRtAccelerator(accelerator_type);
14
    options.SetHardwareAccelerators(hw_accelerator);
15

16
    // 3. 编译模型
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. 调整输入张量形状
27
    std::vector<int> input_dims = {1, kDetInputSize, kDetInputSize, 3};
28
    compiled_model_->ResizeInputTensor(0, absl::MakeConstSpan(input_dims));
29

30
    // 5. 创建托管 Buffer
31
    CreateBuffersWithCApi();
32

33
    return true;
34
}

Managed Tensor Buffer: Der Schlüssel zur Zero-Copy-Inferenz

Der Managed Tensor Buffer von LiteRT ist entscheidend für eine performante Inferenz. Er erlaubt es dem GPU Delegate, direkt auf den Buffer zuzugreifen, ohne dass ein Datentransfer zwischen CPU und GPU nötig ist:

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

5
    // 获取输入 Buffer 需求
6
    LiteRtTensorBufferRequirements input_requirements = nullptr;
7
    LiteRtGetCompiledModelInputBufferRequirements(
8
        c_model, /*signature_index=*/0, /*input_index=*/0,
9
        &input_requirements);
10

11
    // 获取张量类型信息
12
    auto input_type = compiled_model_->GetInputTensorType(0, 0);
13
    LiteRtRankedTensorType tensor_type =
14
        static_cast<LiteRtRankedTensorType>(*input_type);
15

16
    // 创建托管 Buffer
17
    LiteRtTensorBuffer input_buffer = nullptr;
18
    LiteRtCreateManagedTensorBufferFromRequirements(
19
        c_env, &tensor_type, input_requirements, &input_buffer);
20

21
    // 包装为 C++ 对象，自动管理生命周期
22
    input_buffers_.push_back(
23
        litert::TensorBuffer::WrapCObject(input_buffer,
24
                                          litert::OwnHandle::kYes));
25
    return true;
26
}

Die Vorteile dieses Designs sind:

Zero-Copy-Inferenz: Der GPU Delegate greift direkt auf den Buffer zu.
Automatische Speicherverwaltung: OwnHandle::kYes stellt sicher, dass der Buffer freigegeben wird, wenn das C++ Objekt zerstört wird.
Typsicherheit: Prüfung der Tensortypen zur Kompilierzeit.

GPU-Beschleunigung: Wahl und Abwägung von OpenCL

LiteRT bietet verschiedene Optionen zur Hardwarebeschleunigung:

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

10
    subgraph Hardware["Hardware-Mapping"]
11
        direction TB
12
        ADRENO[Adreno GPU<br/>Qualcomm]
13
        MALI[Mali GPU<br/>ARM]
14
        NPU[NPU/DSP<br/>Herstellerspezifisch]
15
        CPU[ARM CPU<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

Beschleuniger	Backend	Vorteile	Nachteile
GPU	OpenCL	Breite Unterstützung, gute Performance	Keine Standard-Android-Komponente
GPU	OpenGL ES	Standard-Android-Komponente	Performance schlechter als OpenCL
NPU	NNAPI	Höchste Performance	Schlechte Gerätekompatibilität
CPU	XNNPACK	Breiteste Kompatibilität	Niedrigste Performance

PPOCRv5-Android hat OpenCL als primäres Beschleunigungs-Backend gewählt. Google veröffentlichte 2020 das OpenCL-Backend für TFLite, das auf Adreno-GPUs eine etwa 2-fache Beschleunigung gegenüber dem OpenGL ES-Backend erreicht⁷.

Die Vorteile von OpenCL ergeben sich aus mehreren Aspekten:

Design-Fokus: OpenCL wurde von Grund auf für allgemeine Berechnungen (GPGPU) entwickelt, während OpenGL eine Grafik-API ist, die erst später Support für Compute Shader erhielt.
Constant Memory: Der Constant Memory von OpenCL ist hocheffizient für den Zugriff auf Gewichte in neuronalen Netzen.
FP16-Support: OpenCL unterstützt nativ Floating Point mit halber Genauigkeit, während der OpenGL-Support erst später kam.

OpenCL hat jedoch einen entscheidenden Nachteil: Es ist keine Standardkomponente von Android. Die Qualität der OpenCL-Implementierungen variiert je nach Hersteller, und manche Geräte unterstützen es gar nicht.

OpenCL vs. OpenGL ES: Tiefer Performance-Vergleich

Um die Vorteile von OpenCL zu verstehen, müssen wir die GPU-Architektur betrachten. Beispiel Qualcomm Adreno 640:

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

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

10
        subgraph Memory["Speicherhierarchie"]
11
            L1[L1 Cache<br/>16KB pro SP]
12
            L2[L2 Cache<br/>1MB Shared]
13
            GMEM[Global Memory<br/>LPDDR4X]
14
        end
15

16
        subgraph Special["Spezialeinheiten"]
17
            TMU[Texture Unit<br/>Bilineare Interpolation]
18
            CONST[Constant Cache<br/>Gewichtsbeschleunigung]
19
        end
20
    end
21

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

Die Performance-Vorteile von OpenCL resultieren aus:

Feature	OpenCL	OpenGL ES Compute
Constant Memory	Native Unterstützung, Hardware-beschleunigt	Muss via UBO simuliert werden
Workgroup Size	Flexibel konfigurierbar	Limitiert durch Shader-Modell
Memory Barriers	Feingranulare Kontrolle	Grobgranular
FP16-Berechnung	`cl_khr_fp16` Extension	Benötigt `mediump` Präzision
Debugging-Tools	Snapdragon Profiler	Eingeschränkter Support

Bei Faltungsoperationen (Convolutions) sind Gewichte normalerweise Konstanten. OpenCL kann diese in den Constant Memory laden und von Broadcast-Optimierungen auf Hardware-Ebene profitieren. OpenGL ES muss Gewichte als Uniform Buffer Objects (UBO) übergeben, was den Overhead beim Speicherzugriff erhöht.

NOTE

Seit Android 7.0 schränkt Google das direkte Laden von OpenCL-Bibliotheken durch Apps ein. Der GPU Delegate von LiteRT umgeht dies jedoch, indem er die OpenCL-Implementierung des Systems dynamisch via dlopen lädt. Deshalb muss der GPU Delegate die Verfügbarkeit von OpenCL zur Laufzeit prüfen.

Graceful Fallback-Strategie

PPOCRv5-Android implementiert eine Strategie für einen eleganten Rückfall (Fallback):

1
constexpr AcceleratorType kFallbackChain[] = {
2
    AcceleratorType::kGpu,  // 首选 GPU
3
    AcceleratorType::kCpu,  // 回退 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
}

Diese Strategie stellt sicher, dass die App auf jedem Gerät läuft, wenn auch mit unterschiedlicher Performance.

Native Ebene: C++ und NEON-Optimierung

Warum C++ statt Kotlin?

Die Antwort ist einfach: Performance. Die Bildvorverarbeitung umfasst eine Vielzahl von Operationen auf Pixelebene, deren Overhead auf der JVM inakzeptabel wäre. Wichtiger noch: C++ kann direkt ARM NEON SIMD-Instruktionen nutzen, um vektorisierte Berechnungen durchzuführen.

NEON: Der SIMD-Befehlssatz von ARM

NEON ist die SIMD-Erweiterung (Single Instruction, Multiple Data) für ARM-Prozessoren. Sie erlaubt es, mit einem Befehl mehrere Datenelemente gleichzeitig zu verarbeiten.

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

9
    subgraph Operations["Vektorisierte Operationen"]
10
        direction TB
11
        LD["vld1q_f32<br/>Lädt 4 floats"]
12
        SUB["vsubq_f32<br/>4-fache parallele Subtraktion"]
13
        MUL["vmulq_f32<br/>4-fache parallele Multiplikation"]
14
        ST["vst1q_f32<br/>Speichert 4 floats"]
15
    end
16

17
    subgraph Speedup["Performance-Steigerung"]
18
        S1["Skalar: 4 Befehle"]
19
        S2["NEON: 1 Befehl"]
20
        S3["Theoretischer Speedup: 4x"]
21
    end
22

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

PPOCRv5-Android nutzt NEON-Optimierungen an mehreren kritischen Stellen. Beispiel Binarisierung (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
        // 一次处理 16 个像素
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
        // 向量化比较
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
        // 窄化到 uint8
22
        uint16x4_t n0 = vmovn_u32(cmp0);
23
        uint16x4_t n1 = vmovn_u32(cmp1);
24
        uint16x8_t n01 = vcombine_u16(n0, n1);
25
        // ... 合并并存储
26
    }
27
    // 标量回退处理剩余像素
28
    for (; i < total_pixels; ++i) {
29
        binary_map_[i] = (prob_map[i] > kBinaryThreshold) ? 255 : 0;
30
    }
31
#else
32
    // 纯标量实现
33
    for (int i = 0; i < total_pixels; ++i) {
34
        binary_map_[i] = (prob_map[i] > kBinaryThreshold) ? 255 : 0;
35
    }
36
#endif
37
}

Die entscheidenden Optimierungspunkte dieses Codes:

Batch-Loading: vld1q_f32 lädt 4 Floats gleichzeitig und reduziert so die Anzahl der Speicherzugriffe.
Vektorisierter Vergleich: vcgtq_f32 vergleicht 4 Werte gleichzeitig und generiert eine Maske.
Typ-Narrowing: vmovn_u32 komprimiert 32-Bit-Ergebnisse auf 16-Bit und schließlich auf 8-Bit.

Im Vergleich zur skalaren Implementierung bringt die NEON-Optimierung eine 3- bis 4-fache Beschleunigung⁸.

NEON-Implementierung der ImageNet-Normalisierung

Die Bildnormalisierung ist ein entscheidender Schritt der Vorverarbeitung. Die ImageNet-Standardisierung nutzt folgende Formel:

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

Wobei $\mu = [0.485, 0.456, 0.406]$ und $\sigma = [0.229, 0.224, 0.225]$ (RGB-Kanäle).

In image_utils.cpp sieht die NEON-optimierte Normalisierung so aus:

1
void NormalizeImageNet(const uint8_t* src, int width, int height, int stride,
2
                       float* dst) {
3
    // 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
    // 预计算: (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
    // 预计算: -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
            // 加载 4 个 RGBA 像素 (16 bytes)
29
            uint8x16_t rgba = vld1q_u8(row + x * 4);
30

31
            // 解交织: 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
            // 归一化: (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
            // 交织存储: 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
        // 标量处理剩余像素
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
    // 标量实现（略）
64
#endif
65
}

Wichtige Optimierungstechniken in diesem Code:

Vorkalkulierte Konstanten: Umwandlung von (x - mean) / std in x * scale + bias, um Divisionen zur Laufzeit zu vermeiden.
Fused Multiply-Add: vmlaq_f32 führt Multiplikation und Addition in einem einzigen Befehl aus.
De-Interleaving Load: vld4q_u8 trennt RGBA automatisch in vier Kanäle auf.
Interleaving Store: vst3q_f32 schreibt die drei RGB-Kanäle verschachtelt in den Speicher zurück.

Null OpenCV-Abhängigkeit

Viele OCR-Projekte hängen von OpenCV für die Bildvorverarbeitung ab. OpenCV ist mächtig, bringt aber eine enorme Paketgröße mit sich; die OpenCV-Bibliothek für Android ist oft über 10 MB groß.

PPOCRv5-Android hat den Weg der „Null OpenCV-Abhängigkeit“ gewählt. Alle Bildvorverarbeitungsoperationen sind in image_utils.cpp in reinem C++ implementiert:

Bilineare Interpolations-Skalierung: Manuell implementiert mit NEON-Unterstützung.
Normalisierung: ImageNet-Standardisierung und Erkennungs-Normalisierung.
Perspektivische Transformation: Zuschnitt von Textbereichen in beliebigen Winkeln aus dem Originalbild.

NEON-Implementierung der bilinearen Interpolation

Die bilineare Interpolation ist der Kernalgorithmus der Bildskalierung. Für eine Quellkoordinate $(x, y)$ berechnet die bilineare Interpolation den Zielpixelwert:

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

Wobei $\alpha = x - \lfloor x \rfloor$ , $\beta = y - \lfloor y \rfloor$ und $f_{ij}$ die Werte der vier benachbarten Pixel sind.

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: 一次处理 4 个目标像素
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
            // 计算 4 个源坐标
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
            // 加载 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
            // 对每个通道进行双线性插值
41
            for (int c = 0; c < 4; ++c) {  // RGBA
42
                float32x4_t f00, f10, f01, f11;
43

44
                // 收集 4 个像素的邻近值
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 类似
50

51
                // 双线性插值公式
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
                // 转换回 uint8 并存储
69
                uint32x4_t result_u32 = vcvtq_u32_f32(result);
70
                // ... 存储
71
            }
72
        }
73
#endif
74
        // 标量处理剩余像素（略）
75
    }
76
}

TIP

Die NEON-Optimierung der bilinearen Interpolation ist komplex, da die Adressen der vier benachbarten Pixel nicht kontinuierlich sind. Eine effizientere Methode ist die separable bilineare Interpolation: Zuerst wird in horizontaler Richtung interpoliert, dann in vertikaler. Dies nutzt die Cache-Lokalität besser aus.

Diese Entscheidung bedeutet mehr Entwicklungsaufwand, aber die Vorteile sind signifikant:

APK-Größe um ca. 10 MB reduziert.
Volle Kontrolle über die Vorverarbeitungslogik für Optimierungen.
Vermeidung von Kompatibilitätsproblemen mit OpenCV-Versionen.

Perspektivische Transformation: Vom rotierten Rechteck zur Standard-Textzeile

Das Texterkennungsmodell erwartet als Eingabe horizontale Bilder von Textzeilen. Die erkannten Textboxen können jedoch rotierte Rechtecke in jedem beliebigen Winkel sein. Die perspektivische Transformation ist dafür verantwortlich, diese rotierten Bereiche „geradezuziehen“.

In text_recognizer.cpp implementiert die Methode CropAndRotate diese Funktion:

1
void CropAndRotate(const uint8_t *__restrict__ image_data,
2
                   int width, int height, int stride,
3
                   const RotatedRect &box, int &target_width) {
4
    // 计算旋转矩形的四个角点
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];  // 4 个角点的 (x, y) 坐标
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
    // ... 计算其他角点
14

15
    // 自适应目标宽度：保持宽高比
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
    // 仿射变换矩阵
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
    // 双线性插值采样 + 归一化（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
}

Wichtige Optimierungen dieser Implementierung:

Adaptive Breite: Dynamische Anpassung der Ausgabebreite basierend auf dem Seitenverhältnis der Textbox, um übermäßiges Strecken oder Stauchen zu vermeiden.
Affine Transformations-Approximation: Für Textboxen, die annähernd Parallelogramme sind, wird eine affine Transformation anstelle einer perspektivischen verwendet, um Rechenaufwand zu sparen.
NEON Bilineare Interpolation: Sampling und Normalisierung erfolgen in einem Durchgang, was Speicherzugriffe reduziert.

JNI: Die Brücke zwischen Kotlin und C++

JNI (Java Native Interface) ist die Brücke für die Kommunikation zwischen Kotlin/Java und C++. JNI-Aufrufe verursachen jedoch Overhead; häufige sprachübergreifende Aufrufe können die Performance erheblich beeinträchtigen.

Das Designprinzip von PPOCRv5-Android lautet: Minimierung der JNI-Aufrufe. Der gesamte OCR-Prozess benötigt nur einen einzigen JNI-Aufruf:

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

7
    K->>J: process(bitmap)
8
    J->>N: RGBA-Pointer übergeben
9

10
    Note over N,G: Native Ebene erledigt die gesamte Arbeit
11

12
    N->>N: Bildvorverarbeitung NEON
13
    N->>G: Textdetektions-Inferenz
14
    G-->>N: Wahrscheinlichkeitskarte
15
    N->>N: Nachverarbeitung Konturerkennung
16

17
    loop Jede Textbox
18
        N->>N: Perspektivischer Zuschnitt
19
        N->>G: Texterkennungs-Inferenz
20
        G-->>N: Logits
21
        N->>N: CTC-Dekodierung
22
    end
23

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

In ppocrv5_jni.cpp zeigt die zentrale Funktion nativeProcess dieses Design:

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
    // 锁定 Bitmap 像素
8
    void *pixels = nullptr;
9
    AndroidBitmap_lockPixels(env, bitmap, &pixels);
10

11
    // 一次 JNI 调用完成所有 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
    // 构造 Java 对象数组返回
21
    // ...
22
}

Dieses Design vermeidet den Overhead für das Hin- und Herschieben von Daten zwischen Detektion und Erkennung.

Architektur-Design: Modularität und Testbarkeit

Die Architektur von PPOCRv5-Android folgt dem Prinzip der „Separation of Concerns“:

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

9
    subgraph VM["ViewModel Layer"]
10
        OVM[OCRViewModel<br/>State Management]
11
    end
12

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

16
        subgraph Detection["Textdetektion"]
17
            TD[TextDetector]
18
            DB[DBNet FP16]
19
        end
20

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

26
        subgraph Preprocessing["Bildverarbeitung"]
27
            IP[ImagePreprocessor<br/>NEON Optimiert]
28
            PP[PostProcessor<br/>Konturerkennung]
29
        end
30

31
        subgraph Runtime["LiteRT Runtime"]
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

Die Vorteile dieser Schichtenarchitektur sind:

UI-Schicht: Reines Kotlin/Compose, fokussiert auf Benutzerinteraktion.
ViewModel-Schicht: Verwaltung von Status und Geschäftslogik.
Native-Schicht: Hochleistungsberechnungen, vollständig von der UI entkoppelt.

Jede Schicht kann unabhängig getestet werden. Die Native-Schicht kann mit Google Test für Unit-Tests genutzt werden, die ViewModel-Schicht mit JUnit + MockK.

Kapselung in der Kotlin-Schicht

In OcrEngine.kt bietet die Kotlin-Schicht eine prägnante API:

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
}

Vorteile dieses Designs:

Nutzung des Result-Typs zur Behandlung von Initialisierungsfehlern.
Implementierung des Closeable-Interfaces für die automatische Ressourcenfreigabe in use-Blöcken.
Modell-Dateien werden automatisch von Assets in das Cache-Verzeichnis kopiert.

Kaltstart-Optimierung

Die erste Inferenz (Kaltstart) ist normalerweise viel langsamer als nachfolgende Aufrufe (Warmstart). Die Gründe dafür sind:

Der GPU Delegate muss OpenCL-Programme kompilieren.
Modellgewichte müssen vom CPU-Speicher in den GPU-Speicher übertragen werden.
Diverse Caches müssen aufgewärmt werden.

PPOCRv5-Android nutzt einen Warm-up-Mechanismus, um Kaltstart-Probleme zu mildern:

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

4
    // 创建一个小的测试图像
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
    // 执行几次推理来预热
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
}

Speicher-Alignment-Optimierung

In TextDetector::Impl werden alle vorallozierten Buffer mit 64-Byte-Alignment ausgerichtet:

1
// Pre-allocated buffers with cache-line alignment
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_;

Ein 64-Byte-Alignment entspricht der Cache-Line-Größe moderner ARM-Prozessoren. Ausgerichtete Speicherzugriffe vermeiden Cache-Line-Splits und erhöhen die Effizienz des Speicherzugriffs.

Memory Pool und Objekt-Wiederverwendung

Häufige Speicherallokationen und -freigaben sind Performance-Killer. PPOCRv5-Android nutzt eine Vorallokationsstrategie, bei der bei der Initialisierung der gesamte benötigte Speicher auf einmal reserviert wird:

1
class TextDetector::Impl {
2
    // 预分配的 buffer，生命周期与 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
        // 一次性分配，避免运行时 malloc
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
};

Vorteile dieses Designs:

Vermeidung von Speicherfragmentierung: Alle großen Blöcke werden beim Start alloziert, zur Laufzeit entsteht keine Fragmentierung.
Reduzierung von Systemaufrufen: malloc kann Systemaufrufe auslösen; die Vorallokation vermeidet diesen Overhead.
Cache-Freundlichkeit: Kontinuierlich alloziierter Speicher liegt mit höherer Wahrscheinlichkeit physisch beieinander, was die Cache-Hit-Rate erhöht.

Branch-Prediction-Optimierung

Moderne CPUs nutzen Branch Prediction (Sprungvorhersage), um die Pipeline-Effizienz zu steigern. Eine falsche Vorhersage führt zu einem Pipeline-Flush, was 10-20 Taktzyklen kostet.

Auf Hot-Paths nutzen wir __builtin_expect, um dem Compiler Hinweise zu geben:

1
// 大多数像素不会超过阈值
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) teilt dem Compiler mit, dass der Wert von expr sehr wahrscheinlich val sein wird. Der Compiler passt das Code-Layout entsprechend an und platziert „unwahrscheinliche“ Zweige weiter weg vom Hauptpfad.

Loop Unrolling und Software-Pipelining

Bei rechenintensiven Schleifen kann manuelles Unrolling (Schleifenentrollung) den Overhead reduzieren und mehr Instruktions-Parallelität freilegen:

1
// 未展开版本
2
for (int i = 0; i < n; ++i) {
3
    dst[i] = src[i] * scale + bias;
4
}
5

6
// 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
}

Nach dem Entrollen kann die CPU mehrere unabhängige Multiply-Add-Befehle gleichzeitig ausführen und die multiplen Ausführungseinheiten der superskalaren Architektur voll ausnutzen.

Prefetch-Optimierung

In der inneren Schleife der perspektivischen Transformation wird __builtin_prefetch genutzt, um Daten der nächsten Zeile vorab zu laden:

1
for (int dy = 0; dy < kRecInputHeight; ++dy) {
2
    // 预取下一行数据
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
    // ... 处理当前行
11
}

Diese Optimierung kann Speicherlatenzen verbergen; während die aktuelle Zeile verarbeitet wird, befinden sich die Daten der nächsten Zeile bereits im L1-Cache.

Technische Details der Nachverarbeitung

Zusammenhangskomponenten-Analyse und Konturerkennung

In postprocess.cpp implementiert die Funktion FindContours eine effiziente Zusammenhangskomponenten-Analyse:

1
std::vector<std::vector<Point>> FindContours(const uint8_t *binary_map,
2
                                             int width, int height) {
3
    // 1. 4x 降采样减少计算量
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. BFS 遍历连通域
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
                    // 检测边界像素
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
                    // 4-邻域扩展
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
}

Wichtige Optimierungspunkte:

4x Downsampling: Reduzierung der 640x640 Binärkarte auf 160x160, was den Rechenaufwand um den Faktor 16 verringert.
Grenzpunkterkennung: Nur Grenzpixel werden gespeichert, nicht die gesamte Zusammenhangskomponente.
Limitierung der maximalen Konturenanzahl: kMaxContours = 100, um Performance-Probleme in Extremsituationen zu vermeiden.

Konvexe Hülle und Rotating Calipers-Algorithmus

Die Berechnung des kleinsten umschreibenden rotierten Rechtecks erfolgt in zwei Schritten: Zuerst wird die konvexe Hülle berechnet, dann wird mittels des Rotating Calipers-Algorithmus das umschreibende Rechteck mit der minimalen Fläche gesucht.

Graham Scan-Algorithmus für die konvexe Hülle

Graham Scan ist ein klassischer Algorithmus zur Berechnung der konvexen Hülle mit einer Zeitkomplexität von $O(n \log n)$ :

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

4
    // 1. 找到最下方的点（y 最小，x 最小）
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. 按极角排序
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
                // 共线时，距离近s的排前面
18
                return DistanceSquared(p0, a) < DistanceSquared(p0, b);
19
            }
20
            return cross > 0;  // 逆时针方向
21
        });
22

23
    // 3. 构建凸包
24
    std::vector<Point> hull;
25
    for (const auto& p : points) {
26
        // 移除导致顺时针转向的点
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
// 叉积：判断转向方向
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
}

Rotating Calipers-Algorithmus

Der Rotating Calipers-Algorithmus traversiert jede Kante der konvexen Hülle und berechnet die Fläche des umschreibenden Rechtecks mit dieser Kante als Basis:

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;  // 三个「卡壳」的位置
9

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

13
        // 当前边的方向向量
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
        // 单位向量
19
        float ux = edge_x / edge_len;
20
        float uy = edge_y / edge_len;
21

22
        // 垂直方向
23
        float vx = -uy;
24
        float vy = ux;
25

26
        // 找到最右点（沿边方向投影最大）
27
        while (Dot(hull[(right + 1) % n], ux, uy) > Dot(hull[right], ux, uy)) {
28
            right = (right + 1) % n;
29
        }
30

31
        // 找到最上点（沿垂直方向投影最大）
32
        while (Dot(hull[(top + 1) % n], vx, vy) > Dot(hull[top], vx, vy)) {
33
            top = (top + 1) % n;
34
        }
35

36
        // 找到最左点
37
        while (Dot(hull[(left + 1) % n], ux, uy) < Dot(hull[left], ux, uy)) {
38
            left = (left + 1) % n;
39
        }
40

41
        // 计算矩形尺寸
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
            // 更新最优矩形参数
49
            best_rect.width = width;
50
            best_rect.height = height;
51
            best_rect.angle = std::atan2(uy, ux) * 180.0f / M_PI;
52
            // 计算中心点...
53
        }
54
    }
55

56
    return best_rect;
57
}

Die entscheidende Erkenntnis bei Rotating Calipers ist, dass sich die drei „Messschieber“ (rechts, oben, links) beim Rotieren der Basis nur monoton vorwärts bewegen. Daher beträgt die Gesamtzeitkomplexität $O(n)$ und nicht $O(n^2)$ .

Kleinstes umschreibendes rotiertes Rechteck

Die Funktion MinAreaRect nutzt den Rotating Calipers-Algorithmus zur Berechnung des kleinsten umschreibenden rotierten Rechtecks:

1
RotatedRect MinAreaRect(const std::vector<Point> &contour) {
2
    // 1. 子采样减少点数
3
    std::vector<Point> points = subsample_points(contour, kMaxBoundaryPoints);
4

5
    // 2. 快速路径：高宽高比的文本框直接使用 AABB
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
        // 直接返回轴对齐边界框
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. 凸包计算
20
    std::vector<Point> hull = convex_hull(std::vector<Point>(points));
21

22
    // 4. 旋转卡壳：遍历凸包的每条边
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
        // 以当前边为基准，计算外接矩形
28
        float edge_x = hull[j].x - hull[i].x;
29
        float edge_y = hull[j].y - hull[i].y;
30

31
        // 投影所有点到边的方向和垂直方向
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
            // 更新最优矩形
39
        }
40
    }
41

42
    return best_rect;
43
}

Die Zeitkomplexität dieses Algorithmus beträgt $O(n \log n)$ (konvexe Hülle) + $O(n)$ (Rotating Calipers), wobei $n$ die Anzahl der Grenzpunkte ist. Durch Subsampling wird $n$ auf unter 200 begrenzt, was die Echtzeit-Performance sicherstellt.

Echtzeit-Kamera-OCR: CameraX und Frame-Analyse

Die Herausforderung bei Echtzeit-OCR besteht darin, jede Frame so schnell wie möglich zu verarbeiten und gleichzeitig eine flüssige Vorschau beizubehalten.

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

9
    subgraph Analysis["Frame-Analyse-Prozess"]
10
        direction TB
11
        IP[ImageProxy<br/>YUV_420_888]
12
        BM[Bitmap-Konvertierung<br/>RGBA_8888]
13
        JNI[JNI-Aufruf<br/>Einmalig sprachübergreifend]
14
    end
15

16
    subgraph Native["Native OCR"]
17
        direction TB
18
        DET[TextDetector<br/>~45ms GPU]
19
        REC[TextRecognizer<br/>~15ms/Zeile]
20
        RES[OCR-Ergebnisse]
21
    end
22

23
    subgraph UI["UI-Update"]
24
        direction TB
25
        VM[ViewModel<br/>StateFlow]
26
        OV[ResultOverlay<br/>Canvas-Zeichnung]
27
    end
28

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

CameraX ImageAnalysis

CameraX ist die Kamera-Bibliothek von Android Jetpack. Sie bietet den ImageAnalysis-UseCase, der uns erlaubt, Kamera-Frames in Echtzeit zu analysieren:

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
    // 更新 UI
10
    imageProxy.close()
11
}

Die wichtigste Konfiguration ist STRATEGY_KEEP_ONLY_LATEST: Wenn der Analyzer langsamer verarbeitet als die Kamera Frames liefert, werden alte Frames verworfen und nur die neueste Frame behalten. Dies stellt die Aktualität der OCR-Ergebnisse sicher.

Abwägung zwischen Framerate und Latenz

Auf Geräten mit GPU-Beschleunigung (mein aktuelles Snapdragon 870 scheint Probleme zu haben, den Großteil der Berechnungen an die GPU zu delegieren) kann PPOCRv5-Android theoretisch hohe Verarbeitungsgeschwindigkeiten erreichen. Das bedeutet jedoch nicht, dass wir jede Frame verarbeiten sollten.

Stellen Sie sich folgendes Szenario vor: Ein Benutzer richtet die Kamera auf einen Textabschnitt; der Textinhalt ändert sich in kurzer Zeit nicht. Wenn wir jede Frame eine vollständige OCR durchführen, verschwenden wir massiv Rechenressourcen.

Eine Optimierungsstrategie ist die „Änderungserkennung“: OCR wird nur ausgelöst, wenn sich das Bild signifikant verändert hat. Dies kann durch den Vergleich von Histogrammen oder Feature-Points aufeinanderfolgender Frames erreicht werden.

Zukunftsausblick: NPU und Quantisierung

Die Zukunft der On-Device-KI liegt in NPUs (Neural Processing Units). Im Vergleich zu GPUs sind NPUs speziell für die Inferenz neuronaler Netze konzipiert und bieten eine höhere Energieeffizienz.

Die Herausforderung bei NPUs ist jedoch die Fragmentierung. Jeder Chiphersteller hat seine eigene NPU-Architektur und sein eigenes SDK:

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

Androids NNAPI (Neural Networks API) versucht, eine einheitliche Abstraktionsschicht zu bieten, aber die tatsächlichen Ergebnisse variieren stark. Viele NPU-Funktionen können nicht über NNAPI angesprochen werden, weshalb Entwickler oft auf herstellerspezifische SDKs zurückgreifen müssen.

INT8-Quantisierung: Eine unvollendete Schlacht

FP16-Quantisierung ist eine konservative Wahl, die fast keine Genauigkeit einbüßt. Wenn man jedoch nach extremer Performance strebt, ist INT8-Quantisierung der nächste Schritt.

Die INT8-Quantisierung komprimiert Gewichte und Aktivierungen von 32-Bit-Float auf 8-Bit-Integer, was theoretisch Folgendes ermöglicht:

4-fache Modellkompression.
2- bis 4-fache Inferenzbeschleunigung (je nach Hardware).
Auf Qualcomm Hexagon DSPs ist eine mehr als 10-fache Beschleunigung möglich.

Diese Verlockung war zu groß. So begann ich eine lange Reise in die INT8-Quantisierung.

Erster Versuch: Kalibrierung mit synthetischen Daten

Die INT8-Quantisierung benötigt einen Kalibrierungsdatensatz, um die Quantisierungsparameter (Scale und Zero Point) zu bestimmen. Anfangs war ich nachlässig und verwendete zufällig generierte „textähnliche“ Bilder:

1
# 错误示范：使用随机噪声做校准
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

Das Ergebnis war katastrophal. Das Modell gab nur Nullen aus:

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

Das Quantisierungstool berechnete basierend auf dem Zufallsrauschen falsche Quantisierungsparameter, was dazu führte, dass die Aktivierungswerte realer Bilder abgeschnitten wurden.

Zweiter Versuch: Kalibrierung mit echten Bildern

Ich wechselte zu echten Bildern aus OCR-Datensätzen: ICDAR2015, TextOCR, offizielle PaddleOCR-Beispielbilder. Gleichzeitig implementierte ich eine Letterbox-Vorverarbeitung, um sicherzustellen, dass die Bildverteilung bei der Kalibrierung der bei der Inferenz entsprach:

1
def letterbox_image(image, target_size):
2
    """保持长宽比缩放，不足部分填充灰色"""
3
    ih, iw = image.shape[:2]
4
    h, w = target_size
5
    scale = min(w / iw, h / ih)
6
    # ... 居中粘贴

Das Modell gab keine Nullen mehr aus, aber die Erkennungsergebnisse waren immer noch Zeichensalat.

Dritter Versuch: Korrektur der Typbehandlung auf C++-Ebene

Ich stellte fest, dass der C++-Code bei der Verarbeitung von INT8-Eingaben Probleme hatte. Das INT8-Modell erwartet rohe Pixelwerte (0-255), während ich noch die ImageNet-Normalisierung (Mittelwert abziehen, durch Standardabweichung teilen) durchführte.

1
if (input_is_int8_) {
2
    // INT8 模型：直接输入原始像素，归一化已融合到第一层
3
    dst[i * 3 + 0] = static_cast<int8_t>(src[i * 4 + 0] ^ 0x80);
4
} else {
5
    // FP32 模型：需要手动归一化
6
    // (pixel - mean) / std
7
}

Gleichzeitig implementierte ich die Logik zum dynamischen Auslesen der Quantisierungsparameter, anstatt sie hart zu kodieren:

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

Endergebnis: Ein Kompromiss

Nach tagelangem Debugging funktionierte das INT8-Modell immer noch nicht korrekt. Die Probleme könnten liegen bei:

Der Quantisierungsimplementierung von onnx2tf: PP-OCRv5 nutzt spezielle Operator-Kombinationen, die onnx2tf bei der Quantisierung eventuell nicht korrekt verarbeitet hat.
Den Ausgabeeigenschaften von DBNet: DBNet gibt eine Wahrscheinlichkeitskarte aus, deren Wertebereich zwischen 0 und 1 liegt. Die INT8-Quantisierung reagiert besonders empfindlich auf solch kleine Wertebereiche.
Fehlerakkumulation in mehrstufigen Modellen: Detektion und Erkennung sind hintereinandergeschaltet; Quantisierungsfehler akkumulieren und verstärken sich.

Lassen Sie uns Punkt 2 genauer analysieren. Die Ausgabe von DBNet durchläuft eine Sigmoid-Aktivierung, wodurch der Wertebereich auf [0, 1] komprimiert wird. Die INT8-Quantisierung nutzt folgende Formel:

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

Für Werte im Bereich [0, 1] kann ein falsch gewählter Scale dazu führen, dass die quantisierten Werte nur einen winzigen Teil des INT8-Bereichs [-128, 127] einnehmen, was zu massiven Genauigkeitsverlusten führt.

1
# 假设 scale = 0.00784 (1/127), zero_point = 0
2
# 输入 0.5 -> round(0.5 / 0.00784) + 0 = 64
3
# 输入 0.1 -> round(0.1 / 0.00784) + 0 = 13
4
# 输入 0.01 -> round(0.01 / 0.00784) + 0 = 1
5
# 输入 0.001 -> round(0.001 / 0.00784) + 0 = 0  # 精度丢失！

Der Schwellenwert von DBNet liegt normalerweise bei 0,1-0,3. Das bedeutet, dass eine Vielzahl aussagekräftiger Wahrscheinlichkeitswerte (0,1-0,3) nach der Quantisierung nur durch 25 Ganzzahlen (13-38) dargestellt werden können – die Auflösung ist völlig unzureichend.

WARNING

Die INT8-Quantisierung von PP-OCRv5 ist eine bekannte Herausforderung. Wenn Sie es ebenfalls versuchen, stellen Sie sicher, dass das FP32-Modell korrekt funktioniert, bevor Sie Quantisierungsprobleme untersuchen. Alternativ könnten Sie das offizielle Paddle Lite-Framework von PaddlePaddle in Betracht ziehen, das PaddleOCR besser unterstützt.

Quantization-Aware Training: Die richtige Lösung

Wenn INT8-Quantisierung zwingend erforderlich ist, ist der richtige Weg Quantization-Aware Training (QAT) anstelle von Post-Training Quantization (PTQ).

QAT simuliert Quantisierungsfehler während des Trainingsprozesses, sodass das Modell lernt, sich an Darstellungen mit niedriger Präzision anzupassen:

1
# PyTorch QAT 示例
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
# 正常训练，但前向传播中插入了伪量化节点
9
for epoch in range(num_epochs):
10
    for images, labels in dataloader:
11
        outputs = model_prepared(images)  # 包含量化模拟
12
        loss = criterion(outputs, labels)
13
        loss.backward()
14
        optimizer.step()
15

16
# 转换为真正的量化模型
17
model_quantized = quant.convert(model_prepared)

Leider bietet das PP-OCRv5-Team keine offiziellen QAT-trainierten Modelle an. Das bedeutet, um ein qualitativ hochwertiges INT8-Modell zu erhalten, müsste man ein QAT-Training von Grund auf durchführen, was den Rahmen dieses Projekts sprengen würde.

Letztendlich entschied ich mich für einen Kompromiss: Nutzung von FP16-Quantisierung + GPU-Beschleunigung anstelle von INT8 + DSP.

Der Preis dieser Entscheidung:

Die Modellgröße ist doppelt so groß wie bei INT8.
Der extrem niedrige Stromverbrauch des Hexagon DSP kann nicht genutzt werden.
Die Inferenzgeschwindigkeit ist 2-3 mal langsamer als das theoretische Optimum.

Der Gewinn jedoch:

Die Modellgenauigkeit ist fast identisch mit FP32.
Die Entwicklungszeit wurde massiv verkürzt.
Die Code-Komplexität wurde reduziert.

Das Wesen des Engineerings ist die Abwägung. Manchmal ist „gut genug“ wichtiger als „theoretisch optimal“.

Fazit

Von PaddlePaddle zu TFLite, von DBNet zu SVTRv2, von OpenCL zu NEON – die technische Praxis von On-Device-OCR umfasst Wissen aus den Bereichen Deep Learning, Compiler, GPU-Programmierung, mobile Entwicklung und mehr.

Die wichtigste Lehre aus diesem Projekt ist: On-Device-KI bedeutet nicht nur, „ein Modell auf das Handy zu schieben“. Es erfordert:

Ein tiefes Verständnis der Modellarchitektur für eine korrekte Konvertierung.
Kenntnis der Hardware-Eigenschaften zur optimalen Nutzung von Beschleunigern.
Beherrschung der Systemprogrammierung für performanten nativen Code.
Fokus auf die User Experience, um die Balance zwischen Performance und Stromverbrauch zu finden.

PPOCRv5-Android ist ein Open-Source-Projekt, das zeigt, wie moderne OCR-Modelle in realen mobilen Anwendungen eingesetzt werden können. Ich hoffe, dieser Artikel dient Entwicklern mit ähnlichen Anforderungen als nützliche Referenz.

Wie Google bei der Veröffentlichung von LiteRT sagte: „Maximum performance, simplified.“⁹ Das Ziel von On-Device-KI ist nicht Komplexität, sondern das Komplexe einfach zu machen.

Nachwort

Ehrlich gesagt, habe ich mich (beruflich und privat) seit mindestens zwei Jahren von Android distanziert. Dies ist das erste Mal, dass ich auf einem GitHub-Zweitaccount (meinen Hauptaccount habe ich Kollegen überlassen, um meine Entschlossenheit zum Abschied zu zeigen) eine ausgereiftere Bibliothek veröffentliche.

In den letzten Jahren lag mein Arbeitsschwerpunkt nicht im Android-Bereich. Die Details dazu kann ich hier nicht vertiefen, aber vielleicht ergibt sich später die Gelegenheit. Jedenfalls werde ich wohl kaum noch große Beiträge im Android-Ökosystem leisten.

Die Veröffentlichung dieses Projekts entsprang meinem persönlichen Interesse während der Entwicklung eines frühen On-Device-Tools für Android – wobei OCR nur ein kleiner Teil der Basistechnologie ist. Dieses Tool wird später (hoffentlich bald) ebenfalls vollständig Open Source gehen.

Wie dem auch sei, danke, dass Sie bis hierhin gelesen haben. Ich würde mich freuen, wenn Sie meinem Repository einen Star geben. Vielen Dank!

Referenzen

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

# On-Device OCR in der Praxis: Native Bereitstellung von PP-OCRv5 auf Android

Hinweise

Einleitung

Modellkonvertierung: Die lange Reise von PaddlePaddle zu TFLite

Die erste Hürde: Operator-Kompatibilität von paddle2onnx

Die zweite Hürde: HardSigmoid und GPU-Kompatibilität

Die dritte Hürde: Koordinatentransformationsmodus des Resize-Operators

Der letzte Schritt: onnx2tf und FP16-Quantisierung

Textdetektion: Die differenzierbare Binarisierung von DBNet

Standard-Binarisierung vs. Differenzierbare Binarisierung

Technische Implementierung des Nachverarbeitungsprozesses

Unclip: Der Expansionsalgorithmus für Textboxen

Texterkennung: SVTRv2 und CTC-Dekodierung

Architektur-Innovationen von SVTRv2

Warum CTC statt Attention?

NEON-optimierte CTC-Dekodierung

Mathematisches Prinzip der CTC-Loss-Funktion und Dekodierung

Das Zeichenlexikon: Die Herausforderung von 18.383 Zeichen

LiteRT C++ API: Die moderne Schnittstelle nach dem Refactoring 2024

Vergleich: Alte vs. Neue API

Umgebung und Modellinitialisierung

Managed Tensor Buffer: Der Schlüssel zur Zero-Copy-Inferenz

GPU-Beschleunigung: Wahl und Abwägung von OpenCL

OpenCL vs. OpenGL ES: Tiefer Performance-Vergleich

Graceful Fallback-Strategie

Native Ebene: C++ und NEON-Optimierung

NEON: Der SIMD-Befehlssatz von ARM

NEON-Implementierung der ImageNet-Normalisierung

Null OpenCV-Abhängigkeit

NEON-Implementierung der bilinearen Interpolation

Perspektivische Transformation: Vom rotierten Rechteck zur Standard-Textzeile

JNI: Die Brücke zwischen Kotlin und C++

Architektur-Design: Modularität und Testbarkeit

Kapselung in der Kotlin-Schicht

Kaltstart-Optimierung

Speicher-Alignment-Optimierung

Memory Pool und Objekt-Wiederverwendung

Branch-Prediction-Optimierung

Loop Unrolling und Software-Pipelining

Prefetch-Optimierung

Technische Details der Nachverarbeitung

Zusammenhangskomponenten-Analyse und Konturerkennung

Konvexe Hülle und Rotating Calipers-Algorithmus

Graham Scan-Algorithmus für die konvexe Hülle

Rotating Calipers-Algorithmus

Kleinstes umschreibendes rotiertes Rechteck

Echtzeit-Kamera-OCR: CameraX und Frame-Analyse

CameraX ImageAnalysis

Abwägung zwischen Framerate und Latenz

Zukunftsausblick: NPU und Quantisierung

INT8-Quantisierung: Eine unvollendete Schlacht

Erster Versuch: Kalibrierung mit synthetischen Daten

Zweiter Versuch: Kalibrierung mit echten Bildern

Dritter Versuch: Korrektur der Typbehandlung auf C++-Ebene

Endergebnis: Ein Kompromiss

Quantization-Aware Training: Die richtige Lösung

Fazit

Nachwort

Referenzen

Footnotes