Попробовал снова поиграться с более продвинутыми методами поиска, но, опять не пришел к положительны / баянометр

баянометр 

Попробовал снова поиграться с более продвинутыми методами поиска, но, опять не пришел к положительным результатам. SIFT/SURF слишком громоздки. ORB ведет себя тоже неплохо, но полегче, и исполняет поставленные задачи, но, встает более серьезная проблема - поиск. Для снижения количества ложно-положительных результатов поиска нужно увеличивать количество точек для изображения. Увеличение количества точек - больше данных для поиска. Больше данных для поиска - меньше скорость и требуется больше мощностей. На реакторе больше 7 миллионов изображений. При < 100 точек - результат ультра гавно. 200-300 - более менее, но не на таком объеме. Это неплохо работало бы, если бы было 1-2 миллиона изображений. +- допустимые результаты, для такого объема, это 450+ точек на изображение. Итого, 3 миллиарда точек. Это порядка 200+ гигов данных, которые нужно хранить в оперативе, для более быстрого поиска. И даже при таких условиях поиск одной картинки длиться порядка 20-25 секунд, что уже далеко за приделами комфортного уровня. Можно ли решить это? Да, конечно, но это уже нужно распределять все на штуки 4+ сервера, а цена аренды такого удовольствия выходит слишком большая(150$+). Согласно опросу недавнему, она вроде бы подъемная, но, я прекрасно понимаю что обстоятельства у людей меняются. Кто-то переоценил свои финансовые возможности, а кого то просто заебет донатить на это, а бегать постоянно делать посты на это тему... Ну такое себе удовольствие.

Потому сорян, я правда старался, но уперся в ограничения не связанные с программными аспектами. Или может вы подскажите метод поиска hamming, который работает быстро на огромном объеме данных, и при этом не требует существенных апаратних ресурсов

p.s. это разве что собирать сразу на годик+ аренды, и тогда есть смысл дальше играться, но уже с несколькими серверами


Подробнее
баянометр
Еще на тему
Развернуть
дайте деняк
setapca setapca 16.07.202316:43 ответить ссылка 14.5
Тот слушай, когда уже не хочеться, что бы дали деняк
И так въебал на это просто прорву времени и сил, и танцевать дальше уже с пачкой серверов не горю желанием сейчас
А обьязательно проводить поиск по всему обьему? Можно распознавать перечень ключевиков на картинке и уже по наличию схожих ключевиков осуществлять перебор. Тогда и область поиска будет меньше и в оперативе хранить будет не обьязательно.
trash41 trash41 16.07.202316:46 ответить ссылка 1.9
Само определение схожей области поиска = поиску по всему объему
Почему? По 5 ключевикам виборка с постгреса на таком обьеме будет занимать 200 мс. Дальше поиск среди 10000картинок, а не 100000000.
Можно ссылку на какой то пример, что бы понимать о чем идет речь?
Я предлагаю пропустить изображения через обучений класификатор и получить список тегов( что изображено на картинке - коти, сиськи, рисунок) обучить класификатор можно по тем-же тегам постов отобрав урезаний диапазон тегов) при совпадении тегов на 90% использовать результат для дальшего разбора набор точек для сравнения хранить в jsonb. Конкретний кейс я на хабре не нашел, но били кейси с сортировкой фотоколекции на опенсорсних решениях.
А нужен ли поиск по всем картинкам? Можно например ограничится за последние 3-5 лет. Запостит кто-то баян, что был 8 лет назад, ну и хуй с ним.. Из того, что осталось сделать кеширование, что бы то, что чаще обнаруживает, висит в памяти, что реже, на диске, так еще вполовину память можно уменьшить..
Парето был умным мужиком, 20% усилий/затрат дают 80% результата.. А больше не особо и надо..
Нужен. 8 лет назад - тем более баян. Кешировать результаты поиска пробовал, но это архи пиздец. Поиск по диску, это часы...
Вы не особо представляете на сколько это громадный объем данных
Значит, искать нужно не по картинкам, а по признакам, а признаки получить, прогнав все картинки.
Ну хотя бы гистограмму какую-то вместо картинки получить.
madgod madgod 16.07.202320:45 ответить ссылка 0.0
Попробовать нейронные сети.
Обучить описательную сеть на небольшой выборке. Посмотреть как будет работать с изменёнными, шакальными и прочими изображениями из обучающей выборки.
Кстати, есть возможность для расширения функционала, вроде рекомендаций недостающих тегов.
Уже пробовал, но забросил, по причине так же огромных требований к ресурсам
Основная проблема не метод подготовки изображений. Основная проблема - фактический поиск по готовым результатам. Существуют сотни хороший алгоритмов работающих в разы лучше чем pHash, и тот же ORB. Проблемы начинаются когда нужно искать не по 200 картинкам, как они показывают в своих охуительных презентациях
А оно там автоматически на уменьшенной копии картинки делает свои поисковые операции или прямо на полноразмерной? Ведь фактически уменьшенная в 2, 4, 8 раз картинка примерно то же самое, может немного деталей исчезает.
madgod madgod 16.07.202317:28 ответить ссылка -0.6
Существуют разные реализаций. Некоторые используют маленькую копию, некоторые используют оригинал
1. Выбери 3 случайных квадрата на плоскости(допустим центр и два угла).
1.5 Blur+downscale всю картинку.
2. Размер каждого квадрата 5% от ширины на 5% от высоты.
3.Координаты задаются в процентах от высоты и ширины картинки(X:10%,Y:5% и т.п.)
2. Квадрат представляешь как матрицу из чисел и получаешь хэш.
3. Держать все хэши в памяти не нужно.
Асинхронно читай с диска в режиме потока и скармливай проверятору.
4. Как только 3 квадрата нашлись в хэшах запускаешь попиксельную проверку с погрешностью.

5. Если всё ещё медленно - выводи спиннер "Ах если бы ты задонатил - спинера бы не было."
carl carl 16.07.202317:03 ответить ссылка 2.0
Пробовал чтото подобное, с разбиением картинки на квадраты. Работало оно плохо, потому что ты не можешь предугадать какой будет кроп. Может быть такое, что нужно будет найти по кусочку как раз на стыке квадратов и результата или не будет, или будет ложно положительный
Обрати внимание на пункт 4.
Квадратный метод - это префильтор. Основная работа идёт только когда ловится совпадение.
Если не нравятся квадраты - можешь группировать по цветовой маске. Например, создать кластера по цветовой маске, соотношению сторон.
Поиск будет проще и быстрее.
carl carl 16.07.202319:59 ответить ссылка 0.0
Цветовая маска - цветокор передает привет, вместе с картинками с текстом.
Соотношение сторон - кроп передает привет
Идею я понял, сократить количество возможных вариантов с миллионов до десятков тысяч - сотен тысяч, но оно не сильно помогает. Потому нужно сокращать количество до сотен. При среднем количестве точек в 500/картинку будет приемлемая скорость поиска. А как можно это сделать? Квадраты - хуйня. Сделать их маленькими - будет тьма данных. Сделать их большими - не будет ловить нужные. Цветовая маска не работает. Соотношение сторон тоже. Что еще можно использовать? Количество точек на изображении? При сжатии режутся градиенты, и на их месте появляються ложно положительные точки, потому даже для внешне одинаковых изображений, количество точек может отличаться в разы. Легкий blur, что бы убрать эти ступеньки, существенно увеличивает количество кожно положительных срабатываний
Я не совсем понял.
Здесь идёт речь о том, что пользователь пытается обмануть баянометр, изменяя размер картинки и цветокор картинки?
Ну понятно, что для поиска эта картинка уже не даст 100% точности сравнения. Это уже какой-то ИИ нужен, чтобы прогонять ещё несколько тысяч проходов, изменяя размеры картинки относительно эталона и то же самое делать с цветокором, хотя каким хером его подберёшь, там же фильтры ещё есть.
Превратить всё в монохром, так там выйдет какая-нибудь яркость-контрастность другая.

Ясно же, что будут какие-то отклонения от 100%.
Банально, новый текст на картинке запилят и это уже новый мем, новый демотиватор с другим текстом. Это тоже баян?

Выходит, нужно получать, к какой картинке по каким параметрам ближе всего, не со 100% совпадением.
Нельзя же определить точно, что "на этой картинке кот, цвет белый, глаза желтые" или "на этой картинке 3 светофора" или "на этой картинке мем JoJo". Вряд ли можно прогнать и такие параметры получить?
Хотя бы можно получить что-то наподобие "на этой картинке 3 объекта, 1 с площадью около 70%. 2 других с площадью 10%, преобладающий цвет синий (возможно небо или море), первый объект преобладающий цвет чёрный" ?

Просто получить хоть какие-то параметры с картинки, даже не вникая в то, какие они (чёрный ящик). И уже эти параметры сравнивать.
По форме, по площади, по относительному расположению.
На выходе просто набор цифр будет, коефициент a1:23 b3:48 и так далее.

И вряд ли оно на 100% совпадёт, если картинку подгоняли под обход баянометра.
madgod madgod 16.07.202321:32 ответить ссылка 0.1
Вопрос не в том, что человек хочет обмануть баянометр. Вопрос в том, что человек нашел чтото на просторах интернета, он не знает, это кроп, не кроп, и ему хочеться запостить. К примеру. Оригинал:
И человек нашел отдельно жопу:
Соотношение сторон разные. Цветовая маска разная. Яркость-контраст так же разные. В итоге все это сужение области поиска покидает чат, а в этом и основная проблема существующего баянометра - он не ищет существенные кропы, а переваривает только обрезку картинки ~10%. Все предложенные тобой методы сужения области поиска бессильны в таких случаях
почитал https://habr.com/ru/articles/571726/

как я и думал, нужно делать кучу операций для каждого изображения, а это пипец как затратно, нужно обладать хорошим железом, мощными видяхами, скорей всего.
По несколько сотен для каждой пикчи.
madgod madgod 16.07.202322:05 ответить ссылка 0.0
В том то и суть, что нужно что-то придумать, что давало бы хорошие результаты поиска, при небольших требованиях к мощностям и при высокой скорости. Выберите 2 из 3, как говорится
ExtraDJ ExtraDJ 16.07.202322:30 ответить ссылка -1.5
Слушай, а если у картинок разный цветокор, то всё равно же должна существовать зависимость между расположенными тёмными и светлыми участками? Перевести в оттенки серого и, возможно, немного усреднить тёмное и светлое, на эталоне и на второй картинке. И уже с этими данными работать. Найти схожие области со схожей интенсивностью серого в нужных местах. Найти какие-то максимумы и минимумы и примерное расположение, расстояния их друг от друга, соблюдаются ли пропорции, если копия оригинала является частью либо искажена по вертикали/горизонтали/по обеим сторонам/увеличена/уменьшена. С поворотами уже тяжко.


Короче, была бы крутая видюха, я бы повозился, а так смысла нет гадать.
madgod madgod 17.07.202312:24 ответить ссылка 0.0
Что бы оно работало, нужно собирать огромное количество данных, которые будут, вероятно, будут жрать даже больше ресурсов чем существующий поиск
Я думал, что там нужно сделать один прогон, для создания индексов и это займёт время, но один раз, для всех картинок. А потом всё будет быстрее.
Посчитать, на каком расстоянии расположены максимумы и минимумы и потом проверять, укладываются ли какие-либо несколько точек в указанные пропорции.
Можно попробовать на небольшой порции картинок и заранее известных паттернах или частях картинок.
madgod madgod 17.07.202320:58 ответить ссылка 0.0
А перцептивный хэш, или на таких объемах уже не работает?
Не имеет значения какой это будет хеш. У тебя их 3-4 ярда. Возьми и найди на таком объеме за менее чем секунд 10, используя при этом железо за приемлемую цену
Было же больше 7 лямов.. Я о этом, если что https://habr.com/ru/articles/120562/
7 лямов картинок. Баянометр сейчас работает на pHash, и вопрос в ликвидации его недостатков
Векторные БД ковырял?
sami822 sami822 16.07.202317:05 ответить ссылка 0.0
Думаю поковыряю, но пока нет на это времени и вдохновения
Я когда то их ковырял, но было это лет 5 назад. Они себя довольно хорошо показывали в тестах, но, у них тогда была главная проблема - кроп. ORB/SIFT/SURF очень не очень в плане скорости и ресурсов, но, они позволяют искать картинки даже имея только маленький кусочек ее. Это крайне специфическое требование, но оно нужно в рамках задач реактора. Куча постов с тянками, где одна фул, вторая - без головы, третья - только жопа, четвертая - только грудь
Картинка старше года уже не боян, а классика.
itury itury 16.07.202317:10 ответить ссылка -3.9
Или например можно для каждого изображения нагенерить текстовые теги. И баяны искать только среди изображений с тем же тегом. Тоже должно сократить объем поиска.
itury itury 16.07.202317:13 ответить ссылка -1.8
У нас одни и те же посты бывают в совшенно разных тегах и фендомах
Можно попробовать смотреть с главной изображения и по тегам. Если по тегам нет и в главной - значит не видели. Не факт, но большая вероятность.
Можно ли брать ограниченное количество точек (50 лучших) на целевом изображении и точек 100 на таргетах. Сохраняем хорошие таргеты, чтобы потом прогнать их с большим количеством точек. Можно попробовать сперва грубым ORBом пройти, потом SIFTом для сокращения ошибок.
argin argin 16.07.202317:34 ответить ссылка 0.0
Как вариант можешь попробовать что то по типу «Разделяй и властвуй», если конечно не пробовал.

Взять простую hash функцию которая при сравнении выдает хороший false negative близкий к 0, ну и конечно со средненькими остальными параметрами, но не с отвратительными.
Я не знаю какие варианты изменения картинок должны быть учтены, но как пример преобразовывать картинку до квадрата 2*2 и отсортировать цвета, можно в rgb, но можно и в hls. Можно и 1 доминирующий конечно взять, тут сильно зависит от входных данных.
Собрать hash со всех текущих картинок и кластеризовать с помощью к примеру c-means, прийдется с параметрами повозится, но надо решить по количеству кластеров дабы разбить на нормальное количество групп нормального размера.

При поиске выполнять hash для картинки и проверять к каким кластерам он относится с определенным порогом, далее уже можно использовать более традиционные методы, которые работают на меньших объемах данных.
Как вариант если hash не учитывает какие либо преобразования, то при поиске для картинки можно вычислять hash несколько раз до преобразования и после, далее сравнивать с теми кластерами с которыми похожи.

Это позволит уменьшить время для поиска. Так как вычисление hash не должно быть сложным, сравнение с центрами кластеров также простая операция. А далее пойдут более тяжелые операции на меньших объемах.
sansss sansss 16.07.202317:58 ответить ссылка 0.1
Я далек от этих алгоритмов но нельзя ли сделать следующий ход конем. Вначале при меньших затратах отсеить изображения которые точно не подходят. Ну допустим пройтись меньшим количеством точек, но абсолютно не подходящие убрать. А потом уже работать с теми которые могут подойти.
melwin melwin 16.07.202318:19 ответить ссылка 0.1
А я тут еще немного подумал. В свою тему. Если взять простых два три условия. Допустим первое. Количество цветов в картинке если уж совсем не хватает. В сторону. Общая сумарная яркость. Ну типо суммарно подсчитать оттенки яркого и темного. Совсем не совпадает в сторону. Как бы интересно комментарии специалиста. На сколько дорого процессору будет стоить такое. Я вот почему то думаю что таким типом можно порядка 50-60 процентов изображений отсеить.
melwin melwin 17.07.202312:26 ответить ссылка 0.0

баянометр замолчал..

дождаться рабочих серверов на ебаных кубитах...
fghjk fghjk 16.07.202318:54 ответить ссылка 0.6
думаешь будет дешевле 150$ в месяц?
Бля, у меня диплом на тему ORB был.
На работе коллега пилил статью на схожую тему, уже есть гораздо более приятные инструменты:
https://newtechaudit.ru/sopostavlenie-izobrazhenij-s-pomoshhyu-python-i-kornia/
Еще одна вариация точек...
Да, не вопрос, наверное она работает, и работает хорошо. Как быстро производить поиск по 7 лямов изображений. Вот главный вопрос
ExtraDJ ExtraDJ 16.07.202319:27 ответить ссылка -2.1
Bloom filter? Fenwick?
arkham arkham 16.07.202319:35 ответить ссылка 0.6
Уже используется
ExtraDJ ExtraDJ 16.07.202320:39 ответить ссылка -0.9
Если вдруг используешь pg_vector, появилась более быстрая альтернатива:
https://neon.tech/blog/pg-embedding-extension-for-vector-search
arkham arkham 17.07.202319:14 ответить ссылка 0.0
Хэши обычно юзают, в данном случае, если верно понимаю - хэши дескрипторов ключевых точек.. Надо локально искать? В любом случае, можно хранить в Clickhouse или другой колоночной БД. Если надо будет- могу подсказать движок и параметры таблицы для хранения такого.
Да, используются хеши ключевых точек. Подскажи базу данных, которая позволяет искать по хешам используя расстояние Хэмминга, при этом делает это быстро для огромного количества данных
ExtraDJ ExtraDJ 16.07.202320:42 ответить ссылка -1.5
Ну как «огромного», не бигдута, всё таки.
Как вариант - тот же Кликхаус:
https://clickhouse.com/docs/ru/sql-reference/functions/bit-functions?ysclid=lk5q6wailp474740462#bithammingdistance
Можно в лоб пробовать, но я бы заморочился с дополнительными признаками чтобы сократить выборку можно было, например - набор цветов.
Поиск делать через argMin() функцию, например. Короче, задача интересная, можно попробовать поковырялся.
clickhouse использовать точно не буду. Разработка яндекса
Дополнительные признаки не работают. Работали б - уже давно сделал бы. Можешь почитать комментарии выше
ExtraDJ ExtraDJ 16.07.202321:06 ответить ссылка -3.0
>>Разработка яндекса
Опенсурс же, э, хоть сам контрибьють.
Greenplum, Vertica, только я хз, есть ли там нужные функции или придётся руками реализовывать. В любом случае, мне кажется, нужна колоночная БД чтобы не таскать с диска гору ненужной инфы.
Отказываться от чуть ли не коробочного решения по идеологии - ну хз.
Я не буду использовать решения сделанные в рф. Это рак, по многим причинам. Какая цена этого мне абсолютно насрать. Тем более когда это касается не коммерческого проекта, за который я максимум что получу - тонну хейта
ExtraDJ ExtraDJ 16.07.202321:53 ответить ссылка -2.9
Кликхаус так хорош, что есть на амазоне и используется много где по миру
По какой причине там яндекс хз, может спонсоры. На работе используем для метрик, хорошая штука.
https://aws.amazon.com/ru/solutions/implementations/clickhouse-cluster/
>> По какой причине там яндекс хз
Потому что изначально Кликхаус - разработка Яндекса. Как и Catboost, например.
Так может, опенсурс сделаешь и мы просто форсунки и допилим с кайфом?
не знаю насчёт базы данных, но поиск по расстоянию хэмминга довольно быстро работает по деревьям (vp, bk).
можно попробовать поискать бд с реализациями индексов на таких деревьях, либо держать рядом микросервис для поиска на каком-нибудь расте, который за пару дней можно написать комбинируя примеры кода из документации даже не зная раст.
ищи реализации, которые поддерживают динамическое добавление элементов в дерево.
Деревня жрут тоже очень много ресурсов. Поиск на них уже пробовал. Результаты +- такие же
любая реализация поиска будет либо фуллскан, либо индекс.
скорей всего любая реализация индекса для поиска расстояний между хешами это будет дерево. вопрос только какое и как реализовано.

"очень много ресурсов" - это сколько? в память не влазит? нужно смотреть реализации, которые умеют держать индекс на диске. разбивать деревья на деревья поменьше и каким-то образом индексировать их, чтоб знать к какому дереву идти.

но в целом поиск по миллиадру значений это в любом случае интересное удовольствие. вот простая математика:
предположим, что размер хеша 64бит. это 8 байт.
миллион хешей это 8мб. за 120мс 8мб на современном процессоре можно обойти просто фуллсканом. наверное, даже не раз.
7 миллионов хешей - 56мб. это не фантастический объем данных.

миллиард хешей это 8 гб. 8гб фуллсканом обойти за разумное время за адекватные деньги за 120мс невозможно. а значит мы возвращаемся к первому пункту - нужен индекс.
а индекс это будет дерево.
Да, уже думал об этом. М наверное нужно пробовать дальше ковырять в этом направлении. Это единственная +- перспективная идея
ElasticSearch смотрел в этом направлении?
Слышал, но на практике не тыкал
Мы используем в проекте по недвиге - херова туча параметров 1 миллион объектов, находит совпадения даже частичные очень быстро.
Гуглеж на скорую руку выдал вот это обсуждение на stackoverflow (как раз поиск картинок) один чувак в комментах расписывает и мощностя и упоминает примеры с 15М объектов..

https://stackoverflow.com/questions/32785803/similar-image-search-by-phash-distance-in-elasticsearch
15 лямов я и так без каких либо проблем ворочаю. Текущий баянометр ворочает 7 лямов за ~120ms, на дохленьком vds. Для поиска по точкам нужно ворочать 3-4 миллиарда. Это совсем другого масштаба задача
Миллион секунд = 11.5 дней
Миллиард секунд = 32 года
Да, ниже уже прочитал что там 3-4 лярда. Выше прочитал про 7 лямов картинок, поэтому не подозревал масштабы объема данных. Ну думаю тогда ответ тут на данный момент только один - либо платить за мощностя либо забить...
Препроцессинг картинок всех через классификатор, грубо говоря - выясняем теги и свойства типа "перобладающие цвета"
Когда на вход баянометра подаётся картинка - тоже проганяется через классификатор и поиск производится через только через пространство тех картинок у которых совпадают теги (часть тегов). Это позволит отсеивать кууучу сорцов которые явно не совпадут.
Про предфильтры писал выше. Теги тоже хуйня. Для одной и той же картинки может быть тег эротика, в одном случае, и тег Pleasure Roomв другом. И при поиске рандомной картинки из интернета что делать? Тоже теги вводить?
теги не пользовательские, а то что через классификатор получится
Это уже ИИ модель, и это очень дорого по ресурсам + неточно. Невозможно гарантировать что модель распознает все что нужно. Всегда будут какие то исключения которые будут ломать поиск, по итогу
Про точность я не говорю, я пока говорю только про сужение пространства поиска. Раз SURF даёт хороший результат, но поиск по всему массиву картинок дорого - начни с того, чтобы сузить пространство поиска. Практика говорит о том, что если не делать "универсальное" решение - всегда найдётся возможность срезать углы какие-то. Я-бы тут начал с 3х вещей:
1. классификатор(грубо говоря определили что это аниме арт - отбрасываем не аниме картинки)
2. преобладающие цвета(эту технику вообще недооценивают, т.к. любой туториал начинается с "переводим в грейскейл", бонусом тут идёт инвариантность относительно размеров, соотношения сторон).
3. попробовал-бы гистограммы цвета. Решение элеметарное, очень "в лоб", но кажется зайдёт для такого контента хорошо
с классификатором эт надо верить пользователю, а это херовая идея сразу

возможно подойдет какой-то коэффициент соотношения сторон с допуском. маловероятно что картинка 16:9 будет баяном картинки 10:6
свети цветовое пятно с коэффициенту тоже хорошая идея. опять же сравнивать с возможностью некоторой погрешности
картинки по вертикали маловероятно что будут отражены, но могут быть отражены по горизонтали. возможно есть смысл делать центральный срез в пропорции, рубить его на шинглы и сводить к какому-нить цветовому пятну яркость которого использовать как коэффициент ( опять ) по которому отсеивать с некоторой границей допуска совпадения
но скорее всего уже есть готовые решения от более умных людей
я не предлагаю точное сравнение. никакой кроп не отъест пол картинки при этом не изменив ее значение. шакалы и цветокорекция не скажутся особо на световом пятне к которому будут сводиться шинглы
Окей, допустим. Определение что находиться на картинке будет жрать больше ресурсов чем фактический поиск, потому что нужно будет снова делать поиск, но уже не по хешам, а по индификаторам каким то, коих может быть и десяток, и сотня на одно изображение. Замкнутый круг. И опять таки, точность определения где искать будет прямо зависеть от того, будет найдено нужное, или нет. Для любой существующей модели невозможно гарантировать правильное определение того, что изображено на картинке, при на столько разносортных данных.
Цвета - помойка. Я не знаю какой долбоеб это везде пропагандирует, но это буквально худший метод из возможных. Очень дорогой по ресурсам, не жрет шакальство, не жрет ватермарки, не жрет нихуя.
Доп разобрал по комментариям выше:
https://joyreactor.cc/post/5589139#comment28045163
побуду капитаном очевидностью
у вас есть большой объем данных с которым в момент надо быстро сравнивать.
этот объем данных можно процессить и до запроса когда скорость важна
не весь объем данных на самом деле нужен, а только небольшая фракция. на сколько эта фракция большая зависит от того что считается баяном, а что нет. тобишь нужен список того что точно указывает на то что это баян
картинки могут отличаться друг от друга по ряду параметров которые уменьшат выборку. так как могут быть какие-то неточности в изображениях ( ватермарки, сжатие, отражение и т. д. ) то точное сравнение на большой выборке использовать нет смысла, но и неточные, скорее всего, позволят отсеять практически все что вот прям совсем не похоже
используя сравнение по точкам вы, возможно, каждый раз собираете точки с изображений. почему бы не хранить собранные данные чтобы каждый раз не обрабатывать весь массив данных?

вообще задача любопытная и явно 100500 раз решенная. надо лезть в гугл и искать что-нить на английском по этому поводу
BOLVERIN BOLVERIN 17.07.202300:41 ответить ссылка 0.0
Нет. Поиск производиться по уже собранным точкам, преобразованным в хеш. Таких точек на весь контент реактора - порядка 3-4 миллиардов, а общий объем всех картинок реактора - порядка 70Tb. Без предварительно собранных точек один поиск занимал бы неделю, если не больше.
Есть 100500 решений, которые не работают когда количество данных переваливает за 10 лямов
зачем искать эти точки по всем изображениям если можно сузить выборку до нескольких сотен вариантов?
самый банальный вариант:
соберите себе в папочку десяток оригинальных картинок и баяны к ним. выделите что повторяется. потом найдите еще пару десятков разных изображений и выделите то что всегда отличается
но, мне кажется, про предварительную обработку изображений для получения по ним данных можно найти уже готовые решения которые помогут упростить отсев совсем неподходящих вариантов
тем более что всего 10 лямов вариантов. большая часть индексов бд будет весить несколько десятков метров
Ручной отбор баянов? Шта?
Мне кажеться ты просто не понимаешь всех подводных камней этой задачи
похоже мы не понимаем друг друга :/
у вас проблема с выборкой данных. выборку можно сократить. чтобы сократить кол-во данных в выборке надо вывести правила отсева данных которые точно не нужны в выборке при этом чтобы этот отсев стоил минимальное кол-во ресурсов
Идея не нова, очевидна и логична, но, решения которое бы давало требуемый результат на практике я не придумал
я не первый кто предлагает вам покопать в сторону отсекания данных и предподготовки данных для того чтобы лишние отфильтровывать. получив такие данные можно создать легковесные индексы по которым сужать выборку
Не вопрос. Дайте реализацию работающую на практике, или материалы где это реализовано. Рассуждать о том, что в теории могло бы работать можно очень долго, но, без перспективно
Ты входной хеш прогоняешь по всем 4 лярдам, каждый раз рассчитывая расстояние Хемминга? Или как-то разделяешь выборку?

Есть условный хэш 39e5bd14f7a80c62, и он считает побитное отклонение, так? Можно рассчитать сумму "по символам". И изначально брать в поисковую выборку диапазоном от сумма +- допустимое отклонение. Эта сумма хотя бы будет индексироваться, хоть и увеличим базу на ~12Гб.
Для поиска используется дерево, которое при самом формировании создаёт более оптимальные связи сужающие область поиска. При формировании уже указывается допустимое отклонение. Но, поскольку данных очень много, то и дерево занимает очень много места в оперативе. Объективно говоря, поиск по 4 ярдам за 30 секунд, это охуенно, но не далеко от комфортного уровня
Зайдём с другой стороны, сколько бит в хеше? Что используется для расстояния хемминга сейчас?
И сколько картинок? +/-
А вариант делать предварительный поиск с использованием 50-100 опорных точек (с кучей ложноположительных срабатываний, как я понимаю?), выбором нескольких десятков-сотен тысяч вариантов, и потом уже среди выбранных кандидатов делать поиск по ~500 точкам без каких-то дополнительных оптимизаций? Или в этом случае что-то очевидным (не очень очевидным) образом будет работать не так, как надо?
trdelnik trdelnik 17.07.202304:19 ответить ссылка 0.0
Простой вопрос. Какие точки, из 4 ярдов, считать опорными?) Оригинальная картинка может иметь 500, допустим. Возьмём точку ближе всего к центру за опорную. Берём кроп, на которой не присутствует элемент с центральной точкой. Все, поиск пошел по пизде
Блин, реактор пожрал коммент. Еще раз вкратце. Я может быть не так понял проблему с поиском по хешам по 100 точкам, что имелось ввиду, что результат "говно". Если не находит фактические баяны - то увы. А если находит много случайных картинок, помимо баянов, то можно было бы построить два набора хешей - по 100 точкам и по 500. По 100 точкам делать предварительный поиск среди всех картинок, потом среди кандидатов проверять расширенные хеши. Да, надо хранить еще больше данных, зато, может быть, поиск по хешам по 100 точкам будет работать гораздо быстрее (и может только эти хеши нужно хранить в рам на постоянке), а по 500 точкам будет проверять гораздо меньше, чем 7 млн изображений.
крутилку на точность поиска запилить. Быстро, но придётся смотреть на ложноположительные. Медленно, но точно. Или быстрый поиск по 100 точка не даёт всех положительных результатов?
Как писал в посте - 100 точек дает результат в виде чего то жидкого. И ложно положительных результатов будут не десятки, а десятки тысяч
С виртухи нашел https://towardsdatascience.com/a-guide-to-building-an-image-duplicate-finder-system-4a46021410f1 и результат теста для его датасета интересные но непонятно подойдут ли для контента с реактора. Я проверил реализацию с EfficientNet-b0 and Euclidean Distance и вроед норм но нужен датасет с реактора и по хорошему нужно сравнить с текущей реализацией. Получение фичей работает быстро но у меня размер векторов фичей выходит на 80кб что на 1кк картинок выйдет за 80гб.
Далее мне было лень эксперементировать но один мой знакомый(https://chat.openai.com/share/f3ae236e-42f5-4ffd-b1f0-bfbb21c6c0d6) подсказал как можно пожать фичи.
В конце нужно по ним будет искать и тут есть варианты https://stackoverflow.com/questions/48019842/get-minimum-euclidean-distance-between-a-given-vector-and-vectors-in-the-databas. faiss я поставилл но далльше не стал ковыряться.
Только зарегистрированные и активированные пользователи могут добавлять комментарии.
Похожие темы

Похожие посты
Загрузить файл
Автоматом
Вставьте иР1_ картинки
Исходная
Пост 3500041
Пост 5548086
Пост 2206351
Пост 2210173
Пост 2210180
Пост 2488690
подробнее»

баяны баянометр баянометр кричал баянометр вопил баянометр найдет твой адрес

Загрузить файл Автоматом Вставьте иР1_ картинки Исходная Пост 3500041 Пост 5548086 Пост 2206351 Пост 2210173 Пост 2210180 Пост 2488690
Г)РОП{in СЫН
юснис,z%лет
пропял Г v „
ил Жм иге „кл/\сс
или ЬС-О.
подробнее»

метод поиска поставь лайк личное песочница

Г)РОП{in СЫН юснис,z%лет пропял Г v „ ил Жм иге „кл/\сс или ЬС-О.