Подсчет объектов на картинке на C

Было бы неплохо на Python переписать и Haskell.

Уважаемый автор, а можно ли в последней версии вашей программы грабить корованы?

а длину предметов по картинке оно не определяет?

2anonymous (*) (01.07.2008 20:17:32):

> Уважаемый автор, а можно ли в последней версии вашей программы > грабить корованы?

Это Unix way, батенька. Программа занимается подсчётом караванов. Для грабления пишите грабилку.

> Уважаемый автор, а можно ли в последней версии вашей программы грабить корованы?

не можно, а нужно, собственно фотаем корован, высчитываем число коров и оцениваем, подвергается ли ограблению своими силами.

Предложенный автором подход хоть и работает, но является затратным по ресурсам, т.к. использует рекурсию. Менее затратный по ресурсам и более простой по реализации алгоритм выглядит так: for (int j = 1; j < height-1; j++) for (int i = 1; i < width-1; i++) { /* По вертикали */ if ((img[j*width+i] = WHITE) && (img[(j+1)*width+i] = BLACK)) img[j*width+i] = BORDER;

if ((img[j*width+i] = BLACK) && (img[(j+1)*width+i] = WHITE)) img[j*width+i] = BORDER;

/* По горизонтали */ ... }

Этот алгоритм выделяет четырхсвязные границы. Чтобы выделять 8-мисвязные границы нужно в цикл добавить еще пару условий.

Не понимаю откуда весь шум? Когда то были лабораторные работы по распознаванию образов - там такие задачи успешно решались: определить угол между объектами, найти контур, найти скелет объекта, устранить шумы.

Существует большое количество алгоритмов, позволяющих это делать. Единственное - проблема в реализации, готовых библиотек этих алгоритмов под Си или Джаву или что еще вроже нет. Но кому надо - так в помощь МатЛаб, там оно все чудесно реализовано и работает.

Матлаб под Линукс вроде есть. Все равно ты делаешь реализацию для одного алгоритма - а все реализовать врядли осилишь, так что как говориться: много велосипедов, хороших и разных...

Респект, применить пока не где но почитать исходники стоит.

И это на главной? Куда катится ЛОР?

>И это на главной? Куда катится ЛОР?

Вот вот а я о чем и говорю. Ну два года назад я на Яве сделал реализацию алгоритма, находящего скелет объекта - и что мне надо это было запостить на ЛОР?

Уже куча реализаций есть, гораздо быстрее работающих, качественных и с открытой лицензий. В общем, автор - начинающий велосипедист ;-)

Вильфред, осиль Матлаб, там все уже давно реализовано (оптимально, как надо).

зря ехидничаете, с этим можно решить громадную кучу прикладных задач. я не претендую, да и потом, проспорил вместе с troorl на победу наших над голландцами.

да и потом, оно у тебя только скелет определяет, а это пусть и коряво, но может даже электрофорез детектить (при наличии воображения)... пожалуйста, улучшайте под конкретику - я не против.

И потом оное можно вставить в код какогоннить motion или liblavrec.c и оно будет в реалтайме все делать. я либ в свое время не нашел свободных и потому пришлось самому.

Алгоритмы уже существуют, это да. Но вот хер они оптимальные, а иные -- и вовсе не палят. Например, взять тот же алгоритм скелетизации Зонг-Суня, который считается классикой. Залезьте в гугль, посмотрите, сколько народу выдумывает к нему обертки, чтобы хоть как-то подправить его недостатки.

>взять тот же алгоритм скелетизации Зонг-Суня

Да этот алгорити не сильно классно работает. Вообще для подобных задач нужно применять волнообразные алгоритмы - но их реализовывать самостоятельно напряжно...

> алгоритм скелетизации Зонг-Суня

посмотрел, почитал... не, я даже об этом и не думал. задача только объект выделить. больше ничего. ну еще надо бы градиентный контур впаять както. но это длинно. почему не матлаб, умеет ли матлаб брать видеокартинку с устройства видеозахвата?

>Респект, применить пока не где но почитать исходники стоит.

Что - так туго с литературой?

спасибо, попробую. правда не факт что быстро и предметно отвечу.

>Было бы неплохо на Python переписать и Haskell.

переписать хаскель на питоне? O_o

Респект !!!

а со структурой объекта, его распознаванием - я даже соваться туда не хочу, ибо лес, полжизни потратить только на изучение. нет, тут маленькая конкретная задача, в чем-то могущая быть универсальной (семки считать =)).

Большое спасибо, как раз такая вещь нужна была.

Вилфред, а это корректно, что ты при обработке скользящим средним всегда, кроме самой первой точки, захватываешь уже усредненные значения пикселов?

нет конечно, там должны быть разные массивы, один исходный, для которого считается скользящее среднее, а другой конечный, в который пишется посчитаное значение. Если там так, как пишиешь ты - то это попросту неправильно.

Это не совсем там, а там, где про самолёт: http://genphys.phys.msu.ru/~dmitriyk/site/mv/contur/aircrafrs.html

значит там неправильно, я тогда чумной был, писал все подряд. но все равно кто будет разбираться в том коде, не так просто там на самом деле-то.

> Хеширование полностью взято из учебника А. Богатырева (Огромное >спасибо Die-Hard за эту ссылку)

Гы! 
Я ж предупреждал, помнится, что нельзя некритично 
воспринимать Богатыревский шедевр, там корка на корке!!

Ты передрал из книжки код, написанный для 16-битной системы.
Цифра 15 в следующем куске:
  while(*key){
    i = (i << 1)|(i >> 15); /* ROL */
    i ^= *key++;
  }
долюна быть "разрядность - 1".

если вы в своей жизни не написали к примеру ни одного 3д-шного движка или программы подсчета предметов типа этого - тогда это для вас

можно попробовать добавить расчёт фрактальной размерности, тогда можно будет разные объекты выделять. у кучи точек и кучи кругов разная фрактальная размерность...

если на картинке мало объектов, то можно сначал разбить её на большие блоки и оставить блоки, где хоть один пиксел чёрный, остальные считать пустыми

это так в порядка общего бреда ;))

>Вышеописанный код на этой странице распространяется по условиям Public License

Уточни, GNU General ли Public License, а то непонятно.

И что будет фрактальной размерностью?

Мужики, а нет ли проги подсчитывающий кол-во пикселей на картинке ?

>Исходная идея заключается в том, что каждый контур является единственным, даже если их много на картинке.

К сожалению, эта идея не работает в тех задачах, где исходные объекты являются многосвязными ("кляксы" с дырками вкутри) или если несколько пятен соприкасаются в нескольких граничных точках.

>а со структурой объекта, его распознаванием - я даже соваться туда не хочу

А вот это правильная мысль, молодец! :)

> Мужики, а нет ли проги подсчитывающий кол-во пикселей на картинке ?

Ага, есть функция:

function подщот_количества_пикселов(Картинко картинко){
return картинко.width*картинко.heights;
}

с приведенным алгоритмом хэширования явно проблемы. и с 15 и с 31.
на 8192 элементах показывает распределение 0.3% при 100% заполнении. явно где-то ошибка.
и вообще я бы советовал использовать алгоритм djbx33x. очень быстрый с высокой степенью распределения:
hash = 5381;
while (*key) {
hash = (hash * 33) ^ *key++;
}

Хорошая подпрограмма для Терминатора!!

Асталависта, бейби!

> Мужики, а нет ли проги подсчитывающий кол-во пикселей на картинке ?

Ага, есть функция:

function подщот_количества_пикселов(Картинко картинко){ return картинко.width*картинко.heights; }

Это только для чб изображений, мой анонимный друг, ибо картинко еще иногда имеет больше каналов цвета, чем один.

>Это только для чб изображений, мой анонимный друг, ибо картинко еще >иногда имеет больше каналов цвета, чем один.

Это и для чб изображений не катит мой анонимный друг.

> Это только для чб изображений, мой анонимный друг, ибо картинко еще иногда имеет больше каналов цвета, чем один.

Тебе количество пикселов надо или что?

> Это и для чб изображений не катит мой анонимный друг.

Это для любых растровых изображений катит, дружище.

>И что будет фрактальной размерностью?

если я правильно помню, то это будет отношение количества квадратиков(кружков и вообще любых элементов, на которые множества бьёшь, при этом они должны изменяться в размерах, но количественный подсчёт возможен для одинаковых элементов)...

короче... покрываем место с объектом квадратиками определённой велечины 10х10 пикселей, считаем сколько их понадобилось, чтобы вместить весь объект

уменьшаем размер квадратика 9х9 и считаем снова, потом находим отношение числа квадратиков.

строится зависимость количества квадратиков для покрытия от размера. ну и для разных объектов, она(функция) будет различна.

до какого-то момента это будет прямая, а потом изменится

p.s. как-то так в общих чертах

Спасибо, это интересно. Если это работает, то в принципе по полученной гистограмме можно поисковые индексы строить. А если для гистограмм брать размер квадратиков в процентах от размера изображения, то можно индексировать и масштабированные копии одного и того же изображения.

> Уже куча реализаций есть, гораздо быстрее работающих, качественных и с открытой лицензий. В общем, автор - начинающий велосипедист ;-)

ссылки в студию

Так одним пьяным русским был заложен базис программы "Скайнет" и планета Земля неотвратимо почесала к собственному капцу.

>то можно индексировать и масштабированные копии одного и того же изображения.

как-то так фрактальное сжатие и работает, алгоритм запатентован и используется в HDTV что ли... гугл должен помочь

>Это только для чб изображений, мой анонимный друг, ибо картинко еще иногда имеет больше каналов цвета, чем один.

Количество пикселов от количества цветов не зависит.

> с приведенным алгоритмом хэширования явно проблемы. и с 15 и с 31.

А система, случаем, не 64битная? ;)

В данном случае производительность будет разниться пренебрежимо. Просто этот пришедший из ДОСа шедевр (<<15) повеселил...

Вдогонку -- кстати, откуда такая интересная запись Бернстейновского алгоритма? Я не сразу поверил, что

while (*key) {
hash = (hash * 33) ^ *key++;
}

и

while (*key) {
hash += (hash << 5);
hash ^= *key++;
}

одно и то же...

>Если это работает, то в принципе по полученной гистограмме можно поисковые индексы строить.

если не хватит, то можно найти центр фигуры(например: путём усреднения координат всех её пикселей) и строить функцию плотности заполнения фигуры от радиуса. Т.е. в простейшем случае считать, сколько пикселей попало в круг с определённым радиусом, увеличить радиус и снова посчитать число пикселей...
этого должно хватить для распознавания букв разного размера...

мер можно ещё придумать и добавить.

p.s. надо будет попробовать ;)

>>> Мужики, а нет ли проги подсчитывающий кол-во пикселей на картинке ?

>>Ага, есть функция:

>>function подщот_количества_пикселов(Картинко картинко){ return картинко.width*картинко.heights; }

>Это только для чб изображений, мой анонимный друг, ибо картинко еще иногда имеет больше каналов цвета, чем один.

Ананимус, бросай курить цветные пиксели.