Если оптимизация I-фреймов даёт на 5% лучше сжатие при прочих равных, то ты на объёмах какого-нибудь YouTube на эти 5% сможешь себе самолёт купить.
оптимизация I-фреймов, которую здесь представляет эксперимент, заключалась бы в стратегии их расположения во время энкодинга. это позволило бы очень сильно уменьшить кол-во расчётов, необходимых для самого по себе энкодинга, а также позволило бы сжимать видео намного эффективнее – просто потому что поисковая стратегия лучшего их расположения лучше и быстрее
Но спасибо за ваш коммент – мы сегодня выкатим демо-стенд, где любой желающий может повторить то же самое, что мы делаем конкретно с TAPe-данными в DBSCAN, но с любым видео. Кину ссылку
Логика возражения понятная, отвечу споконо и по существу, а не
Статья - на конкретную тему по конкретному кейсу, описанному в статье. "Инженерный отчет" и результаты экспериментов, а не полный стек (код, модель, датасеты). Архитектуру и код мы не покажем, потому что это наше ноу-хау и они используются в коммерческих проектах/пилотах.
Мы показываем то, что можно/хотим показать: настройки, список baseline'ов, время и память для каждого метода, графики, визуальные примеры разбиения сцен. Практически максимально прозрачно описали эксперимент. Все сравнения сделаны на одном и том же видео, с одинаковым кластеризатором (DBSCAN/HDBSCAN) и одинаковыми параметрами, мы явно перечисляем все используемые модели (от простых гистограмм до DINOv2/ViT) и даём численные метрики по времени/памяти. Один и тот же пайплайн применен ко всем методам, включая TAPe. Это не научная публикация - мы просто показываем эффект и делимся находками.
В вашем другом комменте про "не пытается показывать применимость к реальным задачам" есть заодно и ответ на этот тезис- про YouTube и купить самолет. Это лишь одна из многих возможных задач.
привет. отличная статья - во всяком случае по духу и направлению мысли. на канал в тг подписался. рекомендую почитать мини-альманах в тему https://comexp.net/posts - думаю тебе будет интересно. он на англ, но сегодня это не проблема, полагаю. удачи в проектах!
Если углубляться - немного - в детали, то мы не формируем фичи вручную каждый раз в зависимости от задачи. Это первое. Второе: в нашем случае из так называемых фич проистекают дальнейшие законы/методы работы с этими фичами. Они взаимосвязаны.
Представьте, что вы работаете со звуками, вам нужно написать музыку, но вы не знаете о существовании нот, как их сочетание влияет друг на друга, что такое квинтовый круг и тд и тп. Скорее всего вам придется "изобрести" и методы работы со звуком, а значит и ноты. Которые могут превращаться в аккорды, мотивы, музыку. Будут ли у вас совсем другие ноты или они будут как минимум похожи с теми, которые мы все сейчас знаем?
Это аналогия с тем, что происходит в TAPe, но с изображениями
Ну нет) Если совсем кратко:TAPe или вернее технология (модель) на базе TAPe напрямую оптимизирует то, какие патчи считать похожими и как их группировать, а не прячет эту логику внутри гигантского backprop по ViT/DINO. То есть модель сама учит свое внутреннее представление по данным, не использует заранее придуманные руками признаки
оптимизация I-фреймов, которую здесь представляет эксперимент, заключалась бы в стратегии их расположения во время энкодинга. это позволило бы очень сильно уменьшить кол-во расчётов, необходимых для самого по себе энкодинга, а также позволило бы сжимать видео намного эффективнее – просто потому что поисковая стратегия лучшего их расположения лучше и быстрее
https://monitor.comexp.net/?scenario=cluster
вот, если любопытно. принимает любое видео (кроме .avi), обрабатывает через DBSCAN с параметрами по умолчанию и отдаёт обратно разбиение.
Но спасибо за ваш коммент – мы сегодня выкатим демо-стенд, где любой желающий может повторить то же самое, что мы делаем конкретно с TAPe-данными в DBSCAN, но с любым видео. Кину ссылку
Логика возражения понятная, отвечу споконо и по существу, а не
Статья - на конкретную тему по конкретному кейсу, описанному в статье. "Инженерный отчет" и результаты экспериментов, а не полный стек (код, модель, датасеты). Архитектуру и код мы не покажем, потому что это наше ноу-хау и они используются в коммерческих проектах/пилотах.
Мы показываем то, что можно/хотим показать: настройки, список baseline'ов, время и память для каждого метода, графики, визуальные примеры разбиения сцен. Практически максимально прозрачно описали эксперимент. Все сравнения сделаны на одном и том же видео, с одинаковым кластеризатором (DBSCAN/HDBSCAN) и одинаковыми параметрами, мы явно перечисляем все используемые модели (от простых гистограмм до DINOv2/ViT) и даём численные метрики по времени/памяти. Один и тот же пайплайн применен ко всем методам, включая TAPe. Это не научная публикация - мы просто показываем эффект и делимся находками.
В вашем другом комменте про "не пытается показывать применимость к реальным задачам" есть заодно и ответ на этот тезис- про YouTube и купить самолет. Это лишь одна из многих возможных задач.
привет. отличная статья - во всяком случае по духу и направлению мысли. на канал в тг подписался. рекомендую почитать мини-альманах в тему https://comexp.net/posts - думаю тебе будет интересно. он на англ, но сегодня это не проблема, полагаю. удачи в проектах!
Если углубляться - немного - в детали, то мы не формируем фичи вручную каждый раз в зависимости от задачи. Это первое. Второе: в нашем случае из так называемых фич проистекают дальнейшие законы/методы работы с этими фичами. Они взаимосвязаны.
Представьте, что вы работаете со звуками, вам нужно написать музыку, но вы не знаете о существовании нот, как их сочетание влияет друг на друга, что такое квинтовый круг и тд и тп. Скорее всего вам придется "изобрести" и методы работы со звуком, а значит и ноты. Которые могут превращаться в аккорды, мотивы, музыку. Будут ли у вас совсем другие ноты или они будут как минимум похожи с теми, которые мы все сейчас знаем?
Это аналогия с тем, что происходит в TAPe, но с изображениями
Ну нет) Если совсем кратко:TAPe или вернее технология (модель) на базе TAPe напрямую оптимизирует то, какие патчи считать похожими и как их группировать, а не прячет эту логику внутри гигантского backprop по ViT/DINO. То есть модель сама учит свое внутреннее представление по данным, не использует заранее придуманные руками признаки
рецензируемые публикации есть. если что-то неясно/непонятно - всегда можно задать уточняющий вопрос. если таковой есть.