-незначительное употребление алкоголя заметно снижает навыки и мозговую активность
А по-моему это очень дельное и правильное замечание, которое не грех переодически озвучивать и напоминать, особенно в среде айтишников.
Примерно такие повороты были и на моей практики в Норвегии. Когда надувные матрасы спустя год лопались, просто менял их на новые. Но больше всего запомнились случаи, когда ребенок захотел рыбачить, купил ему удочку, пошли рыбу половили пару дней. Потом надоело, и я сдал удочку обратно и получил деньги. Потом ребенок захотел кататься на коньках, купили, покатались, сдали, получили деньги обратно.
Но мы не злоупотребляли.
# нужен был для комментирования кода, особенно при отладке. А #include вообще спас от слепоты.
[[ ]] вынуждено добавлено, потому что < и > в иксемели зарезервированные и их нельзя использовать.
Ну а остальное, это взгляд на роад мэп. Можно как угодно.
А к удалению виджетов дело не дошло, потому что к тому времени уже отпустило.
В данном случае секунда это неплохо.
Но проверил на своей базе с 700 тыс хешами:
mysql> SELECT * FROM ( SELECT *, BIT_COUNT( 5175267106820201044 ^ hash ) as d FROM image_hash ORDER BY d LIMIT 0, 100 ) AS s WHERE d <= 7;
1 row in set (0.54 sec)
mysql> SELECT *, BIT_COUNT( 5175267106820201044 ^ hash ) as d FROM image_hash ORDER BY d LIMIT 0, 100;
100 rows in set (0.49 sec)
mysql> SELECT * FROM image_hash WHERE BIT_COUNT( 5175267106820201044 ^ hash ) <= 7;
1 row in set (0.35 sec)
Простая оптимизация запроса дает неплохой прирост.
Один хеш на изображение решает задачу полного либо совсем частичного совпадения. Но при задаче кластеризации дубликатов из базы, оказывается, что решения через SQL запросы не годятся.
Например, имеется 1000 изображений, которые надо найти в базе.
Реализация через запросы будет отрабатывать ~3-5 минут (если запрос за запросом). Если одним большим запросом, то это примерно ~20 секунд.
А если просто сделать линейный поиск в С++ и руками подсчитать, то это ~8 секунд.
Но и это как-то сильно туго. Поэтому дальше идет уже тяжелая артиллерия. Но это уже совсем другая история.
Прогнал по своей небольшой базе. Всего 1 250 фотографий. Плюс в том, что визуально мало похожих и нет дубликатов, поэтому найденные дубликаты — это гарантировано ложное срабатывание.
Началось все с ~2 % дубликатов. Пересмотрел выделения хешей, удалил дубли, вместо 191 хеша стало 50, при этом актуальные совпадения остались. Это дало ~0,75 % ложных результатов.
Решил покрутить критерии оценки. Было, например, расстояние Хэмминга не больше 11, что довольно много. Изменил на 8.
Снизил порог отношения найденных хешей к общему числу. И убрал проверку дескрипторов.
Это дало 0% ложных срабатываний.
И, конечно, не факт, что такое соотношение параметров будет давать 100% результат для любого изображения. Возможно требуется корректировка под частные случаи.
Я сперва тестировал на Харламове:
А Мадонна попалась потом, случайно. Потому что много резанных копий существует этой картинки и как раз на ней были проблемы.
-хэшировать уже такие нормализованные изображения
Примерно так сейчас я и делаю. В кластере нахожу минимальные и максимальные координаты, а потом смотрю и изменяю координаты так, чтобы были кратны расстоянию к центру кластера.
Это позволяет получать пропорциональные картинки и их легче сравнивать.
Думал что можно обойтись фиксированным размером вырезаемых картинок, но такое не годится. Думал может резать вокруг центра кластера как-то, тоже особо мало результатов. Даже проверял возможность сохранить отношения расстояний от центров кластеров. Т.е. пропорции расстояния, как примерно делатется в SIFT. Но так получается очень много чисел и их сложно сравнивать, чтобы получить адекватные результаты.
Ну и думал, что можно очистить вырезанные изображения и нарисовать там карту точек кластера, и уже делать хеш такой картинки. И еще много чего, но это все не работало.
На счет повороты, то тут они критичны, и если повернуть Лену на 180, то 39% только совпадет, pHash дает 39 расстояние.
Если на 90 градусов, то на 50% совпадет.
-3. Для каждого изображения рассчитать для каждой точки N хешей (с разными значениями параметра).
Это считай и есть дескрипторы: берется 16 блоков, по 4*4, вокруг точки и получают 8 чисел ориентиров. 16*8 = 128 чисел на точку.
Совпадение считают поиском ближайших точек.
И если будет 1000 точек, получается 128 000 чисел на картинку. Если картинок 1000, то хранить надо 128 млн чисел.
А проверить на совпадение 128 000 числа с первой картинки * 128 млн всего = 1,63*10^13 чтобы найти одну картинку полным перебором.
Тут вопрос как такое проделать в пределах одного небольшого сервера за умеренное время. И все, когда рассказывают как они делают поиск изображений по контенту, упоминают, что пользуют такие дескприпторы в каком-то виде, но каким образом хранят и проверяют, остается без подробного внимания (может вкраце скажут, что есть кластера, есть алгоритмы на деревьях по поиску совпадений). Ну еще это совсем небольшая часть проделываемых манипуляций.
habrahabr.ru/post/143667/ — Вон Яндекс отсеивает за 2 минуты дубликаты из коллекции в миллион изображений на ноутбуке.
И вариантов поиска изображений по признакам очень много, начиная от гистограмм и до мд5 хешей.
В очень незначительных пределах. И такие хеши не годятся для проверки на такие геометрические преобразования. Возможно есть вариант проверки на последовательность хешей и каждый нарезок будет немного повернут, но в итоге совпадут с не повернутым вариантом.
Сложность была в том, что каждый раз, при загрузке новой картинки, приходилось бы проходить так по базе (сохраненных точек и дескрипторов) и делать проверку на совпадение. Слишком было бы толсто. Думал, что есть возможность сделать легче.
Живая база сейчас не содержит дубликатов вообще. И подобный способ определения дубликатов нужен, чтобы не допустить их появления. Хотя в планах было прогнать все изображения и сравнить со всеми, но думаю там не будет совпадений и найдет только себя, (или будет не много, но проверю).
Потому что похожих картинок не так много, если есть вообще.
Что касается вообще ложных срабатываний, то тут конечно очень большой простор и реально есть множество фотографий, которые неправильно считаются дубликатами, из-за многих факторов.
Например недавно получил ложный дубликат картинки, где было много фактурных нарезков, хеши которых совпадают и, опять, сиськи (как отличить одни сиськи от других?). Т.е. из-за совпадения некоторого числа фоновых нарезков и форм грудей, две картинки были признаны дубликатами.
И критерии я пытался выставлять так, чтобы лучше не было вообще совпадений, чем были ложные.
Возможно более актуальная база изображений показала бы, что требуется серьезная дороботка получения хешей, может более жесткие правила к формату нарезков, может увеличить разрядность кластеризации, может проверять не просто хеши, а строить последовательности и проверять совпадение очередности, ну и так далее. Пока стояла задача облегчить жизнь при модерации.
Интересно, какой рост и какую динамику они хотят от 35летнего сеньер дева? И вообще интересно, какой темп развития может показать опытный разработчик средних лет.
Извините за нескромность, а вы уже довкалывались до 100-200 тыс Евро в год?
Сами верите в такую возможность для гипотетического русского иммигранта в вакууме?
А по-моему это очень дельное и правильное замечание, которое не грех переодически озвучивать и напоминать, особенно в среде айтишников.
Но мы не злоупотребляли.
когда не отпускало, казалось это очень хорошей идеей.[[ ]] вынуждено добавлено, потому что < и > в иксемели зарезервированные и их нельзя использовать.
Ну а остальное, это взгляд на роад мэп. Можно как угодно.
А к удалению виджетов дело не дошло, потому что к тому времени уже отпустило.
Это нарисует такие какртинки как в статье.
В файле bdm.py есть параметр m, количество требуемых точек.
Может потому, что все остальное не вмещалось в 512 на 512 пикселей?
Some people proposed banning the use of this image because of its source.
О времена, о нравы. Какая была шумиха только от одной мысли, что скан был сделан с фотографии где не прикрыто.
В любом случае, прошло уже 42 года, а мы все еще помним. Бабушке Ленне наверное приятно.
Но проверил на своей базе с 700 тыс хешами:
Простая оптимизация запроса дает неплохой прирост.
Один хеш на изображение решает задачу полного либо совсем частичного совпадения. Но при задаче кластеризации дубликатов из базы, оказывается, что решения через SQL запросы не годятся.
Например, имеется 1000 изображений, которые надо найти в базе.
Реализация через запросы будет отрабатывать ~3-5 минут (если запрос за запросом). Если одним большим запросом, то это примерно ~20 секунд.
А если просто сделать линейный поиск в С++ и руками подсчитать, то это ~8 секунд.
Но и это как-то сильно туго. Поэтому дальше идет уже тяжелая артиллерия. Но это уже совсем другая история.
Началось все с ~2 % дубликатов. Пересмотрел выделения хешей, удалил дубли, вместо 191 хеша стало 50, при этом актуальные совпадения остались. Это дало ~0,75 % ложных результатов.
Решил покрутить критерии оценки. Было, например, расстояние Хэмминга не больше 11, что довольно много. Изменил на 8.
Снизил порог отношения найденных хешей к общему числу. И убрал проверку дескрипторов.
Это дало 0% ложных срабатываний.
И, конечно, не факт, что такое соотношение параметров будет давать 100% результат для любого изображения. Возможно требуется корректировка под частные случаи.
А Мадонна попалась потом, случайно. Потому что много резанных копий существует этой картинки и как раз на ней были проблемы.
Примерно так сейчас я и делаю. В кластере нахожу минимальные и максимальные координаты, а потом смотрю и изменяю координаты так, чтобы были кратны расстоянию к центру кластера.
Это позволяет получать пропорциональные картинки и их легче сравнивать.
Думал что можно обойтись фиксированным размером вырезаемых картинок, но такое не годится. Думал может резать вокруг центра кластера как-то, тоже особо мало результатов. Даже проверял возможность сохранить отношения расстояний от центров кластеров. Т.е. пропорции расстояния, как примерно делатется в SIFT. Но так получается очень много чисел и их сложно сравнивать, чтобы получить адекватные результаты.
Ну и думал, что можно очистить вырезанные изображения и нарисовать там карту точек кластера, и уже делать хеш такой картинки. И еще много чего, но это все не работало.
На счет повороты, то тут они критичны, и если повернуть Лену на 180, то 39% только совпадет, pHash дает 39 расстояние.
Если на 90 градусов, то на 50% совпадет.
А вот масштабы тут не важны.
Это считай и есть дескрипторы: берется 16 блоков, по 4*4, вокруг точки и получают 8 чисел ориентиров. 16*8 = 128 чисел на точку.
Совпадение считают поиском ближайших точек.
И если будет 1000 точек, получается 128 000 чисел на картинку. Если картинок 1000, то хранить надо 128 млн чисел.
А проверить на совпадение 128 000 числа с первой картинки * 128 млн всего = 1,63*10^13 чтобы найти одну картинку полным перебором.
Тут вопрос как такое проделать в пределах одного небольшого сервера за умеренное время. И все, когда рассказывают как они делают поиск изображений по контенту, упоминают, что пользуют такие дескприпторы в каком-то виде, но каким образом хранят и проверяют, остается без подробного внимания (может вкраце скажут, что есть кластера, есть алгоритмы на деревьях по поиску совпадений). Ну еще это совсем небольшая часть проделываемых манипуляций.
habrahabr.ru/post/143667/ — Вон Яндекс отсеивает за 2 минуты дубликаты из коллекции в миллион изображений на ноутбуке.
И вариантов поиска изображений по признакам очень много, начиная от гистограмм и до мд5 хешей.
Сложность была в том, что каждый раз, при загрузке новой картинки, приходилось бы проходить так по базе (сохраненных точек и дескрипторов) и делать проверку на совпадение. Слишком было бы толсто. Думал, что есть возможность сделать легче.
Потому что похожих картинок не так много, если есть вообще.
Что касается вообще ложных срабатываний, то тут конечно очень большой простор и реально есть множество фотографий, которые неправильно считаются дубликатами, из-за многих факторов.
Например недавно получил ложный дубликат картинки, где было много фактурных нарезков, хеши которых совпадают и, опять, сиськи (как отличить одни сиськи от других?). Т.е. из-за совпадения некоторого числа фоновых нарезков и форм грудей, две картинки были признаны дубликатами.
И критерии я пытался выставлять так, чтобы лучше не было вообще совпадений, чем были ложные.
Возможно более актуальная база изображений показала бы, что требуется серьезная дороботка получения хешей, может более жесткие правила к формату нарезков, может увеличить разрядность кластеризации, может проверять не просто хеши, а строить последовательности и проверять совпадение очередности, ну и так далее. Пока стояла задача облегчить жизнь при модерации.