По-поводу хэш функции: тут, не столько она плоха, сколько сами данные. Здесь я должен извиниться и сказать, что в данной публикации не описал механизм получения исходных данных для вычисления хэша, а они получаются путём загрубления значений 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 используется для видео (т.е. множества кадров).
Совершенно верно. Велосипед. Но не детский трёхколёсный, а спортивный, многоскоростной.
Моя система по загруженному изображению может сказать не только из какого фильма данный кадр или отрывок, но и показать место из которого данный кадр или отрывок взяты. На данный момент есть готовый поисковый инструментарий, работающий веб-сайт и клиентский софт как для добавления информации, так и для поиска. От пользователя требуется лишь заполнить информацию о видео (название, режиссёр и пр.) и всё.
Что касается упомянутых Вами алгоритмов, то у них другая задача, да и требования к памяти, насколько я могу судить, совсем другие.
По поводу Джины. Судя по описанию на сайте, это некий инструмент, а не готовый к использованию продукт, хотя могу ошибаться, т.к. не имел опыта работы с ней.
Да, пожалуй Вы правы. Так и сделаю.
Спасибо за развёрнутый комментарий!
По-поводу хэш функции: тут, не столько она плоха, сколько сами данные. Здесь я должен извиниться и сказать, что в данной публикации не описал механизм получения исходных данных для вычисления хэша, а они получаются путём загрубления значений 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 используется для видео (т.е. множества кадров).
Моя система по загруженному изображению может сказать не только из какого фильма данный кадр или отрывок, но и показать место из которого данный кадр или отрывок взяты. На данный момент есть готовый поисковый инструментарий, работающий веб-сайт и клиентский софт как для добавления информации, так и для поиска. От пользователя требуется лишь заполнить информацию о видео (название, режиссёр и пр.) и всё.
Что касается упомянутых Вами алгоритмов, то у них другая задача, да и требования к памяти, насколько я могу судить, совсем другие.
По поводу Джины. Судя по описанию на сайте, это некий инструмент, а не готовый к использованию продукт, хотя могу ошибаться, т.к. не имел опыта работы с ней.
Да, пожалуй. Хотя в данный момент это не первоочередная задача.
Не совсем понял идею. Чем их заинтересовать?
Вот здесь тоже делают стеганографию со сжатием именно в JPEG.
Делать это в BMP или PNG — детская забава!