338 lines
25 KiB
Markdown
338 lines
25 KiB
Markdown
|
||
|
||
Структурные решения для `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 и смотрим, как он себя ведёт на реальной статье из нашей ниши? |