Фотографии не совпадают из-за вращения земли, такое же вращение происходит во время съёмки панорамы - а съёмка панорамы хорошо изучена и для неё существует много готовых библиотек. В целом поиск параметров совмещения кадров там делается примерно так же, как у вас, но никакой триангуляции там не делается, вместо этого вычисляются характеристики объектива (в идеале их можно посчитать заранее), проективная проекция переводится в цилиндрическую, после чего фотографии уже можно усреднять и избавляться от шума попиксельно. Думаю такой подход сильно повысит качество и даст возможность детектировать движущиеся объекты
Четвертое измерение интересная штука. Я вот подумал, что если точка движется равномерно по виртуальной оси У (четвертое измерение, движение по которому мы не воспринимаем) начиная с какой то точки (скажем один) на нашей реальной оси Х, то расстояние от центра координат до этой точки будет менятся как 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, но они все так же не работали. В общем с одной стороны карта просто зверь за свои деньги, с другой стороны как с этим работать я не понимаю. Я правда впервые с убунтой столкнулся, может быть кто-то прошаренный и нашел бы выход из положения. Но мне непонятно как может столько времени висеть баг, который убивает всю полезность рокм. Зачем что то писать дальше, если текущее не работает?
Для распознавания лиц, стоит посмотреть в сторону 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, но они все так же не работали. В общем с одной стороны карта просто зверь за свои деньги, с другой стороны как с этим работать я не понимаю. Я правда впервые с убунтой столкнулся, может быть кто-то прошаренный и нашел бы выход из положения. Но мне непонятно как может столько времени висеть баг, который убивает всю полезность рокм. Зачем что то писать дальше, если текущее не работает?