Данный пост создан исключительно с целью продемонстрировать, что реактор может иметь встроенный баянометр приемлемой функциональности без существенных затрат на его реализацию и сервера. Он ни в коем случае не пытается бросить тень на существующий баянометр от ExtraDj - вполне возможно его баянометр в сто раз круче (я не знаю).
Я совсем недавно начал создавать посты на реакторе, но уже успел ощутить всю проблематику поиска повторяющегося контента на этом ресурсе. И задумался о том, как много времени реактор мог бы сэкономить постерам, имей он встроенный баянометр. Сколько человек не смогли преодолеть сложности размещения контента на реакторе и сколько перестали это делать из-за большого количества времени, которое на это требуется (сужу исключительно по себе).
А недавно ещё и получил разрешение от Вождя. Что ж, доступа к коду сайта и базе у меня нет. Выкачивать весь его контент, чтобы собрать отдельный баянометр я особо желанием не горю. Но могу, по крайней мере, разобраться в ситуации и продемонстрировать Proof of concept.
Я дотнетчик по большей части, поэтому технологии используются соответствующие. Вряд ли технологии, которые используются реактором, имеют какие-то существенные ограничения чтобы справиться с этой задачей.
Итак. Перцептивный хэш - похоже, то, что нам нужно. Проблема распространенная, поэтому сразу же нашлась библиотека, которая этот хэш считает - по крайней мере эту рутину писать не придётся. Как будто мы ещё ничего не сделали, а решение уже готово. Протестируем.
Первый кадр из видео. Разрешение 720х1280 против 320х568.
AverageHash и PerceptualHash - абсолютно одинаковые цифры. А это значит, что если вы сохраните этот хэш в БД рядом с картинкой, вы легко сможете достать по нему запись о картинке. Похоже баянометр в простейшем виде уже готов.
Извлечение данных. Т.к. некоторые реакторчане ссылались на проблему поиска в большом количестве данных, нужно протестировать и это. Приблизительно 7000000 картинок есть на реакторе. Возьмём MS Sql server. Создадим таблицу с 7000000 записей со случайными цифрами в качестве хэша. Чтобы всё было по-честному:
Изменим одно из значение на реальный хэш с картинки выше. И посмотрим сколько надо времени чтобы её найти.
По-моему проблем тут нет.
Дальше. Что если картинка немного отличается от оригинала. Например нам надо сравнить первый кадр видео с гифкой. Гифка, будет иметь кучу артефактов и, возможно, другой начальный кадр. Как тут:
Либо яркость на картинке выкручена на максимум, как тут:
Хэши не совпадают. Всё пропало? Не совсем. Обратите внимание на подсчёт "похожести" хэшей внизу картинок. Всё что нам нужно сделать, чтобы начать находить не только идентичные картинки, но ещё и похожие - это перенести логику подсчёта похожести в запрос к БД. Получим.
Теперь по затратам времени и ресурсов. На этот Proof of concept ушло несколько часов - большая часть на подготовку и написание поста. Добавить его на любой свой сайт я могу за несколько часов. Нагрузку на сервер вы можете видеть в статистике запроса к БД. По-моему скромному мнению - она никакая. А если учесть, что эти запросы будут редкими - только при создании новых постов, то ими вообще можно пренебречь. Железу, на котором запущен sql сервер более пяти лет. Более того, пять лет назад это был бюджетный домашний комп.
![■ Demo application ImageHash □ X : [[«*>■ Dl ^ [□] . {o}6 I (2) < AverageHash DifferenceHash Perceptual Hash Browse Load Clear 73051550389305359 1112177781819418778 14419936282921065570 AverageHash DifferenceHash PerceptualHash Browse Load Clear 73051550389305359 1112177781817321882](http://img0.joyreactor.cc/pics/post/full/%D0%B1%D0%B0%D1%8F%D0%BD%D0%BE%D0%BC%D0%B5%D1%82%D1%80-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0-%D0%B4%D0%BB%D0%B8%D0%BD%D0%BD%D0%BE%D0%BF%D0%BE%D1%81%D1%82-8130856.png "баянометр,разработка,длиннопост")
Отличный комментарий!