Как стать автором
Обновить

Комментарии 16

Круто. Но если кому тоже надо просто найти разок дубликаты, то есть готовый инструмент: geeqie: File -> Find duplicates. С сортировкой по похожести и полноценным просмотрщиком изображений. (Для windows похоже его нет.)
На самом деле программ для поиска дубликатов не так чтобы много, но они есть, и изначально я как раз-таки попробовал несколько программ с GUI. Не скажу, что все они были плохи, но у многих опять же всё упирается в производительность, ну и нет у меня столько свободного времени, чтобы сидеть и выбирать, правильно ли они нашли дубликаты. Мне нужен был такой способ, чтобы «сделал и забыл». Сейчас я просто выгружаю фотографии на сервер, а обработчики уже сами выкидывают дубликаты и раскладывают файлы. Ну и отдельная песня — это ОЧЕНЬ похожие изображения, про которые я писал в статье и которые смысла нет хранить, тут у меня анализ сваливается в вебку и вот там уже приходится ручками сортировать.

GUI инструменты трудно автоматизировать, тогда как перл-скрипт, проверяющий дубликаты, можно сделать частью pipeline, и расчищить и раскладывать фотографии в автоматическом режиме.

Если нужно просто найти дубликаты, существует утилита fdupes.
К сожалению fdupes совершенно не подходит для работы с изображениями. Как nix-юзер с многолетним стажем, я в первую очередь эту тулзу попробовал. Дело в том, что у неё первоначальный анализ строится на MD5 хешах, а практически все изображения содержат, кроме собственно изображения, — Exif. И тут уже сразу большая часть дубликатов пролетает мимо. Ну а дальше, опять же низкая производительность, так как используется сверка по-байтно.

Такой нюанс ещё. Может быть несколько фотографий одинаковых, но оригинал один, а остальные сохранённые из мессенджеров, следовательно ужатые.

И ещё была прога от Google - picasa, она тоже отлично дубликаты находила.

В своё время для автоматизации похожих изображений использовал библиотеку phash. Правда она и тогда была уже старая, я ее под php 5.6 ещё собирал )

Совершенно верно, кроме мессенджеров, я у себя нашел слитые папки из IPhoto, там такая же ерунда да еще и превьюшки. Тут я уже использую схожесть хешей, приходится вводить, эм, скажем так «коэффициент достоверности», то есть допуски по расхождению хешей.

пару месяцев провозился с этой темой вот что могу сказать

судя по длине хеш алгоритм сжимает картинку до матрицы 8*8 , на практике этого не достаточно если очень много фото у вас пойдет много ложных срабатываний на первый взгляд разные картинки будут давать полное совпадение хеш

надо увеличить хеш сжимать картинку до 16*16 у вас на каждую картинку будет 4 таких хеш

Общи алгоритм примерно такой:

  • Обрезаем картинку берем квадрат по центру

  • Сжимаем картинку до указанного размера

  • запускаем цикл и проходим по пикселям

  • берем в точке цвет, получаем 3 составляющих красный = 123, зеленый = 23 и синий  = 233 

  • вычисляем итоговое значение Zxy = ( красный-зеленый - синий) 2   квадрат разницы,  полученное число заносим в массив 

  • записываем значения для всех точек в массив

  • вычисляем среднее average   для всего массива

  • проходим в цикле по массиву сравниваем каждое Zxy   со средним значение если оно больше то в битовую маску пишем 1 если меньше пишем 0

  • получаем битовую маску 0101010101010101010101011111111

  • далее битовую маску можно получить в виде x16 кода, битовой строки или массива

Еще один момент на который хочу обратить  внимание - в MySQl максимальный размер BIT поля = 64  бита, а это соответствует матрице 8x8, что нам категорически не подходит. Для того, чтобы увеличить длину  хранимой маски  в 4 раза  я сделал в таблицы MySQL 4 поля по 64 бит.   Выкладываю свой  класс где  возможность задавать размер матрицы до которой сжимается оригинальное фото.  Для  работы требуется библиотека  imagick. http://bugacms.com/?i=267

Большое спасибо за комментарий, по ссылке как раз обсуждаются эти моменты, предлагаются даже матрицы большего размера 32х32. Естественно я принимал во внимание возможность ложного срабатывания, поэтому никогда бы не стал обрабатывать весь массив фотографий, — как я писал ранее, они уже рассортированы по периодам. А вот при обработки новых фото, вероятность практически нулевая, так как нет необходимости сравнивать со ВСЕМИ фотографиями, а только с аналогичным периодом. А для поиска в вебке «по фото», такого размера хеша более чем достаточно, ложными срабатываниями можно пренебречь и даже расширить допуски, чтобы можно было находить ПОХОЖИЕ изображения. И да, я попробовал фотографии с Вашего сайта, вот результаты:
1 Ph: FFFFFF3F00040400
2 Ph: FFFFFF4000000000
3 Ph: FFFFEB0000000000

видимо ваш алгоритм получения матрицы немного отличается от того исходника с которого я начинал

Он не мой :) Я вообще только после Вашего комментария решил заглянуть ему "под капот". Еще раз, спасибо за комментарий.

Почему бы не залить все в гугл фото, где все описанные проблемы будут решены автоматически?

Все фото за 20 лет? А вспоминая истории с потерей файлов на cloud.mail.ru, ну его нафиг. Ну и в свете последних событий, можно и вообще доступа лишится к таким сервисам.

У меня обратный опыт - сколько потерянных фото с разных девайсов и умерших дисков - не счесть.

Да, тоже потерял кучу фото, в основном по выходу из строя HD. Спасибо Sun Ms за ZFS, а особо, за zfs snapshot, не страшно даже по ошибке удалить что-то. Пользуюсь ZFS на «боевых» серверах начиная с FreeBSD 9, — за все годы ни разу не потерял свои данные.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории