Вас же не удивляет, что всякие диффузеры генерят осмысленную картинку? Значит в целом нейросети уже научились определять, что именно на картинке изображено. В случае stable diffusion этим занимается сетка clip - она по картинке делает эмбеддинг, и по фразе делает эмбеддинг и сличает, насколько эти эмбединги похожи. При генерации меняет картинку так, что бы ее эмбединг был сильнее похож на текстовый.
Тут собственно почти тоже самое, что мешает натренировать сеть искать кусок изображения, который при свертке clip даст эмбеддинг максимально похожий на текстовый?
Clip при этом тренировалась не на классах, а на картинках с описанием. Конечно, если нигде в этом наборе объект который вы ищете не встречался, то clip и yola из статьи не сработает. И сейчас все сетки с открытым множеством находят много лишнего, но думаю еще не много и это доделают.
Для декорирования видео у карты какой то свой отдельный блок, его загрузка рисуется в Taskmanager Windows. Не знаю уж, что вы оптимизировали в языках, но если натравить на ртсп ffmpeg и брать кадры через пайп то уже 60 камер по 1280х720 полностью загружают современные видеокарты. Именно карту, все остальное свободно. Cuda при этом не используется, только блок декодирования. И неважно, кто запускает ffmpeg, у меня есть проект с с++ и python, от языка это не зависит, ведь вся нагрузка в другом процессе. Вытащить из пайп кадры может любой калека
В общем как-то совсем ваша информация с моим опытом не стыкуется. 40 fullhd просто кладут карту на лопатки, даже при дешифровки пяти кадров в секунду.
Я а этом году примерно таким же занимался, мне надо было положение велосипедиста найти. GPS, даже со всеми базами, прыгает в довольно большом радиусе, особенно во дворах. С помощью датчика на колесе и 6доф удалось довольно точно трек получить. Получилось, что локально направление очень точно выдаётся, а глобальное уплывание легко корректируется по GPS (если взять удаленные точки трека, то даже если у gps будет большая ошибка, в целом, угол будет правильный, и относительно него можно гироскоп скорректировать). В результате, когда в Москве в центре GPS совсем выключили, оказалось что он не особо то и нужен - достаточно задать несколько ключевых точек трека, что бы он лег на карту
Фотографии не совпадают из-за вращения земли, такое же вращение происходит во время съёмки панорамы - а съёмка панорамы хорошо изучена и для неё существует много готовых библиотек. В целом поиск параметров совмещения кадров там делается примерно так же, как у вас, но никакой триангуляции там не делается, вместо этого вычисляются характеристики объектива (в идеале их можно посчитать заранее), проективная проекция переводится в цилиндрическую, после чего фотографии уже можно усреднять и избавляться от шума попиксельно. Думаю такой подход сильно повысит качество и даст возможность детектировать движущиеся объекты
Четвертое измерение интересная штука. Я вот подумал, что если точка движется равномерно по виртуальной оси У (четвертое измерение, движение по которому мы не воспринимаем) начиная с какой то точки (скажем один) на нашей реальной оси Х, то расстояние от центра координат до этой точки будет менятся как sqrt(kt^2 + 1) Вторая производная тут везде положительная, так что для нас движение будет выглядить с ускорением
Учитывая собственные вектора, любое ортогональное преобразование расскладывается на инвариантные размерности и плоскости вращения. Другое дело, что плоскостей вращения может быть две
Все же сколько не размышляю, не понимаю, как это может работать.
Вот берем двух человек, у которых верхняя половина лица одинаковая, а нижняя разная.
Закрываем нижнюю половину лица и свертка верхней половины получается одинаковая (по условию). При этом она лежит на маленьком расстоянии от сверток полных, незакрытых лиц. Но это значит что и свертки этих лиц тоже лежат на небольшом расстоянии, а так же не может быть?
Они там у себя пишут, какой именно алгоритм участвовал. Я так понял, что наверное он действительно пока публично не доступен, но это вроде бы та же сетка просто обученная на другом наборе данных.
По умолчанию у них вроде buffalo_lЭто она в тестах?
И еще, если это не секрет, вы можете опубликовать результат вашей модели на ijbc - тогда можно было бы вас сравнить со многими публично доступными моделями
Или вы какой то их старый фильтр взяли? Как еще можно объяснить такие результаты?
У них конечно не очень точные свертки - разброс относительно центра для хороших фотографий очень большой, все это благодаря софтмаксу который давно пора выбросить, а не реанимировать arcface-ами и тд. Но при этом, благодаря тому же софтмаксу, они умудряются идентифицировать личность по фотографии на которой только один глаз виден.
И еще я очень удивлен графиком с масками - в этом случае вы использовали тот же фильтр что и для обычной фотографии? Нейросеть, когда пол лица закрыто, склонна дорисовывать какое то среднестатистическое лицо, и в данном случае результат insighface вполне объясним.
Мы собственно на это натыкались, и в случае если есть маска - просто используем другой алгоритм
issue на самом деле не я создавал — я настолько детально наверное не смог бы это все описать. Я нашел его поиском, когда получил несоответствие обучения и валидации на своей сетке. Но получается, что ошибка воспроизводится у многих, и текущее состояние rocm нерабочее уже 4 месяца.
Да, вот он github.com/ROCmSoftwarePlatform/tensorflow-upstream/issues/1105
Поскольку от разработчиков никаких комментариев нет, я не знаю в чем тут дело. Наверное все же какая то особенная конфигурация железа. Не может же это у всех не работать? Простейшие тесты не проходят
Я где то полгода обучал тензор флоу модели на Radeon VII. И был в общем-то доволен, карта с большим количеством памяти стоила сильно дешевле чем аналог от Nvidia. Но все для меня сломалась после выхода tensorflow 2.0. Я долго на него не переходил, но в какой то момент все же пришлось, по моему это уже 2.2 было. В общем оказалось что в 2.2 для rocm какой-то баг, обучение идёт нормально, а валидация глючит, тренировать модели практически невозможно. Это наверное где то в сентябре было. Но при этом 2.2 на VII работает раза в два быстрее чем на 1080, которая тоже была в наличии. Откат на 2.1 проблему решал, но скорость падала чуть ли не на порядок, смысла в такой тренировке не было. По состоянию на декабрь, баг так и не был поправлен, при этом выходили очередные версии rocm и под них портировались очередные версии tensorflow, но они все так же не работали. В общем с одной стороны карта просто зверь за свои деньги, с другой стороны как с этим работать я не понимаю. Я правда впервые с убунтой столкнулся, может быть кто-то прошаренный и нашел бы выход из положения. Но мне непонятно как может столько времени висеть баг, который убивает всю полезность рокм. Зачем что то писать дальше, если текущее не работает?
Запустил ваш "туториал"
Как и предполагалось, такая модель не может ничего путного выдать.
После 1000 эпох аккуратность 45%
Строка на входе
From fairest creatures we desire increase,
That thereby beauty's rose might never die,
But as th
Строка на выходе
oeueaonne ehaee nhre eai a ene andee ne
aahenhahe e e ae nrh seaeue aeneehad e ea n
aaurhaneahe
А пример будет, что такая модель может написать? Бессмысленный набор символов? Или несвязанные слова?
Чуда ожидать не стоит, но все же...
Вас же не удивляет, что всякие диффузеры генерят осмысленную картинку? Значит в целом нейросети уже научились определять, что именно на картинке изображено. В случае stable diffusion этим занимается сетка clip - она по картинке делает эмбеддинг, и по фразе делает эмбеддинг и сличает, насколько эти эмбединги похожи. При генерации меняет картинку так, что бы ее эмбединг был сильнее похож на текстовый.
Тут собственно почти тоже самое, что мешает натренировать сеть искать кусок изображения, который при свертке clip даст эмбеддинг максимально похожий на текстовый?
Clip при этом тренировалась не на классах, а на картинках с описанием. Конечно, если нигде в этом наборе объект который вы ищете не встречался, то clip и yola из статьи не сработает. И сейчас все сетки с открытым множеством находят много лишнего, но думаю еще не много и это доделают.
Вот тут еще пример такой сетки
https://ashkamath.github.io/mdetr_page/
Для декорирования видео у карты какой то свой отдельный блок, его загрузка рисуется в Taskmanager Windows. Не знаю уж, что вы оптимизировали в языках, но если натравить на ртсп ffmpeg и брать кадры через пайп то уже 60 камер по 1280х720 полностью загружают современные видеокарты. Именно карту, все остальное свободно. Cuda при этом не используется, только блок декодирования. И неважно, кто запускает ffmpeg, у меня есть проект с с++ и python, от языка это не зависит, ведь вся нагрузка в другом процессе. Вытащить из пайп кадры может любой калека
В общем как-то совсем ваша информация с моим опытом не стыкуется. 40 fullhd просто кладут карту на лопатки, даже при дешифровки пяти кадров в секунду.
Я а этом году примерно таким же занимался, мне надо было положение велосипедиста найти. GPS, даже со всеми базами, прыгает в довольно большом радиусе, особенно во дворах. С помощью датчика на колесе и 6доф удалось довольно точно трек получить. Получилось, что локально направление очень точно выдаётся, а глобальное уплывание легко корректируется по GPS (если взять удаленные точки трека, то даже если у gps будет большая ошибка, в целом, угол будет правильный, и относительно него можно гироскоп скорректировать). В результате, когда в Москве в центре GPS совсем выключили, оказалось что он не особо то и нужен - достаточно задать несколько ключевых точек трека, что бы он лег на карту
Для распознавания лиц, стоит посмотреть в сторону insightface, вполне прилично работает
Фотографии не совпадают из-за вращения земли, такое же вращение происходит во время съёмки панорамы - а съёмка панорамы хорошо изучена и для неё существует много готовых библиотек. В целом поиск параметров совмещения кадров там делается примерно так же, как у вас, но никакой триангуляции там не делается, вместо этого вычисляются характеристики объектива (в идеале их можно посчитать заранее), проективная проекция переводится в цилиндрическую, после чего фотографии уже можно усреднять и избавляться от шума попиксельно. Думаю такой подход сильно повысит качество и даст возможность детектировать движущиеся объекты
Четвертое измерение интересная штука. Я вот подумал, что если точка движется равномерно по виртуальной оси У (четвертое измерение, движение по которому мы не воспринимаем) начиная с какой то точки (скажем один) на нашей реальной оси Х, то расстояние от центра координат до этой точки будет менятся как sqrt(kt^2 + 1) Вторая производная тут везде положительная, так что для нас движение будет выглядить с ускорением
Учитывая собственные вектора, любое ортогональное преобразование расскладывается на инвариантные размерности и плоскости вращения. Другое дело, что плоскостей вращения может быть две
А ведь в четырехмерном пространстве может быть вращение сразу в двух плоскостях, если оно примерно одинаковое, то изатропия вроде будет...
Все же сколько не размышляю, не понимаю, как это может работать.
Вот берем двух человек, у которых верхняя половина лица одинаковая, а нижняя разная.
Закрываем нижнюю половину лица и свертка верхней половины получается одинаковая (по условию). При этом она лежит на маленьком расстоянии от сверток полных, незакрытых лиц. Но это значит что и свертки этих лиц тоже лежат на небольшом расстоянии, а так же не может быть?
Они там у себя пишут, какой именно алгоритм участвовал. Я так понял, что наверное он действительно пока публично не доступен, но это вроде бы та же сетка просто обученная на другом наборе данных.
Не могли бы вы все таки назвать конкретную модель от insightface которая участвовала в тесте? А то их там масса... https://github.com/deepinsight/insightface/tree/master/model_zoo
По умолчанию у них вроде
buffalo_lЭто она в тестах?И еще, если это не секрет, вы можете опубликовать результат вашей модели на ijbc - тогда можно было бы вас сравнить со многими публично доступными моделями
Судя по приведенным графикам, вы должны бы порвать insightface как тузик грелку
Но почему то они вас опережают по результатам nist в некоторых категориях
https://pages.nist.gov/frvt/html/frvt11.html
Или вы какой то их старый фильтр взяли? Как еще можно объяснить такие результаты?
У них конечно не очень точные свертки - разброс относительно центра для хороших фотографий очень большой, все это благодаря софтмаксу который давно пора выбросить, а не реанимировать arcface-ами и тд. Но при этом, благодаря тому же софтмаксу, они умудряются идентифицировать личность по фотографии на которой только один глаз виден.
И еще я очень удивлен графиком с масками - в этом случае вы использовали тот же фильтр что и для обычной фотографии? Нейросеть, когда пол лица закрыто, склонна дорисовывать какое то среднестатистическое лицо, и в данном случае результат insighface вполне объясним.
Мы собственно на это натыкались, и в случае если есть маска - просто используем другой алгоритм
У меня нормально работал Tensorflow 2.1 (только медленно)
hub.docker.com/r/rocm/tensorflow/tags?page=1&ordering=last_updated&name=2.1
Я правда докеры тестировал, переставлять на железо не пробовал
(Последний который я тестировал был кажется на основе 3.7, сейчас уже 4.0 вышел, но это уже мимо меня прошло)
В любом случае интересно, получится ли у вас запустить tf2.4
Но при этом на картинке не Rocm a PlaidML
github.com/ROCmSoftwarePlatform/tensorflow-upstream/issues/1105
Поскольку от разработчиков никаких комментариев нет, я не знаю в чем тут дело. Наверное все же какая то особенная конфигурация железа. Не может же это у всех не работать? Простейшие тесты не проходят
Я где то полгода обучал тензор флоу модели на Radeon VII. И был в общем-то доволен, карта с большим количеством памяти стоила сильно дешевле чем аналог от Nvidia. Но все для меня сломалась после выхода tensorflow 2.0. Я долго на него не переходил, но в какой то момент все же пришлось, по моему это уже 2.2 было. В общем оказалось что в 2.2 для rocm какой-то баг, обучение идёт нормально, а валидация глючит, тренировать модели практически невозможно. Это наверное где то в сентябре было. Но при этом 2.2 на VII работает раза в два быстрее чем на 1080, которая тоже была в наличии. Откат на 2.1 проблему решал, но скорость падала чуть ли не на порядок, смысла в такой тренировке не было. По состоянию на декабрь, баг так и не был поправлен, при этом выходили очередные версии rocm и под них портировались очередные версии tensorflow, но они все так же не работали. В общем с одной стороны карта просто зверь за свои деньги, с другой стороны как с этим работать я не понимаю. Я правда впервые с убунтой столкнулся, может быть кто-то прошаренный и нашел бы выход из положения. Но мне непонятно как может столько времени висеть баг, который убивает всю полезность рокм. Зачем что то писать дальше, если текущее не работает?