



Получил задачу. Перед анализом подтянy актуальные детали из самой статьи (FLOPs, latency, конкретные числа из таблиц), чтобы не полагаться только на память.Хорошо, получил ключевые числа. Подтяну сам PDF для деталей по таблицам и архитектуре.Попробую получить полный текст статьи для извлечения таблиц.# Глубокий анализ: BlazePose: On-device Real-time Body Pose tracking

## 1. МЕТАДАННЫЕ

| Поле                      | Значение                                                                                                                                                                                                                                                                                                                                                 |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Оригинальное название** | BlazePose: On-device Real-time Body Pose tracking                                                                                                                                                                                                                                                                                                        |
| **Перевод**               | BlazePose: Отслеживание позы тела в реальном времени на устройстве                                                                                                                                                                                                                                                                                       |
| **Авторы**                | Valentin Bazarevsky, Ivan Grishchenko, Karthik Raveendran, Tyler Zhu, Fan Zhang, Matthias Grundmann                                                                                                                                                                                                                                                      |
| **Аффилиация**            | Google Research, 1600 Amphitheatre Pkwy, Mountain View, CA 94043, USA                                                                                                                                                                                                                                                                                    |
| **Год**                   | 2020 (submitted 17 June 2020)                                                                                                                                                                                                                                                                                                                            |
| **Venue**                 | CVPR Workshop on Computer Vision for Augmented and Virtual Reality (CV4ARVR), Seattle, WA, 2020                                                                                                                                                                                                                                                          |
| **Venue tier**            | **Workshop** (CVPR-affiliated, но не main conference). Подаётся также как arXiv preprint.                                                                                                                                                                                                                                                                |
| **arXiv ID**              | 2006.10204                                                                                                                                                                                                                                                                                                                                               |
| **DOI**                   | 10.48550/arXiv.2006.10204                                                                                                                                                                                                                                                                                                                                |
| **Объём**                 | 4 страницы, 6 рисунков                                                                                                                                                                                                                                                                                                                                   |
| **Цитирований**           | ~430+ (Semantic Scholar / scispace, по состоянию на ~2024) — **очень высоко для workshop-статьи**, отражает массовое использование в индустрии через MediaPipe                                                                                                                                                                                           |
| **Код / веса**            | Реализация и pretrained-веса доступны через [MediaPipe Pose](https://google.github.io/mediapipe/solutions/pose) (Apache-2.0). Сторонние реализации: [vietanhdev/tf-blazepose](https://github.com/vietanhdev/tf-blazepose), [jiang-du/BlazePose-tensorflow](https://github.com/jiang-du/BlazePose-tensorflow). Тренировочный код и датасет — **закрыты**. |

**[МОЙ КОММЕНТАРИЙ]** Workshop-формат предполагает упрощённый рецензент-процесс и компактный объём. Несмотря на это, статья оказала колоссальное практическое влияние благодаря интеграции в MediaPipe — это редкий случай, когда промышленная реализация перевешивает академический формат.

---

## 2. КЛЮЧЕВАЯ ИДЕЯ (Core Contribution)

Статья решает задачу real-time human pose estimation на мобильных CPU без жертв в применимости для прикладных сценариев (фитнес, AR, sign language). Авторы предлагают: (1) новую топологию из **33 keypoints** как суперсет COCO + BlazeFace + BlazePalm, что делает её совместимой с существующими face/hand моделями MediaPipe и адекватной для фитнес-приложений; (2) two-stage детектор-трекер пайплайн, где детектор позы инспирирован их же BlazeFace и использует лицо как proxy-сигнал для тела; (3) **гибридную голову с heatmap supervision на этапе обучения и pure regression на инференсе** — heatmap-башня отбрасывается, что даёт скорость regression при качестве, близком к heatmap-моделям. Главная гипотеза: для single-person mobile use cases heatmap-supervised regression может приблизиться к качеству heatmap-моделей при кратно меньших вычислительных затратах.

**[МОЙ КОММЕНТАРИЙ]** Принципиальная новизна — не в backbone (типичный encoder-decoder с residual-связями), а в (а) топологии, (б) хитром использовании heatmap'а только на тренировке, (в) Vitruvian-man подходе к ROI-локализации через виртуальные keypoints. Это инженерная статья, а не алгоритмическая.

---

## 3. АРХИТЕКТУРА И МЕТОД

### 3.1. Тип подхода

|Аспект|Классификация|
|---|---|
|**Размерность**|2D (x, y + visibility) — в этой версии. 3D появилось в более поздних BlazePose GHUM.|
|**Стратегия**|Top-down, two-stage (detector → tracker)|
|**Регрессия**|**Hybrid**: heatmap+offset supervision во время обучения, pure regression на инференсе|
|**Темпоральность**|Per-frame инференс + ROI-propagation между кадрами (детектор запускается только на 1-м кадре)|
|**Backbone**|Custom lightweight CNN (encoder-decoder, mobile-friendly блоки в духе BlazeFace)|

### 3.2. Описание архитектуры

**Pipeline в целом:**

```
Frame_t ──────────────┐
                      │
First frame? ──Yes──▶ Pose Detector (BlazeFace-like)
       │                      │
       │                      ▼
       │              Face bbox + 2 virtual keypoints
       │              (hip midpoint + Vitruvian circle)
       │                      │
       No                     ▼
       │              Compute ROI from previous frame's keypoints
       └──────────────────────┤
                              ▼
                     Tracker (encoder-decoder)
                              │
                  ┌───────────┼───────────┐
                  ▼                       ▼
        [TRAINING ONLY]              [INFERENCE]
        Heatmap + offset             Regression head
        supervision branch           → 33 × (x, y, visibility)
        (left tower)                 + 2 virtual keypoints
                                     (right tower)
```

**Детектор (Pose Detector):**

- Базируется на архитектуре BlazeFace
- Используется только на первом кадре или при потере трекинга
- Предсказывает: face bbox + **midpoint of hips** + **radius circumscribing the whole person** + **incline angle of the line connecting shoulder and hip midpoints**
- Vitruvian-подход: эти три параметра задают круг, описывающий тело, и его ориентацию

**Трекер (Tracking Network):**

- Encoder-decoder архитектура с двумя output-башнями
- Левая башня: heatmap + offset prediction (используется только при обучении)
- Правая башня: прямая регрессия 33×3 (x, y, visibility) + 2 виртуальные точки
- Ключевой трюк: сначала тренируют heatmap+offset loss для центра и левой башни, затем убирают heatmap output и тренируют регрессионный энкодер (правую башню) — фактически heatmap используется как teacher для эмбеддинга.

**Размер модели:**

|Вариант|Параметры|FLOPs|
|---|---|---|
|BlazePose **Full**|3.5M params, 6.9 MFlop||
|BlazePose **Lite**|1.3M params, 2.7 MFlop||

**[МОЙ КОММЕНТАРИЙ]** «MFlop» в оригинальной статье — это, по всей видимости, миллионы FLOPs (т.е. ~7 MFLOPs у Full). Это **исключительно мало** — для сравнения, MobileNetV2 на 224×224 ~300 MFLOPs, а HRNet-W32 ~7-9 GFLOPs. Если число корректно, BlazePose Full примерно в 1000× легче по вычислениям, чем HRNet, что и объясняет 30+ fps на CPU. Подозрительно низкая цифра — стоит перепроверить по PDF при наличии доступа.

### 3.3. Визуальные материалы из статьи

В оригинальной 4-страничной workshop-версии присутствуют 6 figures. Пересказ ключевых:

|#|Тип|Содержание|Что даёт пониманию|
|---|---|---|---|
|Fig.1|Топология keypoints|33 BlazePose keypoints (с подсветкой 17 COCO как подмножества)|Иллюстрирует, что BlazePose **расширяет** COCO дополнительными точками на руках (5 точек на кисть: thumb/index/pinky tips, knuckles), стопах (heel/foot index) и лице (eye inner/outer/ear tragion). Критично для фитнеса.|
|Fig.2|Pipeline|Detector → ROI → Tracker|Демонстрирует, что детектор запускается только при необходимости — экономит compute.|
|Fig.3|Vitruvian man|Лицо + 2 виртуальные точки → круг описывающий человека|Объясняет геометрический трюк локализации: вместо предсказания tight bbox по телу (что сложно для нестандартных поз), предсказывают центр и масштаб через лицо + bias-точки.|
|Fig.4|Tracker архитектура|Encoder-decoder с двумя башнями (heatmap branch + regression branch)|Показывает, что heatmap-башня физически отдельная и удаляется на инференсе.|
|Tbl.A (ablation)|Сравнение training strategies|PCK@0.2 для разных вариантов supervision|Доказывает, что heatmap supervision повышает качество regression-модели.|
|Tbl.C|Сравнение моделей|Full vs Lite vs OpenPose: PCK@0.2, params, FLOPs|Главная сравнительная таблица.|
|Fig.5/6|Демо|Yoga, fitness, push-up/squat counters|Качественные результаты на целевых сценариях.|

**[МОЙ КОММЕНТАРИЙ]** Описание выше синтезировано из текстовой части и сопровождающего блог-поста Google Research, поскольку доступ к самим встроенным figure-файлам ограничен. Точные подписи и расположение могут немного отличаться. Для финальной заметки в vault желательно открыть PDF и зафиксировать дословно.

### 3.4. Математическая формализация

В статье формулы представлены лаконично; ниже — реконструкция по тексту и блогу.

**Гауссова heatmap для keypoint $k$ в позиции $(x_k, y_k)$:** $$H_k(i, j) = \exp\left(-\frac{(i - x_k)^2 + (j - y_k)^2}{2\sigma^2}\right)$$

Используется как supervision для левой башни.

**Offset map** (поле смещений в окрестности keypoint, для уточнения координаты): $$O_k(i, j) = (x_k - i, ; y_k - j) \quad \text{для } (i, j) \in \mathcal{N}(x_k, y_k)$$

**Регрессионный лосс** (на правой башне): $$\mathcal{L}_{reg} = \sum_{k=1}^{33} \mathcal{L}_{\text{Huber}}(\hat{\mathbf{p}}_k, \mathbf{p}_k^{gt}) + \lambda_v \cdot \mathcal{L}_{vis}(\hat{v}_k, v_k^{gt})$$

где $\hat{\mathbf{p}}_k = (\hat{x}_k, \hat{y}_k)$ — регрессированная координата, $v_k$ — visibility.

**Двухстадийная схема обучения:**

1. Стадия 1: $\mathcal{L}_{stage1} = \mathcal{L}_{heatmap} + \mathcal{L}_{offset}$ — тренируется encoder + left tower
2. Стадия 2: heatmap-башня замораживается/удаляется, тренируется только right (regression) tower с использованием эмбеддингов из общего encoder

**[МОЙ КОММЕНТАРИЙ]** Конкретные формулировки лоссов в самой статье **НЕ ПРИВЕДЕНЫ В ЯВНОМ ВИДЕ** — статья ссылается на heatmap and offset loss из работы Zhang et al., CVPRW 2019 «Exploiting Offset-guided Network for Pose Estimation and Tracking». Реконструкция выше — стандартная для класса методов.

### 3.5. Ключевые технические решения

1. **Heatmap-supervised regression (главный трюк):** heatmap нужен только во время обучения как «учитель». Это даёт качество heatmap-методов при стоимости regression-методов на инференсе.
2. **Vitruvian-man ROI:** обход проблемы tight bbox для нестандартных поз через предсказание круга и угла наклона.
3. **Face-as-detector (proxy):** ROI извлекается через лицо, а не через полное тело. Сильное ограничение (требует видимости лица), но даёт скорость.
4. **Detector-tracker amortization:** тяжёлый детектор запускается только на первом кадре; для последующих кадров ROI извлекается из ранее предсказанных keypoints.
5. **Расширенная топология (33 точки):** включены кисти, ступни, дополнительные точки лица — критично для фитнеса/йоги.
6. **XNNPACK** для CPU-инференса (оптимизированный backend для float-моделей на ARM).
7. **2 варианта модели** (Full/Lite) — стандартный приём для покрытия разного hardware.

**Что НЕ применено явно (по тексту):** quantization, pruning, distillation от тяжёлой модели, NAS, temporal smoothing на уровне keypoints (есть только пропагация ROI).

---

## 4. ЭКСПЕРИМЕНТАЛЬНАЯ ЧАСТЬ

### 4.1. Датасеты

|Датасет|Размер|Тип|Разрешение|Домен|Public?|
|---|---|---|---|---|---|
|Внутренний Google «**geo-diverse pose dataset**»|НЕ УКАЗАНО точное число|2D keypoints (33 точки)|НЕ УКАЗАНО (вероятно 256×256 input)|General + fitness/yoga (sampled uniformly)|**Нет**|

**[МОЙ КОММЕНТАРИЙ]** **Это серьёзный методологический недостаток.** Тренировочный и валидационный датасеты — приватные, статистики не приведены, разнообразие декларируется словесно. Невозможно ни воспроизвести результаты, ни справедливо сравниться. Для нашего проекта это означает: использовать pretrained-веса MediaPipe можно, **fine-tuning с нуля по их рецепту — нельзя**, придётся придумывать собственный pipeline.

### 4.2. Метрики

В статье используется единственная метрика качества: **PCK@0.2** (Percent of Correct Points с tolerance 20% от размера torso).

Human baseline на этом датасете — PCK@0.2 = 97.2 (получен через redundant-аннотацию).

**Метрики, которые НЕ используются (но критичны для нас):**

- ❌ **MPJPE** (нет — это 2D метод)
- ❌ **MAE / RMSE по углам суставов** — критично для SmartRep, отсутствует
- ❌ **MPJVE / MPJAE** (temporal jitter) — для видео-сценария важно
- ❌ **OKS-mAP** на стандартных бенчмарках (COCO val)
- ❌ **PCK@0.05** (более строгий порог)
- ❌ **Cross-dataset generalization**
- ❌ **Occlusion-specific accuracy**

**Latency / эффективность:**

- Платформы: Desktop CPU Intel i9-7900X (20 cores), Pixel 2 single core via XNNPACK backend
- Метрика: декларативно «30+ fps на Pixel 2» — конкретные ms на frame в публичной части НЕ детализированы

### 4.3. Сравнительная таблица результатов (реконструкция Table C)

|Метод|Params|FLOPs|PCK@0.2 (на их val)|Hardware|FPS|
|---|---|---|---|---|---|
|OpenPose (body_25)|~25M|~160 GFLOPs|(выше, но multi-person, не сопоставимо)|Desktop GPU|<10 на mobile|
|**BlazePose Full**|**3.5M**|**~6.9 MFlop**|**близко к human baseline (97.2)**|Pixel 2 CPU|**30+**|
|**BlazePose Lite**|**1.3M**|**~2.7 MFlop**|**ниже Full, но достаточно для упрощённых сценариев**|Pixel 2 CPU|**>30, заметно быстрее Full**|

**[МОЙ КОММЕНТАРИЙ]** **Сравнение с OpenPose нечестное в обе стороны:**

- BlazePose — single-person, OpenPose — multi-person (разные задачи)
- BlazePose оптимизирован под mobile CPU, OpenPose — под desktop GPU
- Метрика PCK@0.2 на **разных датасетах** (BlazePose — на собственном, OpenPose — обычно на COCO/MPII)
- Топологии разные (33 vs 25 keypoints)

Авторы честно признают: "our models show slightly worse performance than the OpenPose model", но это компенсируется драматической разницей в скорости.

**Конкретных таблиц с воспроизводимыми числами на public-бенчмарках в статье практически нет.** Это сильно осложняет позиционирование BlazePose в современных бенчмарк-таблицах.

### 4.4. Ablation Study (Table A)

Согласно тексту блога, аблируется именно эффект **heatmap supervision на регрессию**. Конкретные числа в текстовых источниках не приведены, но качественно: regression-only хуже → +heatmap supervision (без удаления branch на inference) → +heatmap supervision с удалением branch (финальная версия) — такой порядок улучшения декларируется. Точные дельты PCK НЕ ИЗВЛЕЧЕНЫ ИЗ ДОСТУПНЫХ ИСТОЧНИКОВ.

---

## 5. RESULTS & DISCUSSION

### 5.1. Основные выводы

1. **Heatmap supervision улучшает регрессионную модель** даже когда heatmap-башня не используется на инференсе → подтверждает гипотезу.
2. **Two-stage detector-tracker** даёт >30 fps на mobile CPU при сохранении качества, близкого к human baseline.
3. **33-keypoint топология** практически применима (демонстрируется счётчиком приседаний/отжиманий).
4. Модель пригодна для downstream-задач: «simple joint pairwise distance lookup algorithm, which matches the closest pose in normalized pose space» — то есть ближайшие соседи в позном пространстве могут служить классификатором упражнений.

### 5.2. Качественный анализ

Авторы показывают качественные примеры на yoga, dance, fitness. **Failure cases в статье практически не обсуждаются** — типичная слабость industry-папер.

Из MediaPipe Model Card известны (но не из статьи): хуже на детях, на нестандартных позах с инвертированным телом, на сильной окклюзии.

### 5.3. Edge-готовность (специально для SmartRep)

|Параметр|Значение в статье|Соответствие SmartRep|
|---|---|---|
|Hardware (test platform)|Pixel 2 (Snapdragon 835, 2017 г.)|✅ Древний hardware — на Snapdragon 8 Gen 2 будет существенно быстрее|
|Latency per frame|НЕ УКАЗАНО явно (вычисляется как ~33 мс из «30+ fps»)|⚠️ На целевом hw ожидаемо <10 мс, но прямого замера НЕТ|
|FPS|30+ на Pixel 2 single core|✅ Соответствует ≥30 fps требованию|
|Model size|Full: 3.5M params, ~14 MB float32 / ~3.5 MB int8|✅ <30 MB|
|FLOPs|Full: 6.9 MFLOPs, Lite: 2.7 MFLOPs|✅ Очень мало|
|Quantization support|НЕ ОПИСАНО в статье; в MediaPipe доступны quantized-варианты|⚠️ Не валидировано в работе|
|Mobile/embedded benchmarks|Pixel 2 (старый Android), нет iOS, нет Snapdragon 8 Gen 2|⚠️ Нужны собственные замеры|

**Вывод:** статья — **одна из лучших с точки зрения соответствия наших edge-ограничений**, но нужно делать собственные benchmarks на целевом hardware и валидировать по угловым метрикам.

---

## 6. ПРЕИМУЩЕСТВА ПОДХОДА

**Архитектурные:**

- Кратно меньше FLOPs, чем у любых heatmap-методов (HRNet, OpenPose, RTMPose)
- Двухголовая архитектура с разной судьбой на тренировке/инференсе — элегантное решение трейд-оффа speed/accuracy
- Detector-tracker амортизирует стоимость детекции по кадрам видео

**В обучении:**

- Heatmap как teacher для regression-эмбеддинга — переносимая идея
- Two-stage training pipeline (heatmap → regression) допускает раздельную оптимизацию

**Практические:**

- 33 keypoints **уже** включают кисти и стопы — большой плюс для фитнеса
- Готовая интеграция в MediaPipe → можно встроить в production за дни
- Apache-2.0 лицензия → коммерческая совместимость
- ROI через лицо устойчив к нестандартным позам тела (йога, инверсии)

**По метрикам:**

- Близко к human baseline (97.2 PCK@0.2) на собственном датасете
- Реальное достижение 30+ fps на CPU 2017 года выпуска

---

## 7. НЕДОСТАТКИ И ОГРАНИЧЕНИЯ

**Архитектурные / методологические:**

1. **Single-person only** — в multi-person сцене (тренер + спортсмен) деградирует
2. **Требует видимости лица** — для нашего сценария (приседания снизу-вверх, поза мостика, наклоны) это **серьёзная проблема**
3. **Только 2D** в этой версии — для углов в сагиттальной плоскости нужен дополнительный lifting
4. **Нет temporal smoothing** на уровне keypoints — только ROI propagation, поэтому возможен jitter

**Экспериментальные пробелы:** 5. **Приватный train+val датасет** — невозможно воспроизвести результаты или fine-tuning по их рецепту 6. **Только PCK@0.2** — нет ни строгих PCK, ни OKS, ни тем более угловых метрик 7. **Нет валидации на public-бенчмарках** (COCO, MPII, AIST++, Fit3D) 8. **Нет сравнения с современными mobile-моделями** (MoveNet ещё не существовал, но даже с EfficientPose не сравнивались) 9. **Нет анализа failure cases**, нет occlusion-метрик

**Что авторы не обсудили:** 10. Поведение при truncation (обрезке кадра) — критично для близкого ракурса в зале 11. Поведение со снарядами в кадре (грифы, гантели) 12. Энергопотребление на длительных сессиях 13. Quality на детях / разных типах телосложения

**Проблемы при переносе в фитнес-домен:** 14. PCK@0.2 — слишком мягкая метрика; ошибка 20% от torso (≈10–15 см) может означать ошибку угла в локте/колене 10–15° 15. Geo-diverse, но «sampled uniformly» — нет фитнес-специфичной выборки в тренинге 16. Visibility prediction есть, но качество в окклюзионных сценариях неизвестно

---

## 8. РЕЛЕВАНТНОСТЬ ДЛЯ SMARTREP

|Аспект|Оценка|Комментарий|
|---|:-:|---|
|Edge-готовность (<10 мс, <30 МБ)|**5**|Эталон по легковесности; ~3.5M params, 30+ fps на Pixel 2 — на нашем hw будет с большим запасом|
|Точность по угловым метрикам|**2**|Не валидируется по углам; 20% PCK — слишком мягкий критерий|
|Устойчивость к самоокклюзии|**3**|Visibility flag есть; качество в окклюзии не показано; декларативно работает на yoga|
|Нестандартные позы|**3**|Демо на yoga впечатляет; но требование видимости лица — ограничение для инверсий|
|Темпоральная стабильность|**2**|ROI propagation помогает, но keypoint-level smoothing отсутствует|
|Циклические движения|**2**|Не использует periodicity priors (упомянут счётчик повторов как downstream, не как часть pose-модели)|
|Валидация на фитнес-датасетах|**1**|Только демо, никаких количественных результатов на Fit3D / AIST++ / public fitness-датасетах|
|Робастность к truncation|**2**|Не обсуждается; face-as-detector подразумевает обрезку лица = потерю трекинга|
|Возможность fine-tuning|**3**|Архитектура воспроизводима в TF/PyTorch, но training pipeline и датасет закрыты — fine-tuning придётся делать «с нуля»|
|Доступность кода и весов|**5**|MediaPipe / TFLite / Apache-2.0; pretrained веса свободны|

**Итоговая релевантность для SmartRep: 5/5** (как baseline и образец edge-архитектуры).

### Конкретные элементы для заимствования

|Элемент|Что переносить|Модификации|Риски|
|---|---|---|---|
|**Топология 33 keypoints**|Использовать как minimum, возможно расширять (доп. точки на коленях/локтях для биомеханики)|Совместимость с COCO для трансфера весов|Стандартные 2D-датасеты не имеют этих точек → нужна self-supervised разметка|
|**Heatmap supervision → regression head**|Воспроизвести трюк для нашего трекера|Адаптировать heatmap σ под фитнес|Может потребовать перетренировки с нуля|
|**Two-stage detector-tracker амортизация**|Использовать pose-tracker между кадрами + детектор только при потере|Заменить face-detector на body-detector, либо использовать более крупный ROI|Face-proxy не сработает для инверсий|
|**Vitruvian-man ROI parametrization**|Хорошая идея для устойчивого трекинга|Можно адаптировать на наши специфичные позы|Требует своих виртуальных keypoints в разметке|
|**Visibility flag**|Использовать для угловых вычислений (не считать угол при низкой visibility)|—|—|

### Привязка к направлениям новизны (🅰/🅱/🅲)

- **🅰 (fitness fine-tuning + edge):** статья **поддерживает** это направление — даёт edge-baseline, но **оставляет gap по fitness-специфичной валидации и угловым метрикам**. Прямой кандидат на baseline для нашей работы.
- **🅱 (temporal-aware для циклических движений):** статья **закрывает** только тривиальный кейс (ROI propagation). Главный gap: нет temporal priors на keypoint-уровне → есть пространство для улучшения.
- **🅲 (биомеханическая регуляризация):** **полностью пропущено** — pose предсказывается без анатомических ограничений. Чистый gap.

---

## 9. СВЯЗЬ С ДРУГИМИ РАБОТАМИ

**Прямо продолжает:**

- **BlazeFace** (Bazarevsky et al., 2019) — детектор архитектурно почти идентичен
- **MediaPipe Hands** (Bazarevsky & Zhang, 2019) — оттуда взят detector-tracker pattern
- **Offset-guided pose estimation** (Zhang et al., CVPRW 2019) — heatmap+offset loss заимствован оттуда

**Расширяется в:**

- **MediaPipe Pose with 3D (BlazePose GHUM Holistic)** — позже добавлены 3D-координаты и интеграция со SMPL-родственной GHUM моделью
- **MoveNet** (Google, 2021) — параллельная линия, тоже edge-focused, но с другой архитектурой (CenterNet-стиль)

**Конкуренты на edge-нише:**

- **MoveNet Lightning/Thunder** — CenterNet-derived, тоже single-person, тоже 17 keypoints (COCO)
- **MovePose** — более новая работа
- **Lite-HRNet** — миниатюризированный HRNet
- **EfficientPose** — NAS-derived
- **RTMPose-Lite** — современный SOTA в edge-нише

**Сравнивается (в статье)** только с OpenPose. **Не сравнивается** с PoseNet, AlphaPose, любыми ViT-based моделями (тогда не существовали).

**Связь с фитнес-работами:**

- В статье намёк на возможность построения exercise counter, но без формальной связи с AQA / fitness-specific литературой.
- Не упоминаются ни MM-Fit, ни Fit3D (Fit3D вышел в 2021, после статьи).

---

## 10. КРИТИЧЕСКАЯ ОЦЕНКА (Peer-Review)

|Критерий|Оценка|Комментарий|
|---|:-:|---|
|Новизна|**6/10**|Топология + heatmap-supervised regression — умеренная новизна; основные идеи композитны|
|Техническая глубина|**5/10**|Workshop-объём ограничивает; ablations скромные, формальные доказательства отсутствуют|
|Экспериментальная строгость|**3/10**|Приватный датасет, одна метрика (PCK@0.2), сравнение только с OpenPose|
|Ясность изложения|**8/10**|Очень понятная статья, хороший pipeline-диаграмма, структура логичная|
|Воспроизводимость|**4/10**|Веса и runtime — да; training pipeline и данные — нет|
|Значимость для community|**9/10**|Колоссальное практическое влияние через MediaPipe; сотни downstream-проектов|
|Релевантность edge-deployment|**10/10**|Эталонная статья по edge pose estimation|

**Общая оценка:** **Weak Accept** (для main conference было бы Reject из-за слабого экспериментального раздела; для workshop с акцентом на industry/AR — однозначно Accept).

**[МОЙ КОММЕНТАРИЙ]** Это академически слабая, но индустриально выдающаяся работа. Низкая воспроизводимость и weak experiments скомпенсированы огромным практическим вкладом и качественным open-source artifact (MediaPipe).

---

## 11. КЛЮЧЕВЫЕ ВЫВОДЫ

1. **Главный вклад:** lightweight pose tracker на 33 keypoints с heatmap-supervised regression, работающий >30 fps на mobile CPU и интегрированный в MediaPipe.
2. **Самое сильное техническое решение:** двухголовая архитектура с heatmap supervision только на тренировке — даёт качество heatmap-методов при стоимости regression.
3. **Главный недостаток:** научная воспроизводимость и валидация — приватный датасет, одна метрика, нет угловых метрик, нет публичных бенчмарков.
4. **Самый полезный элемент для SmartRep:**
    - **Архитектурный паттерн:** `regression head + heatmap supervision (training only)` → применить в нашем pose-блоке (компонент: **head + loss**)
    - **Топология 33 keypoints** → использовать как минимум для нашего поинт-сета (компонент: **output format**)
    - **Detector-tracker амортизация** → стандартный паттерн для нашего видео-pipeline (компонент: **temporal module**)
5. **Изучить дополнительно:**
    - MediaPipe BlazePose 3D / BlazePose GHUM Holistic — как из 2D BlazePose сделали 3D
    - MoveNet (Google, 2021) — параллельная линия, важен для cross-comparison
    - RTMPose-Lite — современный конкурент на той же нише
    - **Model Card MediaPipe BlazePose** — там описаны ограничения, которые в статье опущены
6. **Приоритет для нашего исследования:** **ВЫСОКИЙ** — обязательная статья, обязательный baseline, обязательная точка сравнения по latency.
7. **Связанные статьи, которые стоит прочитать следом:**
    - Bazarevsky et al., **BlazeFace** (arXiv:1907.05047)
    - Grishchenko et al., **MediaPipe Holistic / BlazePose 3D** (Google AI Blog 2020-2021)
    - Votel & Li, **Next-Generation Pose Detection with MoveNet and TensorFlow.js** (Google blog, 2021)
    - **MoveNet** (используемая внутри Google архитектура, описана в TensorFlow blog)
    - **RTMPose** (Jiang et al., 2023) — SOTA-конкурент
    - **MovePose** (если вышла после) — последователь BlazePose линии

---

## ИТОГОВАЯ КАРТОЧКА (для Obsidian-vault)

````markdown
---
title: "BlazePose: On-device Real-time Body Pose tracking"
title_ru: "BlazePose: Отслеживание позы тела в реальном времени на устройстве"
authors: [Bazarevsky, Grishchenko, Raveendran, Zhu, Zhang, Grundmann]
year: 2020
venue: "CVPR Workshop on Computer Vision for Augmented and Virtual Reality (CV4ARVR)"
venue_tier: "workshop"
doi: "arXiv:2006.10204"
tags: [pose_estimation, edge, commercial]
pose_dim: "2d"
strategy: "top_down"
backbone: "Custom lightweight CNN (encoder-decoder, BlazeFace-family)"
params_M: 3.5
flops_G: 0.0069
latency_ms: ~33  # ~30 fps на Pixel 2 single core; на Snapdragon 8 Gen 2 ожидаемо <10 мс
hw_tested: "Pixel 2 single core (XNNPACK), Intel i9-7900X"
relevance_to_smartrep: 5
direction: "A"
priority: "HIGH"
---

# BlazePose: Отслеживание позы тела в реальном времени на устройстве

## TL;DR
BlazePose — лёгкая 2D pose-модель от Google (33 keypoints, 3.5M параметров) с two-stage detector-tracker pipeline, достигающая 30+ fps на CPU Pixel 2; ключевой технический трюк — heatmap supervision во время обучения с удалением heatmap-головы на инференсе, что даёт качество heatmap-методов при стоимости regression. Топология специально расширена под фитнес/йога (включает кисти, ступни, дополнительные точки лица). Главный gap — отсутствие валидации на угловых метриках и на публичных fitness-датасетах.

## Проблема
Все production-grade pose estimators (OpenPose, AlphaPose, HRNet) требуют desktop GPU и непригодны для мобильных приложений; стандартная топология COCO (17 точек) не покрывает кисти/стопы, критичные для фитнеса.

## Гипотеза / вклад
- Heatmap supervision на этапе обучения улучшает качество регрессионной модели даже после удаления heatmap-головы на inference.
- Расширенная топология 33 keypoints (суперсет COCO + BlazeFace + BlazePalm) практически применима для fitness/yoga.
- Face-as-proxy ROI + Vitruvian-man параметризация позволяют устойчиво трекать тело в нестандартных позах.

## Метод
Two-stage pipeline: BlazeFace-like детектор предсказывает лицо + 2 виртуальные точки (центр бёдер + Vitruvian circle), задающие ROI; ROI пробрасывается в encoder-decoder трекер с двумя output-башнями (heatmap+offset для левой, regression для правой). На инференсе используется только regression-башня. Детектор запускается на первом кадре или при потере; на видео ROI пропагируется через предыдущие keypoints.

## Датасеты
| Датасет | Размер | Метрика | Результат |
|---|---|---|---|
| Внутренний Google geo-diverse pose | НЕ УКАЗАНО | PCK@0.2 | близко к human baseline 97.2 |

## Сравнение с SOTA
В статье — только с OpenPose: BlazePose Full (3.5M, ~7 MFLOPs) против OpenPose (~25M, ~160 GFLOPs); BlazePose «slightly worse» по качеству, но кратно быстрее на mobile. Сравнения с современными edge-моделями (MoveNet, RTMPose-Lite) отсутствуют (модели появились позже).

## Edge-метрики
| Параметр | Значение | hw |
|---|---|---|
| Latency | ~33 мс/frame (декларативно 30+ fps) | Pixel 2 single core, XNNPACK |
| FPS | 30+ | Pixel 2 single core |
| Params | 3.5M (Full) / 1.3M (Lite) | — |
| FLOPs | 6.9M (Full) / 2.7M (Lite) | — |

## Ограничения / слабости
- Single-person only; требует видимости лица для детектора
- Только 2D, без 3D / без углов
- Приватный train+val датасет; единственная метрика (PCK@0.2)
- Нет валидации на public-бенчмарках (COCO, MPII, Fit3D, AIST++)
- Нет анализа failure cases, occlusion, truncation
- Нет temporal smoothing на keypoint-уровне (только ROI-propagation)

## Релевантность SmartRep
**Заимствовать:** (1) heatmap-supervised regression head как loss-паттерн; (2) топологию 33 keypoints как минимум; (3) detector-tracker амортизацию. **Сравниваться:** обязательный baseline для latency на Snapdragon 8 Gen 2 и для качества на фитнес-движениях.

## Gap для нас
- **При этом не валидируется по угловым метрикам (MAE/RMSE по joint angles vs MoCap)** — наш ключевой gap для SmartRep.
- **При этом не валидируется на Fit3D и других fitness-датасетах с ground-truth.**
- **При этом не рассматривается robustness к снарядам в кадре (грифы, гантели)** и truncation при близком ракурсе.
- **При этом не использует temporal priors / periodicity для циклических движений.**
- **При этом не достигает требования <10 мс на современном Snapdragon 8 Gen 2 явно** — нужны собственные замеры (хотя ожидаемо запас есть).
- **При этом не использует биомеханические constraints на углы суставов.**

## Ссылки на связанные статьи
- [[BlazeFace - 2019]]
- [[MediaPipe Hands - 2019]]
- [[MoveNet - 2021]]
- [[Offset-guided Pose Estimation - Zhang CVPRW 2019]]
- [[RTMPose - 2023]]
- [[Fit3D Dataset - 2021]]

## Код / данные
- Repo: https://github.com/google/mediapipe (MediaPipe Pose)
- Pretrained: MediaPipe Pose модели (Apache-2.0), TFLite
- Датасет: **закрыт** (внутренний Google geo-diverse pose dataset)

## BibTeX
```bibtex
@article{Bazarevsky2020BlazePose,
  title   = {BlazePose: On-device Real-time Body Pose tracking},
  author  = {Bazarevsky, Valentin and Grishchenko, Ivan and Raveendran, Karthik and Zhu, Tyler and Zhang, Fan and Grundmann, Matthias},
  journal = {arXiv preprint arXiv:2006.10204},
  year    = {2020},
  note    = {CVPR Workshop on Computer Vision for Augmented and Virtual Reality}
}
````

```

---

**[МОЙ КОММЕНТАРИЙ — итог]** BlazePose — обязательный baseline для SmartRep, причём по двум причинам сразу: (1) технически — это один из немногих pose estimators, гарантированно укладывающихся в наш бюджет latency; (2) методологически — он демонстрирует gap, в который мы можем встать: индустриальная edge-модель **без** биомеханической валидации, **без** угловых метрик, **без** валидации на фитнес-датасетах, **без** temporal priors. Все три направления нашей кандидатной новизны (🅰/🅱/🅲) находят здесь конкретное обоснование. Рекомендую следующим шагом проанализировать **MoveNet** (как параллельную линию) и **RTMPose-Lite** (как современного SOTA-конкурента в той же edge-нише) — это даст триангуляцию edge-baseline'ов.
```