Comments 25
2. Остаётся вопрос корректности приведения к чёрно-белому формату. В данном случае ярко-белое снежное поле и голубое небо могут оцениваться как одинаковое изображение. Возможно, имеет смысл делать четыре проверки векторов — «Чёрно-белые» и по каждому из цветов RGB.
- Да, там же сетка относительная, а не абсолютная. Плюс значение узла вычисляется в области, размер которой завязан на общие размеры изображений. Скажу больше — растянутые изображения тоже ищутся.
- Точность, конечно, будет больше, но это в 4 раза больше данных со всеми сопутствующими накладными расходами. На практике метод отлично справляется опираясь только на чёрно-белый вариант.
Скажем так, выбирал не я и было это давно. :)
Возможно я и проведу такое сравнение, но, с очень большой долей вероятности, делать это придется в свободное от работы время, поскольку качество текущей реализации соответствует рабочим ожиданиям.
По скорости — в конце статьи есть ссылка на предыдущую, с "попугаями". В контейнере на локальном буке поиск по 10М изображений отрабатывает за ~1.5 секунды. Ищет хорошо (на тестовом наборе нашла все, что нужно и ничего, что не нужно)
1.5 секунды на поиск? Это очень много, faiss позволяет получить время поиска порядка 50 ms при поиске по миллиардному индексу, hnsw справится за единицы ms (хотя строиться миллиардный индекс будет пару недель).
Довольно глупо меряться абстрактными попугаями, полученными в разных условиях и на коде, писанном с разными вводными и ограничениями.
Устойчивость к кропу проверяли? Вызывает некоторые сомнения, особенно при наличии выраженной текстуры на изображении.
промахнулся.
Алгоритм достаточно устойчив к мусору, но есть нюансы с размером. часто промахи
Моя реализация устойчива к кропу/ресайзу/ватермаркам/поворотам. База 100M на 3х древних серверах (порядка сдвоенного Xeon E5430), ищет порядка 2 картинки в секунду.
У меня есть презентация:
www.youtube.com/watch?v=gD7dSBcL9AI
Вот самое интересное то и не рассказали! :D
Спасибо, очень интересно было посмотреть.
Почему не используете ключевые точки и дескрипторы?
Как я ответил выше — этот алгоритм был выбран довольно давно и не мной. Моей задачей было переписать реализацию для большего соответствия требованиям компании. Собственно поэтому про ключевые точки и дескрипторы я прокомментировать не смогу. Sad, but true.
Моя реализация устойчива к кропу/ресайзу/ватермаркам/поворотам.
А можно на нее посмотреть?
В качестве бейзлайна можно достать дескрипторы картинок из любой предобученной сети (например, какой-нибудь resnet, обученный на imagenet), сложить их в какую-то структуру для быстрого поиска похожих (например, github.com/spotify/annoy) и быстро искать. По точности будет явно не хуже, скорость поиска — тоже, а главное достоинство — когда точности перестанет хватать, можно будет переобучить сетку на своих данных и добиться точности, близкой к идеальной.
Вот исходная научная работа, там довольно подробно разобраны теоретические аспекты алгоритма.
С текстовыми скриншотами есть определенные проблемы — если не поднимать порог, то ложно-позитивные срабатывания бывают, хотя и редко. Но это довольно специфическая область.
Поиск похожих изображений, разбор одного алгоритма