

Структурные решения для `synthesis_method`-промпта (что отличает от A/B/C):

1. **Принципиально другой угол оценки.** A/B/C оценивают модель, которая что-то предсказывает. Здесь модель **создаёт данные**, и оцениваем мы пригодность синтеза для downstream-обучения, а не визуальное качество как самоцель. Sim2real gap — главная ось.
    
2. **Три подкласса под одной шапкой — нужен явный sub-type.** NeRF/3DGS (novel view synthesis из реальных видео), SMPL-rendering (физико-параметрический рендер из mocap), GAN/диффузия (генерация с нуля или conditional) — у них разные параметры качества, разные риски, разные edge-кейсы. Ввожу `synthesis_subtype` в YAML.
    
3. **«Edge feasibility» переосмысливается.** Synthesis в SmartRep — **offline data generation**, не runtime. Поэтому раздел 5 — это не latency на mobile, а **production cost**: GPU-часы на сцену, требования к captureу (число камер, синхронизация, маркеры), масштабируемость. Inference latency может быть вообще нерелевантен.
    
4. **«Fidelity vs Utility» — ключевое разделение.** Visual fidelity (PSNR / SSIM / LPIPS / FID) ≠ downstream utility (улучшает ли downstream MPJPE / accuracy при добавлении синтетики в обучение). Многие работы хвалят fidelity, но не проверяют utility — это главный gap-генератор.
    
5. **Контролируемость генерации — обязательное поле.** Можем ли мы синтезировать **именно ту ошибку техники**, которой нам не хватает в реальных данных (e.g., butt-wink с заданной амплитудой)? Без controllability синтез — просто шумная аугментация.
    
6. **Лицензионные / этические риски.** Synthetic faces, synthetic identities, deepfake-adjacent методы — отдельная категория рисков, которой нет в A/B/C. Особенно если пайплайн синтезирует лица атлетов.
    
7. **Sim2real bridge — отдельный раздел.** Domain randomization, domain adaptation, mixed pretraining recipes (synthetic→real fine-tuning) — есть ли у статьи что-то про это, или она оставляет sim2real upstream-задачей.
    

---

# 📑 Дополнения к тег-словарю для synthesis-papers

```
# Подтип синтеза
nerf, gaussian_splatting, smpl_rendering, mocap_replay, 
diffusion, gan, neural_rendering, physics_simulation, motion_retargeting

# Контролируемость
controllable_pose, controllable_appearance, controllable_camera, 
controllable_lighting, controllable_clothing, uncontrolled

# Sim2real
domain_randomization, domain_adaptation, mixed_training, no_sim2real

# Капчер-требования
multi_view_capture, single_view_capture, mocap_required, marker_based, 
markerless_capture, in_the_wild_capture, studio_capture

# Применение
data_augmentation, novel_view_synthesis, avatar_creation, mesh_recovery_aux
```

---

# 📝 ВАРИАНТ D — Промпт для synthesis / data generation статей

````
ПРОМПТ ДЛЯ АНАЛИЗА SYNTHESIS-СТАТЬИ (paper_type: synthesis_method)

Ты — старший научный рецензент с экспертизой в neural rendering 
(NeRF, 3D Gaussian Splatting), parametric body rendering (SMPL-X / GHUM), 
diffusion-based generation, motion retargeting и synthetic data pipelines 
для обучения CV-моделей. Твоя задача — подготовить разбор статьи для 
проекта SmartRep как кандидата на источник синтетических данных для 
обогащения тренировочной выборки (особенно — для редких ошибок техники, 
которых в реальных датасетах мало).

ВАЖНО-1: если статья — это AQA / pose method / SSL backbone и synthesis 
там вспомогательный модуль, ОСТАНОВИСЬ и переключись на соответствующий 
шаблон (A / C / B). Этот шаблон — для статей, где **синтез данных — 
главный вклад**.

ВАЖНО-2: для нашей задачи критичны четыре оси, которые нужно явно 
проверить:
  (a) Sim2real gap — переносится ли модель, обученная на синтетике, 
      на реальное видео из зала;
  (b) Controllability — можем ли мы задать конкретную ошибку техники 
      (butt-wink с амплитудой X°, valgus knee на повторе N);
  (c) Production cost — сколько стоит сгенерировать N часов видео 
      (GPU-часы, требования к источникам);
  (d) Лицензионные / этические риски — особенно для синтеза лиц / 
      идентичностей.
Если статья молчит по какой-то оси — фиксируй как «НЕ ОЦЕНИВАЕТСЯ» 
и переноси в Gap.

ВАЖНО-3: Visual fidelity (PSNR / SSIM / LPIPS / FID) ≠ downstream utility 
(улучшение downstream MPJPE / accuracy при добавлении синтетики в обучение). 
Это РАЗНЫЕ оси оценки. Если статья хвалит только fidelity без utility-теста 
на downstream-задаче — явно отметь это как красный флаг.

### 1. МЕТАДАННЫЕ (YAML)

```yaml
title: "<оригинальный заголовок>"
title_ru: "<перевод>"
short_name: "<canonical акроним>"
authors: [<фамилии>]
year: <YYYY>
venue: "<conference/journal>"
venue_tier: "<A*/A/B/Q1/Q2/SIGGRAPH>"
doi: "<link>"
code: "<github>"
project_page: "<если есть отдельная>"
paper_type: "synthesis_method"   # обязательно
synthesis_subtype: "<nerf | gaussian_splatting | smpl_rendering | diffusion | gan | physics_sim | motion_retargeting | hybrid>"   # обязательно
tags: [<из фикс. словаря, минимум 4 — обязательны: подтип, контролируемость, capture-требования, sim2real подход>]
relevance_to_smartrep: <1-5>
direction: "<🅰 / 🅱 / 🅲>"   # synthesis обычно служит 🅲 (data adaptation), 
                              # реже 🅰 (controllable error generation), редко 🅱.
                              # Обязательно обоснуй в TL;DR.
status: "reviewed"
```

### 2. CORE CONTRIBUTION (TL;DR)

3 предложения. **Первое** — что именно синтезирует метод 
(novel views реального человека / параметрические аватары / полное видео 
с нуля / motion-only / appearance-only) и из каких входов. 
**Второе** — основной механизм + что нового относительно прямых предшественников. 
**Третье** — обоснование `direction` и принципиальная роль для SmartRep 
(generator of training data / generator of test cases / avatar creation / 
ничто из этого).

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

- **Подтип синтеза:** NeRF / 3DGS / SMPL-rendering / diffusion / GAN / 
  physics simulation / motion retargeting / гибрид.
- **Входы метода:**
  - Source: multi-view видео / single-view / mocap (.bvh / SMPL params) / 
    text prompt / reference image / scan / none;
  - Capture требования: число камер, синхронизация, маркеры, контролируемое 
    освещение, green screen, studio vs in-the-wild;
  - Pose source: GT mocap / pseudo-labels от pose estimator / sampled 
    из латентного пространства.
- **Выходы метода:**
  - Modality: RGB видео / RGB+depth / RGB+normals / mesh + texture / 
    SMPL params + render / pose-only sequence;
  - Resolution + FPS;
  - Длительность сэмпла (несколько кадров / несколько секунд / 
    произвольная длина).
- **Pipeline:**
  - Backbone (CNN / NeRF MLP / Gaussian primitives / U-Net diffusion / GAN);
  - Body / scene representation (volumetric / point cloud / mesh / hybrid);
  - Renderer (volume / rasterization / differentiable);
  - Optimization (per-scene / amortized / hybrid).
- **Контролируемость:**
  - Pose: можно ли задать произвольную позу / последовательность? Источник 
    (SMPL params / skeleton / latent code)?
  - Appearance: одежда, телосложение, кожа — управляемы или фиксированы?
  - Camera: viewpoint, FOV, intrinsics — можно ли варьировать?
  - Lighting: фиксированное / управляемое / relit;
  - Background: studio fixed / interchangeable / generated.
- **Loss-функции в LaTeX** ($\mathcal{L} = \dots$) с разбором по слагаемым: 
  reconstruction (RGB / mask / depth), perceptual (LPIPS), regularization 
  (smoothness / sparsity / SDS-loss для diffusion), pose / shape priors.
- **Mermaid-диаграмма:** Inputs (source data) → Representation (3D model) 
  → Renderer → Output (video / images) → (опционально) Downstream training.

### 4. SYNTHESIS-ЭКСПЕРИМЕНТЫ

#### 4.1 Visual fidelity метрики (что обычно есть)

- **Image-level:** PSNR ↑, SSIM ↑, LPIPS ↓, FID ↓, KID ↓;
- **Video-level:** FVD ↓, temporal LPIPS;
- **Geometry (если применимо):** Chamfer distance, IoU, normal consistency;
- **User study:** preference rate, realism rating (если есть).

#### 4.2 Downstream utility метрики (что обычно НЕТ — но критично нам)

Делает ли статья хотя бы один из тестов:
- Pretraining на synthetic → finetune на real → улучшение downstream метрики 
  (MPJPE / accuracy) vs only-real baseline?
- Mixed training (real + synthetic) → улучшение vs only-real?
- Synthetic-only training → real test → насколько деградирует?
- **Если ни один из этих тестов не проводится — это главный red flag**. 
  Visual fidelity без utility-теста означает, что синтетика может быть 
  красивой, но бесполезной для обучения. Явно отметь.

#### 4.3 Sim2real анализ

- Domain gap между synthetic и real — оценен ли количественно?
- Domain randomization применяется (lighting / background / camera jitter / 
  texture variation)?
- Domain adaptation (после-генерации post-processing, adversarial alignment)?
- Mixed training recipe (соотношение real:synth, curriculum)?
- Failure modes на real data — обсуждаются?

#### 4.4 Controllability эксперименты

- Pose disentanglement: меняется ли только поза при фиксированной 
  appearance? Измерено количественно (например, FID при свапе)?
- Appearance transfer: один человек в позах другого — работает?
- Out-of-distribution позы: синтез работает на позах, далёких от 
  training distribution? **Это критично для нас** — атлетические 
  позы редко в training.

#### 4.5 SOTA-таблица + ablation

Воспроизведи ключевую сравнительную таблицу. Особо отметь, на каком датасете 
сравнение (in-distribution vs OOD).

### 5. PRODUCTION FEASIBILITY (для SmartRep — ОТЛИЧАЕТСЯ от edge!)

Synthesis в SmartRep — **offline data generation**, не runtime. Поэтому 
оцениваем production cost, а не mobile latency.

| Параметр | Значение |
|---|---|
| GPU-часы на одну сцену / аватара (training) | <число / НЕ УКАЗАНО> |
| GPU-часы на N секунд видео (inference) | <число / НЕ УКАЗАНО> |
| Тип GPU в экспериментах | <модель / НЕ УКАЗАНО> |
| Render FPS | <число / НЕ УКАЗАНО> |
| Capture cost (камеры / mocap / studio) | <описание / не нужен> |
| Per-scene optimization (NeRF/3DGS) или amortized | <да / нет> |
| Масштабируемость (можно ли сгенерировать 100+ часов) | <качественная оценка> |
| Лицензия выходных данных | <permissive / restricted / unclear> |

**Качественный fallback:** оценка стоимости как `cheap / moderate / expensive / 
prohibitive` для нашего use case (нам нужны десятки-сотни часов синтетики 
с управляемыми ошибками техники).

### 6. РЕЛЕВАНТНОСТЬ ДЛЯ SMARTREP (synthesis-применимость)

- **Нужный нам тип синтеза:** делает ли метод то, что нам реально нужно — 
  синтез человека в **полный рост в side-view** при выполнении упражнений 
  с предметом (штанга / турник)? Поддерживает ли human-object interaction?
- **Контролируемость ошибок техники:** можем ли мы программно задать 
  «сделай присед с butt-wink амплитудой 15° на повторе 3 из 5»? Если pose 
  controllable через SMPL θ — да. Если только текст/латент — скорее нет.
- **Body / shape diversity:** можем ли варьировать телосложение (β-параметры)? 
  Это критично для генерализации модели на разные тела пользователей.
- **Equipment & occlusion:** есть ли поддержка штанги / гантелей как 
  отдельного объекта в сцене (для реалистичной окклюзии)? Если только 
  голый человек — utility для нас сильно ограничен.
- **Side-view bias:** обычные NeRF/3DGS работают на 360°-захвате; для нас 
  достаточно качественного side-view, но качество должно держаться при 
  смене угла камеры (зеркала в зале, разные смартфоны).
- **Sim2real bridge:** что нужно сделать после генерации, чтобы синтетика 
  работала с реальной gym-камерой (compression, JPEG-noise, motion blur)?
- **Source data requirements vs наши возможности:**
  - Нужен ли multi-view capture (у нас его нет)?
  - Нужен ли mocap / IMU (у нас есть для отдельных сессий)?
  - Можно ли использовать только monocular видео тренировки?
- **Лицензионные / этические риски:**
  - Синтез реальных лиц атлетов — рискованно, потенциально deepfake-adjacent;
  - Синтетические идентичности (без лиц / blurred faces / generic avatars) 
    — безопасно;
  - Если статья синтезирует faces — отметь и предложи модификацию.

### 7. GAP ДЛЯ НАС (НИША НОВИЗНЫ — самое важное поле)

2–4 конкретных гэпа в формате:
- **Гэп N:** [что не делает или плохо делает статья] → [как это становится 
  новизной SmartRep].

Типичные формы для synthesis-papers:
- Только visual fidelity, без downstream utility теста → провести utility 
  benchmark для AQA-задачи (pretrain on synthetic squats → eval on real Fitness-AQA).
- Нет equipment/occlusion поддержки → расширить SMPL-X-рендер композицией 
  с штангой (rigid object + shadow + contact).
- Контролируемость только по joint positions, не по error type → ввести 
  taxonomy-aware controller, который мапит named errors (butt-wink, valgus) 
  на параметрические возмущения SMPL θ.
- Нет sim2real evaluation на gym-camera artifacts → benchmark с smartphone 
  compression / lighting variation как post-processing pipeline.
- Per-scene optimization дорого → дистилляция в amortized feedforward avatar.

### 8. ВЫВОД ДЛЯ ЛИТОБЗОРА

- Приоритет: **ВЫСОКИЙ / СРЕДНИЙ / НИЗКИЙ** + одна строка обоснования.
- Место в SmartRep-pipeline: какой компонент 
  (data augmentation для редких ошибок / controllable error injection / 
  avatar для тестового бенчмарка / baseline для сравнения / неприменимо).
- Прямой вклад в направления:
  - 🅲 (адаптация / few-shot): обычно ненулевой, если есть utility test;
  - 🅰 (error detection): ненулевой только если есть controllable error generation;
  - 🅱 (biomech pose): обычно нулевой, кроме случаев physics-simulated synthesis 
    с biomech-aware приорами.
- 3–5 связанных статей для следующего разбора с краткой ремаркой почему.

---

ИНСТРУКЦИИ AI:
- Не выдумывай данные. «НЕ УКАЗАНО» / «НЕ ОЦЕНИВАЕТСЯ» — допустимые ответы.
- Visual fidelity и downstream utility — РАЗНЫЕ вещи, не смешивай.
- Если статья хвалит PSNR / FID, но не проверяет utility на downstream — 
  явно фиксируй это как red flag в разделе 4.2 и в Gap.
- Если synthesis_subtype гибридный — укажи доминанту и второстепенный 
  компонент, не пиши просто "hybrid".
- Лицензионные и этические аспекты для face/identity synthesis — 
  обязательны, не пропускай.
- Разделяй факты и [КОММЕНТАРИЙ РЕЦЕНЗЕНТА].
- Формулы — LaTeX.
- Перед финальным артефактом — короткий блок структурных решений.
- После артефакта — мета-комментарий о работе шаблона.
````

---

## 🧭 Финальный селектор (4 шаблона + dataset)

|Признаки в abstract / methods|Шаблон|
|---|---|
|Spearman / Kendall / AUROC / per-error F1 / regression на оценку движения|**A (AQA)**|
|Named error taxonomy + classification/scoring по ошибкам|**A (AQA)**|
|Reconstruction error / distance-to-prototype как anomaly score|**A (AQA)**|
|MPJPE / PA-MPJPE / PVE / SMPL fitting / IK / mesh recovery — главный выход|**C (pose)**|
|Joint angles / biomech priors как первичный выход|**C (pose)**|
|Pretext task + linear/finetune eval на классификации|**B (SSL backbone)**|
|Linear / KNN на NTU/Kinetics/ImageNet с Top-1 как главной метрикой|**B (SSL backbone)**|
|**Главный вклад — генерация данных** (NeRF / 3DGS / SMPL-render / diffusion / GAN / motion retargeting)|**D (synthesis)**|
|Novel view synthesis от реальных видео людей|**D (synthesis)**|
|Avatar creation / controllable rendering / data augmentation pipeline|**D (synthesis)**|
|Гибрид: AQA + pose в одной (как AIFit)|**C primary**, A secondary|
|Гибрид: SSL pretraining + pose downstream|**B primary**, C secondary|
|Гибрид: synthesis + downstream evaluation встроенный|**D primary**, B/C secondary|
|Dataset paper (sampling protocol / annotation methodology — главное)|**dataset (14-секц.)**|

---

## Мета-комментарий

**Что специфично для D по сравнению с A/B/C:**

- Раздел 4 разделён на **fidelity** и **utility** с явным red-flag механизмом — это уникально, в pose/AQA/SSL папках такой развилки нет.
- Раздел 5 переименован из «edge feasibility» в **«production feasibility»** и измеряет совсем другие вещи (GPU-часы, capture cost, лицензии вывода) — потому что synthesis у нас offline.
- Controllability — отдельная подсекция (4.4) и отдельный блок в 6 — потому что это килл-фактор для нашего use case (синтез ради синтеза нам не нужен).
- Лицензионно-этический блок — единственный из четырёх шаблонов, где он обязателен (риск face/identity synthesis).

**Что закрыто полным квартетом A/B/C/D:**

- Каждый шаблон явно отгораживается от трёх остальных в верхней части ("ВАЖНО-1: если статья X-типа — переключись").
- `direction` без default везде, с правилом по-умолчанию для подсказки и обязательным обоснованием в TL;DR.
- Edge / production feasibility унифицирован по структуре, но разный по содержанию.
- Тег-словарь покрывает все четыре парадигмы без дублей.
- Все четыре шаблона требуют структурный preamble + meta-commentary.

**Очередь следующих улучшений (после применения на реальных статьях):**

- Возможный **пятый** шаблон `evaluation_protocol` — для статей про метрики и бенчмарки сами по себе (Datasheets for Datasets, AQA evaluation protocols, fairness audits). Сейчас явной нужды нет, но если попадётся — будем знать.
- Миграция старых карточек: добавить `paper_type` в frontmatter Fit3D / FLAG3D / Fitness-AQA / H36M / AIFit (последняя — `pose_method` или `hybrid: pose_method + aqa_method`).
- Cross-reference между гибридными карточками: `primary_card`, `secondary_card` — как договаривались. Реализуется в Obsidian как обычные wikilinks `[[...]]` в frontmatter.
- Dataview-запросы для vault: после миграции можно будет легко фильтровать `paper_type: synthesis_method AND relevance_to_smartrep >= 4` или строить таблицы покрытия по направлениям.

---

Прагматичный следующий шаг: у тебя FLEX (arXiv 2506.03198) был flagged как highest priority и identified как closest competitor. Вероятно, FLEX — это **D (synthesis) или гибрид D + dataset**, если он собирает синтетический fitness-датасет. Прогоняем D-промпт на FLEX и смотрим, как он себя ведёт на реальной статье из нашей ниши?