Комментарии 50
— Оно никогда не бывает выше 96% и меньше 75% даже при абсолютно разных изображениях.
Так нормируйте на 0..100%.

Вообще, круто. Одновременно бесполезно и безбашенно. Наворотили лишнего, но итог заслуживает уважения.

— При отправке изображения в браузере Chrome выяснилась одна неприятная особенность: изображение, полученное таким способом всё ещё защищено политикой CORS и получить его данные из canvas нельзя
А в других можно? oO Если да — это очень серьезная уязвимость.
А я вообще, увидев картинки, еще не читав текста, придумал аж 2 интересных проекта.
Автор, спасибо, дал пищу для размышлений.
в смысле, как нормировать?
пусть ваш процент = perc, нормированный — normPerc:
normPerc = (perc — 75) / 21 * 100
Получите разброс 0..100%
должно быть вы шутите?

goo.gl/O12dM

задача решается использованием поиска гугла по картинкам в два счёта =)
причем здесь я искал по картинке из Вашего поста, и тем не менее результат был найден, так что с конкретной фоткой вообще проблем не должно быть:)
хорош был сервис, пока такой же функционал не прикрутили к поиску гугла (позволяет искать как по URL картинки, так и по загружаемой с компа)
Иногда tineye находит то, чего google найти не может, так что всё ещё использую его как запасной вариант.
Сильно ли падает точность при маштабировании изображения?

> При одновременной загрузке изображений для обработки всех 4х результатов требовалось иногда более 10 сек

Сделайте 4 вокера каждому передайте по полной getImageData(0, 0, 25, 40) каждого снимка. Воркеры для таких целей милое дело применить.
— При масштабировании точность не падает, такие же результаты и при сравнении 50x80. Точность падает, если задать делитель (в формуле) константой.

-Мне кажется такая задержка появляется именно из-за одновременной загрузки 4х изображений. А обработать массив из 4000 значений дело не хитрое.
Тогда надо замерить где тормоза, мб у кинопоиска на такие картинки большие таймауты стоят. А если кэшем обвесить, индекс какой-нибудь сделать?
По моим субъективным наблюдениям скорость последовательной загрузки даже из кэша выше, чем при одновременной. Причём это и в опере, и в хроме.
Опоздал на 1 день. У них по понедельникам сброс рейтинга.
Причём второй участник, возможно, пользовался предыдущей версией скрипта.
у меня что-то текущая не завелась, знаки вопроса везде, хром 22+тамперманки, обновлял страницу.
Я в исходном коде специально закомментировал строчку, которая так делает.
Вы не одиноки :) Делал то же самое пару лет назад (только не в браузере, а отдельной программой). Поисковых подсказок не было, поэтому выполнял обычный поиск и брал первый результат. Пару недель повисел на первом месте. Да и весь интерес был не в рейтинге, а в разработке :)
Да и весь интерес был не в рейтинге, а в разработке :)

Вот это да. Самое интересное — процесс.

Один мой товарищ писал раньше это на автохоткее. Брал самый верхний левый пиксель загаданного изображения, копировал всё изображение в буффер, из личного кэша загружал фотографии и сравнивал. Причём фотки хранились поимённо. Собственно после этого мне и захотелось усовершенствований.
Это имя в книге. Вы, наверное, хотели сказать Зоуи Дешанель.
Я понятия не имею) Я это просто взял у Ализара из статьи. Без этого получаются нереальные данные — порядка 2000%. На stackoverflow что-то находил по этому поводу, но ссыль потерялась.
Если я правильно понял код из другой статьи, там 255 в квадрате, умноженное на три. Откуда вы взяли второй параметр у Math.sqrt, не могу понять.
Ну и да, магическое число остается неясным. Если вдруг вспомните, в какую сторону копать, обновите, пожалуйста, пост.
Кажется я понял что это за число. Это Delta E максимально возможного цвета — 255. Поделив на это число мы получаем степень похожести каждлого пикселя.
Как я понимаю, относительно нуля. Т.е. квадатный корень из суммы трех 2552. Спасибо, теперь стало ясно.
В js Math.sqrt принимает только 1 аргумент. Потому Math.sqrt(Math.pow(255, 2), 3) всегда равно 255 :-S
Вот я лохонулся.
А зачем там второй аргумент 3? да и вообще смысла в этом выражении нет.
о том я и вел речь :) Было непонятно как деление, так и не имеющее по сути смысла вычисление в знаменателе дроби.
Магическое число есть ни что иное как максимальная разница цвета (maximum color difference).
Если представить что цвета — куб — классический RGB, то максимальная разница цветов будет диагональю. Диагональ в классическом виде d = a√3. Данная формула почему-то записана как √(a² * 3).
Признаюсь, никогда бы не подумал, что RGB — это куб :) Почему именно он?
А чтоже ещё? RGB = 3 измерения, значит куб. Еслиб цвет состоял из четыртех компонентов, то тогда был бы тессеракт.
кроссдоменно следовало бы грузить через GM_xmlhttpRequest, либо во фрейме, но с помощью img=new Image(); img.src
Может не так:
changed_pixels+=Math.sqrt(
Math.pow( first_pixel_array[ i ] — second_pixel_array[ i ], 2) +
Math.pow( first_pixel_array[i+1] — second_pixel_array[i+1], 2) +
Math.pow( first_pixel_array[i+2] — second_pixel_array[i+2], 2)
) / 255*Math.sqrt(3);
А так:
changed_pixels+=Math.sqrt(
Math.pow( first_pixel_array[ i ] — second_pixel_array[ i ], 2) +
Math.pow( first_pixel_array[i+1] — second_pixel_array[i+1], 2) +
Math.pow( first_pixel_array[i+2] — second_pixel_array[i+2], 2)
) / (255*Math.sqrt(3));
Точно, правда ваша. Но проверить что бы то ни было не представляется возможности. Варианты ответов генерятся теперь как изображения. Все читают хабр)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.