Мы открыли и разрабатываем новый способ обработки информации - TAPe (Theory of Active Perception, Теория активного восприятия). Работаем над ней давно, результаты мягко говоря впечатляющие, постепенно начинаем ими делиться. Немного писали о Теории на Хабре здесь. Исторически мы начали именно с обработки видео (когда-нибудь об этом расскажем).
В этой статье покажем результаты сравнения разных методов обработки видео (гистограммы, Фурье, структурной похожести, ML-модели) и TAPe в задаче сегментации видео. TAPe в области компьютерного зрения - это Майк Тайсон и/или Майкл Джордан среди любителей (хорошо, еще не Майк Тайсон, но уже вполне себе Рокки Бальбоа). На фоне методов Теории даже супер прокаченные модели на стероидах растерянно сидят в углу ринга. (Ладно, пока что это все влажные мечты, мы даже еще не вышли толком на ринг; но, как мы помним, главное – это величие замысла).
План такой: сначала вобьем в крышку гроба всей ML-индустрии расскажем и покажем результаты TAPe. Затем - о результатах тестирования "стандартных математических" методов, потом покажем результаты десятка ML-моделей. Отдельную главу посвятим DINOv2. Будет много наглядных графиков и видео.
Краткий ликбез про I-фреймы и проблему автоматического деления видео на сцены
Одной из главных целей существования видеокодеков и причина их вариации заключается в экономии места - "сосредоточение" труда в их разработке всегда была компрессия данных, чтобы передача видео занимала как можно меньше памяти, при этом не снижая качества самого исходного видео.
Довольно прорывной фишкой в этом деле является концепция кадров типа IDR (Instantaneous Decoder Refresh), также называемых I-кадрами или I-фреймами. В этом году ей исполняется уже 23 года – для инноваций в области технологий, пожалуй, звучит удивительно. Со времен далекого 2003 года принцип работы I-кадров почти не изменился: для передачи видео необязательно передавать совершенно каждый кадр. В зависимости от того, насколько видео динамичное, можно описывать кадры как определенный "базовый" кадр, а затем серию изменений в частях этого кадра по мере продолжения видео, вплоть до того, пока этих изменений не станет настолько много, что от изначального кадра не останется почти ни одной оригинальной части. В каком-то смысле схема очень похожая на то, как меняются сцены в фильме. Например, 10-ти часовое видео высыхания краски на стене можно описать буквально парой I-фреймов, сэкономив таким образом память в тысячи раз.
Фундаментальный вопрос в том, каким образом мы вообще можем определить момент, в который нам необходимо "вставить" I-фрейм – то есть, когда можно посчитать, что произошла смена сцены? Эту задачу пытались решать многие, различными способами (использованием пикселей напрямую, использованием гистограмм, а также другими комплексными математическими расчетами, замедляющими первоначальную обработку видео). Так, например, эта задача являлась очень важной для YouTube и Google во время разработки ими кодека AV1, который используется сегодня на платформе. По большому счету, задачу (или уже проблему?) так и не решили.
Мы попробовали эту задачу решить с помощью TAPe и в наших экспериментах результаты показались нам хорошими. Тогда мы решили сравнить различные методы нахождения ключевых кадров.
Для тестирования мы использовали DBSCAN/HDBSCAN
Для более простой и стабильной обработки для этой задачи мы использовали "простое" ПО для кластеризации данных DBSCAN. Разделив кадры на определённые кластеры, мы смогли увидеть способность различных видов данных описать исходное видео и передать информацию о сценах - то есть о "похожести" кадров видео друг с другом – для нахождения натуральных границ между ними.
[Для тех, кто не в курсе: DBSCAN (Density-based spatial clustering of applications with noise, плотностной алгоритм пространственной кластеризации с присутствием шума) анализирует плотность данных и на ее основе делит их на кластеры. В Quora есть хорошее объяснение принципов работы DBSCAN на примере кластеризации толпы людей на празднике.]
Алгоритм кластеризации из массива данных выделяет определенный сегмент. Такой алгоритм никоим образом не создан для видео, для картинок, а создан для информации в широком смысле слова. Когда ему скармливают данные, DBSCAN из большого массива данных выделяет кластеры, которые близки друг другу по некоему условно центральному значению. Мы же взяли алгоритм кластеризации, чтобы проверить, как он справится с кластеризацией именно видео. Видео – это те же самые данные с какими-то параметрами.
Было интересно посмотреть, какие параметры алгоритм кластеризации сам сможет взять, если мы ему отдадим просто сырое видео. А также, как он разделит видео на сцены, если мы поможем ему всевозможными, нам известными, способами: в первую очередь, отдадим ему видео не в виде файла и даже не в виде пикселей, а преобразованное в простую кодировку с помощью известных нам математических методов, которые используются сегодня повсеместно в задачах компьютерного зрения, а также с помощью ML-моделей и методов TAPe. Эти кодировки мы и отдали в DBSCAN, чтобы осмотреть, как с помощью разных методов DBSCAN сможет разделить это видео на кластеры (в данном случае кластеры – это сцены, сегменты).
Для теста мы отдавали реальное видео – эпизод из «Интерстеллара» (но, увы, не легендарный момент "It's impossible! - No, it's necessary"). По результатам тестов мы построили графики "работы" каждой кодировки, а также получили видео, как та или иная кодировка поделила эпизод на сцены. Все их можно посмотреть ниже.
Какие параметры мы сравнивали
Во время тестов мы естественным образом выделили несколько ключевых параметров, по которым можно сравнить кодировки:
Время построения индекса или время получения исходных данных
Размер файла, который получается в результате
Время получения кластеров
Качество кластеризации. Эмпирический параметр, который мы не оцифровывали. Мы смотрели на то, правильно или неправильно разделены сцены видео. Это видно, что называется, невооруженным глазом.
Почему в итоге использовали HDBSCAN
После получения первых результатов мы решили использовать HDBSCAN – иерархическую вариацию DBSCAN, потому что иначе данные для НЕ-гистограмных методов не было возможности нормализовать.
В HDBSCAN параметр EPS определяется автоматически. Общими параметрами для анализов всех методов были:
min_cluster_size - это минимальная длина сцены. Выставленная как 36 кадров или же 1.5 секунды;
min_samples - минимальное количество кадров, находящимися друг с другом по соседству в каждом кластере. Выставленное как 12 (то есть равное половины секунды).
Это позволило контролировать, чтобы каждый кадр в сцене похож на N-ное количество других кадров в этой же сцене, и исключить попадание в них шума.
Самые большие изменения отмечаются в первой сцене, где нормализованные значения приводят к более высокому (и, как кажется, правильному) скоплению кадров. Также в ненормализованных кадрах DBSCAN находит больше "мусора". Последняя сцена в каждом видео состоит из фрагментов, которые DBSCAN не смог отнести ни в какую-либо другую сцену. В ненормализованных версиях наблюдается самая большая разница между этими кадрами.
РЕЗУЛЬТАТЫ ТЕСТОВ
TAPe работает с видео на порядки лучше любой другой кодировки, включая многомиллиардной (в долларах) DINOv2 (да и v3, но об этом мы расскажем в другой статье).
Итак, мы провели следующие эксперименты с TAPe – "схлопывание" каналов RGB и по NTSC (0.299 ∙ Red + 0.587 ∙ Green + 0.114 ∙ Blue, стандарту, по которому это происходит в большей части программ по типу ffmpeg или каких-либо видеоплееров).
Результаты:
Получение исходных данных: 10-11 секунд;
Анализ полученных данных: 1 сек (самая быстрая из ML-моделей - DINOv2, больше 20 сек);
Вес файла: меньше 1 Мб (у ML-моделей - мегабайты);
Параметры, шт. (!) - не раскрываем. Меньше на несколько порядков, чем у ML моделей и "традиционных" методов. У ML - миллионы параметров.
Точность: оказался ближе всех. Точно выделил сцены, оставил мало шума.
Графики и видео:
Скорость анализа сигнализирует о том, что данные TAPe коррелируют друг с другом и несут смысловую нагрузку. И эта скорость анализа для TAPe – 1.25 секунды, как раз потому, что значения для каждого кадра "осмысленные". Поэтому HDBSCAN во время анализа не приходилось возвращаться к предыдущим кадрам для перерасчёта, к каким "кластерам"/группам кадров они должны относиться. Фактически, данные TAPe настолько прямо позволяют классифицировать каждый кадр, что в их значениях нет нюанса о том, что кадр одинаково (или близко к этому) относится к двум разным группам кадров.
Второй момент, который хочется отдельно отметить: при использовании "сырого" видео даже анализ двух минут видео приводит к использованию 300 Гб оперативной памяти для полной загрузки видео в память. Во время работы мы загружали видео частями, что не является проблемой с т.з. чистоты эксперимента. Но интересно заметить, что даже в базовых действиях TAPe показывает огромную эффективность как в скорости передачи информации, так и в ее объеме и наполнении смыслом. Во-первых, в TAPe каждый кадр несе�� в себе намного больше информации, чем кадр сырого видео. Во-вторых, при этом TAPe позволяет передать эту информацию, используя данные, которые весят в десятки тысяч раз меньше.
Теперь переходим к результатам "традиционных математических" методов и ML-моделей.
Нашей задачей не было сравнить их все между собой и выявить "лучшую". Мы хотели честно сравнить TAPe со всеми доступными нам методами, чтобы наглядно продемонстрировать эффективность TAPe по сравнению с любыми другими. Но в итоге получилось довольно любопытное соревнование разных моделей, так что кому интересно - могут внимательно изучить таблицы и графики ниже.
Гистограммы, Фурье (не справился), HOG, Sobel и другие
Мы провели тестирование для следующих "традиционных" кодировок:
Гистограммы для вариаций, состоящих из 8, 16, 32 и 64 оттенков серого;
Edge detection по Собелю (оператор Sobel);
Edge detection по Кэнни (оператор Canny);
Optical Flow (расчёт движения кадров, используя их разницу);
Гистограмм Ориентированных Графиков (Histogram of Oriented Gradients, HOG);
Deep Learning Features (CNN-based, VGG16) - модель на ML, собирающая с кадров всевозможные параметры;
Структурной похожести;
Анализ с использованием Быстрой Трансформации Фурье.
Время построения индекса, сек | Время получения кластеров, сек | Размер индекса (вес файла), Мб | Количество параметров | Вес каждого параметра, байт | |
Гистограммы 8 | 27.32 | 13.35 | 6.5Мб | (8*8*8) = 512 | 4 |
Гистограммы 16 | 26.64 | 111.72 | 52Мб | (16*16*16)=4096 | 4 |
Гистограммы 32 | 26.82 | 1003.64 | 411Мб | (32*32*32)=32768 | 4 |
Гистограммы 64 | 28.72 | 9458.78 | 3.3Гб | (64*64*64)=262144 | 4 |
Sobel | 18.23 | 4277.93 | 3.2Гб | 129600 | 8 |
Canny | 14.13 | 4227.2 | 407Мб | 129600 | 1 (целое число) |
Optical Flow | 2958.72 | 8739. | 3.2Гб | 259200 | 4 |
HOG | 530.43 | 2225.93 | 1.7Гб | 67968 | 8 |
ML | 507.90 | 774.99 | 315Мб | 25088 | 4 |
Структурная похожесть | 1181.052 | >10000 | 51ГБ | 2073600 | 8 |
Фурье | 77.65 | >10000 | 9.6ГБ | 388800 | 8 |
Гистограммы
Результаты, с которыми проработали на данный момент - через представление кадров в виде гистограмм N-ного количества оттенков серого в черно-белом изображении каждого кадра. Для этого каждый кадр мы преобразовали в черно-белое изображение, где каждый пиксель представляет собой определенный оттенок серого, с яркостью от 0 (черный) до 255 (белый). Затем для каждого подтипа гистограмм N = (8, 16…128) мы разделили весь возможный диапазон значений в кадре (0-255) на N равных интервалов или "корзин" путём целочисленного деления этого диапазона на N. Таким образом, например, для N=8:
Пиксели со значениями 0–31 попадают в корзину № 1
Пиксели со значениями 32–63 попадают в корзину № 2
И так далее до корзины №8
Мы попробовали разные значения этого коэффициента N (от него зависело в какие "корзины" по округлению попадали пиксели по оттенкам). По итогу самые интересные значения - это 16 и 128.
При значении = 16 и использованию NTSC было твёрдое деление на сцены, по количеству сцен даже похоже на деление TAPe, и многие сцены выглядят "адекватно". Но часть сцен была посчитана похожей, потому что на них было много пикселей одинакового цвета. Например, сцены, где показан белый корабль, система посчитала похожими со сценами, где были астронавты в белых костюмах.
То есть точность заметно ниже, чем при использовании TAPe, при этом с использованием коэффициентов анализа, найденных так же, как и при анализе TAPe. Но самая большая проблема в том, что буквально половина кадров были отброшены DBSCAN как кадры, не обладающими достаточным количеством признаков, чтобы определить их в конкретный кластер.
При том же значении в 16 и использованию среднего значения по каналам выявилась ещё одна проблема – гистограммы очень нестабильные. Использование среднего значения привело к ещё большему количеству "шума" (непризнанных кадров), а также уравниванию кадров, которые не должны быть похожи друг на друга в целом.
Здесь у нас закрались подозрения, что результаты для гистограмм быстро “рассыпаются” при увеличении корзин, что означает, что гистограммы 16 – это наилучший достижимый для гистограмм результат, потому что обладает максимально возможным количеством данных, которые не запутывают DBSCAN. Поэтому мы решили проверить другие значения "корзин". Самые показательные результаты были для 128: при использовании NTSC количество сцен просто значительно убавилось, а при использовании усреднения DBSCAN уже был настолько запутан в данных, что смог определить всего одну сцену – в случае, когда на экране очень много белых пикселей. Всё остальное было признано "шумом".
Ниже приведены гистограммы NTSC с коэффициентами 16 и 128, которые сравниваются с гистограммами average, то есть со своими усредненными значениями с такими же коэффициентами - 16 и 128.
Видео “Гистограмма-16”-NTSC:
Видео “Гистограмма-16”-average:
Гистограммы направленных градиентов
В последнюю очередь мы проверили модель Sobel Edge Detection. DBSCAN "теряется" в измерениях:
Этот способ мы заменили использованием HOG, результаты (отражены ниже) также получились очень нестабильными. HOG используется в распознавании объектов, но как видно из результатов – через этот способ сложно проводить анализ с объектами, формы которых не чёткие/однозначны (например, скафандры в видео, показанные под определённым углом).
Видео HOG:
Графики Canny и Optical Flow:
График и видео Deep Learning Features VGG16:
ML-модели
Мы использовали ML-модели, работающие с видео и которые есть открытом доступе. Нам была важна:
- Осмысленность проведения относительно быстрого анализа, без необходимых затрат на дорогое оборудование (откуда и запуск на CPU);
- Осмысленность их пред-трейнинга для задачи. Поэтому большая часть моделей в списке мобильные (то есть, использованные в мобильных камерах телефонов) - они просто предтренированы как раз на реальных, повседневных изображениях, а значит, представляется, что сумеют дать хороший ответ в видео.
Все эксперименты проведены с одинаковым набором данных и одинаковой системой анализа. Для анализа мы использовали HDBSCAN с одинаковыми параметрами кластеризации, зависящий только от минимальной длины сцен (1 секунда).
Для тестов выделили 16 ядер CPU Intel Core Xeon E5-2697 (стандартный серверный процессор), в остальном же модели не были ограничены (по памяти и т.д.). TAPe данные же были рассчитаны на одном ядре этого же CPU (с использованием средств SIMD, но всё равно на одном ядре; другие методы тоже используют SIMD, насколько это для них самих возможно).
Все алгоритмы, кроме TAPe, используют несколько ядер и написаны на C++.
Все алгоритмы, кроме TAPe и ML, являются частью библиотеки opencv (cv2).
Входные данные для ML-моделей (пиксельное представление каждого кадра в необходимом разрешении, а также полученные эмбеддинги) получили через стандартные инструменты PyTorch отдельно для каждой из моделей.
Также все методы, помимо TAPe, использовали оптимизированные функции из библиотеки cv2, а также из scilearn-kit. Также, чтобы избавиться от оверхеда в скорости Python, по максимуму использовали математические библиотеки numpy во время передачи любых данных в DBSCAN.
Время генерации графиков и создания видео было исключено из бенчмарок.
Всего протестировали (обучили) тринадцать моделей (включая ViT и DinoV2). Таблица, почти три десятка графиков и видео. DinoV2 мы посвятили отдельную главу.
ML-модель | Подтип/размер модели | Время построения индекса, сек | Время получения кластеров, сек | Размер индекса (вес файла), Мб | Параметры модели (млн) |
ConvNeXt (2022) | Tiny | 235.1 | 46.71 | 10.11 | 28.6 |
Small | 373.76 | 46.35 | 10.11 | 50.2 | |
Base | 540.88 | 45.59 | 13.48 | 88.6 | |
Large | 962.17 | 45.16 | 20.21 | 197.8 | |
EfficientNetV2 (2021) | S | 562.3 | 43.07 | 16.85 | 21.5 |
M | 839.03 | 42.97 | 16.85 | 54.1 | |
L | 1259.9 | 43.27 | 16.85 | 118.5 | |
RegNet_Y (2020) | 800MF | 244.69 | 43.12 | 10.11 | 6.4 |
1_6Gf | 391.08 | 43.09 | 11.69 | 11.2 | |
3_2GF | 347,59 | 46.21 | 19.90 | 19.4 | |
Swin (2021) | T | 284.39 | 41.57 | 10.11 | 28.3 |
S | 497.48 | 40.88 | 10.11 | 49.6 | |
B | 694.84 | 44.41 | 13.48 | 87.8 | |
ViT (2020) | B16 | 537.44 | 44.29 | 10.11 | 86.6 |
B32 | 234.29 | 40.80 | 10.11 | 88.2 | |
L16 | 1529.23 | 43.82 | 13.48 | 304.3 | |
Inception (GoogleNet, 2015) | V3 | 370.82 | 40.82 | 26.95 | 27.2 |
DenseNet (2016) | 121 | 452.96 | 44.22 | 13.48 | 8 |
169 | 523.12 | 41.22 | 21.90 | 14.1 | |
201 | 625.96 | 44.83 | 25.27 | 20 | |
ResNeXt (2016) | 50_32x4d | 314.22 | 39.37 | 26.95 | 25 |
101_32x8d | 750.81 | 39.24 | 26.95 | 88.8 | |
Wide ResNet (2016) | 50_2 | 501.32 | 39.28 | 26.95 | 68.9 |
101_2 | 856.3 | 39.21 | 26.95 | 126.9 | |
MobileNet (2021/22) | V3 Small | 169.98 | 39.03 | 26.95 | 2.5 |
V3 Large | 184.09 | 37.67 | 7.58 | 5.5 | |
ShuffleNet (2018) | V2 X0 5 | 129.51 | 38.06 | 12.63 | 1.4 |
V2 X1 0 | 163 | 41.06 | 13.48 | 2.3 | |
V2 X1 5 | 164 | 41.37 | 13.48 | 3.5 | |
MNaSNet (2018) | 0.5 | 144.73 | 41.39 | 16.85 | 2.2 |
0.75 | 165.67 | 36.17 | 16.85 | 3.2 | |
1.0 | 152.96 | 36.68 | 16.85 | 4.4 | |
1,3 | 188,71 | 33,96 | 16.85 | 6.3 | |
DINOv2 | ViT-B/14 | 5220 | 21.49 | 9.7 | 86 |
Три десятка графиков и видео можно посмотреть в "бонусной" части статьи, кому интересно. Там же пара заметок про отдельные модели с любопытными результатами.
Выводы по итогам экспериментов: только факты
Время построения индекса
Время построения индекса с помощью методов TAPe - 10-11 секунд. Метод гистограмм показывают 25-30 секунд. Другие методы показали намного хуже результаты: несколько сотен и даже несколько тысяч секунд. Многие математические методы не уложились в 10 000 секунд – лимит, который мы определили для себя.
Размер индекса, который получается в результате.
У TAPe это менее 1 Мб. Самый ближний к нему – 6,5 мегабайт. Это результат все той же простейшей гистограммы, которая, впрочем, не показала значимого результата по кластеризации. Другие методы с точки зрения размера файла показали несопоставимые объемы: десятки, сотни мегабайт и даже гигабайты. Возможно, это потому, что там большое количество значимых с точки зрения конкретного метода признаков, которое ему нужны для выделения значимых признаков из данных (в данном случае - видео данных). Соответственно, для TAPe таких признаков нужно намного меньше, чем остальным методам и моделям.
Время получения кластеров.
По TAPe-индексу DBSCAN своими стандартными методами разбивал видео на кластеры за 1 (одну) секунду. Гистограммы показали результат в 15 секунд, но качество кластеризации, как уже писали выше, очень плохое (много шумов, а также невозможность определения сцен с небольшим количеством деталей).
Самый близкий результат к TAPe по качеству – модель, с помощью которой DBSCAN построил кластеры за 111 секунд. Объем файла индекса у этой модели 14МБ – тоже хороший показатель по сравнению с другими методами. Но у TAPe, напомним, файл индекса занимает менее 1 Мб.
Остальные методы требуют от DBSCAN астрономического времени для понимания параметров, кластеризации и прочее. Например, один из ML-методов строит индекс 507 сек, и еще столько же занимает кластеризация.
Качество кластеризации. Эмпирический параметр, который мы не оцифровывали. Мы смотрели на то, правильно или неправильно разделены сцены видео. Это видно, что называется, невооруженным глазом. TAPe и здесь показывает самый лучший результат.
Бонус: графики и видео ML-моделей, включая ViT и DINOv2
Модель ConvNeXt (2022)
Подтип/ "размер" модели - Tiny
Получение исходных данных, (сек) - 235.1
Время анализа, (сек) - 46.71
Параметры, млн - 28.6
Подтип/ "размер" модели - small
Получение исходных данных, (сек) - 373.76
Время анализа, (сек) - 46.71
Параметры, млн - 50.2
Подтип/ "размер" модели - base
Получение исходных данных, (сек) - 540.88
Время анализа, (сек) - 45.59
Параметры, млн - 88.6
Подтип/ "размер" модели - large
Получение исходных данных, (сек) - 962.17
Время анализа, (сек) - 45.16
Параметры, млн - 197.8
Модель EfficientNetV2 (2021)
Подтип/ "размер" модели - S
Получение исходных данных, (сек) - 562.3
Время анализа, (сек) - 43.07
Параметры, млн - 21.5
Подтип/ "размер" модели - M
Получение исходных данных, (сек) - 839.03
Время анализа, (сек) - 42.97
Параметры, млн - 54.1
Подтип/ "размер" модели - L
Получение исходных данных, (сек) - 1259.9
Время анализа, (сек) - 43.27
Параметры, млн - 118.5
Модель RegNet_Y (2020)
Подтип/ "размер" модели - 800MF
Получение исходных данных, (сек) - 244.69
Время анализа, (сек) - 43.12
Параметры, млн - 6.4
Подтип/ "размер" модели - 1_6Gf
Получение исходных данных, (сек) - 391.08
Время анализа, (сек) - 43.09
Параметры, млн - 11.2
Подтип/ "размер" модели - 3_2GF
Получение исходных данных, (сек) - 347.59
Время анализа, (сек) - 46.21
Параметры, млн - 19.4
Модель Swin (2021)
Подтип/ "размер" модели - T
Получение исходных данных, (сек) - 284.39
Время анализа, (сек) - 41.57
Параметры, млн - 28.3
Подтип/ "размер" модели - S
Получение исходных данных, (сек) - 497.48
Время анализа, (сек) - 40.88
Параметры, млн - 49.6
Подтип/ "размер" модели - B
Получение исходных данных, (сек) - 694.84
Время анализа, (сек) - 44.41
Параметры, млн - 87.8
Модель ViT(2020)
Подтип/ "размер" модели - B16
Получение исходных данных, (сек) - 537.44
Время анализа, (сек) -44.29
Параметры, млн - 86.6
Подтип/ "размер" модели - B32
Получение исходных данных, (сек) - 234.29
Время анализа, (сек) -40.8
Параметры, млн - 86.6
Подтип/ "размер" модели - L16
Получение исходных данных, (сек) - 1529.23
Время анализа, (сек) - 43.82
Параметры, млн - 304.3
Inception (GoogleNet, 2015) (старичка решили оставить для наглядности)
Подтип/ "размер" модели - V3
Получение исходных данных, (сек) - 370.82
Время анализа, (сек) - 40.82
Параметры, млн - 27.2
DenseNet (2016)
Подтип/ "размер" модели - 121
Получение исходных данных, (сек) - 452.96
Время анализа, (сек) - 44.22
Параметры, млн - 8
ResNeXt (2016)
Подтип/ "размер" модели - 50_32x4d
Получение исходных данных, (сек) - 314.22
Время анализа, (сек) - 39.37
Параметры, млн - 25
Wide ResNet (2016)
Подтип/ "размер" модели - 50_2
Получение исходных данных, (сек) - 501.32
Время анализа, (сек) - 39.28
Параметры, млн - 68.9
MobileNet (2021/22)
Подтип/ "размер" модели - V3 Small
Получение исходных данных, (сек) - 169.98
Время анализа, (сек) - 39.03
Параметры, млн - 2.5
Подтип/ "размер" модели - V3 Large
Получение исходных данных, (сек) - 184.09
Время анализа, (сек) - 37.67
Параметры, млн - 5.5
#Модели MobileNet один из самых новых и "профессиональных" в списке (оригинальный год выхода 2019, но обновления происходили вплоть до конца 2021), и единственные (во всяком случае, из данных, которые мы нашли), которые на данный момент используются коммерчески – в камерах Android-смартфонов, выпущенных между 2019 и 2023 (в 2023 вышла MobileNet v4, к которой на данный момент отсутствует открытый доступ). На наш субъективный взгляд из не-TAPe методов они обладают лучшими результатами в данном задании, выделяя наименьшее количество "шума" (особенно модель small) и захватывая наибольшее количество деталей. Но всё равно они страдают от проблемы всех ML-способов, о которой мы говорили выше.
ShuffleNet (2018)
Подтип/ "размер" модели - V2 X0 5
Получение исходных данных, (сек) - 129.51
Время анализа, (сек) - 38.06
Параметры, млн - 1.4
Подтип/ "размер" модели - V2 X1 0
Получение исходных данных, (сек) - 163
Время анализа, (сек) - 41.06
Параметры, млн - 2.3
Подтип/ "размер" модели - V2 X1 5
Получение исходных данных, (сек) - 164
Время анализа, (сек) - 41.37
Параметры, млн - 3.5
#Исключение из правила "чем меньше модель, тем точнее определение сцен, но больше шума". Наше предположение в том, что модель V2 X0.5 натренирована на настолько малом количестве материала, что приводит к "перераспределению" на сцены, потому как обладает малой точностью, то есть очень нестабильна.
MNaSNet (2018)
Подтип/ "размер" модели - 0.5
Получение исходных данных, (сек) - 144.73
Время анализа, (сек) - 41.39
Параметры, млн - 2.2
Подтип/ "размер" модели - 0.75
Получение исходных данных, (сек) - 165.67
Время анализа, (сек) - 36.17
Параметры, млн - 3.2
Подтип/ "размер" модели - 1.0
Получение исходных данных, (сек) - 152.96
Время анализа, (сек) - 36.68
Параметры, млн - 4.4
Подтип/ "размер" модели - 1.3
Получение исходных данных, (сек) - 188.71
Время анализа, (сек) - 33.96
Параметры, млн - 6.3
Выводы про ML: проблема fitting'а, размера контекста
ML-модели показали похожий друг на друга результат, отличающийся больше в деталях. Из результатов можно заметить объём тренировки - модели с большим объемом тренировочных данных корректно определенным образом справляются с ситуациями отсутствия данных. То есть более "крупные" модели, не важно какого года выпуска, чаще всего корректно вычисляют "пустые" кадры как кадры, всё равно несущие определенный смысл. От новизны модели зависит, определяет ли модель эти пустые кадры в ту же самую корзину, что и "тёмные" кадры, или нет.
При этом все ML "страдают" проблемой "fitting'а", то есть тренировки к определенной задаче, а не повсеместной подготовке ко "всему". В результате чего они теряют какое-то количество деталей, в отличии от любых других методов. Только ML-методы теряют детали между соседними, очень похожими кадрами, потому как попросту не были натренированы на любой тип кадра и (скорее всего), в первую очередь были натренированы на I-кадрах в видео. В результате ML-модели сталкиваются с проблемами на кадрах с большим значением Motion Blur ("смазывания" во время движения), а также кадрах, не обладающих выделяющимися деталями, или цветом (пример: Inception v3).
Также заметная проблема этих моделей в размере контекста. Работа с видео через ML (во всяком случае в открытом доступе) находится в ранних стадиях даже сейчас. Это можно заметить, если посмотреть на размеры контекстов (количество внутренних параметров, которые регулирует ML) моделей. Самое высокое количество параметров для любой из моделей ниже - 309 миллионов в ViT, в то время как самое высокое количество параметров в нейросетях с открытым кодом, работающих с текстом, уже доходит за 500 миллиардов. Разница более чем в 1000 раз, что указывает, с одной стороны, на неэффективность представления информации о изображениях для тренировки ML. С другой стороны, это даже хорошо, что визуальные модели не такие большие, потому что описание и так уже неэффективное, поэтому радует, что оно не настолько раздутое для необходимых задач.
Результаты для DBSCAN DinoV2 (2025)
При делении на кластеры после сборов результатов работы DinoV2 (конкретно DinoV2 ViT-B/14 - то есть, DinoV2, использующая 14*14=196 патчей и Base размер ViT, где размеры каждого выходного вектора - 768 значений) для каждого кадра получаются следующие результаты:
Подтип/ "размер" модели - ViT-B/14
Получение исходных данных, (сек) - 5220
Время анализа, (сек) - 21.49
Параметры, млн - 86
DinoV2, будучи новой SOTA-моделью, очень хорошо справляется с задачей, с одним большим НО - этот факт остаётся фактом только для сцен с неким количеством деталей. Последние сцены (с 10-й по 12-ю включительно) обладают наименьшим количеством деталей, и результаты модели выходят шумными - то есть, DBSCAN не может найти в них закономерности.
Из этих результатов можно увидеть, на каких данных была проведена тренировка модели, а также то, для чего модель тренировалась. Для анализа были использованы данные CLS-токенов, собранные для каждого кадра – это токен, тренируемый для классификации изображений. Отсюда становится очевидно, почему для "пустых" изображений модель не подготовлена в целом.
Также это можно заметить из результатов для сцен 2 и 4: модель определила один из сегментов сцены 4 в сцену 2 исходя не из лиц персонажей, потому что не была натренирована на лицах в целом, а исходя из похожести угла поворота их лиц, а также скафандров.
Сбор данных занял 1 час 27 минут на 16 ядрах CPU - скалируя это к TAPe, который собирал данные на одном ядре - общее время (технически - CPU Time) около 82560 секунд. Анализ занял 21.49 секунд. Конечный размер файла - 9.7 Мб, кол-во параметров - 768 на кадр, вес каждого параметра - 32 бита.
Такие дела.
