Структурные решения для `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: "" authors: [<фамилии>] year: venue: "" venue_tier: "" doi: "" code: "" project_page: "<если есть отдельная>" paper_type: "synthesis_method" # обязательно synthesis_subtype: "" # обязательно 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+ часов) | <качественная оценка> | | Лицензия выходных данных | | **Качественный 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 и смотрим, как он себя ведёт на реальной статье из нашей ниши?