Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
А какие результаты выдаются для одинаковых изображений разной контрастности?
А почему бы не вынести примеры прямо в топик? Нагляднее было бы, если их рядом поместить
Грубовато, но я думаю найти применение можно. Только тут, мне кажется, нужно очень четко представлять какими методами должна уменьшаться картинка.
Согласитесь, что выкидывание 9 из 10 рядов для уменьшения или взятие среднего арифметического(в простейшем случае) для 10 рядов для уменьшения в 10 раз будут совершенно по разному влиять на результат. В первом случае пиксель будет нести информацию только о себе и получается тестовая выборка очень маленького размера. Во втором пиксель будет нести информацию обо всех уничтоженных. А способов уменьшения можно много придумать.
Согласитесь, что выкидывание 9 из 10 рядов для уменьшения или взятие среднего арифметического(в простейшем случае) для 10 рядов для уменьшения в 10 раз будут совершенно по разному влиять на результат. В первом случае пиксель будет нести информацию только о себе и получается тестовая выборка очень маленького размера. Во втором пиксель будет нести информацию обо всех уничтоженных. А способов уменьшения можно много придумать.
Отправляйте в Google inc.)
Текст особо не мешает
А вы попробуйте его перенести вниз(на полосу шириной 1/8) и чтоб он от этой полосы отъедал ~60%. Что-то мне подсказывает, что мешать он будет сильно.
«чтобы он кушал изображения, у которых сильно различается, например, яркость „
Ваш пример с собакой не годится так как в нём появилось больше светлых зон, но и в то же время тёмных. Яркость избражение в среднем — осталась таже. Контраст там изменён а яркость нет.
Как на счёт примера одинаковых изображений одно из которых сильно просветлено или затемено.
Ваш пример с собакой не годится так как в нём появилось больше светлых зон, но и в то же время тёмных. Яркость избражение в среднем — осталась таже. Контраст там изменён а яркость нет.
Как на счёт примера одинаковых изображений одно из которых сильно просветлено или затемено.
Замечание по коду. Это не очень красиво и чрезмерно запутанно выглядит:
for ($i = 0; $i < $count; $i++)
{
for ($k = $i + 1; $k < $count; $k++)
{
//echo "\r\n
" .
$this->Images[$k][1][$i] =
$this->Images[$i][1][$k] = $this->_getDiff($i, $k);
}
}
А как еще можно пройтись по элементам выше главной диагонали?
Мои замечания касаются удобночитаемости кода и рефаторинга. Поэтому немного оффтоп.
Дело субъективное. Я руководсовался книгой Макконелла делая следующие замечания.
применять в многомерных массивах для обозанчения коэффициетов переменных $i $j $k — которые не несут смысловой нагрузки на мой взгляд ухудшает читаемость кода и легко запутаться что есть $i и что есть $k,
в инициализации цикла встречается $k = $i + 1; — о смысле единицы тут можно догодаться, а вот тут Images[$i][1][$k] — чтоб догадаться что это за единица сразу можно и не разобрать.
кусок кода
Возможно следует выделить в метод с красивым понятным названием чтоб было понятно что тут происходит.
Дело субъективное. Я руководсовался книгой Макконелла делая следующие замечания.
применять в многомерных массивах для обозанчения коэффициетов переменных $i $j $k — которые не несут смысловой нагрузки на мой взгляд ухудшает читаемость кода и легко запутаться что есть $i и что есть $k,
в инициализации цикла встречается $k = $i + 1; — о смысле единицы тут можно догодаться, а вот тут Images[$i][1][$k] — чтоб догадаться что это за единица сразу можно и не разобрать.
кусок кода
$this->Images[$k][1][$i] =
$this->Images[$i][1][$k] = $this->_getDiff($i, $k); Возможно следует выделить в метод с красивым понятным названием чтоб было понятно что тут происходит.
Думаю да, надо было вместо единицы использовать ассоциативный ключ.
>применять в многомерных массивах для обозанчения коэффициетов переменных $i $j $k
<offtop>Ненавижу называть переменные $j, т.к. постоянно путаю с $i</offtop>
Но вот как придать смысл этим переменным, если это просто счетчики и смысла в нет, я не знаю
>применять в многомерных массивах для обозанчения коэффициетов переменных $i $j $k
<offtop>Ненавижу называть переменные $j, т.к. постоянно путаю с $i</offtop>
Но вот как придать смысл этим переменным, если это просто счетчики и смысла в нет, я не знаю
Код уникален тем, что практически не одна из переменных не названа удобоварима и без анализа кода не понятно ее значение.
Например, если мне нужно понять что такое $count, я должен найти в начале строчку:
$count = count($this->Images);
А можно было бы по другому: $images_count = count($this->Images);
За $i, $j, и $k нужно, увы, рвать яйца даже не кодерам, а авторам большинства учебников, которые в свою очередь свистнули эти индексы из математики, которой глубоко посрать на какие то конкретные привязки переменных.
Вот у меня на экране код метода:
Кто ни будь, не роясь в остальном коде, может сказать, что такое $i, что такое $k, чему соответствует $this->Images[$k][1][$i], и количеством чего является $count?
Просто счетчики — редкость, если мы не создаем библиотеку различных математических функций. Тогда мы действительно не знаем, что мы считаем. В остальных случаях всегда можно назвать счетчик исходя из того, что мы считаем, строки это, столбцы, сегменты, изображения в массиве или еще что. Если мы не можем назвать счетчик, скорее всего мы сами плохо понимаем что он делает, либо перестанем понимать как только переключимся на другой кусок кода.
Сорри, за все это занудство, просто, пардон, все эти «глупые мелочи», как раз то, что превращает работу программиста (и его колег) из интеллектуальной поэзии в ад, и наоборот.
Про общие вещи — описание алгоритма содержит чуть ли не больше информации как он закодирован в итоге, нежели о том, как это работает, откуда взялись подобные коэффициенты и размерности, почему именно 9 (породив тем самым кучу дорогих операций с плавающей точкой), а не 8 или тогда уж 42. Почему именно 63, а не 64? Многое из этого не понять ни с первого ни со второго захода.
Зачем уменьшать именно до 8х8, а при 4х4 сильно хуже сравнивает, а при 16х16 сильно медленнее? А если делать шашечками через один сегмент? А насколько при этом точнее? А может хватило бы 4-х цветов?
Когда люди тестируют алгоритмы, они в первую очередь после их создания пытаются ответить именно на эти вопросы, что отражено в любой публикации на схожие темы. Иначе просто непонятно, имеет ли их разработка право на жизнь, это прорыв (допустим в быстрых алгоритмах сопоставления) или наоборот, тормоз-франкельштейн? Без апробации и тестирования это просто неизвестно. И она составляет вторую половину работы — создать методику тестирования или применить чужую, набрать тестовый материал, или разные группы для него.
Писать алгоритм на PHP тоже не учень удобно, единственное оправдание — язык хорошо знаком. А так есть Matlab с целым ворохом инструментов для подобной работы, есть языки для быстрого прототипирования, где получится в три раза меньше строк и можно сосредоточиться на непосредственно логике.
Например, если мне нужно понять что такое $count, я должен найти в начале строчку:
$count = count($this->Images);
А можно было бы по другому: $images_count = count($this->Images);
За $i, $j, и $k нужно, увы, рвать яйца даже не кодерам, а авторам большинства учебников, которые в свою очередь свистнули эти индексы из математики, которой глубоко посрать на какие то конкретные привязки переменных.
Вот у меня на экране код метода:
for ($i = 0; $i < $count; $i++)
{
for ($k = $i + 1; $k < $count; $k++)
{
//echo "\r\n
" .
$this->Images[$k][1][$i] =
$this->Images[$i][1][$k] = $this->_getDiff($i, $k);
}
}
Кто ни будь, не роясь в остальном коде, может сказать, что такое $i, что такое $k, чему соответствует $this->Images[$k][1][$i], и количеством чего является $count?
Просто счетчики — редкость, если мы не создаем библиотеку различных математических функций. Тогда мы действительно не знаем, что мы считаем. В остальных случаях всегда можно назвать счетчик исходя из того, что мы считаем, строки это, столбцы, сегменты, изображения в массиве или еще что. Если мы не можем назвать счетчик, скорее всего мы сами плохо понимаем что он делает, либо перестанем понимать как только переключимся на другой кусок кода.
Сорри, за все это занудство, просто, пардон, все эти «глупые мелочи», как раз то, что превращает работу программиста (и его колег) из интеллектуальной поэзии в ад, и наоборот.
Про общие вещи — описание алгоритма содержит чуть ли не больше информации как он закодирован в итоге, нежели о том, как это работает, откуда взялись подобные коэффициенты и размерности, почему именно 9 (породив тем самым кучу дорогих операций с плавающей точкой), а не 8 или тогда уж 42. Почему именно 63, а не 64? Многое из этого не понять ни с первого ни со второго захода.
Зачем уменьшать именно до 8х8, а при 4х4 сильно хуже сравнивает, а при 16х16 сильно медленнее? А если делать шашечками через один сегмент? А насколько при этом точнее? А может хватило бы 4-х цветов?
Когда люди тестируют алгоритмы, они в первую очередь после их создания пытаются ответить именно на эти вопросы, что отражено в любой публикации на схожие темы. Иначе просто непонятно, имеет ли их разработка право на жизнь, это прорыв (допустим в быстрых алгоритмах сопоставления) или наоборот, тормоз-франкельштейн? Без апробации и тестирования это просто неизвестно. И она составляет вторую половину работы — создать методику тестирования или применить чужую, набрать тестовый материал, или разные группы для него.
Писать алгоритм на PHP тоже не учень удобно, единственное оправдание — язык хорошо знаком. А так есть Matlab с целым ворохом инструментов для подобной работы, есть языки для быстрого прототипирования, где получится в три раза меньше строк и можно сосредоточиться на непосредственно логике.
после феерического
остальное не читал
неужто так сложно реализовать один из более годных методов?
Image Quality Assessment: From Error Visibility to Structural Similarity
и вообще погуглить на тему, включив мозг
for ($i = 0; $i < 63; $i++)
{
$Diff += abs($this->Images[$Img1][0][$i][0] - $this->Images[$Img2][0][$i][0]);
$Diff += abs($this->Images[$Img1][0][$i][1] - $this->Images[$Img2][0][$i][1]);
$Diff += abs($this->Images[$Img1][0][$i][2] - $this->Images[$Img2][0][$i][2]);
}остальное не читал
неужто так сложно реализовать один из более годных методов?
Image Quality Assessment: From Error Visibility to Structural Similarity
и вообще погуглить на тему, включив мозг
рад за тебя
Вообще обзор по методикам создания fingerprint-ов изображений был бы полезен.
То, что предлагает автор достаточно известная штука с известными недостатками. Куда интереснее методики поиска частичных совпадений в вейвлет представлениях или анализирующие пропорции расстояний между различными артефактами на изображениях (крайне упрощенно — находим 10 углов или прочих характерных перепадов градиента, записываем расстояния между центрами зон присутствия таких артефактов, потом сравниваем по такому отпечатку), особенно часто такие штуки встречаются в системах распознавания лиц.
Более конкретные методики уже касаются непосредственно детекторов этих уникальных особенностей изображений, например «потомки» Viola-jones много где используются.
Пока самое чахлое из направлений в прикладном плане — это нейросетки, но оно же и самое перспективное, так как потенциально обещает резкий переход количества в качество по мере роста аппаратных мощностей.
То, что предлагает автор достаточно известная штука с известными недостатками. Куда интереснее методики поиска частичных совпадений в вейвлет представлениях или анализирующие пропорции расстояний между различными артефактами на изображениях (крайне упрощенно — находим 10 углов или прочих характерных перепадов градиента, записываем расстояния между центрами зон присутствия таких артефактов, потом сравниваем по такому отпечатку), особенно часто такие штуки встречаются в системах распознавания лиц.
Более конкретные методики уже касаются непосредственно детекторов этих уникальных особенностей изображений, например «потомки» Viola-jones много где используются.
Пока самое чахлое из направлений в прикладном плане — это нейросетки, но оно же и самое перспективное, так как потенциально обещает резкий переход количества в качество по мере роста аппаратных мощностей.
Fingerprint'ов с какой целью? Если сравнения 1-к-1, то они как таковые не особенно и нужны, лишь бы алгоритм мог выдать на выходе степень схожести, если с целью последующего поиска одного из множества — это уже CBIR, и там свои особенности в зависимости от метода.
Мне кажется это черезчур сложно для такой, в общем-то, несложной задачи. Если задумываться о производительности, то, наверное, всё печально совсем будет.
анализирующие пропорции расстояний между различными артефактами на изображениях
Мне кажется это черезчур сложно для такой, в общем-то, несложной задачи. Если задумываться о производительности, то, наверное, всё печально совсем будет.
Для 1:1 изложенного выше алгоритма хватит за глаза, тут уже давно узким местом стала скорость чтения изображения с диска или из памяти :)
> Мне кажется это черезчур сложно для такой, в общем-то, несложной задачи. Если задумываться о производительности, то, наверное, всё печально совсем будет.
Если говорить о готовых решениях на щщах, то подобные штуки с различными анализаторами уже лет 10 как работают с realtime видеопотоком в куче систем слежения, видеонаблюдения и т.д.
Даже нейросетки, и те подтянулись к этому пределу.
А задачи вариативного выделения и классификации объектов, они посложнее, чем сравнение изображений будут, хотя «идеальные» в плане точности алгоритмы сравнения, наверное, должны подразумевать и это.
> Мне кажется это черезчур сложно для такой, в общем-то, несложной задачи. Если задумываться о производительности, то, наверное, всё печально совсем будет.
Если говорить о готовых решениях на щщах, то подобные штуки с различными анализаторами уже лет 10 как работают с realtime видеопотоком в куче систем слежения, видеонаблюдения и т.д.
Даже нейросетки, и те подтянулись к этому пределу.
А задачи вариативного выделения и классификации объектов, они посложнее, чем сравнение изображений будут, хотя «идеальные» в плане точности алгоритмы сравнения, наверное, должны подразумевать и это.
Подскажете какие-то реально существующие системы поиска в видеоколлекции по кадру?
Вряд ли кто-то ставил перед собой такую задачу :)
ну это я порядке оффтопика уже спросил о вашем возможном личном опыте…
Если делать, то скорее всего индексация видео целиком, даже через 5 кадров — это полный ад в плане количества изображений в базе. Наверное, разумно экстрагировать отдельные планы, и потрошить по паре кадров из них на фурье-спектр и потом искать уже по совпадениям с ними, для точности можно доиндексировать подходящие планы на лету уже по более часто идущим ключевым кадрам.
В основу можно положить что-то вроде такого:
research.microsoft.com/pubs/68785/video_scene_extraction_grouping.pdf
Увы, там используется корреляция (алгоритм строится на предположении, что между двумя кадрами большое количество пикселей не будет резко изменять свою яркость), и конвертация цветового пространства, получится дорого в плане вычислений, быстрее чем скорость проигрывания самого видео, но ощутимо. В тех же системах видеослежения и включения регистратора при движущихся объектах триггер включения часто так же устроен, просто меряет диффы между несколькими последними кадрами.
Но можно придумать и что-то попроще, методика описанная топикстартером с сегментацией вполне подойдет.
Ау, MS, я хочу такую хрень в локальном поиске! :)
В основу можно положить что-то вроде такого:
research.microsoft.com/pubs/68785/video_scene_extraction_grouping.pdf
Увы, там используется корреляция (алгоритм строится на предположении, что между двумя кадрами большое количество пикселей не будет резко изменять свою яркость), и конвертация цветового пространства, получится дорого в плане вычислений, быстрее чем скорость проигрывания самого видео, но ощутимо. В тех же системах видеослежения и включения регистратора при движущихся объектах триггер включения часто так же устроен, просто меряет диффы между несколькими последними кадрами.
Но можно придумать и что-то попроще, методика описанная топикстартером с сегментацией вполне подойдет.
Ау, MS, я хочу такую хрень в локальном поиске! :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Еще одна версия алгоритма сравнения изображений