Примитивы оптического потока – RAFT против Lucas-Kanade

TL;DR

Optical flow – это попиксельная карта того, куда в следующем кадре переместились все объекты, видимые в текущем. Это тихий workhorse под video stabilization, frame interpolation, multi-object tracking, action recognition, content-aware encoding и почти под каждой моделью video super-resolution в 2026 году. Два эталонных примитива: Lucas-Kanade – алгоритм 1981 года, оценивающий разрежённое motion-поле на нескольких сотнях отслеживаемых corner-точек, работающий на сотнях FPS на CPU и поставляемый как cv2.calcOpticalFlowPyrLK в OpenCV, – и RAFT – deep learning модель 2020 года от Princeton, оценивающая плотное попиксельное flow, получившая ECCV 2020 best paper award и работающая на 9–20 FPS на современной GPU. Эта статья проводит нетехнического читателя через то, что такое optical flow, почему эти два алгоритма находятся на противоположных концах кривой «скорость – точность», когда какой из них выбирать (плюс их современные наследники – DIS для быстрого плотного flow на CPU, FlowFormer и SEA-RAFT для state-of-the-art точности), и как планировать compute-бюджет и выбирать, какой примитив реально нужен видеопродукту. В финале вы сможете спланировать фичу, зависящую от optical flow, грамотно поговорить с инженерами и обойти failure-mode, которые разваливают production-пайплайны.

Зачем это нужно знать

Optical flow – это не фича, которую вы отгружаете пользователям. Это примитив – кирпич, который живёт внутри фич. Multi-object tracker, который ведёт игрока по футбольному полю, использует optical flow, чтобы предсказать, где появится каждый отслеживаемый bounding box в следующем кадре. Video stabilizer на телефоне использует optical flow, чтобы оценить дрожание камеры. Frame interpolator, превращающий 30 FPS-съёмку в 60 FPS для гладкого slow motion, использует optical flow, чтобы изобрести недостающие кадры. Блок temporal alignment внутри BasicVSR++ – open-weight дефолта для video super-resolution – буквально является обученным optical flow estimator. Ошибётесь с примитивом потока – и все downstream-фичи ломаются. Статья для продакт-менеджера, video-platform-инженера или фаундера, которому надо принять build-vs-buy-решение по видеофиче, в инженерном описании которой упоминается «optical flow» – что в 2026 значит – почти по любой.

Ментальная модель: Optical Flow – это поле движения между двумя кадрами

Представьте два последовательных кадра видео, расположенные рядом. На первом – красная машина в левой части дороги. На втором, сделанном через 1/30 секунды, та же машина сместилась на шесть пикселей вправо. Optical flow – это ответ на один вопрос, задаваемый для каждого пикселя: откуда этот пиксель пришёл из предыдущего кадра и куда он переместится в следующем? Ответ – двухмерный вектор для каждого пикселя: горизонтальная и вертикальная компоненты скорости. Карта всех таких векторов называется flow field – полем потока.

Flow field 1080p-видео содержит около двух миллионов векторов. В HD – примерно 920 тысяч, в SD – около ста тысяч. Точно вычислить все эти векторы тридцать раз в секунду – одна из самых сложных задач в области computer vision, и она остаётся предметом непрерывных исследований с 1981 года.

Число яркости – то, что инженеры называют luma value, – для любой точки в кадре 2 предполагается равным яркости в какой-то точке кадра 1. Это допущение – brightness constancy constraint – лежит в основе каждого алгоритма optical flow. Уравнение выглядит как одна строка школьного анализа: I_x · u + I_y · v + I_t = 0. Члены I_x и I_y показывают, насколько яркость изменяется при сдвиге на пиксель вправо или вниз. Член I_t – насколько яркость меняется от кадра 1 к кадру 2 в этой точке. Неизвестные – u и v, горизонтальная и вертикальная скорости. Одно уравнение, две неизвестные – значит, для отдельного пикселя его не решить. Любой алгоритм optical flow в истории – это разные ответы на один вопрос: какое дополнительное допущение я добавлю, чтобы это стало решаемо?

Нажмите, чтобы увеличить

Lucas-kanade – классика 1981 года, которая всё ещё актуальна в 2026

Брюс Лукас и Таэко Канаде из Carnegie Mellon опубликовали свою итеративную технику регистрации изображений в 1981 году. Идея была элегантной: не пытайтесь решить задачу постоянства яркости для отдельного пикселя – вместо этого возьмите небольшое окно пикселей, обычно размером 3×3, 5×5 или 7×7, и предположите, что у всех пикселей в этом окне одинаковое движение. Получается девять, двадцать пять или сорок девять уравнений с двумя неизвестными – переопределённая система, которую решают методом наименьших квадратов. На выходе получается один вектор движения на окно, а не на пиксель, поэтому метод Лукаса–Канаде называют разреженным (sparse-методом).

Соотношение яркость–позиция внутри небольшого окна линеаризовано – то есть алгоритм предполагает, что яркость изменяется в пределах окна достаточно плавно, чтобы её можно было аппроксимировать прямой линией. Это допущение перестаёт работать при больших перемещениях (например, пиксель, сместившийся на двадцать пикселей между кадрами, невозможно описать локальным плавным приближением), поэтому метод Lucas–Kanade в OpenCV реализован в пирамидальной форме: изображение последовательно уменьшается вдвое – до половины, четверти, восьмой части исходного разрешения, – и алгоритм сначала находит движение на самом грубом масштабе, а затем уточняет его на каждом более детальном уровне. Этот приём, предложенный Бугуэ и коллегами в конце 1990-х, расширяет диапазон применимости алгоритма с нескольких пикселей до сотен и более.

В OpenCV эта функция называется cv2.calcOpticalFlowPyrLK. Стандартный подход – сначала обнаружить углы (corners) – точки, где у изображения сильные градиенты в двух направлениях, что и является условием хорошо обусловленного решения методом наименьших квадратов. Для этого используется cv2.goodFeaturesToTrack (детектор углов Ши-Томаси, 1994). Получают список из двухсот–четырёхсот угловых точек, передают оба кадра и этот список в алгоритм Лукас–Канаде – на выходе получают двести–четыреста векторов движения. Весь процесс занимает около 5 миллисекунд на современном CPU при разрешении 720p – примерно 200 кадров в секунду на одном ядре, без использования GPU.

Выход sparse. Если камера панорамирует по сцене с двумястами отслеживаемыми углами, вы узнаёте движение в этих двухстах точках. Ничего не узнаёте о гладкой, лишённой текстур стены позади – там нет градиентов, которые можно было бы отследить. Эта разреженность – одновременно сила модели (она не претендует на измерение того, что измерить невозможно) и её ограничение (задача, требующая оптического потока на каждом пикселе – стабилизация, интерполяция кадров – получит от метода Люка–Канаде недостаточно данных).

Математика вслух для окна 5×5: вы формируете матрицу A размером 25×2, где каждая строка соответствует (I_x, I_y) для одного пикселя окна. Создаёте вектор b длины 25, в котором каждый элемент – это -I_t для соответствующего пикселя. Решаете систему A^T A · v = A^T b относительно неизвестных v = (u, v). Матрица A^T A имеет размер 2×2, матрица A^T b – 2×1; обратная матрица 2×2 вычисляется по аналитической формуле всего за три строки кода. На одну точку приходится около 200 операций с плавающей запятой – поэтому CPU способен отслеживать сотни точек в реальном времени со скоростью 200 кадров в секунду.

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

RAFT – Deep Learning Ресет 2020

Захари Тид и Дзя Дэн из Принстонского университета опубликовали RAFT – Recurrent All-Pairs Field Transforms – в виде препринта перед конференцией ECCV 2020, на которой работа была удостоена награды за лучшую статью. Препринт доступен на arXiv: 2003.12039. Референсная реализация – github.com/princeton-vl/RAFT. Лицензия BSD 3-Clause, совместима с коммерческим использованием.

RAFT не использует brightness constancy напрямую. Вместо этого он выполняет три действия. Во-первых, feature encoder – небольшая свёрточная сеть с шестью residual-блоками – преобразует каждый входной кадр из сырых RGB-пикселей в 256-канальный feature map с разрешением в одну восьмую от исходного. Этот encoder общий для двух кадров: одна и та же сеть обрабатывает и кадр 1, и кадр 2. Отдельный context encoder работает только с кадром 1 и генерирует контекстные признаки, которые направляют итеративное обновление.

Второе: RAFT вычисляет 4D correlation volume. Для каждой фичи на уровне 1/8 в кадре 1 (их H/8 × W/8) он вычисляет скалярное произведение с каждой фичей из кадра 2 (ещё H/8 × W/8). Результат – четырёхмерный тензор формы (H/8) × (W/8) × (H/8) × (W/8), где каждая ячейка показывает, насколько похожа данная фича в кадре 1 на соответствующую фичу в кадре 2. Этот объём затем усредняется на нескольких масштабах (размеры ядра 1, 2, 4, 8), формируя многоуровневую пирамиду корреляций, охватывающую как небольшие, так и крупные движения.

Третье: update operator – рекуррентная нейронная сеть на основе Gated Recurrent Unit – итеративно уточняет оценку потока. Начинает с нулевого потока во всех точках. На каждой итерации она использует текущую оценку потока, чтобы извлечь корреляционные значения из 4D-объёма, смешивает их с контекстными признаками кадра 1 и выдаёт остаточный апдейт потока. После 12 итераций при обучении (20 – на тесте, обычно) оценка потока становится конечным выходом модели.

Цифры точности на стандартных бенчмарках оказались впечатляющими. На бенчмарке Sintel (синтетический датасет на основе Blender-фильмов), в финальном проходе RAFT достиг end-point error 2,855 пикселя – это на 30 % меньше ошибки по сравнению с лучшим ранее опубликованным результатом. На KITTI (реальный датасет с данными с дорог) RAFT показал F1-all error 5,10 % – снижение на 16 %. Модель содержит около 5,3 миллиона параметров в полной конфигурации – немного для 2026 года, но много для 1981-го.

Runtime: на одной NVIDIA 1080 Ti оригинальная реализация обрабатывает кадр размером 1088×436 со скоростью 9 FPS. Уменьшенная версия с одной пятой параметров – 20 FPS. На современном оборудовании, таком как RTX 4090 или A100, эти показатели удваиваются или утраиваются. Follow-up SEA-RAFT (2024, arXiv 2405.14793) – более 20 FPS на разрешении 1080p на RTX 3090. Это real-time производительность для многих задач, под-реальное время для нагрузок с высокой частотой кадров и ключевая инженерная причина, по которой продуктовая команда выбирает RAFT для оффлайн-работ с акцентом на точность, а Lucas-Kanade или DIS – для live-трекинга.

Нажмите, чтобы увеличить

Компромисс между скоростью и точностью, численно

Два алгоритма находятся на противоположных концах кривой, определяющей в 2026 году каждое практическое решение в области optical flow. Цифры ниже – из оригинальной документации OpenCV по Lucas-Kanade, статьи RAFT, статьи DIS и последующих работ SEA-RAFT и FlowFormer.

Несколько наблюдений из таблицы. Lucas-Kanade нельзя напрямую сравнивать на Sintel или KITTI, потому что стандартные бенчмарки оценивают точность плотного оптического потока, а Lucas-Kanade не выдаёт плотный результат. Классические плотные методы – Horn-Schunck, Farnebäck, DIS – значительно уступают RAFT по точности, и этот разрыв только усилился с появлением FlowFormer и его преемников 2026 года. Выбор здесь – между реальной скоростью на CPU (DIS) и высокой точностью глубокого обучения в оффлайн-режиме (семейство RAFT). Для большинства практических задач в видеообработке 2026 года правильный выбор – либо Lucas-Kanade для разрежённого отслеживания в реальном времени, либо SEA-RAFT для плотного оптического потока в оффлайн-режиме. Экзотические варианты имеют узкоспециализированные применения.

Три режима отказа, которые разрушают пайплайны оптического потока

Мы интегрировали optical flow в видеопайплайны по четырём направлениям в Фора Софт – видеоконференции, видеонаблюдение, OTT и аналитику e-learning. В каждом из них возникает три режима сбоев.

Failure 1: Не та разреженность. Команда выбирает Lucas–Kanade для задачи, где нужен поток на каждом пикселе – например, стабилизация видео на телефоне или интерполяция кадров по пикселям для замедленного воспроизведения, – и в ходе тестирования обнаруживает, что стабилизатор «подрагивает» или в slow motion появляются дыры там, где детектор углов ничего не нашёл. Решение – подбирать разреженность под задачу: используйте Lucas–Kanade только для задач, которым действительно нужны разрежённые треки (предсказание рамок в многотелесном трекинге, отслеживание признаков в стиле KLT для визуальной одометрии, разрежённые якоря AR). Всё, что требует плотного потока – стабилизация, интерполяция, super-resolution alignment – нуждается в плотном оценщике, то есть DIS для быстрого CPU-only-пути или RAFT / SEA-RAFT для точного оффлайн-расчёта.

Failure 2: Игнорирование Brightness Constancy. Команда внедряет фичу, зависящую от optical flow, в продукт видеосвязи и обнаруживает, что она катастрофически проваливается на тусклых внутренних звонках и в переговорных с комбинированным освещением. Каждый классический метод optical flow предполагает, что яркость движущейся точки остаётся неизменной от кадра к кадру; это допущение нарушается при агрессивной автоматической экспозиции, в условиях низкой освещённости, когда у камеры высокое (и шумное) аналоговое усиление, а также из-за мерцания люминесцентных или LED-ламп. Исправление двоякое: во-первых, добавьте явный этап фотометрической нормализации перед вычислением optical flow (локально нормализуйте контраст на каждом кадре); во-вторых, отдавайте предпочтение глубоким моделям, таким как RAFT или SEA-RAFT, для входных данных с нестабильной яркостью, поскольку они обучены быть устойчивыми к таким вариациям интенсивности, с которыми классические методы не справляются.

Failure 3: Latency Как Договороспособная Величина. PM оценивает real-time AR-эффект – например, hand-tracked virtual jewelry в видеозвонке – и включает RAFT в пайплайн, потому что «он самый точный». Реальность: RAFT работает на 9 FPS в 30-кадровом пайплайне, внося 100 мс задержки, которые AR-эффект не может компенсировать – виртуальное кольцо заметно отстаёт от руки пользователя. Решение – планировать задержку до точности: sub-100ms real-time pipeline не может позволить себе этап оптического потока на 9 FPS. Точка. Для real-time AR используйте Lucas-Kanade для sparse anchor tracking и лёгкую модель MediaPipe для dense body-part field, либо закладывайте SEA-RAFT и принимайте его 20+ FPS как верхнюю границу пайплайна.

Нажмите, чтобы увеличить

Production-Паттерн – Когда Что Выбирать

В нашей собственной интеграционной работе decision tree прост. Нужен поток на каждом пикселе? Если нет – достаточно небольшого набора feature-точек для трекинга, визуальной одометрии или sparse-якорей – используйте Lucas-Kanade. Он есть в OpenCV, работает только на CPU, обрабатывает до 200 кадров в секунду, а сорок пять лет использования в продакшене означают, что все режимы сбоев хорошо задокументированы.

Если да – пайплайн real-time (видеосвязь, surveillance, AR)? Если да, выбирайте DIS для CPU-only fast path или SEA-RAFT для ускоренного пути с GPU. Если пайплайн работает в оффлайн-режиме (архивное увеличение разрешения, стабилизация в постпродакшне, предварительный проход с content-aware encoding), выбирайте RAFT или SEA-RAFT для точности, а FlowFormer или наследники 2026 года (MegaFlow, FlowIt, DPFlow) – когда точность важнее скорости выполнения.

Нужно ли только направление движения или требуется полная sub-pixel-точность? Для распознавания действий и многих пайплайнов отслеживания по детекции достаточно направления – подойдут DIS или Farnebäck. А для выравнивания при видео-суперразрешении, интерполяции кадров и стабилизации важна именно sub-pixel-точность – в таких задачах стоит выбирать глубокие модели.

Проблема «разработать самому или купить готовое» в случае optical flow почти не возникает. Все основные алгоритмы доступны как open-source под permissive-лицензиями: Lucas-Kanade в OpenCV (Apache 2.0), DIS в OpenCV-contrib (Apache 2.0), RAFT под BSD 3-Clause, FlowFormer под MIT, SEA-RAFT под BSD 3-Clause. Нет коммерческого вендора optical flow, чей продукт был бы настолько лучше open-source state-of-the-art, чтобы оправдать затраты на интеграцию. Исключением является NVIDIA Optical Flow SDK – его стоит учитывать: он использует специализированное hardware-ускорение для optical flow на GPU архитектуры Turing и новее, обеспечивая детерминированный, low-латентный dense flow при минимальных вычислительных затратах. Для real-time-задач на оборудовании NVIDIA Optical Flow SDK – часто оптимальный выбор; для переносимых open-source-решений – RAFT или SEA-RAFT.

Где Здесь Фора Софт

В Фора Софт мы интегрировали optical flow в видеопайплайны для таких направлений, как видеосвязь, видеонаблюдение, OTT и электронное обучение. В видеосвязи мы применяем метод Lucas–Kanade для разреженного трекинга ключевых точек лица под AR-эффектами в реальном времени, где жёстко ограничен бюджет задержки, а плотный поток не требуется. В системах видеонаблюдения используем DIS для генерации предложений о движущихся областях – выделения фрагментов кадра, сместившихся настолько, чтобы оправдать запуск более ресурсоёмкого multi-object tracker, – и RAFT для оффлайн-анализа инцидентов в целях расследования. В OTT-платформах применяем поток уровня RAFT на этапе content-aware encoding pre-pass для масштабирования архивных материалов, сочетая его с BasicVSR++ на стадии суперразрешения. Мы не проводим собственные исследования в области optical flow: мы интегрируем современные open-source решения в коммерческие видеопродукты, которые поставляются и активно используются.

Ключевые тезисы

• Optical flow – это поле движения на уровне пикселей между двумя последовательными кадрами; это базовый примитив для задач отслеживания, стабилизации, интерполяции и повышения разрешения.
• Lucas-Kanade (1981, разреженный, 20 кадров в секунду на CPU) и RAFT (2020, плотный, 9–20 FPS на GPU) – две ключевые точки отсчёта; всё остальное лежит где-то на кривой между ними.
• Выбирайте плотность в соответствии с задачей: разреженный поток подходит для трекинга, плотный – для стабилизации и интерполяции.
• В 2026 году для реального времени с плотным потоком используйте DIS на CPU или SEA-RAFT на GPU; для оффлайн-точности – RAFT, FlowFormer или их преемников 2026 года.
• Принцип постоянства яркости – допущение, лежащее в основе каждого классического алгоритма, которое первым нарушается при мерцании, слабом освещении или агрессивной автоматической экспозиции.
• Учитывайте задержку перед точностью: этап optical flow с частотой 9 кадров в секунду не вписывается в пайплайн реального времени с частотой 30 кадров в секунду.

Что читать дальше

• Multi-object tracking – DeepSORT, ByteTrack, OC-SORT – использует sparse optical flow как upstream-источник для предсказания движения между bounding box'ами.
• Real-ESRGAN / BasicVSR++ для OTT archive upscaling – применяет dense optical flow внутри блока распространения BasicVSR++ в качестве downstream-компонента.
• Vision Transformer primer для video ИИ инженеров – архитектурное семейство, лежащее в основе transformer-основанных моделей потока (FlowFormer, MegaFlow).

Talk To Us / Кейсы / Скачать

• Поговорить с видеоинженером – забронировать 30-минутный call для обсуждения фичи, зависящей от optical flow.
• Посмотреть наши кейсы – изучить проекты WebRTC, surveillance и OTT, в которых мы интегрировали optical flow в пайплайн.
• Скачать picker по оптическим алгоритмам – одностраничный печатный шаблон, который сопоставляет требования вашей фичи по sparsity, latency и accuracy с одним из шести production-алгоритмов optical flow и указывает вычислительный бюджет на кадр для каждого.