Обзор

Гардероб — каталог своих вещей и коллажи

Кроссплатформенное приложение (iOS + Android) на React Native / Expo. По сути — каталог собственных вещей в эстетике Farfetch: белый фон, тонкие линии, много воздуха, вещи как товары.

1. фотографируете вещь на камеру (или берёте из галереи);
2. приложение вырезает фон — вещь попадает в каталог;
3. собираете из вещей коллажи на белом листе: перетаскиваете, меняете размер и поворот, двигаете слои;
4. при желании включаете режим «Манекен» — вещи автоматически садятся на фигуру по опорным точкам.

Это рабочий прототип ядра: путь «сфотографировал → вещь в каталоге → собрал коллаж» реализован целиком и работает офлайн.

Что уже работает

Как читать документацию

Откройте **docs.html** двойным щелчком — это вся документация (этот файл и пять разборов из docs/), собранная в одну страницу с навигацией. Работает офлайн, ничего устанавливать не нужно.

Исходники — обычные markdown-файлы в docs/. Их можно править в любом редакторе (удобнее всего VS Code), а docs.html — просто снимок для чтения.

Запуск на телефоне

Самый простой путь — двойной щелчок по **START.bat** в корне проекта: скрипт проверит Node.js, поставит зависимости и запустит Expo.

Вручную:

1. Установите Node.js LTS с nodejs.org (обычный установщик, настройки по умолчанию).
2. Установите на телефон Expo Go (App Store / Google Play) и обновите его до последней версии.
3. Подключите телефон и компьютер к одной Wi-Fi сети.
4. В PowerShell:

   cd apps/mobile
   npm install
   npx expo start

1. Отсканируйте QR-код из терминала: на Android — прямо в Expo Go, на iPhone — камерой (предложит открыть Expo Go).

Все нативные модули приложения (Skia, камера, SQLite, Reanimated) входят в Expo Go, поэтому отдельная сборка не нужна — приложение запустится сразу.

Если телефон не видит сервер:

• разрешите Node.js в брандмауэре Windows (при первом запуске появится запрос);
• проверьте, что сеть не «гостевая» с изоляцией клиентов;
• запустите через туннель: npx expo start --tunnel.

Если Expo Go пишет «project is incompatible» — обновите Expo Go до последней версии.

Проверки

npm run typecheck    # tsc по всему приложению
npm run test:core    # юнит-тесты математики (компилируются в .tmp и гоняются в Node)

Настройки (необязательно)

Создайте apps/mobile/.env:

# Свой сервис вырезания фона: POST multipart -> { image: "<base64 png>", width, height, quality }
EXPO_PUBLIC_CUTOUT_URL=https://your-api.example/cutout

# Свой сервис распознавания: POST { image: "data:image/png;base64,...", category } -> { name, tags }
EXPO_PUBLIC_VISION_URL=https://your-api.example/tags

Без этих переменных приложение полностью работоспособно: вырезание идёт локальным алгоритмом, теги — эвристикой по цвету.

Структура

apps/mobile/
  src/
    app/            экраны (expo-router): каталог, коллажи, профиль, камера, карточка вещи, редактор
    components/     UI-кит, плитка каталога, лист коллажа на Skia, манекен, слайдер
    core/           чистая логика без React Native — тестируется в Node
      body.ts       антропометрия -> силуэт манекена и опорные точки
      rig.ts        шаблоны опорных точек по категориям одежды
      tps.ts        thin plate spline — деформация вещи под фигуру
      mesh.ts       треугольная сетка для Skia
      outfit.ts     слои, раскладка коллажа, порядок отрисовки
      cutout.ts     вырезание фона по цвету + заливка от краёв
      color.ts      доминирующие цвета, названия цветов по-русски
    data/           SQLite: схема, миграции, репозитории
    services/       вырезание, распознавание, файлы (провайдеры за интерфейсом)
    state/          zustand-стор
docs/               продуктовый и технический разбор

Админка

Статистика по пользователям живёт по адресу https://djitrikwardrobe.duckdns.org/admin/ и закрыта паролем (HTTP Basic, bcrypt на стороне Caddy). Отдельного домена не нужно: страница отдаётся из /opt/wardrobe/site/admin/, данные — из GET /api/admin/stats, куда Caddy подставляет секретный заголовок только после успешной авторизации.

Считается: пользователи (всего и с данными), вещи, коллажи, картинки (штук и мегабайт), вещи с точками посадки, новые пользователи за 24 часа и 7 дней, активные за 24 часа и 7 дней (по времени последней синхронизации), разбивка по категориям, таблица топ-пользователей, регистрации и добавленные вещи по дням. Страница сама обновляется раз в 15 секунд.

Документация

• [docs/01-product.md](docs/01-product.md) — зачем это, для кого, объём MVP, метрики, монетизация, конкуренты.
• [docs/02-architecture.md](docs/02-architecture.md) — стек и почему он, схема данных, синхронизация, приватность, CI/CD.
• [docs/03-ai-pipeline.md](docs/03-ai-pipeline.md) — вырезание фона, мультиракурс, авто-теги, генеративная примерка, аватар, стоимость.
• [docs/04-fitting-engine.md](docs/04-fitting-engine.md) — как именно вещь садится на фигуру: координаты, опорные точки, TPS, слои, ограничения.
• [docs/05-roadmap.md](docs/05-roadmap.md) — этапы, сроки, команда, бюджет, риски.

Ограничения текущей версии

• «Оставить» возвращает пиксели из исходного вырезания; то, что алгоритм удалил ещё до кисти, вернуть нельзя — для этого нужен исходный снимок.
• Фото-блоки вставляются как есть: кроп и форма (круг, арка) пока не поддерживаются.
• Экспорт делает снимок листа как есть: с разрешением экрана, без выбора фона и размера.
• В коллаже вещи располагаются вручную; авто-раскладка «красиво по сетке» — заготовка на будущее (collagePlacement).
• Режим «Манекен» — 2.5D: вещь деформируется по опорным точкам, но не оборачивается вокруг тела. Для честного 3D нужны 3D-модели одежды (см. docs/04-fitting-engine.md).
• Вырезание фона лучше всего работает на однотонном контрастном фоне — приложение прямо просит об этом в камере. Сложные фото (пёстрый фон, мех, стекло) стоит отправлять в облачную модель.
• Опорные точки вещи расставляются автоматически по шаблону категории; ручной редактор точек — следующий шаг.
• Нет аккаунтов: данные живут на устройстве. Это осознанно для MVP — синхронизация добавляется после проверки ретеншена.

01 · Продукт

01. Продукт

В одном абзаце

«Гардероб» — это каталог собственных вещей человека, устроенный как Farfetch: белый фон, тонкие линии, вещь как товар с карточкой и характеристиками. Поверх каталога — конструктор коллажей: из вырезанных вещей собираются раскладки на белом листе (образ, капсула, «что взять в поездку»), которые можно сохранять и позже показывать. Дополнительный режим — манекен по своим пропорциям, чтобы вещь можно было примерить, а не только разложить.

Проблема

• Люди не помнят, что у них есть: в среднем носится 20–30 % гардероба, остальное лежит.
• Покупки дублируются: «нечего надеть» при полном шкафу.
• Существующие приложения для гардероба требуют много ручного труда: вырезать фон, вручную разметить категорию, цвет, сезон. Через 2–3 недели такого ввода пользователь бросает приложение.

Три барьера, из-за которых гардеробные приложения не выживают:

1. Трение при добавлении вещи. Если вещь добавляется дольше 30 секунд — её не добавят.
2. Качество вырезания. Криво вырезанная вещь на белом фоне выглядит как мусор, и это разрушает доверие ко всему приложению.
3. Вещь некуда «приложить». Каталог сам по себе — склад. Ценность появляется, когда из вещей можно быстро собрать образ.

Наш продукт бьёт во все три: съёмка 10 секунд, автоматическое вырезание и разметка, мгновенный коллаж, а для «как это на мне» — режим манекена.

Конкуренты и чем мы отличаемся

Дифференциатор: качество каталога уровня люксового e-commerce + коллаж в один тап + опциональная посадка на фигуру. Красивый каталог сам по себе удерживает: людям нравится смотреть на свои вещи, разложенные как в магазине.

Визуальный язык

Референс — Farfetch. Это не «минимализм вообще», а конкретные правила:

Правило, которое важнее остальных: никакого «дизайна ради дизайна». Если элемент не помогает выбрать вещь или собрать коллаж — его нет.

Сценарии

1. «Собрать образ» (главный, ежедневный)

Утро. Открыл → «Коллажи» → «Создать коллаж» → тапнул косуху, платье, сапоги, сумку → они разложились по сетке → поправил композицию → сохранил. 30–60 секунд. Цель — довести до одного тапа: готовый коллаж «образ дня» по погоде (post-MVP).

2. «Добавить новую вещь» (еженедельно, сезонно)

Купил футболку → «＋» → снял на кровати → приложение вырезало фон, определило цвет и категорию → поправил название → вещь в каталоге. Цель — 15 секунд от открытия камеры до сохранения.

3. «Посмотреть на свой гардероб как на магазин» (ежедневно, пассивно)

Открыл каталог, полистал сетку, отфильтровал «обувь», нашёл забытые ботинки. Ценность — не действие, а ощущение порядка: вещи разложены красиво и по категориям, как на витрине.

4. «Не купить лишнего» (перед шопингом)

В магазине: есть ли у меня похожее? Что с этим сочетается? Post-MVP — «карманный стилист»: загрузил фото вещи в магазине — приложение говорит, с чем из имеющегося она сочетается и не дубль ли это.

5. «Собрать чемодан» (редко, но с высоким удержанием)

Выбрал даты и погоду — приложение предлагает капсулу из имеющихся вещей. Post-MVP.

Границы MVP

Входит:

• каталог в стиле люксового e-commerce: сетка, поиск, фильтры, карточка вещи с характеристиками;
• добавление вещи камерой или из галереи, локальное вырезание фона;
• автоопределение категории, цвета, сезона, «теплоты»;
• коллаж: свободное размещение вещей на белом листе, перетаскивание, щипок, поворот, порядок слоёв;
• режим «Манекен»: фигура по своим обхватам, авто-посадка вещей по опорным точкам;
• сохранение коллажей, полностью офлайн, без регистрации.

Не входит (осознанно):

Ключевой цикл и метрики

Цикл: добавил вещь → собрал коллаж → сохранил/показал → вернулся добавить новую вещь.

Метрики-диагностики: доля пересъёмок, доля ручных правок категории (если высокая — плохо работает распознавание), время сборки коллажа (если больше 2 минут — неудобный редактор).

Монетизация

Freemium-подписка (ориентир $4.99–7.99 / мес):

• бесплатно: до 60 вещей, манекен, образы без лимита;
• подписка: фотореалистичные рендеры образа, погодные подсказки, капсулы и чемодан, расширенная статистика «цена носки», неограниченный гардероб.

Логика: платить готовы за результат (красивый рендер «как это на мне»), а не за хранение. Поэтому генеративный рендер — платная функция, а не бесплатная.

Риски продукта

Что проверить до разработки (2 недели)

1. 15 интервью: как сейчас выбирают одежду, что мешает, фотографируют ли вещи.
2. Тест «бумажного прототипа»: показать 3 экрана (камера, гардероб, манекен) — понятно ли без объяснений.
3. Golden set из 100–300 реальных фото вещей: на нём измеряем качество вырезания, прежде чем строить всё остальное.
4. Проверить готовность платить: лендинг с ценой и кнопкой «оставить почту».

02 · Архитектура

02. Архитектура

Принципы

1. Local-first. Всё работает без сети и без аккаунта. Сервер — ускоритель и синхронизация, а не условие работы.
2. Ядро без фреймворка. Вся математика примерочной — чистый TypeScript без React Native. Её можно тестировать в Node, переиспользовать в вебе и позже вынести на сервер.
3. Провайдеры за интерфейсом. Вырезание фона и распознавание — это interchangeable-сервисы: локальный алгоритм, свой GPU-сервис или сторонний API. Приложение не знает, кто именно отвечает.
4. Считать на устройстве всё, что можно. Ноль сетевых задержек, ноль счетов за API, работает в метро.

Стек и обоснование

Почему не Flutter. Flutter объективно сильнее в кастомном 2D/3D-рендере, и если продукт уйдёт в честное 3D с тканью — это аргумент мигрировать. Но MVP — это 2.5D-композитинг и много продуктовой логики. React Native + Skia даёт 90 % нужного рендера за 30 % времени, а TypeScript-ядро потом можно переиспользовать где угодно.

Слои и направление зависимостей

app/            экраны, навигация
  ↓
components/     UI-кит, Skia-канвас, манекен
  ↓
state/          zustand: гардероб, профиль, образы
  ↓
services/       cutout, vision, files, (позже) sync
  ↓
data/           SQLite: схема, миграции, репозитории
  ↓
core/           чистая математика: TPS, меши, антропометрия, вырезание

Правило: core/ не импортирует ничего из React Native и не знает про базу. data/ не знает про React. Экраны не работают с SQL напрямую.

Схема данных

garments(id, name, category, image_uri, thumb_uri, image_width, image_height,
         rig JSON, tags JSON, favorite, wear_count, created_at, updated_at)
outfits(id, name, created_at, updated_at, last_worn_at)
outfit_items(id, outfit_id, garment_id, layer, transform JSON, visible, mirrored, position)
settings(key, value)          -- профиль тела, флаги онбординга

Решения:

• **rig и tags — JSON.** Это вложенные структуры (до 24 точек, до 4 цветов, сезоны), которые читаются целиком вместе с вещью. Отдельные таблицы дали бы JOIN-ы без выгоды. Цена — нельзя индексировать по цвету; когда понадобится поиск по цвету, добавим денормализованные колонки primary_color, warmth.
• Порядок слоёв не хранится числом. layer — это enum (lower, upper, knit, outer, shoes…), а z-порядок вычисляется функцией LAYER_Z. Так правила («куртка всегда выше свитера») живут в коде, а не в данных, и не портятся при редактировании.
• **position** сохраняет порядок внутри слоя — важно для нескольких вещей одного типа.
• Пути к файлам детерминированные: documentDirectory/garderob/garments/<id>.png. Это позволяет позже восстановить ссылки после переустановки/синхронизации: id — он же ключ в облаке.
• Миграции через PRAGMA user_version. Добавление таблицы = новая константа MIGRATION_N и инкремент версии.

Синхронизация (этап 2, когда появится бэкенд)

Контекст: один пользователь, 2–3 устройства, картинки по 1–3 МБ, правки редкие.

• Бэкенд: Supabase (Postgres + Auth + Storage + RLS) или собственный Postgres + S3-совместимое хранилище. Edge-функции для тяжёлых вызовов (cutout, VLM).
• Outbox. Любая локальная запись пишется в sync_outbox(entity, entity_id, op, payload, created_at) в той же транзакции. Отдельный воркер отправляет пачками и помечает отправленные. Гарантия «не потеряли правку».
• Версии. У каждой строки rev INTEGER и deleted_at. Сервер принимает запись, только если rev больше текущего — идемпотентно при ретраях.
• Конфликты. Last-write-wins по строке: для одного пользователя этого достаточно. Исключение — outfit_items: они синхронизируются как «набор образа целиком» (replace-all), поэтому конфликт разрешается по outfits.updated_at.
• Картинки грузятся асинхронно после строки, по content hash; на клиенте показывается локальный файл. Скачивание — по требованию, сначала миниатюра.
• Курсор — серверное время последнего pull; клиентские часы не используются.

Приватность и безопасность

Фото одежды — чувствительные данные: по ним видно, что человек носит, где живёт (по фону), какого он телосложения.

• По умолчанию — только на устройстве. Облачные провайдеры вырезания/распознавания выключены, пока пользователь явно не согласится (в MVP их вообще нет).
• Шифрование: iOS — Data Protection (файлы недоступны при заблокированном экране), Android — EncryptedFile/Keystore. Пароли/токены — Keychain/Keystore.
• Минимум данных на сервере: облако получает только вырезанные PNG и теги, оригинальные фото остаются локально.
• Юрисдикция. Если целевой рынок — РФ, персональные данные хранятся в РФ (152-ФЗ): Yandex Cloud / VK Cloud, уведомление РКН, политика обработки. Если глобально — EU-регион (GDPR): DPA с Supabase/AWS, право на удаление, экспорт данных.
• Удаление аккаунта — каскадное: строки в БД + объекты в Storage + анонимизация аналитики. Пользователь должен получить это одной кнопкой.
• Обучающие данные: в политике явно указать, что фото не используются для обучения моделей. Это конкурентное преимущество, а не формальность.

Производительность

Наблюдаемость

• Sentry: крэши, ANR, медленные транзакции, breadcrumbs «какой шаг конвейера упал».
• PostHog/Amplitude, ключевые события:
• garment_added {provider, cutout_quality, duration_ms, category}
• garment_retake {reason}
• outfit_created {items_count, duration_ms}
• outfit_saved, outfit_shared
• body_profile_updated
• Метрика качества вырезания в проде: доля garment_retake + ручные правки категории.

CI/CD

• EAS Build — облачные сборки iOS/Android без локальных тулчейнов.
• EAS Update — OTA для JS-правок между релизами (не для нативных изменений).
• GitHub Actions: pnpm typecheck, pnpm test:core, линт, сборка preview на PR.
• Каналы: development (внутренние), preview (TestFlight/Internal testing), production.
• Версионирование: app.json version + autoIncrement для build number.

Что менять при росте

1. ML-сервис на GPU (Modal/RunPod/Fly.io) с очередью и вебхуками: cutout → качество, VTON → рендеры.
2. Нативный модуль для сегментации (iOS Vision, Android ML Kit) — быстрее и точнее JS-алгоритма, работает в реальном времени.
3. CDN для картинок и миниатюр.
4. Разбиение ядра на пакет @garderob/core для веба и сервера.

03 · AI-конвейер

03. AI-конвейер

Здесь описано, что происходит с фотографией от нажатия на кнопку до вещи на манекене, и какие модели/сервисы для этого нужны. Порядок именно такой: сначала дешёвое и обязательное, потом дорогое и опциональное.

фото → контроль качества кадра → вырезание фона → нормализация PNG
     → распознавание (теги) → опорные точки (шаблон категории) → вещь в гардеробе
                                                              ↘ по запросу: генеративный рендер образа

1. Захват и контроль качества

Мусор на входе даёт мусор на выходе, поэтому камера не просто снимает — она проверяет кадр.

Что просим у пользователя (и показываем в камере):

• однотонный фон, контрастный вещи (белая футболка — на тёмном, чёрные брюки — на светлом);
• ровный свет, без прямой лампы и жёстких теней;
• вещь целиком в кадре, расправлена, без заломов;
• съёмка сверху, телефон параллельно поверхности.

Автопроверки кадра (на устройстве, до отправки):

Эти проверки стоят копейки (те же проходы по пикселям, что и вырезание) и снимают 80 % неудачных добавлений.

2. Сколько ракурсов реально нужно

Пользователь предполагает, что «придётся фотографировать с разных ракурсов». Это верно не всегда, и важно не перегрузить его.

Решение: MVP просит один кадр. Спинку и деталь — опционально, кнопкой «добавить ракурс», они не блокируют сохранение и используются для тегов и будущего рендера. 3D-реконструкцию вещи не делаем: пользователь не будет снимать свитер 20 раз, а без этого 3D-модель не получится.

3. Вырезание фона

Это самая ответственная часть: плохой край убивает впечатление от всего приложения.

Уровни (в порядке включения)

Почему не начать сразу с облака: задержка 1–3 с на каждую вещь и зависимость от сети убивают сценарий «добавить 20 вещей за вечер». Локальный путь даёт 1–2 с и ноль счетов, а на правильном фоне результат сопоставим.

Постобработка (обязательна при любом провайдере)

1. Эрозия альфы на 1 px — убирает светлый ореол от фона.
2. Despill — для полупрозрачных пикселей цвет восстанавливается как C = (P − (1−α)·B) / α, иначе по краю остаётся цветной контур.
3. Сглаживание края (box blur по альфе) — против «лесенки».
4. Обрезка по bbox с полями 2–3 px — вещь занимает весь кадр карточки.
5. Нормализация: длинная сторона ≤ 1024 px, PNG (альфа обязательна), sRGB.

Ручная страховка

Кисть «стереть/вернуть» поверх альфы. Автоматика ошибается на 10–15 % вещей (мех, кружево, прозрачные ткани, блики). Без ручной правки пользователь просто выбросит вещь.

Как измеряем качество

• Golden set: 300 реальных фото (разные фоны, ткани, принты, цвета).
• Метрики: IoU маски, F1 по краю, доля «принято без правок».
• Прогон на каждом изменении алгоритма и при смене провайдера.
• В проде: доля пересъёмок и правок кистью по каждой категории.

4. Распознавание вещи (теги)

Нужно, чтобы пользователь не заполнял 10 полей руками.

**Схема ответа (совпадает с src/core/tags.ts):**

{
  "name": "белая рубашка оверсайз",
  "tags": {
    "category": "top",
    "subcategory": "рубашка",
    "colors": ["#f2f2ef", "#d8d5cc"],
    "pattern": "solid",
    "material": "хлопок",
    "seasons": ["spring", "summer", "autumn"],
    "warmth": 2,
    "formality": 4
  }
}

Как получаем:

• VLM со structured output (JSON Schema): GPT-4o-mini / Gemini Flash / Qwen-VL — что дешевле и доступно на рынке. Важно: temperature 0–0.2, few-shot примеры, строгая схема, ответ валидируется zod.
• Промпт содержит категорию, которую пользователь уже выбрал (если выбрал) — это резко повышает консистентность.
• Кэш по хешу изображения: повторная обработка не стоит денег.
• Стоимость: $0.0005–0.003 за вещь (≈ $0.1–0.3 на гардероб из 100 вещей, единоразово).

Локальная альтернатива (реализована): доминирующие цвета гистограммой + разумные значения по категории. Бесплатно и мгновенно, но не понимает материал и фасон. Используется, когда сервис не настроен.

Эмбеддинги (этап 2): текст-эмбеддинг описания каждой вещи → «похожие вещи», «собери капсулу», «не дубль ли это» при покупке.

5. Персональный аватар

Три уровня, включаются по возрастанию сложности:

Решение: A сейчас, B — как платная функция после MVP, C — только если продукт уйдёт в 3D. Для A важна не «реалистичность», а узнаваемость пропорций: пользователь двигает ползунки и видит, что силуэт меняется как его собственный.

6. Генеративная примерка (фотореалистичный рендер)

Не в MVP, но архитектуру надо заложить сразу, иначе потом больно.

Как работает: VTON-модель получает изображение человека (или сгенерированной модели) и изображение вещи, возвращает человека в этой вещи. Мульти-вещь — последовательные проходы: сначала верх, потом низ, потом верхняя одежда, с масками регионов.

Кандидаты: FASHN, Photoroom, Google Vertex AI Virtual Try-On, self-hosted IDM-VTON / CatVTON / OOTDiffusion на Replicate/fal/Modal.

Что важно знать заранее:

• Латентность 5–20 с → только асинхронно: задача в очереди, пуш «образ готов».
• Цена $0.02–0.10 за рендер → это платная функция, а не бесплатная.
• Модель галлюцинирует: теряет принт, меняет крой, добавляет складки. Поэтому рендер всегда подписан как «визуализация», а рядом остаётся честный 2D-образ.
• Лицензии: у части API запрещено использовать для коммерческих примерок или тренировать на результатах — проверить до интеграции.
• Приватность: фото человека уходит в облако → отдельное согласие, возможность удалить.

Архитектура: клиент → edge-функция render-outfit → очередь → воркер с GPU → Storage → пуш. Клиент получает job_id и подписан на статус. Никаких синхронных запросов из приложения.

7. Стоимость на активного пользователя

Оценка на месяц (100 вещей, 30 образов, 10 генеративных рендеров):

Итого переменные расходы ≈ $0.6–1.0 на активного пользователя в месяц. При подписке $4.99 маржа здоровая, если не давать рендеры без лимита.

8. Чего не делать

• 3D-реконструкция вещи по фото. Дорого, медленно, требует много ракурсов. Пользователь не будет.
• Собственная модель сегментации с нуля. Использовать готовые (BiRefNet/SAM/Vision/ML Kit), дообучать только если упрёмся.
• Realtime-примерка на видео. Отдельная тяжёлая задача, не нужна продукту.
• Обучение на данных пользователей. Юридически и репутационно дорого, выгоды на старте нет.

04 · Движок посадки

04. Движок посадки

Как вещь, снятая на телефон, оказывается на листе коллажа и — в режиме «Манекен» — садится по фигуре, а не просто масштабируется.

Код: apps/mobile/src/core/ (body.ts, rig.ts, tps.ts, mesh.ts, outfit.ts), рендер: src/components/OutfitCanvas.tsx.

0. Два режима одного листа

В обоих режимах одна система координат, поэтому переключение не ломает данные: при смене режима вещи переставляются (collagePlacement в коллаже, identity-трансформ в манекене — дальше их ставит TPS).

1. Система координат

Всё считается в виртуальном канвасе 1000 × 1500 (портрет 2:3), затем масштабируется под ширину экрана. Так пропорции не зависят от устройства, а тесты работают с целыми числами. Формат 2:3 выбран под коллаж: он читается как вертикальный постер и целиком влезает на экран телефона.

• Фигура занимает y ∈ [50, 1450], x симметрично вокруг 500.
• Вещь приходит как PNG с прозрачным фоном, её координаты — пиксели изображения.
• Опорные точки вещи заданы в пикселях изображения, опорные точки фигуры — в канвасе.

2. Антропометрия → силуэт

Пользователь задаёт 5 чисел: рост, плечи, грудь, талия, бёдра. Из них строятся полуширины:

heightScale = clamp(170 / heightCm, 0.85, 1.15)
shoulderHalf = 165 · heightScale      // ≈ 0.118 высоты фигуры
pxPerCm      = shoulderHalf / (shouldersCm / 2)

bustHalf  = clamp(chestCm  · 0.16 · pxPerCm, shoulderHalf·0.55, shoulderHalf·0.86)
waistHalf = clamp(waistCm  · 0.17 · pxPerCm, bustHalf·0.60,    bustHalf·1.05)
hipHalf   = clamp(hipsCm   · 0.18 · pxPerCm, waistHalf·1.00,   shoulderHalf·1.15)

thighHalf    = hipHalf · 0.44
calfHalf     = thighHalf · 0.62
upperArmHalf = shoulderHalf · 0.24

Коэффициенты 0.16/0.17/0.18 — перевод обхвата во фронтальную ширину (обхват ≈ π · ширина, с поправкой на то, что торс не круглый). Они подобраны так, чтобы при 88/70/96 см получалась правдоподобная фигура, и проверяются тестами на монотонность: увеличили талию — силуэт стал шире.

Базовое значение полуширины плеч (165 px при высоте фигуры 1400 px) — это 0.236 от высоты, то есть размах плеч ≈ четверть роста, как у живого человека. Первая версия использовала 62 px (0.09 высоты) — фигура получалась непропорционально вытянутой; это исправлено.

Вертикальные пропорции фиксированы (доли роста):

Силуэт собирается из путей: торс — замкнутая Catmull-Rom кривая по 13 точкам, руки и ноги — толстые штрихи с круглыми концами (два сегмента на конечность, чтобы была видна сужающаяся голень/предплечье), голова — эллипс, волосы — 2–3 фигуры позади/поверх.

3. Опорные точки

24 точки, общие для фигуры и вещи (LandmarkId):

headTop chin neckL neckR shoulderL shoulderR armpitL armpitR
bust waistL waistR hipL hipR crotch kneeL kneeR ankleL ankleR
toeL toeR elbowL elbowR wristL wristR

У фигуры они вычисляются из метрик. У вещи — из шаблона категории: где на типичной футболке находятся плечи, проймы и низ, в долях от bbox вещи.

Это ключевое решение: одна и та же вещь автоматически «знает», где у неё плечи, и ей не нужна ручная разметка при добавлении. Пользователь может поправить точки позже (следующий этап), но по умолчанию — ноль действий.

4. Деформация: thin plate spline

Аффинного преобразования (масштаб + сдвиг) недостаточно: у людей разная талия и бёдра, и футболка должна сузиться в талии, но остаться широкой в плечах. Нужна нелинейная деформация по опорным точкам.

TPS минимизирует энергию изгиба и точно проходит через заданные пары точек:

f(p) = a₀ + a₁x + a₂y + Σ wᵢ · U(|p − cᵢ|),   U(r) = r² ln r

Коэффициенты находятся из системы:

[ K + λI   P ] [ w ]   [ v ]
[ Pᵀ       0 ] [ a ] = [ 0 ]
Kᵢⱼ = U(|cᵢ − cⱼ|),  Pᵢ = [1, xᵢ, yᵢ]

Реализация (tps.ts):

• Нормализация координат. Перед решением точки центрируются и масштабируются в диапазон ~[−1, 1]. Без этого матрица плохо обусловлена (пиксели — сотни, r² ln r — десятки тысяч), и решение «плывёт».
• Регуляризация λ ≈ 0.002–0.004. Если пользователь поставил две точки почти в одно место, матрица вырождена. λ делает деформацию мягче и гарантирует решение; при этом опорные точки воспроизводятся с точностью ~0.01 px (проверено тестом).
• Fallback. Меньше 3 точек или вырожденная матрица → аффинное приближение (перенос + масштаб), приложение не падает.

Почему TPS, а не кусочно-аффинное по триангуляции: при 6–10 точках триангуляция даёт заметные изломы на стыках треугольников, TPS — гладкую поверхность. Цена — O(n³) на решение, но n ≤ 10 и считается один раз при изменении профиля.

5. Сетка и рендер

Вещь нельзя рисовать как один прямоугольник с текстурой — текстуру надо «натянуть» на деформированную поверхность. Поэтому:

1. Вокруг вещи строится регулярная сетка cols × rows (плотность зависит от размера: cols ≈ w/110, от 4 до 16; rows ≈ h/110, от 6 до 24).
2. Каждый узел прогоняется через TPS → координаты в канвасе.
3. Текстурные координаты узлов остаются в пикселях исходной картинки.
4. Skia рисует это как Vertices с ImageShader — GPU-текстурированные треугольники.

Итог: вещь изгибается по фигуре, край остаётся резким (текстура сэмплируется с линейной фильтрацией), всё рисуется в 60 fps.

6. Трансформации поверх деформации

Каждая вещь дополнительно имеет transform { x, y, scale, rotation }. Он применяется вокруг центра bbox вещи:

translate(x + cx, y + cy) · rotate · scale · translate(−cx, −cy)

где (cx, cy) — центр bbox. Такая семантика позволяет:

• свободным вещам (сумка, аксессуар) задавать позицию центра в канвасе;
• масштабировать вещь от центра, чтобы она не «уезжала»;
• двигать пальцем, не меняя посадку.

7. Слои

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

under 5 → lower 10 → full(платье) 25 → upper 30 → knit 40 → outer 50 → shoes 55 → bag 60 → accessory 70

Так куртка всегда выше свитера, свитер выше рубашки, обувь выше брюк. Пользователь может скрыть вещь или убрать её, но не «сломать» физику слоёв. Валидатор образа дополнительно подсказывает неочевидное (платье + низ, две вещи в слое «верх»), но не блокирует сохранение.

8. Честные ограничения 2.5D

Путь к 3D (если продукт туда пойдёт): SMPL-X как тело → параметрические 3D-модели одежды (CLO/Marvelous Designer, шаблоны по категориям) → скиннинг по телу → cloth simulation на устройстве (или запечённая анимация). Это в 10 раз дороже по контенту: на каждую вещь нужна 3D-модель, а не фото. Поэтому 2.5D — правильная точка старта.

9. Инварианты и тесты

npm run test:core проверяет:

1. TPS точно воспроизводит опорные точки (ошибка < 0.01 px).
2. TPS переносит и точки между опорами, а не только их.
3. Сетка: (cols+1)(rows+1) вершин, 2·cols·rows треугольников.
4. Деформированная сетка накрывает фигуру, а не исходный прямоугольник.
5. Плотность сетки ограничена сверху (защита от тормозов).
6. Монотонность антропометрии: больше талия → шире силуэт; выше рост → уже в фиксированном канвасе.
7. Симметрия и порядок опорных точек (плечи выше талии, талия выше бёдер…).
8. Шаблоны есть у всех категорий с одеждой.
9. Слои: платье между низом и трикотажем.
10. Валидатор образа ловит отсутствующую вещь и конфликты.

Это тесты на математику, а не на UI: они гоняются в Node за 50 мс и ловят регрессии при изменении коэффициентов.

05 · План

05. План

Где мы сейчас

Готов рабочий прототип ядра: путь «сфотографировал → вещь в гардеробе → собрал образ на своём манекене» реализован целиком, офлайн, без единого API-ключа. Это не макет: вырезание фона, антропометрия, TPS-посадка и рендер работают, математика покрыта тестами.

Что это даёт: можно за неделю показать продукт живым людям и проверить главный риск — «будут ли люди фотографировать свою одежду». Всё остальное (аккаунты, облако, платежи) добавляется поверх, не переписывая ядро.

Этапы

Этап 0. Валидация — 2 недели

Цель: понять, стоит ли строить, до больших затрат.

• 15 интервью с целевой аудиторией.
• Golden set 300 фото вещей, замер качества вырезания.
• Тест прототипа на 10 людях: сколько вещей добавят, где бросают.
• Лендинг с ценой, замер готовности платить.

Выход: решение go/no-go, список 5 главных проблем UX.

Этап 1. MVP-ядро — 6 недель

Цель: приложение, которым можно пользоваться неделю и не бросить.

• Полировка камеры: автопроверки кадра, подсказки, повторная съёмка.
• Ручная кисть правки маски (без неё 10–15 % вещей не добавить).
• Редактор опорных точек вещи (сейчас только шаблон).
• Миниатюры и оптимизация памяти (300+ вещей).
• Онбординг: 3 экрана, создание «себя», первая вещь.
• Пустые состояния, ошибки, восстановление после сбоя.

Выход: внутренняя сборка, 10 пользователей, неделя использования.

Этап 2. Бета — 4 недели

Цель: выход в TestFlight / Play Internal.

• Нативная сегментация: iOS Vision, Android ML Kit, локальный алгоритм как fallback.
• VLM-теги через свой edge-сервис (категория, цвет, материал, сезон).
• Аккаунты (Apple/Google) + синхронизация local-first (outbox, LWW).
• Sentry, аналитика, события качества.
• Облачный cutout для сложных фото по кнопке «улучшить».

Выход: 100–300 бета-пользователей, метрики активации и D7.

Этап 3. Релиз — 3 недели

• Подписка (RevenueCat или нативные IAP), пейволл, восстановление покупок.
• ASO: иконка, скриншоты, описание, ключи.
• Политика конфиденциальности, удаление аккаунта, возрастной рейтинг.
• Поддержка: почта + FAQ, обработка жалоб на контент (если появится шаринг).
• App Store / Google Play review, исправление замечаний.

Выход: публичный релиз.

Этап 4. Post-MVP — 8 недель

Приоритет по данным, а не по желанию:

1. «Образ дня» по погоде и календарю (главный ежедневный сценарий).
2. Фотореалистичный рендер образа (платно, асинхронно).
3. Капсулы и чемодан.
4. Шаринг образов / совместный гардероб.
5. Фотореалистичный аватар по фото.

Итого

Трудозатраты до релиза ≈ 14–16 человеко-месяцев. Деньги зависят от ставок: при blended $4–6k/мес это $60–95k, при инхаус-команде — фонд оплаты труда за 4 месяца.

Инфраструктура на старте: Supabase $25–100/мес, Sentry $26/мес, аналитика $0–50/мес, GPU-сервис — по факту использования ($0, пока рендеры выключены).

Definition of Done для релиза

• Новый пользователь без подсказок добавляет 5 вещей и собирает образ за первую сессию.
• 85 %+ вещей сохраняются без пересъёмки.
• Приложение работает офлайн полностью, кроме платных рендеров.
• Холодный старт < 2 с, добавление вещи < 20 с на среднем устройстве.
• Крэш-фри ≥ 99.5 %.
• Данные удаляются по запросу, политика опубликована.
• Есть метрики активации, D1/D7/D30 и воронка добавления вещи.

Риски и что делаем

Что делать на этой неделе

1. Собрать golden set из 50–100 фото реальных вещей (свои шкафы, друзья) — без него нельзя оценивать качество.
2. Прогнать прототип на 5 людях: замерить time-to-add и долю пересъёмок.
3. Проверить нативную сегментацию на iOS 17+ и Android: сравнить с локальным алгоритмом на golden set.
4. Решить по бэкенду: Supabase или свой стек (влияет на этап 2).
5. Собрать dev-build через EAS и проверить на реальных устройствах (Skia + камера).