Товара пока ещё нет. То, что в некоторых ситуациях при активном хвате устройство скорее будет мешать - это верно. В остальное время я думаю, особых неудобств кольцо доставлять не должно. Оговорюсь, я не про зиму с нашими холодами и варежками-перчатками.
Прошу прощения за столь долгое ожидание, в выходные дни я был занят.
В данном случае из-за низкого разрешения скриншота вылезли локальные различия с проиндексированным образцом. У меня в настройках стояло условие, что если усреднённое значение в локальной области (разбивка на табличные области подробно рассматривается в одной из статей по ссылке) больше 20, то такой образец отбрасывается. Я поставил более грубое значение 30 и поиск оказался успешным. Попробуйте повторить сами.
Думаю надо добавить возможность настройки пользователем выполнить более тщательный поиск, но это, к сожалению, сказывается на скорости поиска и, как следствие, на производительности .
А код приложения обработки исходного видео? А код построителя базы данных, а код скрэпера?
А ключи от квартиры где деньги лежат?
Залить фото по url на сервер я и так могу,
Не-а, не можете. Сервер не принимает изображения. Обработка изображений на сайте и в приложениях ведётся на стороне клиента (для клиента это занимает секунду, а сервак разгружает). Сервер получает только результат обработки изображения (массив чисел).
Именно поэтому и нужна библиотека. Она этой обработкой и занимается.
На сегодняшний день в базе данных более 30 000 проиндексированных фильмов (список есть на сайте), но порно там нет (ну может, какие то фильмы случайно затесались).
В принципе, нет ограничений по жанрам, и, если Вы хотите добавить сами целенаправленно какие то фильмы, то для этого есть специальное приложение. Нужно только потратить время на заполнение полей (название, жанр, актёры, год выпуска и т.п.) и само видео, после чего отправка индексных данных на сервер, а потом в БД. В начале этого поста есть ссылки на другие публикации, там этот процесс описан довольно подробно.
Поиск медиаконтента - в целом весьма интересная тема, но слищком мало по этой теме информации
В целом согласен, но есть очень интересные публикации. Вот, наткнулся недавно, хотя сами статьи опубликованы 5 лет назад.
Существуют ли какие-то "общепринятые" решения в этой области? Например для обычного хеширования (применяемого в том числе в p2p сетях) применяют некий набор хешей со стандартными алгортмами. А для перцептивных хешей изображений, аудио и видео есть такие общепринятые решения?
Нет, не встречал. Думаю, отчасти это связано с тем, что компании, занимающиеся этим, не хотят так просто раскрывать свои секреты. А они есть! Тема весьма непростая, на мой взгляд.
Предоставляют ли крупные веб-сервисы (поисковики, соцсети) возможность поиска по готовому хешу?
Не всё так просто, на самом деле. Алгоритм работы такой, что для построения базы требуется файл указателей (некоторые подробности алгоритма есть в статьях). Он предназначен для быстрой работы с гигантским объёмом информации и сам тоже не маленький - 32 ГБ. Каждый день выделять по 32 ГБ (это не считая самих данных) - это около 214 ГБ в неделю быстрой SSD памяти. Тут ещё и износ и прочее. Если бы этим занимался Яндекс, Майкрософт или Гугл, то они бы на эти расходы чихали с высокой башни. А если этим занимается небольшая комманда с ограниченным бюджетом, то ...
Идея вроде неплоха, но, если честно, я проектировал систему исходя из того, что она будет обрабатывать сотни поисковых запросов в секунду (даже сейчас на слабом неттопе даёт под сотню), и, если хотя бы половина из них будет иметь отрицательный результат, то даже база под эту информацию будет довольной большой. Не говоря уж о том, что потом эти запросы надо заново прогнать и отправить пользователю сообщение... Большая нагрузка. И нужен ли этот результат пользователю спустя неделю или месяц?
Абзац был там с самого начала. Почему не обновляется сразу? Алгоритм требует перестройки всей базы (помимо базы с описаниями фильмов, она обычная) для быстроты поиска. Делать это после добавления каждого видео - слишком большие затраты и износ SSD. Поэтому обновление происходит через значительный промежуток времени.
Спасибо за проделанную работу! Вы правы в списке фильмов приложения добавленный фильм появляется сразу, хотя проверка и добавление в базу происходят не так часто. В статье я указал, что сборка базы происходит раз в неделю, думаю, что через указанное время он там появится.
Пока думаю над этим. Дело в том, что планируемый объём данных будет довольно большим, порядка 15-20 ТБ и это должны быть данные на SSD. Требуется довольно мощное и специфичное железо, что большинству не по карману и уже накладывает определённые ограничения.
По-поводу хэш функции: тут, не столько она плоха, сколько сами данные. Здесь я должен извиниться и сказать, что в данной публикации не описал механизм получения исходных данных для вычисления хэша, а они получаются путём загрубления значений R,G,B.
R'=R/8; G'=G/8; B'=B/8;
Иначе флуктуации значений (от пережатых версий видео или JPEG компрессии скриншотов) будут зашкаливать.
Самое большое количество кадров приходится на значения R=G=B=0. Потом R=G=B=255, ну и дальше - градации серого.
Что касается 32 битного целого, то тут ситуация такова. То, что кадров больше, чем значений хэша - в этом нет ничего плохого. Просто когда мы ищем наш кадр, мы анализируем группу с этим значением хэша. Если их там несколько десятков, то мы их быстро проанализируем. Даже если несколько сотен, то на SSD всё летает. Проблема, когда их тысячи и больше. А в выше упомянутых ячейках R'=G'=B'=0 их в той базе может быть несколько миллиардов, что уже очень плохо. Но, плюс U32 в том, что база указателей имеет фиксированный размер в 32 ГБ и она по первому же fseek'у и read'у даёт нам место, где читать данные уже в файле с записями и сколько их читать! Для U64 файл указателей будет нереально большой. Кроме того, это потребует много аппаратных и вычислительных ресурсов при перестроении данных (если мы добавим информацию о новых видео).
Всё же поиск в отдельных случаях требует дополнительного ускорения и я для этого использую перцептивные хэши (об этом в следующей публикации). Как я их использую? Внутри группы с конкретным индексным хэшем данные сортируются по перцептивному хэшу. Получается двойное механизм индексации. Это реально помогает, хотя там есть некоторые нюансы. И, несмотря на это, для некоторых значений R'=G'=B'=0 и некоторых других внутри данной группы могут быть очень длинные подгруппы с одинаковым значением перцептивного хэша. Вот такие цепочки я отбрасываю.
Что касается последнего Вашего замечания, то я его не понял. Хэш я вычисляю для каждого кадра, а mjpeg используется для видео (т.е. множества кадров).
Все манипуляции можно производить большим пальцем. Этого вполне достаточно для нажатия кнопок и вращения колёсика прокрутки.
Товара пока ещё нет. То, что в некоторых ситуациях при активном хвате устройство скорее будет мешать - это верно. В остальное время я думаю, особых неудобств кольцо доставлять не должно. Оговорюсь, я не про зиму с нашими холодами и варежками-перчатками.
Спасибо за информацию, но в Хроме, Лисичке и Эдже всё OK.
Есть похожее приложение "Стихотворец". В чём то очень похоже.
Спасибо за информацию. Ознакомился с сайтом. В чём то похвально, но
Hidden text
Прошу прощения за столь долгое ожидание, в выходные дни я был занят.
В данном случае из-за низкого разрешения скриншота вылезли локальные различия с проиндексированным образцом. У меня в настройках стояло условие, что если усреднённое значение в локальной области (разбивка на табличные области подробно рассматривается в одной из статей по ссылке) больше 20, то такой образец отбрасывается. Я поставил более грубое значение 30 и поиск оказался успешным. Попробуйте повторить сами.
Думаю надо добавить возможность настройки пользователем выполнить более тщательный поиск, но это, к сожалению, сказывается на скорости поиска и, как следствие, на производительности .
OK, гляну.
А код приложения обработки исходного видео? А код построителя базы данных, а код скрэпера?
А ключи от квартиры где деньги лежат?
Не-а, не можете. Сервер не принимает изображения. Обработка изображений на сайте и в приложениях ведётся на стороне клиента (для клиента это занимает секунду, а сервак разгружает). Сервер получает только результат обработки изображения (массив чисел).
Именно поэтому и нужна библиотека. Она этой обработкой и занимается.
Можно в личку информацию о браузере, а ещё лучше скриншот с консоли?
Вопрос, конечно интересный, но ...
На сегодняшний день в базе данных более 30 000 проиндексированных фильмов (список есть на сайте), но порно там нет (ну может, какие то фильмы случайно затесались).
В принципе, нет ограничений по жанрам, и, если Вы хотите добавить сами целенаправленно какие то фильмы, то для этого есть специальное приложение. Нужно только потратить время на заполнение полей (название, жанр, актёры, год выпуска и т.п.) и само видео, после чего отправка индексных данных на сервер, а потом в БД. В начале этого поста есть ссылки на другие публикации, там этот процесс описан довольно подробно.
В целом согласен, но есть очень интересные публикации. Вот, наткнулся недавно, хотя сами статьи опубликованы 5 лет назад.
Нет, не встречал. Думаю, отчасти это связано с тем, что компании, занимающиеся этим, не хотят так просто раскрывать свои секреты. А они есть! Тема весьма непростая, на мой взгляд.
Нет.
Не всё так просто, на самом деле. Алгоритм работы такой, что для построения базы требуется файл указателей (некоторые подробности алгоритма есть в статьях). Он предназначен для быстрой работы с гигантским объёмом информации и сам тоже не маленький - 32 ГБ. Каждый день выделять по 32 ГБ (это не считая самих данных) - это около 214 ГБ в неделю быстрой SSD памяти. Тут ещё и износ и прочее. Если бы этим занимался Яндекс, Майкрософт или Гугл, то они бы на эти расходы чихали с высокой башни. А если этим занимается небольшая комманда с ограниченным бюджетом, то ...
Идея вроде неплоха, но, если честно, я проектировал систему исходя из того, что она будет обрабатывать сотни поисковых запросов в секунду (даже сейчас на слабом неттопе даёт под сотню), и, если хотя бы половина из них будет иметь отрицательный результат, то даже база под эту информацию будет довольной большой. Не говоря уж о том, что потом эти запросы надо заново прогнать и отправить пользователю сообщение... Большая нагрузка. И нужен ли этот результат пользователю спустя неделю или месяц?
Абзац был там с самого начала. Почему не обновляется сразу? Алгоритм требует перестройки всей базы (помимо базы с описаниями фильмов, она обычная) для быстроты поиска. Делать это после добавления каждого видео - слишком большие затраты и износ SSD. Поэтому обновление происходит через значительный промежуток времени.
Спасибо за проделанную работу! Вы правы в списке фильмов приложения добавленный фильм появляется сразу, хотя проверка и добавление в базу происходят не так часто. В статье я указал, что сборка базы происходит раз в неделю, думаю, что через указанное время он там появится.
Основная идея сервиса - создать нечто подобное Shazam,но только для видео. А всё остальное - вторично.
Вы правы, спасибо, я исправил.
Пока думаю над этим. Дело в том, что планируемый объём данных будет довольно большим, порядка 15-20 ТБ и это должны быть данные на SSD. Требуется довольно мощное и специфичное железо, что большинству не по карману и уже накладывает определённые ограничения.
Да, пожалуй Вы правы. Так и сделаю.
Спасибо за развёрнутый комментарий!
По-поводу хэш функции: тут, не столько она плоха, сколько сами данные. Здесь я должен извиниться и сказать, что в данной публикации не описал механизм получения исходных данных для вычисления хэша, а они получаются путём загрубления значений R,G,B.
R'=R/8; G'=G/8; B'=B/8;
Иначе флуктуации значений (от пережатых версий видео или JPEG компрессии скриншотов) будут зашкаливать.
Самое большое количество кадров приходится на значения R=G=B=0. Потом R=G=B=255, ну и дальше - градации серого.
Что касается 32 битного целого, то тут ситуация такова. То, что кадров больше, чем значений хэша - в этом нет ничего плохого. Просто когда мы ищем наш кадр, мы анализируем группу с этим значением хэша. Если их там несколько десятков, то мы их быстро проанализируем. Даже если несколько сотен, то на SSD всё летает. Проблема, когда их тысячи и больше. А в выше упомянутых ячейках R'=G'=B'=0 их в той базе может быть несколько миллиардов, что уже очень плохо. Но, плюс U32 в том, что база указателей имеет фиксированный размер в 32 ГБ и она по первому же fseek'у и read'у даёт нам место, где читать данные уже в файле с записями и сколько их читать! Для U64 файл указателей будет нереально большой. Кроме того, это потребует много аппаратных и вычислительных ресурсов при перестроении данных (если мы добавим информацию о новых видео).
Всё же поиск в отдельных случаях требует дополнительного ускорения и я для этого использую перцептивные хэши (об этом в следующей публикации). Как я их использую? Внутри группы с конкретным индексным хэшем данные сортируются по перцептивному хэшу. Получается двойное механизм индексации. Это реально помогает, хотя там есть некоторые нюансы. И, несмотря на это, для некоторых значений R'=G'=B'=0 и некоторых других внутри данной группы могут быть очень длинные подгруппы с одинаковым значением перцептивного хэша. Вот такие цепочки я отбрасываю.
Что касается последнего Вашего замечания, то я его не понял. Хэш я вычисляю для каждого кадра, а mjpeg используется для видео (т.е. множества кадров).