Практика OCR на устройствах: нативное развертывание PP-OCRv5 на Android

Примечания

Этот пост в блоге:

Обложка: Сгенерирована на основе Google Nano Banana 2, без авторских прав.
Исходный код проекта: Опубликован на GitHub, пожалуйста, посетите PPOCRv5-Android для получения доступа.

Дисклеймер:

Автор (Fleey) не является профессионалом в области ИИ, проект создан исключительно из интереса. Прошу читателей отнестись с пониманием к возможным упущениям и ошибкам и своевременно указывать на них!

Введение

В 2024 году Google переименовала TensorFlow Lite в LiteRT. Это не просто ребрендинг, а символ смены парадигмы в области мобильного ИИ: от «mobile-first» к «edge-first» ¹. В этом контексте OCR (оптическое распознавание символов), как одно из самых практичных применений ИИ на устройствах, переживает тихую революцию.

Команда PaddleOCR из Baidu в 2025 году выпустила PP-OCRv5 — унифицированную модель OCR с поддержкой упрощенного и традиционного китайского, английского, японского и других языков ². Ее мобильная версия весит всего около 70 МБ, но способна распознавать 18 383 символа в рамках одной модели. За этой цифрой стоит совместная работа двух глубоких нейронных сетей: детекции и распознавания.

Но есть проблема: PP-OCRv5 обучена на фреймворке PaddlePaddle, в то время как самым зрелым движком инференса на Android является LiteRT. Как преодолеть этот разрыв?

Давайте начнем с конвертации модели и постепенно раскроем инженерные аспекты реализации OCR на мобильных устройствах.

1
flowchart TB
2
    subgraph E2E["End-to-End OCR процесс"]
3
        direction TB
4

5
        subgraph Input["Вход"]
6
            IMG[Исходное изображение<br/>Любой размер]
7
        end
8

9
        subgraph Detection["Детекция текста - DBNet"]
10
            DET_PRE[Предобработка<br/>Resize 640x640<br/>ImageNet Normalize]
11
            DET_INF[Инференс DBNet<br/>~45ms GPU]
12
            DET_POST[Постпроцессинг<br/>Бинаризация - Контуры - Повернутый прямоугольник]
13
        end
14

15
        subgraph Recognition["Распознавание текста - SVTRv2"]
16
            REC_CROP[Обрезка с персп. преобр.<br/>48xW адаптивная ширина]
17
            REC_INF[Инференс SVTRv2<br/>~15ms/строка GPU]
18
            REC_CTC[CTC декодирование<br/>Слияние дублей + Удаление пробелов]
19
        end
20

21
        subgraph Output["Выход"]
22
            RES[Результаты OCR<br/>Текст + Уверенность + Позиция]
23
        end
24
    end
25

26
    IMG --> DET_PRE --> DET_INF --> DET_POST
27
    DET_POST -->|N текстовых блоков| REC_CROP
28
    REC_CROP --> REC_INF --> REC_CTC --> RES

Конвертация модели: долгий путь от PaddlePaddle до TFLite

Фрагментация фреймворков глубокого обучения — это «боль» всей индустрии. PyTorch, TensorFlow, PaddlePaddle, ONNX — у каждого свои форматы моделей и реализации операторов. ONNX (Open Neural Network Exchange) пытается стать универсальным промежуточным представлением, но реальность часто оказывается суровее ожиданий.

Путь конвертации PP-OCRv5 выглядит следующим образом:

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

6
    subgraph ONNX["Промежуточный ONNX"]
7
        OM[model.onnx<br/>opset 14]
8
    end
9

10
    subgraph Optimization["Оптимизация графа"]
11
        GS[onnx-graphsurgeon<br/>Декомпозиция операторов]
12
    end
13

14
    subgraph TFLite["Формат LiteRT"]
15
        TM[model.tflite<br/>FP16 Quantized]
16
    end
17

18
    PM -->|paddle2onnx| OM
19
    OM -->|Декомпозиция HardSigmoid<br/>Изменение режима Resize| GS
20
    GS -->|onnx2tf| TM

Этот путь кажется простым, но он полон скрытых нюансов.

Первое препятствие: совместимость операторов в paddle2onnx

paddle2onnx — это официальный инструмент конвертации от PaddlePaddle. Теоретически он может перевести модель PaddlePaddle в формат ONNX. Однако PP-OCRv5 использует специфические операторы, маппинг которых в ONNX не всегда однозначен.

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

Важная деталь: файлы модели PP-OCRv5 называются inference.json, а не традиционно inference.pdmodel. Это изменение формата в новых версиях PaddlePaddle, на котором многие разработчики «спотыкаются» ³.

Второе препятствие: HardSigmoid и совместимость с GPU

Конвертированная ONNX-модель содержит оператор HardSigmoid. Математически он определяется как:

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

где $\alpha = 0.2$ , $\beta = 0.5$ .

Проблема в том, что GPU Delegate в LiteRT не поддерживает HardSigmoid. Когда модель содержит неподдерживаемый оператор, GPU Delegate выполняет «fallback» всего подграфа на CPU, что приводит к серьезной потере производительности.

Решение — разложить HardSigmoid на базовые операторы. Используя библиотеку onnx-graphsurgeon, мы можем провести «хирургическую операцию» на уровне графа вычислений:

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

Ключевой момент здесь в том, что Mul, Add и Clip — это операторы, полностью поддерживаемые LiteRT GPU Delegate. После разложения весь подграф может выполняться на GPU непрерывно, избегая накладных расходов на передачу данных между CPU и GPU.

TIP

Почему бы не изменить код обучения модели напрямую? Потому что расчет градиентов для HardSigmoid при обучении отличается от Clip. Разложение следует проводить только на этапе инференса для сохранения численной стабильности обучения.

Третье препятствие: режим трансформации координат оператора Resize

Оператор Resize в ONNX имеет атрибут coordinate_transformation_mode, который определяет, как выходные координаты отображаются на входные. PP-OCRv5 использует режим half_pixel, но поддержка этого режима в LiteRT GPU Delegate ограничена.

Изменение его на режим asymmetric позволяет добиться лучшей совместимости с GPU:

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

WARNING

Такая модификация может привести к незначительным численным различиям. В реальных тестах влияние этих различий на точность OCR пренебрежимо мало, но в других задачах может потребоваться тщательная оценка.

Последний шаг: onnx2tf и квантование FP16

onnx2tf — это инструмент для конвертации ONNX-моделей в формат TFLite. Квантование FP16 (половинная точность) — частый выбор для мобильного развертывания. Оно уменьшает размер модели вдвое при приемлемой потере точности и позволяет использовать вычислительные блоки FP16 мобильных GPU.

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

Параметр -ois здесь задает статическую форму входных данных. Статическая форма критически важна для ускорения на GPU; динамические формы заставляют перекомпилировать программу GPU при каждом инференсе, что сильно бьет по производительности.

Детекция текста: дифференцируемая бинаризация DBNet

Модуль детекции в PP-OCRv5 основан на DBNet (Differentiable Binarization Network) ⁴. Традиционные методы детекции текста используют фиксированный порог для бинаризации, в то время как инновация DBNet заключается в том, что сеть сама обучается оптимальному порогу для каждого пикселя.

1
flowchart TB
2
    subgraph DBNet["Архитектура DBNet"]
3
        direction TB
4
        IMG[Входное изображение<br/>H x W x 3]
5
        BB[Backbone<br/>MobileNetV3]
6
        FPN[FPN Пирамида признаков<br/>Многомасштабное слияние]
7

8
        subgraph Heads["Двухветвевой вывод"]
9
            PH[Ветка карты вероятностей<br/>P: H x W x 1]
10
            TH[Ветка карты порогов<br/>T: H x W x 1]
11
        end
12

13
        DB["Дифференцируемая бинаризация<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

Стандартная бинаризация vs Дифференцируемая бинаризация

Стандартная бинаризация — это ступенчатая функция:

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

Эта функция не дифференцируема, что делает невозможным сквозное обучение (end-to-end) через обратное распространение ошибки. DBNet предлагает аппроксимирующую функцию:

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

Где $P$ — карта вероятностей, $T$ — карта порогов (обучаемая сетью), а $k$ — коэффициент усиления (при обучении устанавливается равным 50).

TIP

Эта формула по сути является функцией Sigmoid, где входом служит $P - T$ . Когда $k$ достаточно велико, ее поведение приближается к ступенчатой функции, сохраняя при этом дифференцируемость.

Инженерная реализация процесса постпроцессинга

В проекте PPOCRv5-Android процесс постпроцессинга реализован в файле postprocess.cpp. Основные этапы включают:

1
flowchart LR
2
    subgraph Input["Вывод модели"]
3
        PM[Карта вероятностей P<br/>640 x 640]
4
    end
5

6
    subgraph Binary["Бинаризация"]
7
        BT[Фильтрация по порогу<br/>threshold=0.1]
8
        BM[Бинарная карта<br/>640 x 640]
9
    end
10

11
    subgraph Contour["Детекция контуров"]
12
        DS[4x Даунсэмплинг<br/>160 x 160]
13
        CC[Анализ связных областей<br/>Обход BFS]
14
        BD[Извлечение граничных точек]
15
    end
16

17
    subgraph Geometry["Геометрические вычисления"]
18
        CH[Выпуклая оболочка<br/>Graham Scan]
19
        RR[Вращающиеся калибры<br/>MinAreaRect]
20
        UC[Расширение Unclip<br/>ratio=1.5]
21
    end
22

23
    subgraph Output["Выход"]
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

В реальном коде метод TextDetector::Impl::Detect демонстрирует полный цикл детекции:

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
}

Ключевым моментом здесь является «минимальный ограничивающий повернутый прямоугольник». В отличие от рамок, выровненных по осям (AABB), повернутые прямоугольники могут плотно прилегать к тексту под любым углом, что критично для наклонного текста в естественных сценах.

Unclip: алгоритм расширения текстовых рамок

Области текста, выдаваемые DBNet, обычно немного меньше реального текста, так как сеть обучается на «ядре» текстовой области. Чтобы получить полные границы текста, необходимо выполнить операцию расширения (Unclip) обнаруженного многоугольника.

Математический принцип Unclip основан на обратной операции алгоритма отсечения многоугольников Ватти. Для многоугольника $P$ и расстояния расширения $d$ , расширенный многоугольник $P'$ удовлетворяет условию:

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

Где $A$ — площадь многоугольника, $L$ — периметр, а $r$ — коэффициент расширения (обычно устанавливается равным 1.5).

В postprocess.cpp функция UnclipBox реализует эту логику:

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
}

Эта упрощенная версия предполагает, что текстовая рамка является прямоугольником. Для более сложных многоугольников потребуется полноценная реализация смещения многоугольника с использованием библиотеки Clipper:

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 выбрано упрощенное прямоугольное расширение вместо полного смещения многоугольника. Это обусловлено тем, что:

Большинство текстовых рамок близки к прямоугольным.
Полноценная библиотека Clipper значительно увеличивает размер бинарного файла.
Упрощенная версия работает быстрее.

Распознавание текста: SVTRv2 и CTC-декодирование

Если детекция — это «найти, где текст», то распознавание — это «прочитать, что там написано». Модуль распознавания в PP-OCRv5 основан на SVTRv2 (Scene Text Recognition with Visual Transformer v2) ⁵.

Инновации в архитектуре SVTRv2

SVTRv2 имеет три ключевых улучшения по сравнению с предыдущим поколением SVTR:

1
flowchart TB
2
    subgraph SVTRv2["Архитектура SVTRv2"]
3
        direction TB
4

5
        subgraph Encoder["Визуальный энкодер"]
6
            PE[Patch Embedding<br/>4x4 свертка]
7

8
            subgraph Mixing["Блок смешанного внимания x12"]
9
                LA[Локальное внимание<br/>окно 7x7]
10
                GA[Глобальное внимание<br/>глобальное поле восприятия]
11
                FFN[Feed Forward<br/>MLP]
12
            end
13
        end
14

15
        subgraph Decoder["CTC декодер"]
16
            FC[Полносвязный слой<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

Механизм смешанного внимания: поочередное использование локального внимания (для захвата деталей штрихов) и глобального внимания (для понимания структуры символов). Локальное внимание использует скользящее окно 7x7, что снижает вычислительную сложность с $O(n^2)$ до $O(n \times 49)$ .
Многомасштабное слияние признаков: в отличие от фиксированного разрешения в ViT, SVTRv2 использует разные разрешения карт признаков на разных глубинах, подобно пирамидальной структуре CNN.
Модуль семантического руководства (Semantic Guidance Module): в конце энкодера добавлена легкая семантическая ветка, помогающая модели понимать смысловые связи между символами, а не только визуальные признаки.

Эти улучшения позволяют SVTRv2 достигать точности, сопоставимой с методами на основе Attention, сохраняя при этом простоту CTC-декодирования ⁶.

Почему CTC, а не Attention?

Существует две основные парадигмы распознавания текста:

CTC (Connectionist Temporal Classification): рассматривает распознавание как задачу разметки последовательности, где вывод выровнен по входу.
Attention-based Decoder: использует механизм внимания для генерации вывода по одному символу за раз.

Методы на основе Attention обычно точнее, но CTC — проще и быстрее. Вклад SVTRv2 заключается в том, что за счет улучшения визуального энкодера метод CTC достигает или даже превосходит по точности методы на основе Attention ⁶.

Суть CTC-декодирования заключается в «слиянии дублей» и «удалении пробелов»:

1
flowchart LR
2
    subgraph Input["Вывод модели"]
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["Слияние дублей"]
19
        M["blank, H, blank, e, l, o"]
20
    end
21

22
    subgraph Remove["Удаление пробелов"]
23
        R["H, e, l, o"]
24
    end
25

26
    subgraph Output["Выход"]
27
        O["Helo - Ошибка"]
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

Подождите, здесь проблема. Если исходный текст — “Hello”, две буквы ‘l’ были ошибочно объединены. Решение CTC: вставлять токен blank между повторяющимися символами.

1
Правильное кодирование: [blank, H, e, l, blank, l, o]
2
Результат декодирования: "Hello"

CTC-декодирование с оптимизацией NEON

В PPOCRv5-Android для CTC-декодирования используется Argmax с оптимизацией NEON. В файле 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
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
}

Для Argmax по 18 384 категориям оптимизация NEON дает примерно 3-кратное ускорение.

Математический принцип функции потерь CTC и декодирования

Основная идея CTC: для входной последовательности $X$ и всех возможных путей выравнивания $\pi$ рассчитать вероятность целевой последовательности $Y$ :

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

Где $\mathcal{B}$ — это «функция отображения многие-к-одному», которая переводит путь $\pi$ в выходную последовательность $Y$ (путем слияния дублей и удаления пробелов).

При инференсе мы используем жадное декодирование (Greedy Decoding) вместо полного 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 (индекс 0)
20
        // 2. Сливать последовательно повторяющиеся символы
21
        if (max_idx != 0 && max_idx != prev_idx) {
22
            result += dictionary[max_idx - 1];  // -1, так как blank занимает индекс 0
23
        }
24

25
        prev_idx = max_idx;
26
    }
27

28
    return result;
29
}

Временная сложность жадного декодирования составляет $O(T \times C)$ , где $T$ — количество временных шагов, а $C$ — количество категорий. Для PP-OCRv5 $T \approx 80$ , $C = 18384$ , что требует около 1,5 миллиона сравнений при каждом декодировании. Вот почему оптимизация NEON так важна.

TIP

Beam Search может повысить точность декодирования, но объем вычислений в $k$ раз больше, чем при жадном декодировании ( $k$ — ширина луча). На мобильных устройствах жадное декодирование обычно является лучшим выбором.

Словарь символов: вызов в 18 383 знака

PP-OCRv5 поддерживает 18 383 символа, включая:

Часто используемые иероглифы упрощенного китайского
Часто используемые иероглифы традиционного китайского
Английские буквы и цифры
Японские хирагану и катакану
Распространенные знаки препинания и специальные символы

Этот словарь хранится в файле keys_v5.txt, по одному символу на строку. При CTC-декодировании логиты на выходе модели имеют форму [1, T, 18384], где T — количество временных шагов, а 18384 = 18383 символа + 1 токен blank.

LiteRT C++ API: современный интерфейс после рефакторинга 2024 года

PPOCRv5-Android использует C++ API LiteRT, обновленный в 2024 году. Этот API предлагает более современный дизайн интерфейса. По сравнению с традиционным TFLite C API, новый API обеспечивает лучшую типобезопасность и возможности управления ресурсами.

Сравнение старого и нового API

Рефакторинг LiteRT 2024 принес значительные изменения в API:

Характеристика	Старый API (TFLite)	Новый API (LiteRT)
Пространство имен	`tflite::`	`litert::`
Обработка ошибок	Возврат перечисления `TfLiteStatus`	Возврат типа `Expected<T>`
Управление памятью	Ручное управление	Автоматическое через RAII
Конфигурация Delegate	Разрозненные API	Унифицированный класс `Options`
Доступ к тензорам	Указатели + ручное приведение типов	Типобезопасный `TensorBuffer`

Основное преимущество нового API — типобезопасность и автоматическое управление ресурсами. Пример обработки ошибок:

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);  // Автоматическое управление жизненным циклом

Инициализация окружения и модели

В text_detector.cpp процесс инициализации выглядит так:

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: ключ к zero-copy инференсу

Managed Tensor Buffer в LiteRT — это ключ к высокопроизводительному инференсу. Он позволяет GPU Delegate напрямую обращаться к буферу, исключая передачу данных между CPU и GPU:

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
}

Преимущества такого дизайна:

Zero-copy инференс: GPU Delegate имеет прямой доступ к буферу без копирования данных.
Автоматическое управление памятью: OwnHandle::kYes гарантирует освобождение буфера при деструкции объекта C++.
Типобезопасность: проверка соответствия типов тензоров на этапе компиляции.

Ускорение на GPU: выбор OpenCL и компромиссы

LiteRT предоставляет несколько вариантов аппаратного ускорения:

1
flowchart TB
2
    subgraph Delegates["Экосистема LiteRT Delegate"]
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 Optimized]
8
    end
9

10
    subgraph Hardware["Маппинг на железо"]
11
        direction TB
12
        ADRENO[Adreno GPU<br/>Qualcomm]
13
        MALI[Mali GPU<br/>ARM]
14
        NPU[NPU/DSP<br/>Специфично для вендора]
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

Ускоритель	Бэкенд	Преимущества	Недостатки
GPU	OpenCL	Широкая поддержка, хорошая производительность	Не является стандартным компонентом Android
GPU	OpenGL ES	Стандартный компонент Android	Производительность ниже, чем у OpenCL
NPU	NNAPI	Максимальная производительность	Плохая совместимость между устройствами
CPU	XNNPACK	Максимальная совместимость	Самая низкая производительность

В PPOCRv5-Android в качестве основного бэкенда ускорения выбран OpenCL. Google выпустила бэкенд OpenCL для TFLite в 2020 году, и по сравнению с OpenGL ES он обеспечивает примерно 2-кратное ускорение на GPU Adreno ⁷.

Преимущества OpenCL обусловлены несколькими факторами:

Изначальное предназначение: OpenCL с самого начала проектировался для вычислений общего назначения, в то время как OpenGL — это API для графического рендеринга, в который поддержка вычислительных шейдеров была добавлена позже.
Константная память: константная память OpenCL очень эффективна для доступа к весам нейронных сетей.
Поддержка FP16: OpenCL нативно поддерживает вычисления с половинной точностью, тогда как в OpenGL поддержка появилась позже.

Однако у OpenCL есть существенный недостаток: он не является стандартным компонентом Android. Качество реализации OpenCL у разных вендоров разнится, а некоторые устройства его вовсе не поддерживают.

OpenCL vs OpenGL ES: глубокое сравнение производительности

Чтобы понять преимущества OpenCL, нужно углубиться в архитектуру GPU. Возьмем для примера Qualcomm Adreno 640:

1
flowchart TB
2
    subgraph Adreno["Архитектура Adreno 640"]
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["Иерархия памяти"]
11
            L1[L1 Cache<br/>16KB на SP]
12
            L2[L2 Cache<br/>1MB Shared]
13
            GMEM[Global Memory<br/>LPDDR4X]
14
        end
15

16
        subgraph Special["Специализированные блоки"]
17
            TMU[Texture Unit<br/>Билинейная интерполяция]
18
            CONST[Constant Cache<br/>Ускорение весов]
19
        end
20
    end
21

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

Преимущества производительности OpenCL складываются из:

Характеристика	OpenCL	OpenGL ES Compute
Константная память	Нативная поддержка, аппаратное ускорение	Требует эмуляции через UBO
Размер рабочих групп	Гибкая настройка	Ограничен моделью шейдеров
Барьеры памяти	Тонкий контроль	Грубый контроль
Вычисления FP16	Расширение `cl_khr_fp16`	Требует точности `mediump`
Инструменты отладки	Snapdragon Profiler	Ограниченная поддержка

В сверточных операциях веса обычно являются константами. OpenCL может поместить веса в константную память, используя аппаратную оптимизацию широковещательной передачи (broadcast). OpenGL ES вынужден передавать веса как Uniform Buffer Object (UBO), что увеличивает накладные расходы на доступ к памяти.

NOTE

Начиная с Android 7.0, Google ограничила приложениям прямую загрузку библиотек OpenCL. Однако GPU Delegate в LiteRT обходит это ограничение, динамически загружая системную реализацию OpenCL через dlopen. Именно поэтому GPU Delegate должен проверять доступность OpenCL во время выполнения.

Стратегия грациозной деградации (Fallback)

В PPOCRv5-Android реализована стратегия грациозной деградации:

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
}

Эта стратегия гарантирует работоспособность приложения на любом устройстве, меняется только производительность.

Нативный слой: C++ и оптимизация NEON

Почему C++, а не Kotlin?

Ответ прост: производительность. Предобработка изображений включает в себя огромное количество попиксельных операций, накладные расходы на которые в JVM недопустимы. Что еще важнее, C++ позволяет напрямую использовать инструкции ARM NEON SIMD для векторизации вычислений.

NEON: набор инструкций SIMD для ARM

NEON — это расширение SIMD (Single Instruction, Multiple Data) для процессоров ARM. Оно позволяет одной инструкции обрабатывать сразу несколько элементов данных.

1
flowchart LR
2
    subgraph NEON["128-битный регистр NEON"]
3
        direction TB
4
        F4["4x float32"]
5
        I8["8x int16"]
6
        B16["16x int8"]
7
    end
8

9
    subgraph Operations["Векторные операции"]
10
        direction TB
11
        LD["vld1q_f32<br/>Загрузка 4 float"]
12
        SUB["vsubq_f32<br/>Параллельное вычитание (4 пути)"]
13
        MUL["vmulq_f32<br/>Параллельное умножение (4 пути)"]
14
        ST["vst1q_f32<br/>Сохранение 4 float"]
15
    end
16

17
    subgraph Speedup["Прирост производительности"]
18
        S1["Скаляр: 4 инструкции"]
19
        S2["NEON: 1 инструкция"]
20
        S3["Теоретическое ускорение: 4x"]
21
    end
22

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

PPOCRv5-Android использует оптимизацию NEON на нескольких критических путях. Пример бинаризации (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
    // Скалярный fallback для оставшихся пикселей
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
}

Ключевые точки оптимизации в этом коде:

Пакетная загрузка: vld1q_f32 загружает 4 float за раз, сокращая количество обращений к памяти.
Векторное сравнение: vcgtq_f32 сравнивает 4 значения одновременно, создавая маску.
Сужение типов: vmovn_u32 сжимает 32-битные результаты до 16-битных, а затем до 8-битных.

По сравнению со скалярной реализацией, оптимизация NEON дает ускорение в 3-4 раза ⁸.

Реализация нормализации ImageNet на NEON

Нормализация изображения — важный этап предобработки. Стандартная нормализация ImageNet использует формулу:

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

Где $\mu = [0.485, 0.456, 0.406]$ , $\sigma = [0.229, 0.224, 0.225]$ (каналы RGB).

В image_utils.cpp реализация нормализации с оптимизацией NEON выглядит так:

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 байт)
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
}

Ключевые приемы оптимизации в этом коде:

Предварительный расчет констант: преобразование (x - mean) / std в x * scale + bias для исключения деления во время выполнения.
Fused Multiply-Add: vmlaq_f32 выполняет умножение и сложение за одну инструкцию.
Загрузка с деинтерливингом: vld4q_u8 автоматически разделяет RGBA на четыре канала.
Сохранение с интерливингом: vst3q_f32 записывает три канала RGB в память с чередованием.

Нулевая зависимость от OpenCV

Многие OCR-проекты полагаются на OpenCV для предобработки изображений. OpenCV мощная, но она приносит с собой огромный размер пакета; библиотека OpenCV на Android обычно превышает 10 МБ.

PPOCRv5-Android выбрал путь «нулевой зависимости от OpenCV». Все операции предобработки реализованы на чистом C++ в image_utils.cpp:

Масштабирование билинейной интерполяцией: ручная реализация с поддержкой NEON.
Нормализация: ImageNet и нормализация для распознавания.
Перспективное преобразование: обрезка текстовых областей под любым углом из исходного изображения.

Реализация билинейной интерполяции на NEON

Билинейная интерполяция — основной алгоритм масштабирования изображений. Для координат $(x, y)$ в исходном изображении значение целевого пикселя рассчитывается как:

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

Где $\alpha = x - \lfloor x \rfloor$ , $\beta = y - \lfloor y \rfloor$ , а $f_{ij}$ — значения четырех соседних пикселей.

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

Оптимизация билинейной интерполяции на NEON сложна, так как адреса четырех соседних пикселей не являются непрерывными. Более эффективный метод — раздельная билинейная интерполяция: сначала по горизонтали, затем по вертикали. Это позволяет лучше использовать локальность кэша.

Цена такого выбора — больший объем разработки, но выгода очевидна:

Размер APK уменьшен примерно на 10 МБ.
Полный контроль над логикой предобработки для оптимизации.
Отсутствие проблем с совместимостью версий OpenCV.

Перспективное преобразование: от повернутого прямоугольника к стандартной строке текста

Модель распознавания текста ожидает на входе горизонтальные изображения строк текста. Однако обнаруженные текстовые рамки могут быть повернутыми прямоугольниками под любым углом. Перспективное преобразование отвечает за «выпрямление» области повернутого прямоугольника.

В text_recognizer.cpp метод CropAndRotate реализует эту функцию:

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];  // Координаты (x, y) 4 угловых точек
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
}

Ключевые оптимизации этой реализации:

Адаптивная ширина: динамическая настройка выходной ширины в зависимости от соотношения сторон текстовой рамки во избежание чрезмерного растяжения или сжатия.
Аппроксимация аффинным преобразованием: для текстовых рамок, близких к параллелограммам, используется аффинное преобразование вместо перспективного для снижения объема вычислений.
Билинейная интерполяция на NEON: сэмплирование и нормализация выполняются за один проход, сокращая количество обращений к памяти.

JNI: мост между Kotlin и C++

JNI (Java Native Interface) — это мост для связи между Kotlin/Java и C++. Однако вызовы JNI накладны, и частые межъязыковые вызовы могут серьезно ударить по производительности.

Принцип проектирования PPOCRv5-Android: минимизация количества вызовов JNI. Весь процесс OCR требует только одного вызова JNI:

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
9

10
    Note over N,G: Native-слой выполняет всю работу
11

12
    N->>N: Предобработка изображения NEON
13
    N->>G: Инференс детекции текста
14
    G-->>N: Карта вероятностей
15
    N->>N: Постпроцессинг, детекция контуров
16

17
    loop Каждая текстовая рамка
18
        N->>N: Обрезка с персп. преобр.
19
        N->>G: Инференс распознавания текста
20
        G-->>N: Logits
21
        N->>N: CTC декодирование
22
    end
23

24
    N-->>J: Результаты OCR
25
    J-->>K: List OcrResult

В ppocrv5_jni.cpp основная функция nativeProcess демонстрирует этот подход:

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
}

Такой дизайн исключает накладные расходы на передачу данных туда-сюда между этапами детекции и распознавания.

Архитектура: модульность и тестируемость

Архитектура PPOCRv5-Android следует принципу «разделения ответственности» (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/>Управление состоянием]
11
    end
12

13
    subgraph Native["Native Layer - C++"]
14
        OE[OcrEngine<br/>Оркестрация]
15

16
        subgraph Detection["Детекция текста"]
17
            TD[TextDetector]
18
            DB[DBNet FP16]
19
        end
20

21
        subgraph Recognition["Распознавание текста"]
22
            TR[TextRecognizer]
23
            SVTR[SVTRv2 + CTC]
24
        end
25

26
        subgraph Preprocessing["Обработка изображений"]
27
            IP[ImagePreprocessor<br/>Оптимизация NEON]
28
            PP[PostProcessor<br/>Детекция контуров]
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

Преимущества такой многослойной архитектуры:

Слой UI: чистый Kotlin/Compose, сфокусированный на взаимодействии с пользователем.
Слой ViewModel: управление состоянием и бизнес-логикой.
Нативный слой: высокопроизводительные вычисления, полностью отвязанные от UI.

Каждый слой можно тестировать независимо. Нативный слой — с помощью Google Test, слой ViewModel — с помощью JUnit + MockK.

Инкапсуляция на уровне Kotlin

В OcrEngine.kt слой Kotlin предоставляет лаконичный 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
}

Преимущества такого дизайна:

Использование типа Result для обработки ошибок инициализации.
Реализация интерфейса Closeable, поддержка блоков use для автоматического освобождения ресурсов.
Автоматическое копирование файлов моделей из assets в кэш-директорию.

Оптимизация холодного старта

Первый инференс (холодный старт) обычно проходит значительно медленнее последующих. Это связано с тем, что:

GPU Delegate должен скомпилировать программы OpenCL.
Веса модели должны быть переданы из оперативной памяти в память GPU.
Различные кэши должны быть прогреты.

PPOCRv5-Android смягчает проблему холодного старта через механизм Warm-up:

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
}

Оптимизация выравнивания памяти

В TextDetector::Impl все предварительно выделенные буферы используют выравнивание по 64 байта:

1
// Предварительно выделенные буферы с выравниванием по кэш-линии
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_;

Выравнивание по 64 байта соответствует размеру кэш-линии современных процессоров ARM. Выровненный доступ к памяти позволяет избежать разделения кэш-линий и повышает эффективность работы с памятью.

Пул памяти и повторное использование объектов

Частое выделение и освобождение памяти — убийца производительности. PPOCRv5-Android использует стратегию предварительного выделения, выделяя всю необходимую память один раз при инициализации:

1
class TextDetector::Impl {
2
    // Предварительно выделенные буферы, жизненный цикл совпадает с 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
};

Преимущества такого дизайна:

Избежание фрагментации памяти: все большие блоки памяти выделяются при запуске, фрагментация во время работы исключена.
Сокращение системных вызовов: malloc может вызывать системные вызовы, предварительное выделение избавляет от этих расходов.
Дружелюбность к кэшу: последовательно выделенная память с большей вероятностью будет физически непрерывной, что повышает частоту попаданий в кэш.

Оптимизация предсказания переходов

Современные CPU используют предсказание переходов для повышения эффективности конвейера. Ошибочное предсказание приводит к сбросу конвейера и потере 10-20 тактов.

На «горячих путях» мы используем подсказки компилятору __builtin_expect:

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) сообщает компилятору, что значение expr, скорее всего, будет равно val. Компилятор на основе этого корректирует компоновку кода, вынося «маловероятные» ветки подальше от основного пути выполнения.

Развертывание циклов и программный конвейер

Для циклов с интенсивными вычислениями ручное развертывание может снизить накладные расходы цикла и открыть больше возможностей для параллелизма на уровне инструкций:

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
}

После развертывания CPU может одновременно выполнять несколько независимых инструкций умножения-сложения, максимально используя несколько исполнительных блоков суперскалярной архитектуры.

Оптимизация Prefetch

Во внутреннем цикле перспективного преобразования используйте __builtin_prefetch для предварительной загрузки данных следующей строки:

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
}

Эта оптимизация позволяет скрыть задержки памяти: пока обрабатывается текущая строка, данные следующей уже подгружаются в кэш L1.

Инженерные детали постпроцессинга

Анализ связных областей и детекция контуров

В postprocess.cpp функция FindContours реализует эффективный анализ связных областей:

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
}

Ключевые точки оптимизации:

4x даунсэмплинг: уменьшение бинарной карты 640x640 до 160x160 сокращает объем вычислений в 16 раз.
Детекция границ: сохранение только граничных пикселей вместо всей связной области.
Ограничение максимального количества контуров: kMaxContours = 100 для предотвращения проблем с производительностью в экстремальных случаях.

Выпуклая оболочка и алгоритм вращающихся калибров

Расчет минимального ограничивающего повернутого прямоугольника состоит из двух этапов: сначала вычисляется выпуклая оболочка, затем с помощью алгоритма вращающихся калибров находится прямоугольник с минимальной площадью.

Алгоритм Graham Scan для выпуклой оболочки

Graham Scan — классический алгоритм вычисления выпуклой оболочки со сложностью $O(n \log n)$ :

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

4
    // 1. Поиск самой нижней точки (min y, затем min 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
                // При коллинеарности более близкая точка идет первой
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) обходит каждое ребро выпуклой оболочки, вычисляя площадь ограничивающего прямоугольника с основанием на этом ребре:

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
}

Ключевое озарение алгоритма вращающихся калибров в том, что при вращении основания три «калибра» (самая правая, верхняя и левая точки) будут двигаться только вперед, не возвращаясь назад. Таким образом, общая временная сложность составляет $O(n)$ , а не $O(n^2)$ .

Минимальный ограничивающий повернутый прямоугольник

Функция MinAreaRect использует алгоритм вращающихся калибров для вычисления минимального ограничивающего повернутого прямоугольника:

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
}

Временная сложность этого алгоритма составляет $O(n \log n)$ (выпуклая оболочка) + $O(n)$ (вращающиеся калибры), где $n$ — количество граничных точек. Ограничение $n$ до 200 с помощью субсэмплинга гарантирует производительность в реальном времени.

Камера OCR в реальном времени: CameraX и анализ кадров

Вызов OCR в реальном времени заключается в следующем: как обеспечить плавное превью и при этом максимально быстро обрабатывать каждый кадр?

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["Процесс анализа кадров"]
10
        direction TB
11
        IP[ImageProxy<br/>YUV_420_888]
12
        BM[Конвертация Bitmap<br/>RGBA_8888]
13
        JNI[Вызов JNI<br/>Один межъязыковой вызов]
14
    end
15

16
    subgraph Native["Нативный OCR"]
17
        direction TB
18
        DET[TextDetector<br/>~45ms GPU]
19
        REC[TextRecognizer<br/>~15ms/строка]
20
        RES[Результаты OCR]
21
    end
22

23
    subgraph UI["Обновление UI"]
24
        direction TB
25
        VM[ViewModel<br/>StateFlow]
26
        OV[ResultOverlay<br/>Отрисовка на 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 в CameraX

CameraX — это библиотека камер из Jetpack, предоставляющая кейс ImageAnalysis, который позволяет нам анализировать кадры камеры в реальном времени:

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
}

Ключевая настройка — STRATEGY_KEEP_ONLY_LATEST: если анализатор не успевает за частотой кадров камеры, старые кадры отбрасываются, сохраняется только последний. Это гарантирует актуальность результатов OCR.

Баланс между частотой кадров и задержкой

На устройствах с GPU-ускорением (у моего Snapdragon 870, похоже, есть проблемы, он не всегда может переложить большую часть вычислений на GPU) PPOCRv5-Android теоретически может достигать высокой скорости обработки. Но это не значит, что мы должны обрабатывать каждый кадр.

Рассмотрим сценарий: пользователь наводит камеру на текст, содержимое которого не меняется в течение короткого времени. Если мы будем выполнять полный цикл OCR на каждом кадре, мы впустую потратим вычислительные ресурсы.

Одной из стратегий оптимизации является «детектирование изменений»: OCR запускается только тогда, когда изображение в кадре значительно изменилось. Это можно реализовать путем сравнения гистограмм или характерных точек последовательных кадров.

Перспективы: NPU и квантование

Будущее мобильного ИИ за NPU (Neural Processing Unit). По сравнению с GPU, NPU специально спроектирован для инференса нейронных сетей и обладает более высокой энергоэффективностью.

Однако проблемой NPU является фрагментация. У каждого производителя чипов своя архитектура NPU и SDK:

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

Android NNAPI (Neural Networks API) пытается предоставить унифицированный уровень абстракции, но реальные результаты разнятся. Многие функции NPU не раскрываются через NNAPI, и разработчикам приходится использовать специфические SDK вендоров.

Квантование INT8: незавершенная битва

Квантование FP16 — консервативный выбор, почти не теряющий в точности. Но если стремиться к экстремальной производительности, следующим шагом будет квантование INT8.

Квантование INT8 сжимает веса и активации с 32-битных чисел с плавающей запятой до 8-битных целых чисел, что теоретически дает:

4-кратное сжатие модели.
2-4-кратное ускорение инференса (в зависимости от железа).
На Qualcomm Hexagon DSP возможно ускорение более чем в 10 раз.

Это искушение слишком велико. Так я начал долгое путешествие в мир квантования INT8.

Первая попытка: калибровка на синтетических данных

Квантование INT8 требует набора данных для калибровки, чтобы определить параметры квантования (Scale и Zero Point). Сначала я поленился и использовал случайно сгенерированные изображения, имитирующие текст:

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

Результат был катастрофическим. Вывод модели состоял из одних нулей:

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

Инструмент квантования рассчитал неверные параметры на основе случайного шума, что привело к отсечению значений активации реальных изображений.

Вторая попытка: калибровка на реальных изображениях

Я перешел на реальные изображения из датасетов OCR: ICDAR2015, TextOCR, официальные примеры PaddleOCR. Также я реализовал предобработку Letterbox, чтобы распределение изображений при калибровке соответствовало инференсу:

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
    # ... вставка по центру

Модель перестала выдавать одни нули, но результаты распознавания все равно оставались «абракадаброй».

Третья попытка: исправление обработки типов на стороне C++

Я обнаружил проблему в коде C++ при обработке входных данных INT8. Модель INT8 ожидает исходные значения пикселей (0-255), а я все еще выполнял нормализацию ImageNet (вычитание среднего и деление на отклонение).

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
}

Параллельно я реализовал логику динамического чтения параметров квантования вместо их жесткого кодирования:

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

Итоговый результат: компромисс

После нескольких дней отладки модель INT8 так и не заработала должным образом. Проблема могла заключаться в:

Реализации квантования в onnx2tf: PP-OCRv5 использует специфические комбинации операторов, которые onnx2tf мог некорректно обработать при квантовании.
Характеристиках вывода DBNet: DBNet выдает карту вероятностей со значениями от 0 до 1, а квантование INT8 крайне чувствительно к таким малым диапазонам.
Накоплении ошибок многостадийной модели: детекция и распознавание соединены последовательно, и ошибки квантования накапливаются и усиливаются.

Давайте подробнее разберем второй пункт. Вывод DBNet проходит через активацию Sigmoid, сжимая диапазон до [0, 1]. Квантование INT8 использует формулу:

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

Для значений в диапазоне [0, 1], если scale установлен неверно, квантованные значения могут занять лишь малую часть диапазона INT8 [-128, 127], что приведет к серьезной потере точности.

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  # Потеря точности!

Порог DBNet обычно устанавливается на уровне 0.1-0.3. Это означает, что огромное количество значимых вероятностей (0.1-0.3) после квантования будет представлено всего 25 целыми числами (от 13 до 38), чего явно недостаточно для высокого разрешения.

WARNING

Квантование INT8 для PP-OCRv5 — известная сложная задача. Если вы тоже пробуете это сделать, рекомендую сначала убедиться, что модель FP32 работает корректно, а затем постепенно исключать проблемы квантования. Или рассмотрите возможность использования официального фреймворка Paddle Lite, который лучше поддерживает PaddleOCR.

Квантование с учетом обучения: правильное решение

Если использование INT8 необходимо, правильным методом будет квантование с учетом обучения (Quantization-Aware Training, QAT), а не пост-тренировочное квантование (Post-Training Quantization, PTQ).

QAT имитирует ошибки квантования в процессе обучения, заставляя модель адаптироваться к представлению данных с низкой точностью:

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
# Обычное обучение, но с узлами имитации квантования в forward pass
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)

К сожалению, официальная команда PP-OCRv5 не предоставила моделей, обученных с QAT. Это означает, что для получения качественной модели INT8 потребуется проводить QAT-обучение с нуля, что выходит за рамки данного проекта.

В итоге я выбрал компромисс: использование квантования FP16 + ускорение на GPU вместо INT8 + DSP.

Цена этого решения:

Размер модели в 2 раза больше, чем у INT8.
Невозможность использовать сверхнизкое энергопотребление Hexagon DSP.
Скорость инференса в 2-3 раза ниже теоретического оптимума.

Но выгода в том, что:

Точность модели практически идентична FP32.
Срок разработки значительно сокращен.
Сложность кода снижена.

Суть инженерии — в балансе. Иногда «достаточно хорошее» важнее «теоретически оптимального».

Заключение

От PaddlePaddle до LiteRT, от DBNet до SVTRv2, от OpenCL до NEON — инженерная практика OCR на мобильных устройствах охватывает знания в области глубокого обучения, компиляторов, программирования GPU, мобильной разработки и многого другого.

Главный урок этого проекта: мобильный ИИ — это не просто «засунуть модель в телефон». Это требует:

Глубокого понимания архитектуры модели для корректной конвертации.
Знания особенностей «железа» для полноценного использования ускорителей.
Владения системным программированием для реализации высокопроизводительного нативного кода.
Внимания к пользовательскому опыту для поиска баланса между производительностью и энергопотреблением.

PPOCRv5-Android — это проект с открытым исходным кодом, который демонстрирует, как развернуть современные модели OCR в реальных мобильных приложениях. Надеюсь, эта статья станет полезным справочником для разработчиков с похожими задачами.

Как сказали в Google при запуске LiteRT: «Maximum performance, simplified.» ⁹ Цель мобильного ИИ — не усложнять, а делать сложное простым.

Послесловие

Честно говоря, я (как в работе, так и в хобби) отошел от Android как минимум на два года. И это мой первый случай публикации зрелой библиотеки на моем «твинке» в GitHub (основной аккаунт я передал коллегам в знак решимости уйти).

В последние годы фокус моей работы был смещен с Android. Не могу раскрывать детали, но когда-нибудь, возможно, расскажу подробнее. В общем, мне, вероятно, будет трудно достичь новых высот в Android-разработке.

Выпуск этого проекта обусловлен моим личным интересом — я создаю ранний инструмент для Android, работающий на устройстве, и OCR — лишь малая часть его нижнего слоя. Позже (надеюсь, скоро) я полностью открою его исходный код, но пока не могу раскрывать подробности.

В любом случае, спасибо, что дочитали до конца. Буду рад, если вы поставите Star моему репозиторию. Спасибо!

Список литературы

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

# Практика OCR на устройствах: нативное развертывание PP-OCRv5 на Android

Примечания

Введение

Конвертация модели: долгий путь от PaddlePaddle до TFLite

Первое препятствие: совместимость операторов в paddle2onnx

Второе препятствие: HardSigmoid и совместимость с GPU

Третье препятствие: режим трансформации координат оператора Resize

Последний шаг: onnx2tf и квантование FP16

Детекция текста: дифференцируемая бинаризация DBNet

Стандартная бинаризация vs Дифференцируемая бинаризация

Инженерная реализация процесса постпроцессинга

Unclip: алгоритм расширения текстовых рамок

Распознавание текста: SVTRv2 и CTC-декодирование

Инновации в архитектуре SVTRv2

Почему CTC, а не Attention?

CTC-декодирование с оптимизацией NEON

Математический принцип функции потерь CTC и декодирования

Словарь символов: вызов в 18 383 знака

LiteRT C++ API: современный интерфейс после рефакторинга 2024 года

Сравнение старого и нового API

Инициализация окружения и модели

Managed Tensor Buffer: ключ к zero-copy инференсу

Ускорение на GPU: выбор OpenCL и компромиссы

OpenCL vs OpenGL ES: глубокое сравнение производительности

Стратегия грациозной деградации (Fallback)

Нативный слой: C++ и оптимизация NEON

NEON: набор инструкций SIMD для ARM

Реализация нормализации ImageNet на NEON

Нулевая зависимость от OpenCV

Реализация билинейной интерполяции на NEON

Перспективное преобразование: от повернутого прямоугольника к стандартной строке текста

JNI: мост между Kotlin и C++

Архитектура: модульность и тестируемость

Инкапсуляция на уровне Kotlin

Оптимизация холодного старта

Оптимизация выравнивания памяти

Пул памяти и повторное использование объектов

Оптимизация предсказания переходов

Развертывание циклов и программный конвейер

Оптимизация Prefetch

Инженерные детали постпроцессинга

Анализ связных областей и детекция контуров

Выпуклая оболочка и алгоритм вращающихся калибров

Алгоритм Graham Scan для выпуклой оболочки

Алгоритм вращающихся калибров

Минимальный ограничивающий повернутый прямоугольник

Камера OCR в реальном времени: CameraX и анализ кадров

ImageAnalysis в CameraX

Баланс между частотой кадров и задержкой

Перспективы: NPU и квантование

Квантование INT8: незавершенная битва

Первая попытка: калибровка на синтетических данных

Вторая попытка: калибровка на реальных изображениях

Третья попытка: исправление обработки типов на стороне C++

Итоговый результат: компромисс

Квантование с учетом обучения: правильное решение

Заключение

Послесловие

Список литературы

Footnotes