DCTL

Самая важная модель DCTL — разделять host и script. Fusion-нода обеспечивает подключение изображения, выбор установленного DCTL и запуск кода; математический алгоритм живёт во внешнем файле. Поэтому две одинаковые DCTL-ноды с разными scripts могут выполнять совершенно разные задачи.

DCTL не равен LUT. Обычная 1D/3D LUT хранит таблицу заранее вычисленных значений и интерполирует между ними, тогда как DCTL содержит исполняемый код и напрямую вычисляет преобразование изображения на GPU.

Blackmagic описывает DCTL как C-подобный язык. Простая transform-signature может получать RGB одного пикселя и возвращать float3, а spatial-варианты способны работать с размером кадра, координатами и texture sampling. Поэтому сводить DCTL только к цветовой матрице неправильно.

В Resolve DCTL является внешней runtime dependency. Проект не содержит магическим образом весь выбранный код: если на другой станции отсутствует нужный файл, изменена его версия или Resolve не видит нужную LUT/DCTL-папку, воспроизводимость результата теряется.

Resolve 21 Reference Manual относит DCTL Resolve FX к Studio-only возможностям. Если композиция должна открываться в Free edition, нужен отдельный fallback или заранее отрендеренный результат — сам факт наличия ноды не отменяет edition dependency.

Интерфейс DCTL host следует сверять с целевой сборкой Resolve: выбранный script может менять Controls динамически, а UI Color page и Fusion не обязан совпадать. Поэтому визуальные примеры должны быть привязаны к конкретной версии и exact script.

При состоянии DCTL = NONE пользовательский transform не выбран. Это полезный baseline, но не основание обещать byte-perfect passthrough всех каналов на любой версии: критические alpha/auxiliary cases всё равно следует проверять live.

После выбора конкретного script Inspector может получить дополнительные controls, которые этот DCTL публикует. Их набор не универсален: один файл может не добавлять ничего, другой — sliders, toggles, integer/float controls или selector-подобные параметры.

Script-defined controls нельзя переносить в общую документацию DCTL host как постоянные параметры. Даже два DCTL с похожим назначением могут иметь разные ranges, defaults и математику под одинаково звучащими названиями.

Settings — это общая вкладка Fusion-ноды. Она не является универсальным контейнером параметров DCTL-script. Динамические controls выбранного script относятся к его host UI на Controls и должны документироваться вместе с конкретной версией файла.

Правильное место DCTL в Flow определяется не названием ноды, а signal contract выбранного script. Один transform может ожидать camera Log, другой — scene-linear, DaVinci Wide Gamut/Intermediate, display-referred image или совсем другой технический representation.

Ошибочный input state часто выглядит как слишком сильный contrast, неверная gamma, clipping или странная saturation. Лечить это следующим ColorCorrector опасно: сначала нужно проверить, не применён ли transform дважды и соответствует ли upstream signal ожиданиям DCTL.

Output DCTL остаётся обычным 2D image stream. Его можно передавать в ColorCorrector, Merge, Viewer, MediaOut и другие 2D-ноды, но смысл RGB/Alpha после processing принадлежит конкретному script contract.

Простые DCTL-примеры из документации демонстрируют RGB processing, но не доказывают, что любой сторонний DCTL одинаково сохраняет Alpha, auxiliary channels или data outside nominal 0–1. Для compositing-critical pipeline это отдельная проверка.

Spatial DCTL может читать соседние pixels через texture sampling. В таком случае edge behavior, filtering и coordinate assumptions становятся частью алгоритма и их нельзя описывать как обычный per-pixel LUT-style transform.

DCTL может использовать float math и работать с широкими значениями, но это не означает автоматическую безопасность любого script для HDR/scene-linear data. Код может сам clamp-ить, нормализовать или предполагать диапазон 0–1.

Наличие GPU execution не гарантирует одинаковую производительность у всех DCTL. Сложность кода, количество texture reads, conditional branches, разрешение кадра и GPU существенно влияют на playback и render time.

Для технического transform A/B нужно сравнивать исходный и обработанный branch без изменения upstream/downstream state. Иначе невозможно понять, какой именно stage вызвал отличие.

Смешивать technical transform через Merge Blend 0.5 обычно нельзя считать корректным способом уменьшить его силу. Для creative DCTL это может быть допустимо по замыслу автора, но технические transforms должны ослабляться только способом, который документирован самим script.

Для production DCTL полезно фиксировать exact filename, version и checksum. Один и тот же filename не гарантирует идентичный код на двух workstation, особенно если файл обновлялся вручную.

Файлы .dctle могут быть зашифрованными вариантами DCTL. Для пользователя они остаются внешней зависимостью; отсутствие исходного кода не отменяет необходимости фиксировать точную версию и условия лицензирования/установки.

После добавления нового DCTL Resolve должен увидеть файл в активной LUT/DCTL location. Конкретная операция refresh/restart зависит от host workflow и версии; не следует копировать Color-page кнопки в Fusion UI, если они не подтверждены live.

DCTL Resolve FX доступен на Fusion page как effect-host, но интерфейс Color page и Fusion Inspector не обязан совпадать. Общая статья должна описывать только подтверждённый общий contract и явно отделять host-specific UI.

Если DCTL используется как диагностический false-color, gamut/clipping viewer или exposure aid, его output обычно не предназначен для финального render. Такие ноды стоит явно подписывать DIAGNOSTIC и bypass-ить/удалять перед delivery.

Если DCTL является частью обязательного color pipeline, полезно подписывать IN → OUT state прямо в имени/комментарии ноды. Это снижает риск случайно переставить transform после Merge, CST или display-referred stage.

При использовании нескольких DCTL подряд каждый script получает output предыдущего. Поэтому цепочка должна рассматриваться как последовательность контрактов, а не как набор независимых looks.

Для migration между Resolve builds полезен reference frame со scopes и checksum script. Если результат изменился после update, это помогает отличить изменение кода DCTL от изменения host/GPU behavior.

Автоматизация должна опираться на реально сериализованные input IDs конкретного Resolve build. Display-label DCTL и динамические control names недостаточны для надёжного scripting/macros без экспортированного .setting/.comp.

Итоговая production-проверка DCTL включает четыре независимых вопроса: тот ли script загружен, верен ли input/output signal contract, совпадает ли поведение каналов/границ и воспроизводится ли результат на целевой Resolve/GPU. Только после этого ноду можно считать сертифицированной для pipeline.