Изпечатай

[neter]

/извън темата

gat3way, на заигравката ти с това много ѝ пасва да бъде разказана на някоя конфереция. Помисли за това, ако вече не си го направил. OpenFest ми се вижда най-подходящото място за случая, но няма лошо да се появи и на други места, било то като повторение или разказване на новите постижения

[go_fire]

5.

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

[gat3way]

Не е готово още, но имам напредък. Първо - намерих как да траквам обектите - по идиотски начин, но е относително коректно - за всеки контур намирам геометричния център и при новата итерация го търся в някакви тесни рамки. Понеже може да имаме малки контури, които и без това са ни проблем - имам една проверка за минимална площ на контура, през която "малките" контури не минават. Това повиши с порядъци точността.

Но все още не е достатъчно. В зависимост от осветлението, някои обекти от кадъра "минават" през двата RGB филтъра. За да отсявам "дим" от случаен обект, наблюдавам няколко неща - първо във всеки кадър, площта на контура трябва да е различна (димът променя бързо площта си), геометрията (броят на точките, формиращи контура) също се променя, но в някакви граници, но ориентацията (това е нещо като ъгъла между ординатната ос и оста на най-малката елипса, в която може да се впише обекта) остава почти константна. Следя тези промени на тези параметри за бройка кадри и за който обект те са факт за тази бройка поредни кадри, го обявяваме за пушек.

Това работи много добре в смисъл почти не дава false негативи, но все още дава false позитиви понякога, на слабо осветление особено. Затова търся още неща, чисто геометрични, които дефинират поведението на "пушека".  Снощи ми дойде една идея, ама беше късно да я реализирам и много ми се спеше вече, днес ще я помъча. Що се отнася до момента с местенето на камерата, засега решението е да игнорирам всички сметки и да discard-на всички досегашни статистики ако промените в кадъра са прекалено големи (площта на всички контури е над определен процент от броя на пикселите в кадъра). Но това не работи перфектно, има още какво да се желае. Видеа снимани с камера, която трепери например, не дава толкова големи отклонения....но пък дава достатъчно за да ни съсипе сметките и пушеци да започнат да се откриват в разни улици (асфалтът доволно добре минава през RGB филтрите).

Едно е сигурно - не е лесно да се правят предположения за движението на обектите "пушек", които наблюдаваме. Пробвах да използвам предположения от сорта на "щом е пушек, значи би трябвало да се издига нагоре", това е голяма грешка и не работи добре както се оказва. Търсех и определена точка, да я наречем "източник на горене" спрямо която всички открити обекти би трябвало да се отдалечават в последвалите кадри - друга голяма грешка. На точно такова поведение не може да се разчита, особено ако става въпрос за огън на открито където духа вятър или за огън на закрито, където дима бързо стига до тавана и почва да се движи надолу.

[4096bits]

Трептенето на камерата, когато например се държи от ръка и се снима, обикновено се случва бързо. Отклоненията обикновено се случват доста по-бързо отколкото, ако движението на камерата целенасочено в някаква посока, за да хване друг кадър например. Това не може ли да елиминира до някаква степен споменатия проблем

[gat3way]

Абе...не винаги е толкова бързо, за съжаление. Примерно при 25 кадъра в секунда, като държиш внимателно камерата в ръка, дори при най-доброто старание, тя не остава статична, а се движи малко или много. Като при това, движението може да се случва спокойно в рамките на едно поне десетина кадъра и за жалост и не е толкова радикално, за да има огромни промени между два кадъра. Парадоксално, големите промени в положението на камерата, които се случват бързо са по-малък проблем, отколкото тези малките и не толкова бързите. Засега имам две решения на този проблем - освен изхвърлянето на досегашните статистики при достатъчно радикални промени, другият вариант е да увелича броя кадри, за които събирам статистики - така случайни промени дължащи се на движение на камерата, които се вписват в критериите, просто не са достатъчно дълготрайни за да дадат false positives. Обаче и двата подхода са емпирични, нагодени към ситуацията, с ръчно набити параметри, които не работят универсално добре. Лошото е че не мога да измисля нещо по-добро засега, по някое време сигурно ще трябва да видя какви решения има на този проблем де, със сигурност някой трябва да го е измислил вече.

[4096bits]

Обикновено, когато човек снима или камерата е насочена към обект, той е приблизително в центъра. Доколкото зная при фотоапаратите има едно софтуерно стабилизиране на кадъра. Няколко пиксела се взимат от страните, които не са... част от снимката и при отклонение ... не мога да го обясня. Може би нямам нужните знания или термини в главата си, но ето тук има едно видео, което илюзтрира, за какво говоря. Отнася се май за някакъв постпроцесинг, но идеята е ясна.
http://tldrify.com/8e4
Ако картината се стабилизира, тези проблеми би трябвало да се отсранят. Трептене и прочее.

[Oxy]

Не мога да го чета цялото и хвърлих поглед, че утре ми е изпита топология и геометрия :Д Имам въпрос: Какво става ако някой остави примерно газовия котлон пуснат –? Нали няма дим.. предполагам има някакви други случаи за горене без дим? Относно ИЧ камера : Много занимавка е докато се постигне нещо, пък и се оказа че камери с висока резолюция над 800х600 май са регулирани и примерно ги ползват военните по някакви хеликоптери.. проблема с ел крушка обаче остава.. затова фюжън и елиминиране на познати обекти като крушка които излъчват на трешхолда. Иначе винаги има вероятност сисмета да даде фалс негатив... в случай на пожар май фалс позитив на мен ми изглежда по-добре в критични апликации :–) Утре ще пиша повече като мине изпита и съм жив

[gat3way]

Ами очаква се че газовия котлон ще подпали нещо, което ще пуши, преди бутилката да гръмне Ако не - лошо

Сериозно иначе не знам, аз съм по-скоро склонен да се съглася че е по-добре да се търси за пушек в изображението - пламъците докато станат достатъчно "представителни" за да можем да отсечем че сме открили такива, нещата наистина вече са на зле. Отделно ако помещението е малко и затворено, сигурно ще се напълни с пушек преди да може камерата ясно да отчете въпросните пламъци.

Иначе днес реализирах идеята, почти де. Новата ми идея беше да използвам не геометрични характеристики, а това че димът "замазва" картината, с други думи, визуално, нещата изглеждат "blur-нати" през дима. Което чисто математически реших да реализирам с хистограми, но понеже тази част от OpenCV не съм я изучил още, засега се задоволявам с примитивни изпълнения. Цялата забава около python-ското програмиране с opencv е че трябва да намериш подходяща opencv функция за това което искаш да правиш - иначе numpy е хубава библиотека за матрични операции, ама е толкова отвратително бавна....понякога ми се иска да отеба и да си пренапиша нещото на C, но засега се въздържам. Та за готови функции е лесно, за такива където трябва да бърникаш сам из матриците и да си правиш сметки - може, но производителността се срива ужасно.

Та идеята с хистограмите (които представляват просто таблица с колко пъти се срещна всяка стойност на пиксела в изображението) е че на база на тях мога относително лесно да открия между две изображения кое е по-размазаното и кое е по-"острото". Разбира се, бих могъл ако си правех сам сметките, което както казах е много бавно. Та засега съм се задоволил да смятам само разликата между максималните стойности в хистограмите, което е много лоша и неточна работа - спокойно по чудо не-размазаната картинка от която очакваме да има по-висока "ентропия" може да се окаже че има някой цвят който е силно изявен и бие максималната стойност на "размазаната" такава - това става като гледам като имаме разни отблясъци или наситен черен цвят. Правилния начин да сравняваме хистограмите включва разни кофти операции върху двете матрици, които ако правя на ръка с numpy, горката машина грохва и почва да обработва по 2-3 кадъра в секунда, което е лошо.

Но като цяло съм на прав път, дори намалих "тежестта на геометричните критерии за сметка на недъгавите хистограмни сравнения. Когато открия начин да се оправям като хората с хистограмите, ще имам истински голям напредък най-накрая, надявам се.

Та засега е това:

https://www.youtube.com/watch?v=HPG69p_BX2k

Забравих да кажа, промених и RGB филтрирането и на видеото си личи как не съм подбрал все още оптималните параметри. Идеята ми с филтрирането сега е да ползвам един RGB филтър за ниво на "сивото" и два grayscale филтъра за "черен" пушек и "бял" пушек. Горе-долу крайното филтриране е така:

filter = gray_rgb_filter(image) & ( white_grayscale_filter(image) | black_grayscale_filter(image) )

gray_rgb_filter просто хваща за всеки пиксел максималната разлика между max(r,g,b) и min(r,g,b) и пропуска само тези, за които разликата е под определено ниво.

Другите два филтъра оперират върху grayscale версия на кадъра и търсят тъмни и светли разлики. Крайният резултат е грубо казано "нещо относително сиво, което е или определено тъмно или определено светло".


Та филтрите не съм ги настроил добре, което се вижда на видеото. Понякога пушек се открива върху други обекти, например яркото небе (понеже "светлият" филтър му е даден прекалено висок максимум) или тъмнозеления металик на колата (понеже сивия филтър е в по-широки граници, отколкото трябва). С филтрирането специално, нещата са чекиджииска история и нагаждане, на базата на предишни изображения, като цяло изкуствено зададен модел.


False позитиви почти не дава вече на камерата в къщи...рядките изключения са при нощно осветление ако много бавно се приближава към камерата тъмен обект, последното е благодарение на калпавите ми филтри, но като ги подобря ще го отняма вече предполагам. Но за сметка на това, имаме кофти false негативи, които са и до голяма степен благодарение на некачествените проверки с хистограмите. Само да разбера как се прави като хората, най-вероятно ще си имам относително надежден детектор на пушеци от камери. Може би най-накрая в уравнението ще трябва да се вкара цветовия баланс, за да коригирам филтрите, по някакъв начин, понеже нощно време е едно, дневно е друго и с фиксирани граници на филтрите не е добра идея, ще трябват малко сметки....ма и до там ще стигнем.

П.П сега се сетих че днес гледах едно видео от противопожармена алармена система, която се опитва да бъде прекалено умна - гугълска разработка. Умните неща може да са доста противни, когато са глупави: https://www.youtube.com/watch?v=BpsMkLaEiOY

[gat3way]

Айде, почти съм готов

Най-най-най-накрая имам нещо което работи доста точно. С други думи в 10 тестови видеа с пушек открива 8 и от 10. В 10 от 10 тестови видеа без пушек, не открива такъв, а някои от тях са доста криви изпитания за алгоритъма (едното е видео от камера по време на тропически ураган, визуално сипещият се дъжд на вятъра си прилича на пушек и има горе-долу същия сив цвят, какъвто се очаква от пушек).

Двата фалшиви негатива са заради кофти осветление. В единия случай, камерата е прекалено близо до огъня, който лумва бързо и нямаме бавния полупрозрачен стелещ се дим. Вторият случай е в едно хале без прозорци, на слаба изкуствена светлина и отново огънят лумва бързо, за първия случай не ми е присърце, но по втория може да се поработи за подобрения.

Якият момент с успешно откриване на дим - запис от камера на взрив в някаква рафинерия. Цистерни минават бавно по пътя, хвърлящи ярки сенки върху асфалта, по начин по който знам че ще "задейства" алгоритъма, съдейки по геометричните и цветовите критерии. Нo това не се случва. Накрая заводът гръмва брутално, има около секунда и нещо взрив в далечината докато дима заема цялия кадър и за това време го и откриваме.  Изглежда забавно


Както очаквах - сравнението на хистограмите се оказа ключа към нещата, но го направих интелигентно и бързо. Смятам ентропията на изображението (какво е ентропия в този смисъл на думата - http://en.wikipedia.org/wiki/Entropy_%28information_theory%29 ), по добре познатата формула на Клод Шанън, H(x) = -1*sum(P(x)*log(P(x)). OpenCV си има готова функция за смятане на логаритми върху елементи на матрици за което не знаех, както и за сумиране и умножение на матрици съответно. Единственото необходимо нещо е "нормализирането" на хистограмата преди да й търсим ентропията, което е просто, просто трябва да разделим елементите на матрицата със скаларна стойност, броя на пикселите (площта на контура). Така сумата от стойностите винаги е равна на 1, с други думи просто обръщаме стойностите от "брой срещания" във "вероятност тази стойност на пиксела да се срещне".

Очаквано, замъгленото от дима изображение (по-скоро контура наложен върху изображението) има по-ниска ентропия от контура наложен върху фона. Оттам всичко е доста елементарно. Повечето геометрични критерии просто ги изхвърлих, изключай само площа и вмъкнах един нов параметър - координатите на rounding rectangle-а, с други думи "рамката" около контура - нещо, което не знам как opencv го смята, но го смята бързо.

Допълнително използвах момента, че при blob-овете с пушека, ентропията на изображението се променя бавно. Това е защото пушекът бавно се "смесва" и "избледнява", което прави фона по-ярък и изчистен постепенно с времето (това е момента в който пушекът избледнява и става все по-"прозрачен").

Целият алгоритъм има нужда от още малко прецизиране, защото все още има няколко входни параметъра - константи, част от които бих заменил по възможност с правилните съотношения, но последните ми убягват.

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

А, забавен страничен ефект от цялата работа с намесата на сравняването на ентропии на изображения - клатенето на камерата не ме касае силно вече. Много приятно се "изчиства" от проверките за ентропията плюс двете геометрични такива. Видеото с най-лошото клатене, на някакъв пич дето снима взрив на бензиностанция и ръцете му треперят доволно, заляга под прозореца и подобни глупости, не дават нито един false positive при клатенето, но улавят пушека от взрива. Лошото обаче е че клатенето на камерата осира и откриването на позитивите, в смисъл съсипва статистиките и пушекът се открива в кратките моменти, в които пичът не клати камерата много.

Абе като цяло е възможно. Имам още да го прецизирам, но съм ужасно доволен от резултата. Ако успея да изчистя и малкото останали проблеми, ще съм много доволен. Обаче проблемът с неоткриването на обектите при слабо изкуствено осветление май нямат решение по този метод поне.

[4096bits]

Като се наиграеш, ще ти дам една задачка, да кажеш дали е възможна. Свързана е с това, което правиш ти в момента 

[romeo_ninov]

Обикновено, когато човек снима или камерата е насочена към обект, той е приблизително в центъра. Доколкото зная при фотоапаратите има едно софтуерно стабилизиране на кадъра. Няколко пиксела се взимат от страните, които не са... част от снимката и при отклонение ... не мога да го обясня. Може би нямам нужните знания или термини в главата си, но ето тук има едно видео, което илюзтрира, за какво говоря. Отнася се май за някакъв постпроцесинг, но идеята е ясна.
http://tldrify.com/8e4
Ако картината се стабилизира, тези проблеми би трябвало да се отсранят. Трептене и прочее.

Това (с местещата се матрица) е по-редко срещано от стандартното при което едни лещи в обектива се местят (вътре в обектива има няколко жироскопа и малък компютър както и двигатели, които местят лещите). Да не говорим че някои обективи могат са стабилизират и при следване на обект (panning)

[gat3way]

Хехе, в момента още си подобрявам гадинката. Оказва се че има други моменти, има примерно огромно значение колко близо е камерата до "пожара" и дали духа вятър, който издухва пушека. Това е страничния неприятен момент, когато условията са ти свързани с проверки на ентропията/геометрията/цветовия баланс и брой кадри назад за които пазиш статистика, проверките са в определени рамки и тези рамки са много различни очевидно, когато сцената се променя по-радикално (димът го духа вятъра и камерата е близо до него например).

Оказва се че е доста лесно да направиш детектор за пожари които се случват някъде в далечината, развиват се бавно, не динамично, там дори друсането на камерата не е проблем. Нещата доста се променят ако имаш източник на пожар на метър-два от камерата и/или духа вятър и димът заема по-голямата част от кадрите и се мандахерца на случаен принип. В екстремните случаи просто нямам идеи какво бих могъл да направя, за да работи достатъчно акуратно. Там вече очевидно си плаче за по-интелигентни решения - невронни мрежи, знам ли и аз

Алгоритъма за откриване повече не мога да го подобря, но пък имам известен напредък с препроцесинга на кадрите.

P.S абе все пак има какво да се направи за откриването - има един параметър на thresholding-а на маската при откриването на "движение" между кадрите, който ако се тунингова, работи доста по-добре за близък бързо менящ се дим, но доста по-зле за далечен и бавен такъв. Обаче не мога да открия начин да го "тунинговам" автоматично, това ми е ръчен параметър и няма на база на какво да решавам какви да са стойностите. Ако измисля това ще е супер, обаче проблемът е там, че това е доста сложно решение, за да се взема автоматично, прекалено много параметри има, които няма как да ги знаем.

[gat3way]

Tweak-нах алгоритъма за последен път, някои неща ще си ги запазя като тайната на готвача хаха. Но като резултат, имам още един порядък по-точно разпознаване, главният виновник е автоматичното настройване на RGB threshold-а за откриването на "сивеещи" петна, който настройвам динамично вече. Така апропо ако имаме охранителна камера, за която осветлението се променя динамично през деня, откриването на пушек ще ни е доста по-ефективно, не е като да вярваш на предварително заложени рамки, които да работят за един случай добре, за друг не толкова

Production-ready, дори си го интегрирах в системата за домашна аларма. Обаче се оказа гадина, акуратността му не търпи пропускането на кадри и тоя номер дето го правя с лицевото разпознаване и детектора за движение дето ги "захранвам" с всеки трети кадър от камерата, тук е силно противопоказен. Резултатът: FPS-а се насира, не много, но при включен детектор за дим, крайното видео което се stream-ва вече не е толкова мазно и гладко И изяжда едно 15-20% повече процесорно време, по груби сметки, моя 6-ядрен Bulldozer ще започне да си има проблеми с дропени кадри след грубо 7-8 навързани камери на които правим smoke detection, които записват видео архив и събират видео-аларми (когато имаме alert, записваме PNG изображение и пазим видеофайл за събитието).


Това също предполага че има само един клиент, който гледа stream-а в същото време и изключва всякакви странични CPU-интензивни процеси. В противен случай, железарията ми ще започне да издъхва вероятно при далеч по-малко от 7-8 камери навързани.


Хрумнаха ми по-забавни забави, например видях има евтин вариант за IP PTZ камера. Ще е ужасно забавно да мога да управлявам камерата софтуерно и поради тази причина, мисля да си я закупя. Има доста интересни неща, които ми се въртят из главата. Например, ние можем да проследяваме движението на големи движещи се обекти (хора примерно). На базата на това, алгоритмично можем да въртим PTZ камерата, за да проследим траекторията им. Би било доста забавно, макар че ще е малко параноично като се разхождам из стаята, камерата да се врътка така че да ме държи на фокус.


P.S ама се радвам де, яко се получи:

https://www.youtube.com/watch?v=Nk29QMSkOD0&feature=youtu.be

Това е без "RGB самообучаването", последното просто няма достатъчно време за да влезе в уравнението, преизчисляването на RGB баланса става веднъж на 60 кадъра и в някакви тесни рамки, понеже идеята е CCTV камери, не случайни видеоклипове от нета, та имаме съвсем случайно видео, към което се нагаждаме по-бавно, отколкото автора на видеото променя сцената. Вижда се и как накрая даваме false негативи когато камерата zoom-ва, просто става прекалено бързо, за да може алгоритъма да реагира.

Но е забавно как добре се справя само с някакви евристични критерии и чисто статистически методи.

[gat3way]

Все повече се убеждавам, че OpenCV е велика библиотека, ужасно големи забави позволява лесно, не случайно толкова много индийци я ползват.

Това е последният ми алгоритъм за проследяване на движещи се обекти:

https://www.youtube.com/watch?v=cTbdQ9fkXSs&feature=youtu.be

...наложен върху свалено от youtube видео от различни пътни камери в София (качеството на входното видео е под всякаква критика след няколко пъти компресиране). Въпреки това успява коректно да проследява обектите в доста от ситуациите. С видеопоток директно от камера и с правилните настройки спрямо нея, това ще е с порядъци по-адекватно.

При все това работи потресаващо добре при тези условия. Сега забавното е колко лесно е да дефинираш прости правила, базирани на чисто човешко знание. Например ако алгоритъма се разшири с един Калманов филтър и ако дефинираш две линии между които разстоянието е известно, както и FPS-а с който камерата ни сервира кадри, може да се изчисли приблизителната скорост на движещ се обект. Няма да е супер точно, далеч по-неточно от доплеров радар, но е достатъчно да повдигне аларма за някой, който би трябвало да гледа камерата примерно. Може да се дефинират и прости алгоритми в зависимост от сцената, примерно за неправилно изпреварване, преминаване на червено и т.н.

Обаче най-забавния казус - катастрофите - не се покриват от този алгоритъм. Както се вижда, близките обекти "converge-ват" в един. Това е слабост, която може да се коригира или с Калманови филтри (доста глупава идея според мен, поради ред причини) или с някой алгоритъм като LK за optical flow. Опитите ми обаче доволно добре осират производителността за да не можем да го правим в реално време.

Като цяло, този алгоритъм е около 300 реда код на python. Изглежда доволно сложно, а е супер просто. Просто съм очарован. Като цяло, велики неща могат да се направят, относително лесно.

А, да, използвам MOG за изваждане на фона (с морфологичен филтър върху маската - erode и dilate) и camshift с 3D хистограми, за проследяване на обектите плюс няколко прости правила, за да отсявам невероятни сценарии. Всичко това работи добре в реално време. Поне докато някой не се сети да разклати камерата или да смени сцената брутално - тогава настъпва Армагедон.

[gat3way]

Това с проследяването на бройка обекти се оказва голяма забава.

В общи линии "простите" начини се оказват два - и двата се базират на вероятности. Първият одеве го споменах - базиран на хистограми и хистограмни backprojection-и. В общи линии проследяваме движещият се обект на базата на на това в кой регион от изображението имаме хистограмен баланс най-близък до вече сметнатия за обекта. Тъй като използваме HSV colorspace е относително достатъчно да ползваме само H и S хистограми, 3D хистограмите се оказват лоша идея заради широките вариации между кадрите. Добра илюстрация на подхода е това:

https://www.youtube.com/watch?v=zXI2wOFaQ7Q

Предимствата на този метод са че е много бърз и че осветлението не играе огромна роля - ако обектът попадне в сянка, съотношенията между bin-овете в хистограмата ще се запазят сравнително добре (в някакви рамки) CAMShift е адаптивен алгоритъм и добре се нагажда и към промяна на ориентация и размер на обекта. Недостатъците обаче са много - първият е че в сцената може да имаме друг обект, който по-добре да пасва на моделната хистограма. При което почваме да следим грешния обект. Другият огромен проблем (който винаги е проблем, но тук е ужасно голям проблем) - колизия на два обекта води до "загубване" на дирята на единия от тях. Това е понеже в точката на колидиране, хистограмите на "общия" обект са едни и същи и в двата случая почваме да клоним към "общия обект" след не много итерации. Това не е огромен проблем ако камерата ни е разположена точно над главата и нямаме "презастъпване". Но случаят обикновено не е такъв. Другият проблем е че тези изпълнения са изключително чувствителни към клатенето на камерата.  Друг проблем е че когато обектът се вижда под различен ъгъл, хистограмата му може да е съвсем различна, бруталният пример би бил с кубче което се върти и всяка страна му е с различен цвят. Ще го загубим в момента в който се извърти така че не виждаме вече страната за която сме смятали хистограмите.

Евентуални подобрения са възможни (аз си играх) - примерно през няколко кадъра да преизчисляваме хистограмата-модел, но това не е много надеждно. Решението на проблема с проследяване на грешни обекти се минимизира чрез използване на побитови маски (при които чертаем маска малко по-голяма от текущия размер на обекта и залагаме на хипотезата че обектът няма рязко да си смени позицията и размера - ако го направи, ще го изгубим). Решаването на проблема с презастъпването е ужасно сложно (чисто математически). Решенията са хакове - можем да приемем че временно губим обекта при колизия, използваме калманов филтър за да "предскажем" позицията му след колизията и ако нещата пасват, обявяваме новооткрития обект за стария изгубен такъв. Това е ужасно чекиджийска история и лично на мен не ми харесва.


Сега втория метод - т.наречения "optical flow". Тук идеята е по-различна - вместо хистограми (вероятности някои стойности на пикселите да се срещат по-често от други), ползваме т.нар "features". Такива обикновено са ръбовете на обектите, разглеждаме ги като матрици където feature-а е центъра на матрицата и съотношението между централната стойност и съседите й трябва да стоят в някакви тесни рамки. В следващите кадри търсим същите features. Тук има много подходи при селектиране на началните features и откриването им в следващите кадри. Включително гореспоменатия SIFT, който върши добра работа ако по обекта има някаква текстура, примерно фирмено лого, което да следим (и не особено добра работа иначе). Аз си харесах Harris детектора, използван от Shi-Tomasi findGoodFeaturesToTrack(). Крайният резултат от това (засега):

https://www.youtube.com/watch?v=05ALOtdvOeQ

Такава сцена е убиец за всякакви CAMShift и като цяло за всякакви ползващи хистограмни вероятности подходи. Просто ще ги задави много лошо - имаме обекти с доста варираща големина под кофти ъгъл с ужасно много презастъпване. Тук обаче optical flow / feature tracking подходите работят далеч по-добре.


Предимства: доста по-добре отреагираме на случаи в които обектът се вижда под друг ъгъл и има съвсем различен вид от въпросния ъгъл. Доста по-добре се проследяват обекти, които колидират. Доста по-трудно се бъркаме с други обекти. Доста по-толерантно на клатене на камерата. Относително бързо.

Недостатъци: алгоритъмът (Lucas-Kanade, апропо пълна изродия, изобщо не мога да схвана как нещо работи след няколко прочита) е много чувствителен на промяна на осветеността на търсения обект. Влезе ли в сянка примерно, всичко отива по дяволите. Алгоритъмът не е перфектен и чат-пат някой feature се "открива" на случайно място в кадъра. С цел да минимизирам последното, ползвам два трика: първият е "обратна проверка" - на всеки кадър проследявам feature-ите в двете посоки - от предишен към следващ и от следващ към предишен и вземам само тези features, които се откриват в двата случая. Така се отсяват огромна част от случайните false positives. Другият номер е по-забавен - използвам функцията findHomography() за да открия трансформацията в перспективата между двата кадъра и да отсея "грешните" features - с други думи намираме модел при който всичките features променят координатите си между двата кадъра като тези, които не се вписват във въпросната трансформация ги изхвърляме. Не особено добра илюстрация на това:



Всички features които не се вписват във въпросната трансформация (горе из облаците има няколко такива) ги разкарваме.


Проблемът е че след няколко кадъра след тези агресивни проверки, не ни остават features за проследяване, затова динамично търсим нови такива. Другия проблем е че дори и тези агресивни проверки не отсяват грешките на 100% (както се вижда във видеото). Третият проблем е с откриването на центъра на движещият се обект - геометричният център на всички открити features не ни върши работа (прекалено много шум и вариации - дори Калманов филтър не може да се справи с тях). Та тук използвах друг фокус добре познат от статистиката - K means clustering. Идеята е да търсим точка, където имаме "клъстерирани" възможно най-голям брой открити features и тези дето са прекалено далеч от "клъстера" ги отсвирваме за сметките за центъра. Само на тези, които пасват, търсим геометричния център. За илюстрация това:



Тук имаме цели три центъра на клъстери, но нас ни интересува случаят когато имаме един "изявен такъв". Този център ползваме за център на открития обект. Когато смятаме траекторията на движещите се обекти, минаваме на всеки кадър координатите на центъра през Калманов филтър, за да "изгладим" траекторията от излишен "шум". Това както се вижда работи добре.


Големият проблем - вече не знаем реалният размер и форма на търсения обект. Можем да гадаем де, но не  е точно. Много добре се вижда как смятаме за движещ се обект само краката или главата на човека. Това е резултата от homography филтъра - защото при движението си, главата на човека може да се движи в една посока, ръцете и краката в други, но ние вземаме предвид единствено "доминиращата" тенденция. Та нямаме красивите очертаващи рамки от Camshift алгоритъма.


Крайното решение? Вероятно някакво хибридно такова. Обаче още не мога да измисля как да стане. Двата подхода са радикално различни и е доста трудно да се обединят


Защо проследяването на обекти е забавно нещо иначе - защото има доста практични приложения в крайна сметка. Като изключим видеонаблюдението, където бихме искали да получаваме аларми когато някой обект примерно навлезе в забранена зона, доста интересни приложения има за следене на интензивност на трафика, откриване на задръствания, проследяване на потока от пазаруващи в някой мол или супермаркет, откриване на пътни нарушения или "утилизиране" на паркинги, всякакви такива неща.

А, другото забавно нещо което открих покрай тези експерименти е че мога да махам с ръце пред камерата и да го използвам като mouse pointer, хаха. Само дето кликането не знам как трябва да стане. Но е забавно донякъде, напомня ми за разни sci-fi филми дето разни хора махат с ръце и отварят местят и затварят разни джамове