Интервью с командой ONYX Ai Matte

Для меня ONYX был прежде всего возможностью заняться чем-то новым. В монтаже и композитинге заказов становилось всё меньше, а программирование мне нравилось всегда. Я начал с Python, потом перешёл к C++ и C#. Для ONYX сознательно выбрал C++: он ближе к железу и лучше подходит для такой интеграции. Увидев Python-прототип Алексея, я сразу подумал: из этого можно сделать нормальный рабочий инструмент.

Я пришёл в ONYX из compositing, из ежедневной работы с кадром. Вообще мы с Евгением оба художники, просто в какой-то момент разошлись по разным направлениям. Я остался ближе к шотам, маскам и применению нейросетевых инструментов в production, а Евгений всё глубже уходил в программирование и инженерную часть.

На один и тот же инструмент мы смотрим по-разному. Я сразу примеряю его к конкретному шоту: быстро ли получу результат, смогу ли его нормально контролировать и что буду делать, когда автоматика ошибётся. Евгений в этот момент думает об архитектуре, скорости и стабильности. Потом мы спорим, проверяем друг друга и ищем вариант, который выдерживает обе проверки.

В самой идее я убедился ещё на первой Python-версии: маски такого качества и с такой скоростью я раньше просто не получал. А вот попытка передать плагин другим людям быстро отрезвила. Рабочий прототип для себя и продукт, который можно поставить на чужую машину, – совсем не одно и то же. Тут без инженерного подхода Евгения дальше было не пройти.

Мы хотели убрать одну из самых тягучих частей compositing: найти объект, провести его через весь шот, получить маску, а потом вылавливать места, где она поплыла, задрожала или зацепила фон. Красивого результата на одном кадре было мало. Нужен был процесс, с которым можно пройти весь шот, поправить ошибку и спокойно продолжить comp.

Алексей собрал первый MVP на Python и доказал, что сама идея работает. Я уже переводил её в полноценный C++-продукт. Тут и выяснилось, что модель – только одна часть задачи. Вокруг неё нужны cache, corrections, управление памятью и, главное, предсказуемое поведение внутри Nuke.

Что именно подтолкнуло к первому MVP, лучше расскажет Алексей – это была его идея. Меня зацепила возможность соединить мощный движок на SAM3 с программой, в которой мы сами работаем каждый день. Не делать абстрактную технологию, а улучшить собственный workflow.

Какого-то одного кадра, после которого я решил писать плагин, не было. Просто одна и та же проблема повторялась снова и снова. Появился первый SAM, затем SAM2, а более-менее управляемой площадкой для экспериментов у меня оставался ComfyUI. Были Rotobrush в After Effects, Mask ML и другие инструменты, но у каждого – свои ограничения. Иногда борьба с ними раздражала сильнее, чем ручная работа.

С ComfyUI всё быстро пошло глубже: Linux, Python, устройство моделей, разные способы их связать. Открылся огромный мир, и я начал постоянно пробовать новые варианты, а не просто запускать готовые workflow.

Как лаборатория ComfyUI был прекрасен: можно разобрать всё по нодам, заменить модель и сразу увидеть, что изменилось. Но каждый реальный шот снова требовал подготовки материала и сборки окружения. Для эксперимента это нормально, для ежедневной production-работы – уже слишком много лишних действий.

К выходу SAM3 уже стало понятно, что всё это можно поднять на другой уровень и перенести основные этапы работы с маской прямо в привычный pipeline. Без постоянных походов в ComfyUI, огромных графов, отдельной подготовки видео или sequence и вечной возни с лимитами памяти.

Когда я разобрался, как устроены SAM3 и refiner-модель VitMatte, оказалось, что многие ограничения по памяти вполне обходятся. Примерно за две недели я собрал первую версию плагина для Nuke – со своим интерфейсом и оптимизациями. И вот тогда произошёл настоящий перелом: настолько быстро и качественно маски я до этого не делал.

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

Тогда я окончательно понял: пора переходить на OFX и превращать эксперимент в продукт. Мы с Евгением к тому моменту уже плотно общались. В начале нового года я закрыл старый репозиторий, и мы начали делать ONYX AI Matte вместе.

Алексей ставит задачу со стороны кадра и проверяет результат в реальном compositing. На мне C++-движок, производительность, стабильность и вся инженерная реализация. Есть ещё группа тестеров: они используют ONYX в работе и без церемоний говорят, чего не хватает. Такие запросы мы обсуждаем вместе. У нас нет схемы, где один пишет ТЗ, а второй молча кодит. Технические ограничения меняют workflow, а опыт художника постоянно переставляет инженерные приоритеты.

Часто в интерфейсе появляется именно то, чего не хватало тестерам. Самый наглядный пример – кнопка Go to Init Frame, о ней подробнее в вопросе 11. Таких вроде бы мелочей за время тестирования набралось много, но именно из них и складывается удобство.

В итоге мы всё время сводим две вещи: что реально экономит время на шоте и что можно надёжно запустить на обычной рабочей станции. На этом стыке ONYX и стал продуктом.

Сначала я настаивал на отдельном интерфейсе, как в моей Python-версии. Он был заточен под SAM3, а refiner жил отдельной нодой с кучей настроек. Можно было подробно управлять краем и памятью – как раз этого мне не хватало в похожих инструментах. И видеопамяти моя версия ела заметно меньше.

Когда перешли к OFX, мы долго спорили об интерфейсе. Я хотел отдельное окно, примерно как у Neat Video. Евгений предлагал оставить всё в нативном overlay самого хоста.

В итоге я согласился с ним – и теперь рад, что согласился. Художник не открывает ещё одно окно и не прыгает между интерфейсами: всё основное происходит прямо поверх кадра в той программе, где он уже работает.

Правда, у такого решения есть потолок. Для более сложных функций возможностей OFX и интерфейсов отдельных хостов может уже не хватить, и тогда придётся делать собственное приложение. Мы это понимаем. Но для нынешней версии плагина нативный overlay оказался удобнее.

Эта история хорошо показывает, как мы работаем. Ни моя идея, ни идея Евгения не получает автоматического преимущества. Мы спорим, упираемся в реальные ограничения и в конце оставляем то, с чем удобнее работать на шоте.

Главная проблема – память. Модели тяжёлые, и уложить их вместе в 6 гигабайт VRAM без потери стабильности было непросто. На слабых видеокартах мы добились надёжной работы именно в этом бюджете. На мощных всё быстрее, потому что уже не приходится настолько жёстко экономить память.

Вторая часть – адаптация моделей к нашему pipeline. Это длинная цепочка, и точность важна на каждом шаге. Собрать все компоненты последовательно, не потеряв качество между ними, оказалось отдельной большой инженерной задачей.

В первых экспериментах с segmentation казалось, что задача почти решена: указал объект, быстро получил маску, на отдельном кадре всё выглядит убедительно. Но стоило положить объект на другой фон, и сразу становилось видно: найти объект и получить production-ready край – две разные задачи.

В волосах исчезали детали, motion blur превращался в жёсткий обрез, полупрозрачность либо пропадала, либо становилась непрозрачной. И даже геометрически точная маска после merge могла сразу выдать себя из-за spill, grain или focus, не совпадающих с новым фоном.

На стоп-кадре часть этих проблем ещё можно не заметить. Но стоит запустить playback или немного изменить фон, и край начинает жить отдельно от объекта. Для compositor именно это и есть настоящая проверка, а не красота alpha в отдельном viewer.

Но в compositing вообще далеко не всегда нужна идеальная маска всего объекта. Гораздо чаще, чем принято думать, нужна «грязная» служебная маска под одну операцию. После chroma key мне, например, может понадобиться только кожа актёра, чтобы применить despill именно к ней и не обводить область вручную. Для таких вещей ONYX очень удобен.

Ещё одно наблюдение из практики: SAM3 стабильнее, когда получает одну понятную область – один смысл или материал. Просишь человека, он и ищет человека. Рюкзак, сумка или другой предмет на нём для модели уже отдельный объект. Когда пытаешься насильно склеить несколько разных сущностей в один выбор, результат часто начинает плавать.

Под это в ONYX появились разные режимы выбора. Можно попросить модель захватить больше того, что относится к человеку, а можно, наоборот, точкой сузить задачу до конкретной области. Таких мелких открытий при изучении SAM3 было очень много. Потом они постепенно превращались в реальные настройки плагина.

В итоге я для себя чётко разделил процессы. Segmentation отвечает за то, что мы вообще нашли нужный объект или область. Matting возвращает частичную alpha на волосах, motion blur, расфокусе, стекле. А финальный край всё равно оценивается только в кадре – после merge и обязательно в движении.

Отсюда выросла и логика ONYX: сначала найти объект и провести его через шот, потом отдельно заняться пиксельным краем. Причём refiner не привязан к маске самого ONYX. Через Refiner Direct в него можно подать готовое roto или результат другого инструмента.

SmartRoto и ONYX не заменяют друг друга напрямую. В SmartRoto сохраняется классическая логика roto: художник строит spline-shapes, а AI помогает переносить их между правильными состояниями. ONYX через Refiner Direct может подхватить результат дальше и заняться уже пиксельным краем. Грубо говоря, SmartRoto определяет, куда движется форма, а ONYX – как выглядит её финальный край. В production полезны оба подхода.

Вначале для нас это вообще был большой эксперимент. SmartRoto и похожие продукты решают свою задачу, а мы пошли другим путём: не просто маска объекта, а маска плюс отдельное уточнение края. Теперь люди пишут, что используют плагин каждый день, значит, направление оказалось рабочим.

Сама схема простая. Сначала pipeline находит объект и строит маску, затем refiner доводит край до рабочего качества. Мы специально разделили эти шаги: segmentation может идеально найти объект и всё равно грубо обрезать волосы или полупрозрачность. А раз refiner существует отдельно, ему можно дать любую готовую tracked mask – из Mocha, обычного roto или другого источника – и работать только с краем.

Магии в ONYX нет. Волосы, мех, motion blur, полупрозрачность и сложные края на быстром движении в практике держатся хорошо – мелкие искажения там просто не считываются. А на статике, наоборот, может стать заметно, что край дрожит. У refiner пока нет темпоральной памяти между кадрами, поэтому на спокойном шоте flicker виден лучше. Мы и говорим о быстрых первых 60–80% работы, а не об автоматическом финале для любого кадра.

При этом именно в этих 60–80% раньше и сидела основная рутина. Теперь художник получает хорошую стартовую точку и уже решает, где добавить holdout, где пройтись refiner, а где быстрее закрыть проблему коротким ручным shape.

С инженерной стороны самое неприятное – связанность системы. Добавляешь фичу или правишь один участок, а ошибка вылезает совсем в другом месте. Тронул одну связь – проверяй всё, что к ней подключено. Иначе здесь нельзя.

ONYX не всесилен. Иногда быстрее и надёжнее нарисовать маску руками, причём, как ни странно, у меня это часто статичные объекты. Если форма почти не меняется, я быстро строю обычный shape, трекаю его по шоту и отправляю готовую маску в Refiner Direct. ONYX в таком случае нужен уже для края.

Результат получается понятным и стабильным: форма и движение остаются под моим контролем, а сложный пиксельный край не приходится восстанавливать вручную. Заставлять segmentation решать то, что обычное roto закрывает за несколько минут, смысла нет.

Другое ограничение появляется, когда объектов слишком много. Если свалить в один выбор разные части, SAM3 начинает путаться, теряет разделение и даёт нестабильный результат. Пока это ограничение самой модели, поэтому в одной ноде ONYX можно создать до 16 объектов. Нужно больше – лучше разнести задачу по нескольким нодам.

И вмешательство художника здесь не сводится к ремонту плохой маски. Иногда самое правильное решение – вообще не включать segmentation на конкретной части кадра. Стабильную основу сделать руками, а ONYX оставить ту работу, где он действительно экономит время: refinement и финальный matte.

Лучше всего получаются крупные объекты. Входное разрешение SAM3 – 1008 на 1008, поэтому кадр приходится кропать. В оригинальной реализации SAM3 такого механизма нет, его мы придумывали сами.

Слабое место – мелкие объекты. На таком разрешении детали и небольшие отверстия исчезают. Если несколько объектов стоят близко, они тоже могут слиться.

Ещё модель пока не видит отдельные торчащие волосы за пределами основного силуэта. Над этим мы сейчас работаем.

Я бы вообще не делил шоты на «подходящие» и «неподходящие» для ONYX. Для меня здесь работает старое правило: разделяй и властвуй. Не надо пытаться вынуть из кадра всё одной маской. Как и в обычном roto, шот лучше разложить на понятные части.

Художнику так проще не потерять контроль, а модель точнее понимает запрос. Один объект или область с общими свойствами SAM3 определяет стабильнее, чем смесь разных предметов и материалов. Модель за такую постановку задачи тоже скажет спасибо. Потом маски спокойно складываются, вычитаются и пересекаются уже в comp.

Волосы, например, я с самого начала выношу в отдельную задачу. Не пытаюсь одной маской получить человека, одежду, аксессуары и причёску. Иногда добавляю точные garbage masks, чтобы ограничить область поиска. При нормальной подготовке волосы достаются хорошо.

С motion blur проблема чаще возникает позже, на refinement. Там многое зависит от erode и dilate; на сложном шоте их приходится анимировать. Иногда я уменьшаю рабочее разрешение видео, и refiner лучше схватывает размытую границу. Это уже не «нажал и готово», но процесс остаётся контролируемым.

Для простого статичного объекта с понятной геометрией я сразу выберу обычное roto: нарисую shape, протрекаю его и подключу ONYX только на край. Не вижу смысла уговаривать segmentation сделать то, что другой инструмент делает быстрее.

В keying мы всегда работали примерно так. На одном шоте у меня бывало до девяти типов служебных масок: от грубого garbage matte до отдельных масок на кожу, despill или доработку motion blur. Опытный compositor знает, что «маска объекта» – это редко одна маска и одна задача.

Самый сильный результат получается, когда художник не перекладывает на ONYX весь сложный кадр сразу, а заранее понимает: эту часть выгоднее сделать segmentation, эту – refiner, а эту – обычным roto.

У меня workflow начинается не с ноды ONYX, а с вопроса: что вообще нужно от этого шота? Финальная маска всего объекта, отдельно волосы, holdout, кожа для despill, зона motion blur или просто грубое отделение от фона?

От ответа зависит количество масок и задача каждой из них. И уже после этого я выбираю способ: где нужны segmentation и tracking ONYX, где быстрее обычное roto, а где достаточно отправить готовую маску в Refiner Direct и заниматься только краем.

Обычно я указываю объект, провожу его через шот и смотрю, где результат сломался. Если на нескольких кадрах потерялась часть объекта или прилип фон, добавляю correction points только там. Хороший участок tracking при этом не трогаю. Дальше собираю маски через add, subtract и intersect, отдельно настраиваю refiner, проверяю и делаю bake.

На сложном материале приходится подбирать crop, trimap, gamma, erode и dilate, иногда анимировать их по шоту. Бессмысленно просто крутить всё подряд. Нужно видеть, какую именно ошибку исправляет каждый параметр.

Волшебной кнопки пока нет. Поставить плагин, не прочитать документацию и ждать идеального результата – плохая тактика. ONYX раскрывается, когда понимаешь его компоненты, входы и заранее делишь кадр на задачи.

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

SAM3 изначально вообще не проектировали для compositing. Нам пришлось строить вокруг модели адаптивную обвязку, которая и с хостами совместима, и compositor'у понятна. По сути это переводчик в обе стороны: объясняет модели, что от неё хотят, а художнику даёт привычный способ этим управлять.

ONYX не требует выбрасывать инструменты, которые уже есть в pipeline. Анимированную маску художника или другой системы можно передать в Refiner Direct. Segmentation и tracking повторять не придётся – ONYX займётся пиксельным краем.

Его можно поставить после обычного roto, SmartRoto, Silhouette или похожего инструмента. Редактируемые spline-shapes остаются там, где нужны студии, а ниже по цепочке ONYX работает с волосами, мехом, полупрозрачностью и финальным matte. После bake это обычная последовательность файлов.

Отдельная боль – поддержка OFX разными хостами. В Nuke плагин может получить произвольный кадр таймлайна, а в DaVinci Resolve через OFX доступен только кадр под playhead. Поэтому некоторые вещи из Nuke физически нельзя один в один повторить в DaVinci. В нашей работе Nuke даёт плагину через OFX больше нужных возможностей. Мы это различие не выбирали, оно приходит от конкретного хоста.

В инженерных решениях приходится постоянно лавировать и выжимать из OFX максимум. Не каждая наша идея в него помещается. К этой теме мы ещё вернёмся в roadmap.

Я часто работаю с масками из Silhouette, и никаких проблем с таким обменом у меня нет. Строю и трекаю формы в Silhouette, экспортирую их в Nuke и подключаю к нужному входу ONYX.

Если форма и движение уже готовы, повторять segmentation и tracking незачем. Маска идёт в Refiner Direct, а ONYX занимается motion blur, полупрозрачностью и деталями, которые одной spline-формой нормально не передать.

Есть и второй вариант: запустить ONYX прямо в standalone Silhouette как OFX-плагин. Из-за ограничений хоста там доступен не весь функционал, но refiner и text prompt работают. Можно построить маску и сразу же обработать её, не переходя в другое приложение.

На моих шотах refiner ONYX часто давал более чистый и удобный для дальнейшего comp результат, чем встроенный refiner Silhouette. Но это именно мой опыт, а не лабораторный рейтинг. На motion blur, волосах и других типах края сравнение может выглядеть по-разному, поэтому я бы всегда проверял на конкретном материале.

Мне как раз нравится, что привычный инструмент не приходится менять. Silhouette остаётся сильной в построении и tracking форм, ONYX подключается там, где нужен более качественный край. Это дополнительное звено pipeline, а не попытка заменить всё сразу.

Ключом стало распределение памяти между моделями. Все сразу они не помещаются, поэтому мы сделали переключение: в каждый момент загружено только то, что сейчас нужно. Благодаря этому достаточно 6 гигабайт VRAM, а пиковое потребление обычно даже ниже 5. Это было самое сложное инженерное решение в этой части.

GTX 1080 Ti тоже хотели поддержать, но здесь, к сожалению, не получилось.

Для меня главное преимущество локальной работы очень простое: материал больше не нужно гонять через внешний workflow. С ComfyUI я конвертировал EXR в PNG-sequence, отдельно всё загружал, настраивал граф, получал результат и тащил его обратно в comp.

В ONYX подключаю исходный footage и сразу выбираю объект. Я остаюсь в Nuke, вижу маску в контексте шота и тут же понимаю, годится ли она для нужной операции.

Для меня это не только экономия на конвертации. Я не теряю контекст: рядом остаются key, grade, despill и остальная часть comp. Поэтому решение о качестве маски принимается там, где она действительно будет использоваться, а не в отдельном тестовом окружении.

Очень удобно исправлять отдельные кадры. Даже если результат уже frozen, я могу снять freeze, поправить один кадр и заморозить его снова. Нужный файл перезапишется; повторять весь внешний цикл подготовки и импорта не придётся.

Единственного «правильного» workflow у нас нет. Даже beta testers работают по-разному: один сначала полностью заканчивает tracking, другой исправляет проблемные места сразу, третий по-своему организует freeze и bake. Мы наблюдаем за этим и не хотим загонять всех в один сценарий.

Если появляется предложение, которое нужно людям и которое реально сделать, мы его обсуждаем. ONYX всё ещё активно развивается. У меня как у человека, с идеи которого всё началось, задумок меньше не стало; некоторые мы уже разбираем вместе с Евгением. Детали пока рано раскрывать, но работы впереди много.

У нас есть группа тестеров, которые постоянно используют ONYX в реальной работе и честно рассказывают, что им нравится, а что нет. Правда, в последнее время говорят в основном хорошее :)

Кнопки Go to Init Frame сначала вообще не было. Тестеры вручную искали нужное состояние и попросили: сделайте уже кнопку, которая сразу туда переносит. Сделали.

Потом был спор вокруг Locked Init Frame: залоченный режим устраивал не всех. В итоге вместо двух вариантов появились три – динамический, статический и вообще без Init Frame. Для надёжного восстановления сохранённого проекта и tracking лучше всего работает статический. Динамический не так точно поднимает прежнее состояние, и восстановить tracking сложнее. Но мы оставили все три режима, потому что люди действительно пользуются ими по-разному.

Начать стоит с документации на сайте, хотя бы чтобы понять, из каких частей состоит продукт. У ONYX больше возможностей, чем видно при первом запуске, и входы лучше изучить все. Мало кто, например, сразу замечает, что можно подавать саму маску – mask prompt довольно мощный инструмент. А Refiner Direct умеет принять уже склеенные объекты с видимыми границами и сгладить стыки.

Полноценные туториалы тоже будут, но сейчас нам банально не хватает на них времени. Если кто-то из сообщества хочет заняться записью, я готов подробно пройтись по всем возможностям плагина, а дальше можно оформить материал вместе. Желание поделиться знаниями есть, не хватает часов в сутках.

Я бы начинал не с «идеального тестового шота», а с понимания самого плагина. Документация большая, это правда, но прочитанное очень быстро превращается в рабочие приёмы. Без этой базы даже простой тест легко создаёт неправильное впечатление об ONYX.

Вот типичная ситуация. Новичок выбирает человека с рюкзаком. SAM3 находит человека, а рюкзак оставляет за бортом, потому что считает его отдельным объектом. Пользователь начинает добавлять точки, пытается «расширить» человека до рюкзака, и в какой-то момент модель путается и хватает лишнее.

Здесь нужно различать новый объект и уточнение уже выбранного. Рюкзак лучше создать отдельно, провести через шот и потом объединить маски. Correction points решают другую проблему: возвращают потерянную часть выбранного объекта или исключают фон, который модель прихватила по ошибке.

С refiner тоже стоит разобраться отдельно. Его ползунки задают ширину и глубину переходной зоны вокруг маски. Внутри неё модель ищет мягкий край, partial alpha, motion blur, волосы и мелкие детали. По сути художник говорит refiner, насколько далеко смотреть по обе стороны исходной границы.

Для первого упражнения я бы взял короткий шот с крупным человеком и отдельным предметом, тем же рюкзаком. Выбрал человека, создал рюкзак вторым объектом, провёл оба через шот и попробовал correction points на нескольких кадрах. Потом объединил маски и отдельно покрутил refiner, чтобы своими глазами увидеть, как ширина его рабочей зоны влияет на мягкий край и детали.

Люди с опытом roto обычно схватывают эту логику быстрее: сложный кадр всё равно делится на контролируемые участки. Плагин ускоряет процесс, но сначала нужно понять, из каких масок складывается результат и какую часть края должен анализировать refiner.

Хотим решить общую проблему refiner с темпоральной памятью. Это уже отдельное направление разработки, и о деталях пока рано говорить. Скорость тоже будем увеличивать: из текущей архитектуры выжали почти всё, но новые технологии могут дать следующий прирост.

Ещё одно направление – собственный UI вне OFX. Сейчас интерфейс OFX серьёзно нас ограничивает, вдобавок каждый хост поддерживает его по-своему.

В идеале хочется прийти к действительно однокнопочному ONYX: нажал и получил хорошую маску на любой объект. Сейчас мы уже близко, но не везде. Есть идея модуля автоматического поиска: указываешь папку, а он сам находит объекты по семантике, без ручного выделения. Идей много; чаще всего в потолок мы упираемся именно из-за интерфейса OFX.

Пока отвечал на это интервью, сам яснее сформулировал один приоритет: сначала нужно понимать, зачем вообще делается конкретная маска. Идей для ONYX у нас море, но прежде чем добавлять следующую фичу, мне хочется внимательнее посмотреть на сами типы масок и на то, как художники используют их в живой работе.

Конечно, всем хочется волшебную кнопку: нажал – и получил красивую идеальную маску. Только одной универсальной маски не существует. Под словом «маска» скрывается целый набор задач, и далеко не каждой нужна идеальная обтравка объекта с идеальным краем.

В compositing одна маска грубо отделяет объект, другая ограничивает despill кожей актёра, третья помогает восстановить motion blur или волосы. Бывает depth mask для работы с глубиной кадра, бывает отдельная область для локальной коррекции света. Чем дольше работаешь, тем больше находишь таких неочевидных применений. И свойства везде нужны разные.

Поэтому со стороны художника мне интересна не только автоматическая генерация. ONYX должен помогать правильно сформировать нужные области, дополнить их и собрать несколько специализированных масок в контролируемый результат. То есть учитывать не только объект, но и назначение маски.

Одна из идей, которую мы изучаем, – локальное управление refiner на разных участках одной маски. Сейчас настройки действуют на весь контур. Но в настоящем шоте здесь может быть жёсткий край одежды, рядом волосы, а дальше сильный motion blur. Одни параметры на всё это сразу – неизбежный компромисс.

Направление я теперь вижу так: ONYX должен быть не одной кнопкой segmentation, а гибким набором способов работать с разными масками. Пусть автоматика быстро закрывает рутину, но художник всё равно должен иметь возможность сказать, какую задачу решает эта маска и как её обрабатывать.

Когда мы начинали ONYX, я думал в первую очередь о скорости получения маски. Сейчас смотрю шире: результат работы – не маска сама по себе, а решённая задача кадра.

AI-инструменты будут забирать повторяющиеся механические операции и ускорять то, что раньше часами делалось руками. Но compositor никуда не исчезает. Наоборот, от него сильнее требуется понимание кадра: как разделить задачу на маски, какой инструмент выбрать, где автоматика ошиблась и в какой момент лучше вмешаться вручную.

И скорость не должна автоматически удешевлять работу. За ней стоят дорогие GPU, софт, обучение и годы опыта. Клиент платит не за то, сколько часов человек просидел перед монитором. Он платит за решённую задачу, ответственность и знания, благодаря которым результат вообще удалось получить быстро.

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

Больше всего меня беспокоит привычка заказчика считать только часы и всё время давить в сторону «дешевле и быстрее». Так легко обесценить труд и студий, и фрилансеров. Если профессия, которая требует долгого обучения и дорогого оборудования, перестанет нормально кормить человека, опытные специалисты просто уйдут. В какой-то момент работать доставщиком или сантехником действительно окажется выгоднее, чем заниматься VFX. Для индустрии это очень плохой сценарий.

Как разработчики инструмента мы должны ускорять рутину, не пряча профессиональные решения от художника. Хороший AI-инструмент даёт больше возможностей и контроля. Он не превращает сложную работу в дешёвую автоматическую услугу.

Мы хотели убрать рутину – и во многом её убрали. Вместе с ней меняется сама работа. Человеку остаётся понять задачу, заметить ошибку и вовремя остановить автоматику. Инструмент должен ускорять эти решения, а не прятать их.

Для VFX влияние AI я оцениваю положительно: процессы становятся быстрее. И мы ещё в самом начале. Модели пока плохо адаптированы к ограниченной памяти и обычным пользовательским видеокартам. Но разработки идут так быстро, что compositing, монтаж, cleanup и другие части работы скоро могут измениться до неузнаваемости. По сути, начинается новая эпоха цифрового кино и видео.

Информация о продукте есть на onyxofx.com, документация – на onyxofx.com/docs. За обновлениями можно следить в Discord ONYX, там же обсуждаем практическую работу: discord.gg/yTDenMD95j.

Мой LinkedIn: linkedin.com/in/evgeniy-shatskiy-497999237. Алексей: linkedin.com/in/al-azarov-555255387.

Мы открыты к общению. Если не ответили сразу, значит, скорее всего, просто не успели. Но стараемся никого не терять – ни в support, ни в Discord, ни в LinkedIn.