Linux за българи: Форуми

Абе някой имал ли е вземане-даване с откриване на обекти с opencv?

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

Та ми хрумна великата идея да си надращя един скрипт дето ми разпознава мутрата плюс още няколко предмета и се прави на интелигентен, използвайки и някаква TTS библиотека да говори гадно. Примерно сутринта сядам на компютъра, скрипта разпознава грозната ми мутра и се опитва да ми открие и чашата за кафе. Някаква проста сметка правя ако за над 1-2% от фреймовете в рамките на първите 1-2 секунди грозната ми мутра е открита, но чашата за кафе - не, TTS-а изпява нежно "добро утро, gat3way, няма ли да си направиш кафе". Ако чашата присъства над threshold-а съответно, изпява не толкова нежното "добро утро, gat3way, пий кафето по-бързо и се оправяй че закъсняваш за работа". Някак много идилично издържано в sci-fi светлина и по груби предварителни сметки, не особено сложно.

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

Сега като гледам това се оказва доста сложна и досадна и бавна задача (пуснал съм да се търкаля и го прави от няколко часа и не вярвам да свърши в близките 1-2 дни). Би било много жалко опита да е неуспешен и след това да похабя n пъти по толкова време докато се науча как се прави като хората.

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

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

Колко входни семпли (позитиви и негативи) горе-долу са достатъчни, за да се изгради приличен модел, дето работи относително коректно (т.е примерно няма да открие че телефона ми прилича на чашата ми за кафе)?

Има ли начин генерирането да се ускори?

Колко stages като минимум са ОК при тренирането на модела? Гледам чуждите опити, движи се между 20 и 30.

Между негативите и позитивите има ли някаква релация от вида "най-добре е негатива да е същото като позитива, само че без обекта"? Или примерно позитивните картинки може да са ми обекта, негативните - каквото и да е, ако ще и гъза да си снимам?


Ако не беше толкова бавно, ресурсоемко и досадно това, щеше да е ужасно забавно. Аз виждам огромни приложения на тази технология, предимно за лоши неща (от сорта на таргетирана реклама на база какви филмчета качваш в youtube да речем - забелязва бутилка бира и те спами с Хайнекен, забелязва лаптоп и те спами с Dell и т.н.). Или пък някаква полицейска антиутопия, където в реално време илюминатите лоши узнават коя камера в града вижда колата ти. Но пък варианта с "добро утро, направи си кафе" ми е достатъчно забавен и без да е зъл и лош.

Не зная изобщо как го правят това, но зная, че са доста напред. Вече каква железария използват.... И това е под въпрос.
Иначе тук ($2) се споменават едни фрапиращи за мен проценти дето, ако са верни... Браво на хората!

Фрапиращото в случая е че всичко е въпрос на статистика и колкото по-приличен модел си изградил, толкова по-прилично ще разпознава. Няма никаква магия и никакви мистериозни изкуствени интелекти в цялата тая тарапана. Обаче остава въпросът как да изградиш модела като хората и тук някак си се опира до естествения интелект. Признавам че когато се е получило добре, резултатът е доста потресаващ, аз като много зелен в цялата работа, останах без думи на моменти. И това далеч не е върха на цялата работа, има и по-добри алгоритми, целящи същото очевидно, но аз като бос и зелен, за момента се занимавам с Haar класифицирането.

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

Най-интересното е, че преди няколко години баш във Википедия попаднах на критика на цялото нещо, не от кой да е, а баш от самият Чомски (Хомски, не е ясно как се казва). Това е същият Чомски, който направи революция в лингвистиката, но не се прочу с научните си открития, а критиката към американската политика. И въпреки, че от научното му бърборене, нищичко не схванах, поне разбрах, че и той говори за същото. Статистиката е само имитация  на ИИ  и в действителност убива идеята, а не ѝ помага.

Истината е, че ИИ или имитация няма да е възможен без квантови компютри. Те няма да са възможни без студен синтез, за да им се осигури тока. Обаче в Руанда, Авганистан, Еквадор едва ли ще е възможно изграждането и на двете. Така НСР на Буш-старши става невъзможен. НСР не може да обвхване цялата планета. И така си остава ССР (стар  СР) дето сигурно го е имало преди 5 хил. години, а дори 50 хил. години още на дървото. Най-силните управляват и определят правилата на играта. На другите е позволено да ядат банани.

Съществува възможност откриването/разпознаването на образи да става на базата на невронни мрежи, тогава нямаме строго двете стъпки с изготвянето на модела и ползването му. Просто не съм стигнал дотам още. Наскоро гледах една демонстрация на NVidia за computer vision assisted driving, където го правеха в реално време, ползвайки невронни мрежи - онова разпознаваше пътни знаци, светофари, изскачащи пешеходци на платното и тем подобни глупости с идеята някой ден автомобила да компенсира несъвършенствата на шофьора или пък наистина самопаркиращи се автомобили и тем подобни глупости. Невронните мрежи сами по себе си имат много общо със статистиката апропо, поне това ми е останало в главата по спомени от университета. Което не е кой знае какво, защото никога не ми е било особено интересно. И в момента също не ми е интересно като става въпрос.

Ами хората дето съм им дал линка са приложили там отляво един pdf и го разгледах. Има един куп формули, ако ти се занимава. Ако е въпрос на статистика, значи е въпрос на прехвърляне и обработване на голям обем данни. Пак опира до железарията. За момента. За решаването на такива нелеки задачи, вярвам, че всичко опира до добър алгоритъм.
Предполагам, че е същото, както със производителността на чиповете. Закона на Мур ли беше. Та въпросния закон засега се запазва. Преди години предричаха, че скоро - от тогава . ще се стигне до 10GH процесори. Е оказа се, че не във скоростта на работа е разковничето.
Малко съм се занимавал с програмиране и съм позабравил. Вероятно ще стане по-бързо, ако се отвхърлят повечето от вариантите. Едно хубаво структуриране. Тея с големите носове там, другите с по-малко разтояние между очите другаде. Вероятно това не е по-добрия начин. Не ми се задълбава  ???

Обмислял ли си по-прост вариант, например филтриране по цветове - https://www.youtube.com/watch?v=bSeFrPrqZ2A Не е най-удачното, защото може да се обърка с други предмети от същият цвят, но пък за една чаша би трябвало да се получи.

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

Но пък холивудските ефекти също не са ми особено интересно занимание, нещо не съм особено артистична натура.

Истината е, че ИИ или имитация няма да е възможен без квантови компютри. Те няма да са възможни без студен синтез, за да им се осигури тока. Обаче в Руанда, Авганистан, Еквадор едва ли ще е възможно изграждането и на двете. Така НСР на Буш-старши става невъзможен. НСР не може да обвхване цялата планета. И така си остава ССР (стар  СР) дето сигурно го е имало преди 5 хил. години, а дори 50 хил. години още на дървото. Най-силните управляват и определят правилата на играта. На другите е позволено да ядат банани.

Какви са тези конспиративни дивотии пък сега. Поне от обща култура, има да ги чакаш тези квантови компютри и това не е защото им липсват реактори за студен синтез, евтина енергия, много енергия или нещо от сорта. Парадигмата е съвсем различна и според мен просто хората не знаят какво да правят с теоретична такава машина. Точно както не знаят какво да правят с доста по-прости и достъпни неща като например с хардуера за масивния паралелизъм. Днес примерно хардуеристите ти сглобяват поредното GPU или FPGA изчадие и какво от това, паралелното програмиране и да изглежда просто е толкова шокираща и доволно сложна парадигма, че не е случайно че приложенията са ограничени. Може да ми вярваш за това. Това са изцяло ограничения на нашето мислене, ние не можем да мислим така. Едно време е имало една голяма глава, Дийскстра, която е развивала теории върху синхронизацията и паралелното изпълнение, забележително понеже е ставало през 70-те на миналия век. За много задачи ние си вярваме че не се подават на паралелизация, просто защото не знам, не можем да си го представим това досатъчно добре, може пък и да се подават. Човешкият мозък не е устроен да работи така. Аз лично съм виждал ужасно големи усилия иначе прости неща да ги паралелизирам, когато накрая това би било логично. Ти сега искаш да разсъждаваме върху нещо което е усъвършенствана перверзия над концепцията за паралелизация, имплицитна паралелизация един вид, с тази разлика че условията са различни и резултатите са различни и цялата постановка е далеч по-перверзна. Ми няма да стане. Според мен нещата се развиват защото имаме някаква нужда от тяхната поява, има и икономическа обосновка, би трябвало да го знаеш това по-добре от мен. Физиците могат да се хвалят как имат модели за какви ли не глупости и просто им трябвали емпирични наблюдения за да ги докажат. Е тук е обратното според мен, някак моделите липсват, а иначе тук-там има емпирични наблюдения върху някакви крайно ограничени събития.

това знаете ли го. https://www.tineye.com/
Качете някоя картинка и веднага ще ви открие същите или подобни картинки в Интернет. Как ли го правят?

С нещо подобно се занимавам в момента.  Трябва да открия дублиращи се или приличащи си картинки. Използват нещо което му викат 'perceptual hashing'. Е на мен това 'perceptual hashing' ще ми свърши работа. Обаче това не е истинско разпознаване на образи. Например справя се чудесно ако картинката е смачкана/разтеглена с различна резолюция. Обаче ако ако е леко позавъртяна или shift-ната или пък картинка в картинка - няма да свърши работа.

Четох как ли се прави и стигнах до термина 'geometric hashing' . http://en.wikipedia.org/wiki/Geometric_hashing

http://stackoverflow.com/questions/22585989/partial-image-detection-with-perceptual-hashing

One approach for doing this can be 1. Extract geometric markers (special points), for both input and output, for example by using the Harris corner detector. 2. Compare every possible pair of triangles on each image . If they have the same angles, they define a transformation (resize, rotate,shift, and mirror). Google "geometric hashing" 3 Count how many points in the target agree with the transformed source, and you have a score for the match. 4. Verify the best match by other means (histogram, edge-registration).

This approach is slow in theory (o(n^6) in the number of points) but I believe it can be practical using an appropriate choice of n and some tricks to speed it up.

http://en.wikipedia.org/wiki/Corner_detection
http://en.wikipedia.org/wiki/Harris_affine_region_detector

Как се превежда на БГ Афинно пространство... Афинни точки... ???
Няма ли някакви command line тулове, които да изплюват 'geometric hashing'-а на снимки или региони и така по-лесно да се екперементира без да се пишат програми.

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

Но пък холивудските ефекти също не са ми особено интересно занимание, нещо не съм особено артистична натура.

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

Не мисля че е толкова просто, базирано просто на делтите в стойностите на пикселите. Ако примерно намалиш или пуснеш осветлението, би трябвало за момент всичко да побелее, което не го забелязвам. Обаче си прав за сенките. Всъщност, пуснах го срещу едно клипче от сутрешния трафик на някаква градска магистрала в Чикаго - обектите, които се движеха бяха автомобилите плюс отблясъците от фаровете в мокрия асфалт. Всъщност то има два такива алгоритъма като гледам, поне API функциите са две. Първият някак вади само контурите на движещите се обекти (това придава малко странен вид, все едно гледаш черно-бял комикс). Това не би вършило работа за "смесване" на два фона. Другото вади самите обекти като това в контурите е бяло. Обаче като гледам сенки, отблясъци и т.н са крива работа. Може би все пак каскадьорските сцени ги подбират по-добре, снимат ги от ъгли където такива ефекти се минимизират. Нямам идея.

това знаете ли го. https://www.tineye.com/
Качете някоя картинка и веднага ще ви открие същите или подобни картинки в Интернет. Как ли го правят?

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

А аз си мислех, че е достатъчно човек да махне информацията за GPS координатите от снимката преди да я пусне някъде  :D Ужас!!!  ???

О-о-о не само чашата за кафе разпознават ами и логото върху нея :-)
някъде наскоро гледах
също и разпознаване (може и само контури) на движещи се обекти
ако се сетя ще дам и адресите по-късно...


А, да ето къде съм го гледал (към края на статията и из коментарите)
http://blog.qt.io/blog/2015/03/20/introducing-video-filters-in-qt-multimedia/
и то на Embedded Linux devices supported by Qt Multimedia, for example the i.MX6-based Sabre SD board

Ако ще ти е по-лесно може и това да пробваш - ГНУ в.3
Live CV - Real Time Computer Vision Coding
http://livecv.dinusv.com/
https://www.youtube.com/watch?v=uEnJE6Jawfw

П.П. Та можеш да пишеш там на Laszlo Agocs и да го питаш как става т.е. те как са го обучили да разпознава (е да то с компютърен шрифт е по-лесно - като го обучат КАПЧИ да ми разпознава тогава да ми се обадят  :P )

Мне, коденето не ми е голям проблем, API-то е лесно и склонно да прави много неща наготово, без да мислиш особено, а специално python-ския wrapper прави нещата наистина тривиални. Това е и причината досега да не ми се е налагало да се опитвам да разбирам добре как точно работи класифицирането, обаче като гледам за съжаление май ще се наложи в крайна сметка.

Големият проблем ми е тренирането на класификатора и там няма никакво кодене - има няколко command-line тулове идващи с opencv. Досега нямам никакъв успех с това - обикновено тренирането гърми с някакви странни грешки преди да стигне до последния stage. Единият път когато успях да тренирам модел (базиран на снимка на батерия Duracell) бях оплескал нещата брутално - за фон на снимката при генерирането на семплите съм избрал черен цвят, вместо бял и бях разменил ширината с височината. Резултатът беше че батерии се разпознаваха в раетата на блузата ми, докато истинската батерия не се разпознаваше изобщо.

Незнам.... ??? ???. ама това с Haar, поне каквото успях да пропрочета не ми се вижда правилният подход за разпознаване на образи. Да не говорим че изисква и страшно много трениране. А и нещата се свеждат до обикновенна статистика.
нали за това става дума: https://www.youtube.com/watch?v=hPCTwxF0qf4


Много по перспективни ми се виждат тези алгоритми с  'geometric hashing'. Поне тук се влага не само статистика а и интелект.
Представям си нещата така:
1. определяне контурите на картинката (http://docs.opencv.org/_images/Sobel_Derivatives_Tutorial_Result.jpg)
2. намиране на особенни точки, които ни итересуват. може да са контури, ъгли....
3. строи се масив с тези точки. което ще е и hashing масива.
4. ако може да се направят няколко снимки от различни ъгли на обекта или стерео изображение този масив да стане 3D масив. Или пък с някакъв по специален алгоритъм (на базата на светлосенките) да се апроксимира 2Д към 3Д hash масив.

И това ще бъде цялото трениране. Не би трябвало да има огромни изчисления.

А разпознаването:
Пак се строи hashing масива на изображението.
1. търси се с алгоритъма  'geometric hashing' дали някой извесните hash масиви се съдържа в hashing-а на изображението. И това е.

Обаче не мога да намеря нищо готово......Само общи статии. :'(
Почвам да си мисля, че когато мина колата на гого, не само снимки на улиците и сградите е направила но са направили и 3d hash-ове на сградите.

това знаете ли го. https://www.tineye.com/
Качете някоя картинка и веднага ще ви открие същите или подобни картинки в Интернет. Как ли го правят?

С нещо подобно се занимавам в момента.  Трябва да открия дублиращи се или приличащи си картинки. Използват нещо което му викат 'perceptual hashing'. Е на мен това 'perceptual hashing' ще ми свърши работа. Обаче това не е истинско разпознаване на образи. Например справя се чудесно ако картинката е смачкана/разтеглена с различна резолюция. Обаче ако ако е леко позавъртяна или shift-ната или пък картинка в картинка - няма да свърши работа.

Четох как ли се прави и стигнах до термина 'geometric hashing' . http://en.wikipedia.org/wiki/Geometric_hashing

http://stackoverflow.com/questions/22585989/partial-image-detection-with-perceptual-hashing

Цитат

One approach for doing this can be 1. Extract geometric markers (special points), for both input and output, for example by using the Harris corner detector. 2. Compare every possible pair of triangles on each image . If they have the same angles, they define a transformation (resize, rotate,shift, and mirror). Google "geometric hashing" 3 Count how many points in the target agree with the transformed source, and you have a score for the match. 4. Verify the best match by other means (histogram, edge-registration).

This approach is slow in theory (o(n^6) in the number of points) but I believe it can be practical using an appropriate choice of n and some tricks to speed it up.

http://en.wikipedia.org/wiki/Corner_detection
http://en.wikipedia.org/wiki/Harris_affine_region_detector

Как се превежда на БГ Афинно пространство... Афинни точки... ???
Няма ли някакви command line тулове, които да изплюват 'geometric hashing'-а на снимки или региони и така по-лесно да се екперементира без да се пишат програми.

Със същата работа за сравняване на картинки ми се налага да се занимавам и аз сега. За щастие на мен ми трябват само съвпадения с 99% (образно казано), и не се налага да търся съвпадения в по-голяма картинка, завъртяни картинки и т.н.
За което perceptual hashing върши прекрасна работа (само да имаше и кадърна библиотека за PHP, ех  :'( )

Цялата дивотия е базирана на Discrete cosine transform ($2). Сега с математиката съм жестоко скаран, така че не съм чел толкова надълбоко. Един пич от hacker news ($2) има обаче статийка по въпроса и според него общо взето ниските честоти дават общата картина, докато високите честоти дават детайли - като разкараш високите честоти с въпросния DCT, можеш да търсиш съвпадения в структурата. Така че вероятно TinEye правят същото за да не се влияят толкова много от осветление, размазаност и т.н., след което прилагат идеята с geometric hashing. Уви, за geometric hashing не знам дали има нещо под конзола. ImageMagick предлага сравняване на картинки с PHASH метрика от версия 6.8.8.3, но ако задълбаваш по-надълбоко, нататък всичко е тъмна Индия - две три академични хартии по въпроса, и няколко изречения в Wikipedia. Това установих след близо 3 дни нон-стоп ровене.

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

P.S: това ($2) изглежда интересно. За съжаление за него има пак само академични хартии.

само да имаше и кадърна библиотека за PHP, ех  :'( )

Има.
phash.org има модул за php. pHash.so, който обаче много трудно се компилира. Пробвах и работи. От цялата работа ти трябва само една функция:

ph_dct_imagehash

(No version information available, might only be in Git)

ph_dct_imagehash — pHash DCT image hash
Description
resource ph_image_hash ph_dct_imagehash ( string $file )

Perceptual image hash based on DCT.

пробвах я и работи прекрасно. Изплюва 16 символен низ с шестнадесетични символи.
А сравнението на hash-овете си го направи сам.
Ако ли пък не ти се занимава с пхп модули има и чисто php библиотека https://github.com/kennethrapp/phasher , която не съм я пробвал още.


Това за сега....

Цитат на: NorthBridge в Mar 29, 2015, 17:06

само да имаше и кадърна библиотека за PHP, ех  :'( )

Има.
phash.org има модул за php. pHash.so, който обаче много трудно се компилира. Пробвах и работи. От цялата работа ти трябва само една функция:

Цитат

ph_dct_imagehash

(No version information available, might only be in Git)

ph_dct_imagehash — pHash DCT image hash
Description
resource ph_image_hash ph_dct_imagehash ( string $file )

Perceptual image hash based on DCT.

пробвах я и работи прекрасно. Изплюва 32 символен низ с шестнадесетични символи.
А сравнението на hash-овете си го направи сам.
Ако ли пък не ти се занимава с пхп модули има и чисто php библиотека https://github.com/kennethrapp/phasher, която не съм я пробвал още.


Това за сега....

pHash-a беше първото нещо което намерих, но едно че предпочитам да избегна компилирането на нов модул, и друго че лиценза е GPL. Иначе ако беше само за мене си, досега да съм го пуснал да върви :)

Най-много ме е яд че ImageMagick го има вградено и работи много по-бързо, но точно PHASH метриката я няма изложена в PHP wrapper-a.

Иначе мерси за линка, в GitHub бях намерил само две архаични библиотеки от 2008 с трагично качество. Това изглежда че ще ми свърши работа.  [_]3

   този същият има и по нов блог
http://www.hackerfactor.com/blog/index.php?/archives/529-Kind-of-Like-That.html

Вътре говори и за нов алгоритъм dhash.
 По спомени във въпросната пхп библиотека не се съдържа алгоритъма phash с DCT,  но за сметка на това се подържа dhash. 

Като ви чета, малко се учудвам. Лицевото разпознаване е стара идея и по нея се работи от доста време. Учудвам се, че намирате толкова малко по въпроса.

Незнам.... ??? ???. ама това с Haar, поне каквото успях да пропрочета не ми се вижда правилният подход за разпознаване на образи. Да не говорим че изисква и страшно много трениране. А и нещата се свеждат до обикновенна статистика.
нали за това става дума: https://www.youtube.com/watch?v=hPCTwxF0qf4

Това е...е, малко го подценяваш според мен. Ето го впрегнато да върши работа и поне според мен се справя изключително добре:

https://t.co/2MSCrwsryz

Има според мен голяма разлика между "разпознаване" на образи и "откриване" на образи. Haar класификаторите не са добра идея ако искам да разпозная моето лице измежду всички останали - вероятно не е невъзможно, но е доста неоптимално. Идеята в случаят е "откриване" на образ, не "разпознаване". Специално за лицевото разпознаване има далеч по-ефективни алгоритми в opencv като гледам, но за "откриването" на обекти, haar дори да не е най-ефективното решение, след кратък research стигам до извода че е най-прекият път към нещо което работи добре същевременно не е ресурсоемко.

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

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

Всъщност, лицевото разпознаване е следващото нещо, което ще проуча след като докарам като хората създаването на haar класификатори.

Има според мен голяма разлика между "разпознаване" на образи и "откриване" на образи.

Да така нещата си идват на мястото.

колкото до геометричното хеширане това което прочетох във википедията за алгоритъма на мачваване страшно много ми хареса.

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

А, имам малък успех, успях да си тренирам каскаден модел. За повече от 24 часа и само с 10 stages и само с няколкостотин позитива и негатива.

Не работи особено добре поради гореизброените причини, дава прекалено много false positives за съжаление, ама е добро начало, поне да знам че нещо не греша.


Също така се оказва че OpenCV подържа няколко статистически алгоритъма за тази цел. Поне доколкото разбирам Haar нещата грубо казано отнемат най-много време и ресурси за етапа на тренирането, но и позволява най-висока точност на откриването на обекти. Другият вариант (LBP) не е такава изчислителна мъка по отношение на тренирането на модела, но теоретично при най-добро старание обикновено докарвало с 1-2% по-лоши резултати от Haar. Като това може да било незначително, но при добре тренирани модели, и двата алгоритъма се вписвали в рамките на *над 95% вероятност да разпознае обекта* и поради това според големите глави, Haar видимо се справял по-добре. Което е странно, моят първи Haar cascade.xml силно ме съмнява да се вписва изобщо в тези смели резултати. А има и трети алгоритъм, HOG, за който не мога да открия прилична информация и май е някаква новост в OpenCV 3.0

Малко интересни адреси. Да използвам linux-bg като bookmark >:D

http://www.cs.haifa.ac.il/~rita/visual_recog_course/Visual%20Recognition%20Spring.htm
http://www.robots.ox.ac.uk/~vgg/research/affine/   ( http://www.robots.ox.ac.uk/~vgg/ )
http://libccv.org/tutorial/ (тоя предлага готово решение за детектване на лица, а и пакета е доста голям.)

На няколко места срещам непреки твърдения че явно G.Goggles използва геометрични алгоритми за разпознавенето.

в една книга хвалят много този алгоритъм. Като казват, че той е изместил по-предишните алгоритми като 'geometric hashing'

The RANSAC (RANdom SAmple Consensus) algorithm, introduced by Fischler and Bolles (1981) [51] has become by far the most successful correspondence search method. RANSAC is a general, robust method for model fitting in noisy data, with signicant
outliers.

Ще трябва доста да се чете :'( Прави ми впечатление че твърде много се набляга на алгоритмните за определяне на неща, области, точки и т.н., като обаче самото мачване някакси се подминава или не знам къде и какво да гледам.Не мога и да разбера има ли някакъв негласен стандарт (и как се казва) на данните/масивите дето изплюват въпросните алгоритми. Щото след това тези данни ги обработват с алгоритмите за мачване ???

Гугъл може да ползва каквото си иска ...и да не забравяме че имат най-голямата база от данни да си го тренират все пак:
http://googleblog.blogspot.com/2012/06/using-large-scale-brain-simulations-for.html
http://www.wired.com/2012/06/google-x-neural-network/
http://www.dailytech.com/Googles+Unsupervised+SelfLearning+Neural+Network+Searches+For+Cat+Pics/article25025.htm
даже unsupervised learning - оставили са го на самотек (като децата) само да се учи и баш като аз на 5 г. имах същата идея за котките (предимно учлини навремето)  8)

но човекът питаше как може това да стане с по-оскъден ресурс...

А, това unsupervised learning и генетичните алгоритми са голяма перверзия. Преди време бях чел за някакъв спътник на НАСА, който им е бил с демонстрационна цел покрай другото - да тестват разни нови концепции. Антената за връзка с наземния контрол е проектирана точно от такъв алгоритъм и изглежда така:

(http://www.nasa.gov/centers/ames/images/content/75316main_st5-104-10.jpg)

Сега никой инженер няма да проектира точно такава антена, но се оказва че проектираната от алгоритъма има оптимални качества (КСВ, оптимална диаграма на излъчване и т.н) и е по-добра от решенията, които обикновено се проектират от хора на базата на солидна теория и досегашен опит. И съответно наистина са го изработили това и са го пратили в космоса. Алтава работа.


P.S: https://www.nasa.gov/mission_pages/st-5/main/04-55AR.html

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

Голяма база данни не означава точна  база. Щото в нея неминуемо има и шум. Не искам да кажа, че не ти трябва огромна/голяма база да тренираш нещо статистически, но има един момент, че колкото и да увеличаваш базата, качеството няма да продължи да се покачва. Дали това дето извличат от нета е много качествено? Всеки ден се генерира огромно количество спам от всички и след това този спам им влиза и в моделите.

Дали не се само хвалят. Това например не обеснява защо търсенето им се влошава със всеки ден, а         твърдят че имат 'графи на знанието'

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

Далечна асоциация, помня едни откровения на Schneier по отношение на security проблемите, той правеше някакви асоциации със бъговете в софтуера и закона на Мърфи и бъговете със security импликации със нещо което наричаше "Satan's law". Един вид че точно бъговете със security последствия са тези, които някой нарочно ще тръгне да експлойтва и поради тази причина целия QA процес при софтуера е криво измислен, защото coverage-а и приоритетите са едни, а реалността е друга. Та същата работа с алгоритмите на гугъл, те може добре да се справят със случайния шум, но вероятно не толкова добре с нарочните зловредни SEO изпълнения.

Поиграх си с SIFT с command line тулове от тука: http://www.cs.ubc.ca/~lowe/keypoints/

има две команди: едната ./sift дава ключовите точки и ги записва в txt файл или ги визуализира в картинка

втората ./match прави сравнение между двата txt масива изплюва броят мачнати точки (което явно и метриката за съвпадение) и може и да визулизра съвпаденията между картинките.


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

Ужастъ :o


   

.....
Ужастъ :o
 

Джордж Оруел 1984

Готови ли сте?

За това ли става въпрос?

https://opencv-python-tutroals.readthedocs.org/en/latest/py_tutorials/py_feature2d/py_matcher/py_matcher.html#matcher


Изглежда забавно..

Цитат на: Naka в Apr 04, 2015, 15:02

.....
Ужастъ :o
 

Джордж Оруел 1984

Готови ли сте?

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

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

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

Конкретно за България примерно имаме наличие на свободни избори, но нямаме образовано население. Това на моменти особено добре си личи. Примерно наскоро гледах в някакъв псевдоновинарски сайт някакво видео където някакви руски спецполицаи разбиват врати и пребиват заподозрени престъпници, в общият случай ужасно ненужна демонстрация на сила, примерно влизат 10 глигана в един апартамент и смазват от бой разни хилави невъоръжени чички, които ако ще да са терористи, просто нямаха никакъв шанс да им окажат каквато и да било съпротива. 90% от коментарите бяха превъзнасяне как трябвало да се прави и как им се падало, дива радост. И се замислих по въпроса откъде идва тази радост след като тези там не са осъдени и ядат една кофа бой просто защото са заподозряни. Още повече, в т.наречения "цивилизован свят" такова видео би довело предимно до негативни реакции, коментари за превишени полицейски правомощия, асоциации с третия райх, Оруел и т.н.


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

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

Я, имам напредък.

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

Ама проучих въпроса с лицевото разпознаване...та оказва се че Eigenface и Fisherface са най-разпространените варианти. Eigenface се оказа доста капризно и неточно нещо, не знам сигурно работи в някакви идеални условия, но fisherface докарва прилични резултати и без да се счупиш да тренираш модела с идеален мат'рял в достатъчно количество. Та схемата се оказва проста - ползвам готовия Haar модел за разпознаване на човешки лица. Във видеото открие ли се лице, парчето от битмапа където е намерено се скалира до някаква по-прилична резолюция (fisherface се задъхва да го прави примерно върху 800x600 с няколко десетки кадъра в секунда), обръща се в grayscale и се пуска fisherface разпознаването. Резултатът е приличен - разпознава домочадието вкъщи успешно.

Намерих и питонска TTS библиотека (espeak) която се оказа голямо дърво за съжаление (да не почвам оттам че беше мъка да го накарам да работи с pulseaudio). Има един гаден мъжки и един гаден женски глас с доста роботизирано звучене.

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

Сега нещо забавно и доста неочаквано. Понеже ми хрумна да разпознавам лица от DVB-T телевизията (и даваха новини) или примерно от видеоклипове от нета, та кой с най-голяма вероятност ще дадат по новините...дам, бате ви Бойко. Обаче срещнах изключително големи трудности да си тренирам fisherface алгоритъма с неговата физиономия. Сега някой ще каже че това е нелепо, защото той е вездесъщ и из интернет могат да се намерят хиляди негови снимки. Ми може - пробвайте да търсите за "Бойко Борисов" в images.google.com. Проблемът веднага се набива на очи - почти невероятно е да видите снимка на Бойко където последния е застанал точно срещу камерата. Винаги, ама винаги го снимат под ъгъл и това достатъчно добре съсипва нещата. От първите 100 резултата сигурно не повече от 4-5 стават. Мен това не ме отказа и реших да търся клипчета в youtube където го интервюират или нещо от сорта. Това беше още по-потресаващо - пробвайте да намерите видео с ББ където пича гледа директно в камерата, а не под ъгъл. Това се оказва още по-сложна задача и аз досега не съм открил подходящ вариант.

Реших че е някакъв странен чалъм на фотографите и операторите или сигурно е модерно така да ги снимат вече или аз не знам какво. Обаче следващият за който се сетих да си тренирам модел (логично Цв.Цв, те двамата си ходят в комплект) - там е изключително лесно - не че повечето снимки дето google ми ги вади са перфектно правени срещу камерата, но мога да си събера относително бързо самплите.

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


Хаха, още по-забавен експеримент, тренирах лицево разпознаване срещу членовете на Бийтълс....само че по видеоматериал от интервюта правени през 80-те. След това изпробвах модела срещу клипа на Hey Jude, който е правен....не знам някъде края на 60-те, демек пичовете са с 20 години по-млади и доста по-различно изглеждащи със сигурност. Не очаквах голям успех, то и за човек би било сложно. Резултатът е тва:

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

Пол Макартни упорито отказваше да го разпознае, което е странно предвид че субективно според мен най-много си приличаше с образа на младини. Джон Ленън обаче го закова, хитрата гад.

Интересно, как червената рамка изчезва, когато си наведе главата.

Не знам защо цялата тази сага тук ме подсети за една класика...
Може и да е трудно да се намери но си струва гледането.

The Adolescence of P-1 ($2)
или както е по-известен на запад
Hide and Seek (1984) ($2)


If this was 1977, imagine what computers can do now!!, 7 November 2001

Едно е да го четеш - друго е да го гледаш ($2)

П.П. И всичкия тоя труд само да го накараш да те разпознава, а...

Имам някакви смътни спомени, че това май са го давали в бг.... Много много одавна. 'Игра на криеница' ли се казваше ?!?!?

Относно нещата разисквани тук не става дума за Изкуствен интелект -- макар, че изглежа точно такова.

Става дума за тъпа и проста математика или за обикновенна статистика. Интелекта в случая се дължи или е привнесен от тези дето са мислили алгоритмите. Как да се вземе точно това от картинката което най добре описва нещо и след това да се сравни. Гадни числа без душа. >:(

например за SIFT алгоритъма акцента пада само върху особенни точки по картинката, ъгли и градиента на сигнала около тях. Е дали така мисли човека -- я каква картинка а тук има едни ъгли и точки. .. ми тези точки и ъгли ми приличат на точки от друга картина.... :o дай само тях да гледам. ама за другите работи по картината съм абсолютно сляп и изобщо не ги забелязвам.

Колкото и механично да звучи все пак върши превъзходна работа.

@Naka - те точно този е филмът (не помня вече под какво заглавие излезе тогава - отдавна беше), ама наскоро го гледах пак ..а и понеже стана въпрос за социалната страна та се сетих.

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

Та спорен е въпросът за интелекта въобще и изкуственият в частност. Според мен даже и теста на Тюринг нищо не решава т.е. решава най-много частния случай че онова насреща има интелект като на човек ...щото не съм сигурен че напр. при извънземни ще работи  8)


Благодаря на всички за идеите - ще ги пробвам скоро.. аз по друг повод де
http://www.alpha-wars.com/
и т.п. - мисля че това геометричното ще свърши работа
(щото мразя по лесния начин там - да се набърквам из джава и заявки.. предпочитам ИИ)

П.П. Споко и по една  [_]3 за всички

Айде сега, хвърли ме в размисъл. Да, определено това няма нищо общо с изкуствени интелекти, просто математика. Дали това е недостатък не съм убеден - върши си работата, често по-добре от човек дори. Човешкото зрение също си има граници. Примерно OCR софтуер, която разчита регистрационни номера на автомобили преминаващи с достатъчно голяма скорост, винаги ще работи далеч по-добре, отколкото човек. Алтернативно, софтуер който открива образи с идеята да ги брои, при подходящите условия, винаги ще се справя по-добре от човек. Но няма нищо "интелигентно" в това.

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

Айде сега и ти ме хвърли в размисъл (и аз па зех че изрових - не знаех че е толкова старо)
http://news.bbc.co.uk/2/hi/science/nature/1194565.stm
та вече имаме (изкуствен) интелект колкото на 1-2 г. дете
т.е. то тва парче вече требе да е 14-15 годишно..,
та както казваше един колега още навремето подсмихвайки се под мустак
време е вече да им отидем на гости с 1-2 дискети под мишница да си го изкопираме

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

Бах го, кви са тия sci-fi глупости сега. Между другото в една от последните sci-fi книжки, които четох, динозаврите бяха еволюирали, бяха си създали изкуствена звезда с един купол около нея и си пътуваха из космоса като adopt-ваха разни видове, докато един прекрасен ден не се сблъскаха с хората от родната им планета, за които не знаеха и които тотално им разказаха играта на общественото устройство и де да знам, готвеха се да им унищожат купола, но това в следващата книга, дето още не е излязла.

Аз след тази книга намразих птиците честно казано, бидейки еволюирали влечуги.

Интелигентността не е, дали ще се справиш с дадена ситуация или въпрос. Интелигентността е способността да се задават правилните въпроси, когато се срещнем с нещо непознато. Въпроси, които ще очертаят непознатото в правилни рамки, за да можем да го вместим в представите си. Да можем с тези въпроси да търсим отговорите в правилната посока.
На сегашното ниво на алгоритми и изчислителна мощ, не виждам как това може да бъде постигнато с някой софтуер. Всеки калкулатор за долар-два смята много по-бързо и точно от почти всички хора. Всяка машинария обработва статистически данни много по-бързо от човек. Сега. По въпроса със смятането... Знае се, че има хора способни на чудеса буквално в това отношение. Идва въпроса дали и останалите хора не са способни на същото. Ако да, нуждата ни от тъпите компютри може да отпадне в много случаи. Статистиката също, ако се приведе в нужния математически модел и математически точна граматика, също може би ще може да се обработва от надарени или развили тази способност хора. Ако приемем, че всички сме способни да смятаме така.
Тук идва въпроса и за цената на тези усилия вече де. Сигурно ще е изморително. Ако не са ни научили от малки на това, ще ни е трудничко. На мен ми е трудно с много неща. Спомням си като по-малък как поглъщах буквално всякаква интересна информация и ми оставаше в главата. Бях гъвкав. Сега не толкова.
Според мен компютри изобщо няма да са ни нужни един ден, а в момента повече пречат, отколкото помагат. Хората затъпяват. Учат се да решават проблемите и задачите си, като влагат усилия да научат някой друг да ги реши, пресметне, вместо тях. Аз съм го изпитвал на собствен гръб. Два теста по математика, като на първия се справих много добре, но на втория, две седмици след това, имах тройка. Само защото тези две седмици се радвах на сметачката, която ползвах. Смяташе вместо мен, аз само записвах така, че все едно аз съм го смятал. Нула усилия от моя страна и резултата беше очакван.
Този софтур за разпознаване на образи  или лица сигурно лесно може да се излъже. Особено лицевия. Ако човек реши да се крие от него или хората зад него, може да го направи доста успешно.
Споменах ли, че преди време, когато нямаше жиесеми и изобщо нещо, което да помни телефонните номера вместо мен, помнех почти всички номера, които ми бяха дали приятели и съученици. Сега зная моя номер, домашния ми също, зная домашния на нашите, на един приятел и помня и още два мобилни номера на друг човек. Това е всичко. Много зле

Тая дивотия ме закрасти обаче, реших да направя нещо по-практично и да си напиша бъгаво софтуерче за проста система за видеонаблюдение, не особено професионална, но пък забавен опит в реализирането на изцяло уеб-базирана такава с благинки като human body/face detection, лицево разпознаване и истинско засичане на движение (не делти между кадри - тва е доста нескопосано). Не че нямам СОТ вкъщи, ама ще е забавно въпреки всичко.

Та тръгнах на (напоследък любимия ми) питонец да си го дращя, ползвайки django фреймуърка. "Архитектурата" я замислих, моделите и няколко view-та ги разписах, остава най-важното: самата функционалност. Реших да ползвам ffmpeg за да стриймвам видео, което да може да се гледа в браузъра. Подаването на видеофреймове от opencv към ffmpeg е ужасно голяма кочина да му се не види, идиотите просто не са предвидили друга възможност освен всичко да минава през адски бавен pipe. OpenCV има и досадния навик да работи с BGR а не с RGB стойности на пикселите и докато се сетя за това се чудих защо нещата излизат все едно си се надрусал с ЛСД. Допълнително (жив да не бях) най-накрая разбрах каква е тази драма с подържаните от HTML5 браузърите кодеци и формати. Понеже нещата се оказаха достатъчно насрани, просто не виждам по-добър вариант от стриймването на FLV и показването в браузъра с някакъв swf плеър.

Та докарах нещата дотам да хващам входа от камерата, да го процесвам с opencv, да го encode-вам във FLV формат и да го стриймвам с ffserver. Вероятно ще трябва динамично да генерирам ffserver.conf и да рестартирам гадината при промяна в конфигурацията на уеб приложението, ма тва не е голям проблем. Това което наистина ме отчайва е възможните разновидности на тема "какво подържа камерата". Иначе с моята оптимизирах нещата и сега изхода от обработеното с opencv видео при стриймване генерира около 2-3mbit/s трафик (и това включва трафика за качването от ffmpeg към ffserver), което е нищо в рамките на един етернет сегмент. Това е 640x480, 24-битов цвят, изкуствено орязано до 10fps. Една идея е да го превръщам в 8-битов grayscale - ще помисля по въпроса, мене си ми харесва цветно и някак бих могъл да прежаля по-ниския framerate. Та при това положение енкодването с ffmpeg товари с по-малко от 10% процесора, но питонския скрипт който разпознава лица твърдо окупира едно процесорно ядро :(

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

Но пък би било забавно - movement detection-а ще ми позволи да записвам видео само когато има причина да го правя, т.е изискванията към дисково пространство ще намалеят с порядъци.

Така както съм замислил нещата, ще има и alert-и които ще могат да се дефинират на база какво е събитието (просто движение или full body засечено или човешко лице засечено или човешко лице засечено и разпознато като някой в базата). Alert-ите съответно имат action, който може да бъде пращане на мейлове, изпълнение на външни команди (например aplay alarm.wav), дори по едно време ми хрумна идиотската идея да се качва някъде видео-то - щото примерно като влезе крадец в къщата едва ли ще пощади десктоп машината и кел файда че съм го логнал на диска.

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

Ако има достатъчно рам, не може ли да се слагат нещата в  tmpfs и директно после в облака. Така няма да се бави машината с писане по харда.

Може, стига да измисля добра дефиниция на това "после".

Апропо добре се получава засега...

(http://s10.postimg.org/h2x3n6e89/noise1.png)

Да се чете "как да хакнем алармена система с разпознаване на образи която още не е написана" :)


П.П ааааа вече знам ако Джон Ленън е влязал да краде в апартамента!!!

(http://s30.postimg.org/rc3g92qcx/johnlennon.png)

Имам много лоши новини за всички дето са решили да ползват SIFT и компания за feature detection - всичките алгоритми в opencv са патентовани, водят се non-free и ако се ползват за комерсиална цел, трябва да се плаща royalty, това включително ако искаш да го ползваш в някаква уеб услуга.

Иначе се оказва голяма краста - в момента напредвам с домашната алармена система. Днес открих че камерата може да се използва като детектор за пожар относително успешно. Дори май направих първото си собствено откритие в тая област (макар че силно ме съмнява никой да не се е сетил, защото не е особено велико, доста елементарно и логично е) - промених един алгоритъм измислен от братята турци за откриване на пламъци, елиминирайки нуждата от обучение. Те го правят на базата на марковски модели, базирани на факта, че контурите на пламъците "трептят" по определен начин. Ако игнорираме момента с това че камерата може да се мести или видеото, в което разпознаваме може да има драстични делти с времето (примерно да откриваме огън в музикален видео-клип където се сменят радикално различни сцени), тогава ние може тотално да елиминираме момента с тренирането и да постигнем много висока акуратност на разпознаването на пламъците, използвайки единствено побитови операции върху матрици, определени RGB филтри, background extraction алгоритмите в OpenCV (MOG е най-подходящ, изгъзиците на MOG2 не ни вършат работа), както и стандартния blob detection с малко tweak-нати параметри (по отношение на минимална площ, инерция и convexity). Трябва да пазим и няколко кадъра назад и акуратността силно зависи от това, но дори с пазенето на един кадър назад, нещата са доста прилични. Performance-а е достатъчно приличен и можем да го правим в реално време.

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

Съжалявам за тъпото аудио, youtube е доста дразнеща работа. Но се вижда де, при промяна на сцената, акуратността спада брутално, огньове се откриват където ги няма. Но пък за камера за видеонаблюдение, тези неща няма да са проблемни.

А какви честоти на вълната на светлината хващат нормалните камери? Защото, ако ловят над определени в инфрачервената област, спокойно може да се ползват дори само така за детектори. Без разпознаване на пламъци.

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

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

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

Имам много лоши новини за всички дето са решили да ползват SIFT и компания за feature detection - всичките алгоритми в opencv са патентовани, водят се non-free и ако се ползват за комерсиална цел, трябва да се плаща royalty, това включително ако искаш да го ползваш в някаква уеб услуга.

В Европа нали нямаше софтуерни патенти. А и пише че SIFT и братчето му SURF са патентовани в US.


А за пламъците ако се стигне до детектване на пламъци ще е вече много много късно - ебати и детектора. Нещо може да гори и без пламъци. да тлее и да пуши. Затова пушека е много по надежден критерий - така както са направени стандартните детектори.

Ние ползвахме нещо друго преди време в университета. До колко вече може да се ползва за комерсиални цели трябва да се види в лиценза...
Ето тук се помещава животното: http://ivt.sourceforge.net/book.html
Там е и книгата по която вървя част от едната ми лекция по темата...
Книгата е писана много разбираемо, стига човек да е учил малко от малко математика :)

Гейт, има инфрачервени камери ако нещо гори.. доста по лесно е да замерва температурата и ако някъде мине прага да сигнализира... нищо толкова сложно.. По забавното е фюжъна на 2те камери, особено ако са с различни резолюции на сензорите и различните им позиции... :) Ако ти се занимава с Геометрия ето интересно нещо, което със сигурност някой е решил но все пак. Имаме 2 камери А и Б които стоят една до друга с някакъв ъгъл, така че да хващат еднаква част от пространството. Знаем ъгъла, да приемем че имат еднаква резолюция, проблемът е: как да мапнем данните от инфрачервената камера А върху данните от нормалната камера Б. Сега ако бяха 2 нормални камери щеше да е по лесно, защото модела на стандартната камера е ясен и винаги можеш да изчислиш проекцията върху даден пиксел на матрицата от къде идва. Номера ще е какъв е модела на инфрачервената камера? После ключова Дума може би е Епиполарна геометрия...

По темата за Невроналните мрежи, статисткиката и класификацията като цяло:
1. Изненада! Невроналните мрежи са статистически модел: Ключова дума нелинейна регресия...
2. Невроналните мрежи имат проблеми като всеки модел, но основния според мен е че при голям брой неврони, много трудно може да се анализира самата мрежа след тренировката, това означава, че може да се разглежда като блекбокс модел. Естествено може да се срязва мрежата и да се разглежда изхода след даден слой, но като цяло ташаци на рояци...
3. Различни алгоритми и модели за различни проблеми.
Примери: Скрит марков модел за моделиране на акустиката при гласово разпознаване. Или Ен-Грам модела за моделиране на речта.
4. Различни модели дават различни като качество резултати:
Аз последно ползвах Линейната дискриминанта на Фишър за да класифицирам ментално натоварване на база концентрацията на хемоглобина в определени мозъчни дялове. Интересното е, че метода работи доста добре, предвид факта каквъв беше експеримента стигнах до 80% Акурантност (И мисля че може да се качи още ако се поработи още)...
5. Интересно нещо е използването на десижън функции и множество РАЗЛИЧНИ класификатори. Проблема тогава, е че може да се стигне до неразличима ситуация. За това приоритети, тежести етц...
6. There is no silver bullet: Означаващо, че няма един модел в който фитват всички проблеми, както и няма един алгоритъм който класифицира всички данни. Отделно, че има разлика между класификация и предсказване примерно.

То ясно, че всяко тяло с температура над абсолютната нула излъчва. Излъчва и черната дупка дори.
Но все си мисля, че температурата на горене може да се засече така директно. Сигурно ще е неудобно, защото различните материали, както и ти каза, горят при различна температура, та това ще трябва да се задава като параметър. Вероятно не е особено добро решение, щото различни материали десетки в едно помещение например.

А за пламъците ако се стигне до детектване на пламъци ще е вече много много късно - ебати и детектора. Нещо може да гори и без пламъци. да тлее и да пуши. Затова пушека е много по надежден критерий - така както са направени стандартните детектори.

И това може да се направи както се оказва, някой го е измислил...тази вечер си играх да го имплементирам (некадърно):

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

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

Алгоритъмът е доста прост - изваждаме фона, за да вземем движещите се обекти, намираме контурите, правим малко магии за да обединим близки малки контури (аз го правя тъпо - ползвам blur), чертаем ги върху черно изображение, AND-ваме го с оригинала, обръщаме резултата от RGB в YUV и за всеки контур смятаме средната стойност за Y (luminance) стойността на всички пиксели, средното отклонение, площта на контура и геометрията (опростено - аз вземам броя на точките които го формират). Вземаме тези стойности примерно за 20 кадъра назад и правим сметката - ако имаме контур където средната стойност на Y не се променя, а стандартното отклонение стои в някакви граници, както и ако площта и геометрията се променят за всеки кадър, тогава имаме кандидат за пушек. При достатъчно добре подбрани threshold стойности и достатъчно много кадри назад, за които пази информация, класификатора работи относително добре. Проблеми са както движението, така и кадри, взети от места с ярки източници на светлина в общи линии, първото осира откриването, второто осира false позитивите.

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

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

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

Разбира се, специализирана техника, която е правена да работи в много по-тесен честотен обхват, с висок dynamic range, филтрираща боклуците на съседни честоти които се alias-ват и бъркат по всевъзможни начини и е калибрирана като хората, би могла да ни каже далеч по-точно дали това е нещо дето гори или не и каква му е температурата. Обаче не съм убеден че това е толкова просто с обикновени камери, дори IR такива.

Не грешиш. Изтъкнах същото и аз. Трябва да се укаже за конкретния обкет, какви стойности на светлината от него могат да се приемат за горене. Трудна задача и изискваща доста ръчна работа. Вероятно разделяне на зони или, ако пък разпознава обекта като "това канапе" сам да си вземе от някъде данните, че текстила или изкуствената кожа горят при тази инфрачервена светлина излъчвана от тях. Сложно и ресурсоядящо. Май димен детектор е за предпочитане  :D

Така като си се заел със софтуер за разпознаване на образи и покрай всички тези приказки, току-що ми хрумна друго интересно приложение на такъв софтуер и мисля, че ще се справя и не толкова трудно. Дори мобилно приложение може да се измисли.
Може и пари да се направят от това.
Благодаря!  ::)

Тъй, това е последното до което стигнах за момента:

https://www.youtube.com/watch?v=He0F9qU-O28&feature=youtu.be

Идеята ми е да го реализирам възможно най-просто базирано само на статистически модели. Алгоритъмът си го изработих сам и е заиграване на тема онзи paper от по-горе, съчетан с мои наблюдения. Първо, реших да не се занимавам с YUV colorspace-а, а само с RGB и наблюдавах различни сцени с дим, очевидно има два вида дим - "обикновения" където гори нещо генериращо "нормален" пушек, както и "химически" дим - наситени и ароматни въглеводороди, които при горенето си отделят доста черни сажди. Първото е лесно, защото е отенък на сивия цвят и R=G=B стойността работи доста добре - за запалена хартия, дърво, въобще всичко, което има неутрален сив цвят на пламъка. "Химическият" дим със саждите обаче е забавен и това е на практика резултата от горенето на повечето полимери и нефтопродукти. След известни изследвания на кадри от такъв дим стигнах до извода че RGB стойностите се колебаят между 60 и 80 като червената стойност е най-висока следвана от зелената и синята, в някакви интервали. Оттам стария алгоритъм, базиран на това че геометрията се променя, площта нараства, средната стойност на RGB пикселите е почти константа.

Големият проблем е с проследяването на blob-овете, в момента ползвам доста ахмашки и компромисен вариант където ползваме много смели предположения, това относително добре работи в реално време, но е супер неточно и оттам идват и разни false positives, особено при големи промени в сцената. Правилното проследяване включва една сметка за геометричния център на blob-а най-малкото, но само от това ако почнем, изискванията към изчислителното време стават такива, че става ужасно затормозяващо да го правим в реално време върху stream от камера, какво остава за няколко камери. Отделно се губят кадри, които ни носят важна информация и акуратността се насира. Та засега мисля оптимизации, но нямам много идеи.

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

P.S Обаче трябва да призная, не работи добре при странно осветление, примерно нощно такова. Мамицата му и прасе, няма да е толкова просто.

А нещо използващо геометрия, движение на флуиди? Пушека определено има характерно поведение и форми.

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

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

5.

---

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

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

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

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

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

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

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

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

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

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

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

Иначе днес реализирах идеята, почти де. Новата ми идея беше да използвам не геометрични характеристики, а това че димът "замазва" картината, с други думи, визуално, нещата изглеждат "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

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

Най-най-най-накрая имам нещо което работи доста точно. С други думи в 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 при клатенето, но улавят пушека от взрива. Лошото обаче е че клатенето на камерата осира и откриването на позитивите, в смисъл съсипва статистиките и пушекът се открива в кратките моменти, в които пичът не клати камерата много.

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

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

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

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

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

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

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

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

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-ва, просто става прекалено бързо, за да може алгоритъма да реагира.

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

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

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

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

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

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

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

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

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

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

В общи линии "простите" начини се оказват два - и двата се базират на вероятности. Първият одеве го споменах - базиран на хистограми и хистограмни 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 променят координатите си между двата кадъра като тези, които не се вписват във въпросната трансформация ги изхвърляме. Не особено добра илюстрация на това:

(http://teyvoniathomas.com/images/stories/UTC/fast_lkt_no_supp_6frames.png)

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


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

(http://mlpy.sourceforge.net/docs/3.2/_images/kmeans1.png)

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


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


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


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

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

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

Разбира се това е много фалшива камера с CMOS сензор и IR филър, но въпреки това нощният режим е забавен, заради IR осветлението. Установих че не може да се ползва през прозорец. Изкарах камерата на терасата и ми стана много забавно как някои източници на видима светлина във "видимия" спектър са по-силни от други във псевдо-инфрачервения. IR ледовете посмъртно не могат да хвърлят на такова разстояние, за да имат значение отраженията.

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

Тия дни ще си правя опитите с PTZ проследяването на движение. Това за да изкарвам акъла на домочадието и котките камерата автоматично да се върти, следейки ги.

Каква е чувствителността на такова нещо?

Чувствителност към кое?

Ако е към IR/near-IR - не много висока. Аз между другото едва след като я взех тази камера осъзнах как работи тази работа с нощното виждане. Освен ако не е някаква много специална камера, няма начин хем да работи добре през деня, хем да работи добре през нощта в случая в който наблюдава относително отдалечени обекти. Тези камери идват с инфрачервени led-ове, моята също има, но те не са безкрайно мощни, примерно за моята камера й дават до 8 метра разстояние за нощно виждане - това е разстоянието от което отразените инфрачервени вълни са достатъчно силни, за да се регистрират от камерата. Поради тази причина, камерата е почти "сляпа" в нощен режим на улицата - виждат се единствено уличните лампи, при това слабо и вероятно защото са халогенови, като ги заменят и тях някой ден с LED осветление както почнаха да правят на места в София, сигурно няма да се "виждат". Доколкото разбирам, решението на такива проблеми е допълнителен по-мощен IR източник, който да "осветява" сцената, например нещо такова:

http://www.supercircuits.com/accessories/infrared-illuminators/150-ft-outdoor-ir-illuminator-ir34


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


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

А аз си мислех, че е достатъчно човек да махне информацията за GPS координатите от снимката преди да я пусне някъде  :D Ужас!!!  ???

А каква мислиш е основната цел на Google Street View :)

Перфектна база от „данни“ за сравняване на изображения ::)

Като ви чета, малко се учудвам. Лицевото разпознаване е стара идея и по нея се работи от доста време. Учудвам се, че намирате толкова малко по въпроса.

А дали си спомняш какво ставаше с научните публикации при евентуален пробив в съответната област на приложение ::)

Хм, Gate.

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

Чувствителност към кое?

Ако е към IR/near-IR - не много висока. Аз между другото едва след като я взех тази камера осъзнах как работи тази работа с нощното виждане. Освен ако не е някаква много специална камера, няма начин хем да работи добре през деня, хем да работи добре през нощта в случая в който наблюдава относително отдалечени обекти. Тези камери идват с инфрачервени led-ове, моята също има, но те не са безкрайно мощни, примерно за моята камера й дават до 8 метра разстояние за нощно виждане - това е разстоянието от което отразените инфрачервени вълни са достатъчно силни, за да се регистрират от камерата. Поради тази причина, камерата е почти "сляпа" в нощен режим на улицата - виждат се единствено уличните лампи, при това слабо и вероятно защото са халогенови, като ги заменят и тях някой ден с LED осветление както почнаха да правят на места в София, сигурно няма да се "виждат". Доколкото разбирам, решението на такива проблеми е допълнителен по-мощен IR източник, който да "осветява" сцената, например нещо такова:

http://www.supercircuits.com/accessories/infrared-illuminators/150-ft-outdoor-ir-illuminator-ir34


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


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

Добре дошъл в света на невидимото. Повишената температура, например петната, значи наличие на източник на енергия. Може да са духове или същества от съседното измерение  :D
Иначе тея камери са прости. Трябва ти източник естествено, защото нощно време няма много достатъчно мощни източници на такава светлина и отдалечените предмети няма какво да отразяват. А дължината на вълната е достатъчно дълга, за да се губи поради разтоянието и може би да излиза извън възможностите на камерата. Любопитен съм, ако я обърнеш към нощното небе, какво ще се вижда. Топли, студени въздушни течения. Самолетни следи.
Под чувствителност разбирам, поне аз, каква амплитуда между отделните дължини на вълната хваща. Каква е стъпката. Например 3400-3500-3600 нанометра или 3400-3420-3440 нанометра. Не зная, как да го обясня с по-малко думи. Може би ми липсват термините в речника.
Познавах един тираджия който нощно време караше с такива очила и не зная, откъде ги беше купил. Това в мутренско време. То и сега такова де. Та много пари беше дал тогава, чак се хванах за главата. Но пък караше спокоен в нощно време по неосветените магистрали на нашенската част от Европа. Дъжд не го бъркаше, сняг. Виждаше на 600 метра напред  ;D

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

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

Пак да кажа че това не е точно същото като инфрачервена камера. Доколкото става ясно (и което съответства с наблюденията ми) - механично се сменят филтрите за нощна/IR светлина (когато преминава в нощен режим и обратно се чува едно прещракване). Сензора е същия и в двата случая. В дневния режим винаги има известна част от IR спектъра, която се регистрира - споменах вече за проверката с дистанционното на телевизора, вижда се добре на камерата. Съответно в нощния режим винаги част от видимия спектър се регистрира - силен източник на видима светлина, не излъчващ в ИР спектъра пак ще се види с голяма вероятност. Това е и причината разни детайли да се виждат като например контурите на детската карта на България закачена на стената. Извън това, най-вероятно чувствителността е предимно в най-горната част на инфрачервения спектър. Такива неща като с термокамерите (и света през очите на Хищника) просто не се случват с такава камерка за видеонаблюдение, тя не е правена за такива неща. Мен силно ме съмнява дори да може да се различат визуално два еднакви предмета един до друг с абсолютно един и същ цвят (на видима светлина), но единият да е по-горещ примерно с 20-30 градуса. Може би съм прекалено скептичен, но от не многото което видях миналата вечер...по-скоро се съмнявам де.

Хм! Не зная. Преди време четох, че направили снимка на фоновата радиация уловили отклонения в температурата от порядъка на 0.00057 градуса. С какво са го правили...
Все пак 20-30 градуса са прекалено много за всяка камерка, за да не ги хване като разлика. Достатъчно е да легнеш на леглото и да се снимаш. Завивките би трябвало да са със стайна температура, а тялото с нормалната за него. Разликата ще е 15-18 градуса сигурно. За опит става.

Хм! Не зная. Преди време четох, че направили снимка на фоновата радиация уловили отклонения в температурата от порядъка на 0.00057 градуса. С какво са го правили...

със сензор, охладен до много ниска температура

Днес пак ръчкам код и нямах много време да си играя.

Все пак нещо интересно. Първо теорията ми че frequency response-а е предимно в горната част на инфрачервения спектър май ще се потвърди. Няма особена визуална разлика между два еднакви предмета (топчета, едното държано известно време в ръката) с различна температура. Поне е трудно да се забележи. Не съм пробвал да си играя софтуерно с контраста.

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

От друга страна прозрачно фолио (целофан) май се оказва голям проблем за нощното виждане...но не знам дали не е заради отражението от LED-овете.

Друго забавно което ми хрумна, но няма да експериментирам тази вечер, защото трябва да мажа още код и да лягам - интересно как ще се държат Haar класификаторите за лицево откриване и fisherface за лицево разпознаване в нощен режим. Би трябвало да няма проблем, защото те си работят със grayscale изображения....обаче вероятно feature-ите са различни, забелязвам че човешкото лице се изменя при това положение, ирисите яко блестят, някои ъгли се губят, устните и очите изглеждат доста по-ярко контрастни. Ще е забавен експеримент. Ако все пак се окаже че разпознават успешно, ще е доста забавно. Ще се окаже че нощно време, тъпата железария се справя доста по-добре от човека при разпознаване на лица. Защото на тъмно е трудно да разпознаеш физиономии не че нещо.

Я виж ти, много добре работило лицевото разпознаване в нощен режим:

(https://pbs.twimg.com/media/CE_Nja9WAAAMHkA.png:large)

Това е в тъмна стая, единственото осветление идва през пердетата и далеч не е ярко. Haar класификатора работи изненадващо добре, но fisherface разпознаването не е толкова акуратно, колкото на дневна светлина. Може би защото моделът е трениран с изображения, взети на дневна светлина, както споменах, лицата се изменят на нощен режим. При същите условия, за човек е невъзможно да различава лица, виждат се само силуети.

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

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

Това дали ще може да разпознава извънземни :o
Може да си направиш SETI@home и да чакаш някое заблудено извънземно да са озвери в камерата.

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

Пфу голяма борба с тия PTZ контроли. Аз великата ми идея за домашната система за видеонаблюдение и аларми въобще не съм я забравил и работя върху нея. Тия дни ми се скъсаха нервите с откриване на камери по UPnP протокола (bonjour и ONVIF още не съм подхванал). За да са по-забавни нещата, очевидно всяка IP камера си има различно виждане за PTZ контролите - някои ползват HTTP GET заявки, други POST, автентикацията може да е различна, отместването може да е релативно, но може да е абсолютно...ще им .... мамата задето не са измислили някакъв стандарт.

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

Обаче криво-ляво поне grid view-то което се очаква от всеки софтуер за видеонаблюдение го докарах...грозно засега, има доста да се стилизира. Плюс PTZ контролите, които се управляват с drag евенти, на практика малко наподобява на FPS shooter, макар че трябва да дооправя контролите за да стане като истинско гейминг преживяване хаха. Но пък е ужасно забавно всичкото да става в браузъра, аз не очаквах че ще работи относително прилично. Тия HTML5 извращения верно си имат забавна страна...

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

Откъм бекенда ми остава да забранявам всякакви откривания на движение, лицеви разпознавания, откривания на дим и тем подобни opencv глупости докато камерата се върти. Което звучи лесно, ама всъщност изобщо не е, изисква достатъчно сложна логика и IPC комуникация между процесите, хардуерно зависимо е, което дразни :(

Я осъзнавате ли, че това е първият път, в който Гейта публикува своя снимка???

Надвил е страха си  :D
Аз още не мога

Хм, на път съм да разбера как работи още една антиутопична играчка....

http://postimg.org/image/vc6nj2t5j/

http://postimg.org/image/9uyp884t9/


Оказва се че това наистина го има и си работело съвсем прилично (с точност над 95% в някои реализации).

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

В общия случай има няколко стъпки:

1) Локализация. Това е стъпката на която откриваме потенциални регистрационни номера в сцената. Аз го направих просто и заради това дава малко повече false positives от оптималното, но пък не е и голям проблем. False negatives почти никога не дава. Номерът е прост - blur-ваме леко картинката, за да избегнем "шум" от сорта на дребни петна, отблясъци и т.н., прилагаме gaussian threshold върху картинката, вадим контурите и търсим контур, който 1) е достатъчно голям, контури от десетина пиксела примерно не ни трябват и 2) bounding rect-а му отговаря на определени геометрични критерии. Критериите са отношението между ширина и височина, а въпросното го намерих в интернет, оказва се че е стандартизирано, поне за регистрационните табели в ЕС.

Малко изхитряване е да "изхвърляме" потенциалните кандидати, които "включват" други такива в себе си - това намаля обикновено с 1-2 бройки false позитивите (като се има предвид че на сцена обикновено има до десетина такива, това пак е приемлива сметка).


2) Препроцесинг. За всеки такъв регион обръщаме изображението в grayscale и правим още един път thresholding. Целта е да се "откроят" тъмните петна (буквите) от светлите петна (фона на регистрационния номер). Това само по себе си не ни върши идеална работа, защото разни винтчета, гайки, логото на европейския съюз с надписа "BG", както и обикновено една черна рамка около регистрационния номер, остават. Остава и "случаен" шум - сенки, кал по номера, отблясъци и т.н. Последният се отстранява с морфологични операции - dilate/erode.

3) Сегментация. Ако резултата от стъпка 2) я подадем на tesseract, то той обикновено се задавя много лошо - заради рамката на номера, логото встрани, въпросните нитове и винтове за които е набиван знака и т.н. За да изчистим тези неща, отиваме по-нататък - от регистрационния номер "изваждаме" всяка буква или цифра. За целта threshold-ваме изображението отново и вадим контурите. Прекалено малките контури ги изхвърляме (така си заминават болтчетата и случайно каквито дребни петна са останали) и отново налагаме геометричен филтър, възползвайки се от факта, че се ползва един и същ шрифт и отношението височина/ширина е в някакви рамки. Отношението височина на буквата/височина на табелата също е hint, но не го ползвам. Така вадим една по една всички букви - можем съответно и да направим още една проверка дали това е регистрационен номер - ако има по-малко от 6 букви, значи не е и не го подаваме нататък

4) Разпознаване. В случая с tesseract, "лепя" отново всичките букви/цифри на бял фон и му ги подавам, но може и буква по буква. Тъпото е че въпросната сегментация от горния параграф, tesseract-а пак ще я направи, та може би да му се подава буква по буква ще е по-добре.


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


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

Сега няма как да се похвали с велики качества и >95% акуратност, но и така работи довоооолно добре.

Мммммм тва с разпознаването на регистрационни табели във видео не е толкова лесна работа, доста оптимистично съм гледал на нещата :)

Първо, изчетох отгоре-отгоре няколко paper-а за да видя големите глави как подхождат към проблема с разпознаването на символи. Явно масово прилаганото решение е трениране на SVM класификатор (статистически метод, не съм разбрал още достатъчно добре как работи, но на първо четене странно напомня на марковските вериги дето ги ползвах в hashkill-а за да генерирам пароли по модел, трениран от речник ).

SVM модела се тренира с HOG хистограми. Доколкото се опитах да разбера що е то HOG, не мога въобще да разбера защо това нещо работи. В бедните ми представи за нещата, би трябвало да имаме ужасно много false позитиви от съвсем различно изглеждащи обекти (или обратно, негативи от ужасно сходни). Та това е нещо, което трябва да се опитам да разбера като хората.

В OpenCV няма готова функция, която да смята въпросните HOG хистограми, та срам не срам преправях чужд код.

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

Входните данни за модела (за български регистрационни номера) ми е следния (след сума ти къртовски труд):

http://postimg.org/image/62iykuxf3/

За всеки възможен символ имаме три изображения, върху които смятаме въпросните хистограми на ориентирани градиенти. Това е ужасно малко и големите глави твърдят че ще ми трябват поне едно стотина като за начало ако искам прилична акуратност. Е заклевам се, успея ли някога да го постигна това, НЯМА да го споделям безплатно - тъпия скучен упорит труд си заслужава заплащане - и както човек може да се досети, готови модели няма (изключай усилията на един пич да направи същото за испанските регистрационни табели, където отсъстват няколко букви).


Както и да е, с този беден модел, резултатът е следния:

http://postimg.org/image/ea6a2uuxb/

И има ужасно много проблеми.

Първият очевиден проблем идва от кофти модела - символите А, 8 и Т се разпознават като "0". Всъщност, на някои кадри, 8 успешно се разпознава, но A и T - никога.

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

Третият проблем - производителността, сега 25fps видео се срива до около 2-3 fps в следствие на всички тези сметки. Но видеото е 720p в крайна сметка, а доста неща има за оптимизиране, така че това не ми е проблема. Бавенето не идва от SVM разпознаването, идва от сегментацията, която при мен е доста....деазнам, малко като руския цар подхождам към проблема. Има голям мегдан за подобрение.


Като цяло се нервирам, ще се окаже все пак играчка това.

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

http://postimg.org/image/d447wckof/full/

Разпознава относително коректно вече....е тук-таме в някой кадър "3" става "9", "8" става "0". a "C" в един момент прилича на "0", но напредъкът е голям.


Всъщност оказва се че при така зададените параметри с които се тренира (36 символа общо, 20x20 резолюция на картинка, 4 HOG хистограми, общо 64 bin-а) имаме много бързо "насищане" на акуратността при добавяне на нови картинки към training set-а. До около 5 картинки на символ, акуратността скача рязко, след това нормално файдата започва рязко да спада. При 10 картинки на символ с които тренираме модела, тестовете срещу нов set от картинки (A-Z, 0-9) показва 92% акратност в разпознаването - което означава че само с 3 от 36-те нови символа не са разпознати коректно.

Лошото е че и да тествам с 20 картинки на символ да тренирам модела, трудно ще скочи акуратността с повече от 1-2 процента и не знам доколко си оправдава усилията.

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

Специално локализацията използва адаптивен thresholding, което е хубаво защото работи относително добре при всякаква осветеност на сцената. Но не се справя добре с хвърлени сенки и дребен "шум" по сцената. Навсякъде из paper-ите хвалят OTSU thresholding-а и пробвах с него - обаче тук има друг проблем - параметрите му трябва да се настройват ръчно за всяко различно видео, защото един threshold работи много добре за едно видео и много зле за друго. Автоматично няма как да го подбираме, трябва някакъв изкуствен интелект да ги взема такива решения.

Поради което ще се чете още, не може да няма по-добър подход. В крайна сметка може би има по-добър подход от thresholding-а като цяло.

Достатъчно бързо ли е пайтънчето за тези неща?!

Това няма голямо значение, защото "тежката" работа я върши opencv, която е c++ библиотека. В случаите в които няма наготово opencv функция или набор от такива, за да се свърши нещо и се налага сам да ръчкаш по изображенията (които са numpy матрици "по начало") тогава може да се появят проблеми с производителността.

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

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

Нямам идея, аз не съм много по нещата с уроците.

Python ужасно много време го ненавиждах като език и го приемах като някаква модернизирана версия на Perl. Синтаксисът специално ме вбесяваше (и още ме вбесява на моменти). Обаче трябва да си призная че върши идеална работа за много неща и спестява ужасно много глупости. Що се отнася до performance-а, никой не пречи да си напишеш критичния код на C, да го билднеш под формата на shared библиотека и със swig да го ползваш от python. Доста досаден и противен момент са типовете данни в случая, но какво да се прави.


P.S тренирах модел с повече картинки на символ - 20, както и оптимизирах доста алгоритъма така че вече кажи-речи става в реално време без голямо дропене на фреймрейта на изходното видео. Добавих и подръжка на гадните квадратни регистрационни номера (ЕГАТИ УЖАСА е това - номера е подреден на два реда и ти имаш сегментирани региони с координати, широчина и височина по екрана - честито разпознаване кои са буквите от горния ред и кои са буквите от долния ред предвид възможността да го гледаш това под ъгъл). Значително подобрих препроцесинга и локализацията - вече не използваме адаптивен thresholding (ужасно бавен е), вместо това използвам комбинация от median филтър, за да отсявам дребни артефакти плюс canny edge, за да хващам рамката на регистрационния номер.

Та всичко това доведе до повишено бързодействие и акуратност:

http://postimg.org/image/3to58oz2v/

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

http://postimg.org/image/4l1n3dygv/

..не може да се похвали с нито едно успешно разпознаване. В случаят имаме огромен проблем с цифрата "6".

Забавното е че като investigate-нах проблема, оказва се че шрифта за регистрационните номера в Европа е стандартизиран по DIN-1451 или нещо от сорта, но има вариации по отношение на това. В източна европа, 6 и 9 не се изписват с голямата завъртулка (вж скрийншота), докато в западна Европа се изписва. Като резултат от това, сега моделът ми има training изображения предимно от западноевропейския шрифт и българските номера го отнасят лошо. И както се вижда, шестицата се разпознава като осмица или девятка. Единственото решение на проблема е тренирането на още по-свински модел, където присъстват двата варианта....или алтернативно трениране на един модел за нашите номера и друг модел за европейските.

Та извода е, още по-брутално трябва да се тренира модела. А за жалост training samples вече трудно откривам :(


P.S за да илюстрирам по-добре проблема, това е български номер:

(http://www.licenseplatemania.com/fotos/bulgarije/bulgarije28.jpg)

Това е португалски:

(http://www.licenseplatemania.com/fotos/portugal/portugal35.jpg)


6 и 9 много много не си приличат....и съответно тормозят OCR-ването...


Това не е единственото недобре стандартизирано нещо в тази област де, другото е нулите. В някои държави няма никаква разлика между 0 и O, защото или нямат буквата О в номерата си, или нямат цифрата нула в номерата си, или са разделени като при нас на части само с букви и само с цифри. При повечето въпреки всичко имаме малка разлика между О и нула в шрифта, което помага на моето OCR-ване, но това е ambiguous. Сега за да е още по-забавно, немците дебело си подчертават нулата като нула, толкова дебело че започва да прилича на съвсем различен символ и се опасявам че ако вкарам няколко семпъла в trainset-а от немски шрифтове, ще настане същата боза като с 6-цата и 9-ката. Очевидно за да имаш високоакуратна система за разпознаване на табели, трябва да си го тренираш срещу изображения на номера от държавата. Това че сме в ЕС и има някакво стандартизиране - очевидно последното касае само размера на табелите и онази синята част там с логото на ЕС и кода на държавата...

Мех, готово, разпознаваме вече български регистрационни номера на видео с доста висока акуратност (трудно ми е да дам точни цифри, но е над 90%, вероятно над 95%, но в идеалния случай, в естествена среда може да се случи номерата да ти идват под достатъчно кофти ъгъл или с достатъчно крива сянка - за второто, с IR камера и нещо дето светка, на практика си докарваме идеални условия).


Работи напълно в реално време, както може да се види на видеото (с камера срещу браузъра):

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

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


Това е на базата на доста подобрен статистически модел за разпознаване, доста оптимизиран localization алгоритъм и въведени правила, които са валидни само за български номера (някъде във видеото много добре си личи как fail-ваме срещу някакъв чешки номер, който прилича на български и Z го разпознава като 2 - защото съм изключил "неизползваните" латински букви от модела).

Забавното е че ако изкуствено увелича резолюцията (софтуерно скалирам от 640x480 до 1280x960 например), разпознаването ни става още по-точно, което не е много очакван резултат и трябва да разбера защо става. Но на практика очаквам от HD камера още по-добри резултати. От near-IR камера с добра подсветка на сцената, цялата тази патаклама е абсолютно реална и работи и на светло и на тъмно и не яде особено много изчислителни ресурси.

Което е забавно, сега се замислих как може да се cheat-ва. Номерата с фолиото и спрейовете дето отразяват силно IR спектъра сигурно работи, но се замислям за по-интелигентни решения. Според мен съвсем малки "видоизменения" към номера (постигнати с лепенка черно фолио върху номера) които визуално за човек не са голям проблем, за автоматичното разпознаване могат да се окажат достатъчно голям проблем. Стига разбира се комерсиалните системи да ползват и те SVM статистически модели, а не някакъв друг подход, който не може да се излъже така.


Друго което ми хрумна, още по-забавно - обикновено емблемата на производителя на колата е някъде много близо до регистрационния номер. Можем да тренираме спокойно SVM модел с HOG хистограми и за емблемата. Така на видео няма само да откриваме регистрационни номера, би било доста забавно примерно "черен форд CA1234TP" или "зелен фиат РР5432РА".  Няма да е много голяма играчка и според мен е напълно постижимо. Вероятно има доста криви модели коли, където ще е трудно с прости евристики да докараме нещата и където ще имаме кофти hit rate, но пък по мои наблюдения в повечето случаи би трябвало да мине номера. Ще започна да се оглеждам повече докато шофирам за работа и обратно.

Сега е момента да пуснеш кода. Ще му намерим приложение.   ;D
Аз искам python, че там разбрах, че може да се работи с числа с всякаква бройка цифри, стига да има достатъчно памет. Трябва ми за едни сметки с много големи числа. 'C' не съм пипал от години и ще ми трябва един период на опресняване. А и нещо gcc ми изписва, че някакви библиотеки ми липсвали. Дали още се наричат така, не зная. iostream.h например. Май не съм инсталирал нещо. Тея библиотеки не съм ги търсил още, но ... Ще изчакат няколко дена

Добре! Редакция няма да правя, но...
Оказа се, че от '98-ма година, вече няма iostream.h, а се декларира само iostream
Също се оказа, че не мога в C++ да използвам просто cout, а трябва преди това да извикам веднага след декларациите using std::cout;
Та тестовата програмка тръгна. Са остава да разбера, колко големи числа може да поддържа С.

Как в Python да му кажа, къде е Tkinter, защото вика, че няма такъв модул?

Някъде най-отгоре просто нашиваш using namespace std и тогава няма да пишеш std::cout вместо cout.

C подържа толкова големи числа, колкото е разредността на машината и в зависимост от използваният тип и дали е signed. По стандарт обаче, int е 32-битов и на x86_64 и ако ти трябва нещо по-голямо от ~2 милиарда (signed) / ~4 милиарда (unsigned), тогава се ползва long. Кодът не е portable и ще има драми на 32-битова система.

Ако ти трябват сметки с големи числа, тогава ползваш някаква bignum библиотека като gmp.

Що се отнася до TKinter, нямам идея. Сигурен ли си че е инсталиран? Питон-а коя версия е (2.x? 3?)

Инсталиран е. Python 3.4. Пуснах find да търси и намерих някаква папка мисля, но не зная как да му го посоча къде е. В /usr/lib/python3.4/tkinter но намери. Ами трябват ми много големи числа. Милиардите ще са като едно и две. Също и ще трябва да видя, как да го накарам да ползва всички ядра, че ще сгъна откъм време.

Ем значи import tkinter.

Threading-а в питон е пълен ташак, да го имаш предвид когато решиш да "ползваш ядрата". Ако си свикнал с pthreads специално.


Апропо, трябва да легна да спя най-накрая, досега съм тренирал невронни мрежи (multi-label перцептрон). Мързи ме да пиша всичко което забелязах, но невронните мрежи няма как да заменят SVM класификатора, тъй като при тези зададени условия и брой samples с които тренираме модела, работят доста по-зле. И това трудно ще се промени като се замисля, единственото предимство им е че могат динамично да се дообучават - късмет с SVM в това отношение. Та в крайна сметка засега използвам комбинация от SVM и невронна мрежа - ако SVM ми открие буква, тогава гледам петте най-добри кандидата от класификатора с невронната мрежа с най-добър резултат и ако е там, вземам предвид резултата от SVM, в противен случай вземам най-добрия резултат от MLP. Получава се това:

https://t.co/LYWIf6EsPL

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

Import tkinter си го пиша. Реве. Ще се разровя още в нета, че нямах време да търся, как става.

Ем виж тогава дали библиотеката ти е в PYTHONPATH-а.

Ще прощавате за офтопика, ама...

https://t.co/LYWIf6EsPL

Това да шофираш в София е като руска рулетка с 5 патрона. ???

Нещо подобно но в "умален" мащаб
http://blog.qt.io/blog/2015/06/04/qt-5-5-computer-vision-and-the-nitrogen6x/

Нали разправях че някой ден ще се захвана с проследяването на обекти с PTZ камера. Покрай другите занимания с ANPR разпознаването и покрай уеб-базираното домашно видеонаблюдение, нямах време да си играя. Днес обаче си поиграх малко и резултатът е това:

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

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

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

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

Според мен това нещо може да стане съвсем истинско и работещо. И би било доста полезно в сценариите когато нахлуват разни крадци или нещо от сорта, защото ще максимизира времето, когато въпросните са регистрирани и записани от камерите.

П.П всъщност съвсем механично, pan/tilt стъпката е контролируема и ако се възползвам от това, мога дори да насиля обекта да е в центъра на камерата, ама за целите на видеонаблюдението, това изглежда грозно. Ако заедно с камерата беше монтирана и картечница дето стреля, сигурно щеше да има други изисквания. Чисто идиотска тролщина, ама добре че такива неща не е имало по хитлеристко време, защото тогава на някой naistina щеше да му хрумне да направи наистина нещо такова с монтирана картечница и да търси примерно циг...роми по някакъв признак, примерно хистограма и да ги стреля. Доста тролско, но щяха да го донаправят психопатите.

Примитивно, но това пуснато докато те няма и да праща по кадър на секунда някъде в облака, ако влезе непознат.... Какво като е примитивно  ;)

Аз не съм много убеден че това има голяма стойност за видеонаблюдение в апартамент. Някаква файда има единствено в големи стаи когато обектът е поне на едно 5-6 метра от камерата. Виж, за дворове и открити пространства е много идейно. А ако се доработи малко алгоритъма и да zoom-ва вместо само да се върти, тогава възможностите наистина са големи. Това има негативни страни (увеличавайки върху нещо, губим евентуално важни събития, които могат да възникнат в същото време встрани), както и чисто като логика е доста сложно - например какъв да е "обикновения" zoom level, колко да zoom-ваме, кога да възтановяваме "обикновения" zoom level - след фиксирано време е тъпо, защото примерно ако е крадец, който се суети около нещо и не мърда много, да го отебем е глупава стратегия . Дори само с въртенето има любопитни моменти, като например дали след проследяването да се връщаме в началното състояние на камерата, дали да я оставим да "патрулира" - т.е да се врътка наляво-надясно докато засече движещ се обект. Сценарии много, а оптимална стратегия май няма, зависи си от ситуацията.

За жалост, камерата ми не подържа zoom и следователно тази част от забавата няма как да се сблъскам с нея. А на открито, това би дало доста забавни възможности, комбинирайки го с други....feature-и. Примерно ако се комбинира с ANPR, може да zoom-ва върху далечни автомобили, за да им прочетем и логнем номера. Може да се комбинира с лицево разпознаване и да се разпознават хора в далечината. Дори да не се разпознава, може да използваме само лицево откриване с Haar модел и да се стремим да държим лицето на фокус. Наскоро нали убиха едно момче в Борисовата градина и заподозряния е някакъв бръснат тип, уловен на записи от камера. Имаше из медиите изображение от тази камера, заподозреният там в далечината и като добавим и кофти резолюцията и размазването заради движението, лицето му не е особено разпознаваемо. Но с PTZ камера с някакъв алгоритъм за проследяване и zoom-ване върху лица, може би нещата щяха да са доста различни сега. А може би не - ако е имало повече движещи се обекти, вероятно дори нямаше да го регистрира, щеше да е zoom-нало върху нещо друго.

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

Това с проследяването на камерата, ако се приложи върху инфрачервена камера. Ама инфрачервена, плюс алгоритъмчето за разпознаване на лица, но приложено към определени твърди предмети, няма ли да е забавно, да си личи през дрехите, кой какво носи по джобовете си и, ако е нещо опасно и евентуално нелегално, да алармира?!  :)

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

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

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

Горния край на инфрачервения спектър не са ли 50 000 нанометра?! Това не е ли твърде голям диапазон за всеки сензор? Ако го хваща, а също и част от видимия.... Браво! Някои хора са магьосници.
Иначе холивудските изпълнения ги зная и зная, че действителността е друга. А как стои въпросът с ултравиолетовата светлина? Тя е с по-къса дължина и би трябвало да не е толкова размазано? Или не си се интересувал.

Всъщност, наистина има доста снимки правени из нета. Мога да потвърдя, че при мен нещата изглеждат горе-долу по същия начин:

(http://i.ytimg.com/vi/1FLie3vDIEQ/maxresdefault.jpg)

Що се отнася до ултравиолетовия спектър, вероятно матрицата "регистрира" долната част от него, близо до видимия. Все пак железарията не е точно като човешкото око и frequency response-а и е по-различен. Но предполагам стъклото в лещата служи като естествен филтър за голяма част от него. Между другото, същата е историята и с инфрачервената светлина, огромна част от камерките имат IR филтър, защото иначе изображенията изглеждат неестествени. Специално тази за видеонаблюдението доколкото разбирам освен че пуска LED-овете, "премахва" и филтъра, чисто физически, чува се едно "щрак" когато минава от дневен в нощен режим. Това е и вероятно причината светлината от дистанционното да се вижда бледо в дневен режим, но да "заслепява" камерата в нощен режим.


Хах, апропо открих нещо забавно. Евтинката IP камера d-link 5020l която имам по принцип има motion detection, но той може да се конфигурира или да праща мейлове или да качва видеа някъде, тези неща сами по себе си са неизползваеми за сървър за видеонаблюдение, защото няма как да знаеш в реално време кога се е случило движението, за да вземеш мерки (да вдигнеш аларма, да почнеш да записваш и т.н.).  ONVIF решава това като дефинира механизъм за HTTP-базирани нотификации. Но камерката е евтина и не подържа ONVIF.  Най-забавното е че има някакво закътано старо API за d-link, с някакви cgi команди. Половината не работят, но се оказва че точно endpoint-а за event нотификациите работи. Първоначално не ми регистрираше движение, но се оказа че трябва да го инициализирам със заявка, която е доста специфична за модела. В крайна сметка дори с евтинията сега си имам edge motion detection, вместо да смятам с opencv. Резултатът е покъртителен - там където преди изяждах 40% от процесорното време на едно ядро, сега изяждам по-малко от 20% (това включва запис на видео и регистриране на event-и които в случая идват от камерата). Това в крайна сметка означава че на моята скромна десктоп машинка спокойно биха и понесли до около 15-20 навързани такива камерки, с хардуерен motion detection преди да почне да губи кадри и да се дави заради ограничените процесорни ресурси. Голяма забава. Апропо, понеже има и микрофон и съвсем лесно мога да приемам и нотификации за регистриран звук над някакви децибели (но пък не записвам и не мисля да записвам звук). Въпреки това, би било полезна функционалност, в случай че се трошат стъкла и се разбиват врати.

В крайна сметка, според мен е много реална идеята чисто софтуерно и с евтини камери да се реализира интелигентно видеонаблюдение за малки обекти.

Докъде стигна с това?
А склонен ли си да се върнеш пак към C/C++?

https://www.youtube.com/watch?v=8KShQnKgnms

Ами в общи линии занимавам се още, неприятната част е че прекалено много вземане-даване имам с уеб фронтенд глупостите покрай това и нито разбирам от тях, нито ми е приятно. Иначе видеостриймването и записите и IVS алгоритмите съм ги интегрирал вече (с едно изключение - motion tracking-а, защото чакам читав 3.0 release с добре документиран python интефейс - понеже сегашния алгоритъм който ползвам там е реализиран изцяло на C и едно дето ще е по-бърз и две дето вероятно ще е по-читав). Освен което злите езици говорят че OpenCL ускорението ще е достъпно и за питонския код - ама все още няма никаква документация по въпроса и не знам.

Това което не съм направил и имам чисто философски проблем как да го измисля е с "алармите" и това е понеже ми се въртят разни сложни схеми и трябва да ги опростя, за да е използваемо. Идеята ми е грубо да разделя това на няколко неща - събития (които и сега логвам и обработвам), правила (кое събитие от коя камера колко е критично и какво да се случи ако настъпи) и действия (примерно мейл нотификация). Та правилата не мога да ги измисля като хората (като ORM обекти). Значи за тези правила, първото важно е множество от камери за които това ще важи. Второто важно е severity на събитието. Третото е какво действие да се изпълни. И последното, което не мога да навържа е времето за което това правило да важи - примерно всеки ден от 9 до 18 часа. Това е важно, защото ако примерно реша за всяко засечено движение да се изпраща SMS нотификация, определено не искам да се оспамвам сутринта или вечерта като се върна от работа, а варианта ръчно да ровя из уеб интерфейса да преконфигурирам всеки ден е малоумен. Обаче как най-лесно и като реализация и като за пред потребителя това да стане още не съм измислил.

Та философските драми ще ги реша защото излизам в отпуска скоро и ще ми остане време да дращя по листи разни гениални идеи. Ама бъхтенето по шибаните HTML темплейти, js код и CSS неща ми къса нервите и доста ме демотивира.

Ммм иначе на C не бих го портнал посмъртно. Може би единственото нещо, което бих написал на C е частта с прекодирането на стрийма от камерата и записа във видеофайл, защото OpenCV не е мислен за целта и е недъгав, а няма някаква читава питонска библиотека за целта, а и да има, няма да е достатъчно бърза. Та евентуално някой ден като свършат по-важните драми, с цел оптимизация, може да разпиша един демон който ползва на ffmpeg библиотеките за целта.

Иначе като за толкова малко време прилично доста неща успях да направя, което е радостно. Ако всичко това трябваше да го пиша на C, щеше да отнеме месеци, сигурно години. Автоматично откриване на камери по UpNP (евентуално и по ONVIF след време), IVS нещата, напълно функциониращ admin интерфейс и (засега) лимитиран потребителски интерфейс - има grid view (но пък стана ДОСТА добре, горд съм с тези спагети), както и event timeline. Тепърва ще се правят търсенето на събития, ровенето из видеоархиви и т.н. екстри. Всъщност, дори realtime event нотификация си имам за събития в grid view-то (което можеш да си подреждаш и мащабираш както си искаш). Камерите на които се случва събитие в реално време се ограждат в червена рамка, дори мога аудио да стриймвам в браузъра (примерно "ВНИМАНИЕ! ЗАСЕЧЕНО ДВИЖЕНИЕ!").

Демо за съжаление не мога да дам за досегашните усилия, за без пари в биг брадър не участвам :)

П.П а, да и най-хубавото е че реших да тегля един дебел чеп на Adobe и на Microsoft - с флаш нямам никакво намерение да се занимавам, а workaround-а за mjpeg подръжка в Internet Explorer не само че не го донаправих като хората, ами го изхвърлих с кеф. Не ми беше лесно решение, защото определено стриймването на истинско видео с компресия между кадрите, а не поредица от JPEG изображения има и предимства (главно в по-голям избор от транспортни протоколи, не е казано че трябва да е върху HTTP, както и в по-добрата компресия и съответно по-малко bandwidth изисквания, макар че това е условно). Обаче като взех решението да ги отеба честно казано се почуствах доста по-добре.

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

След главоблъскане с IP камерите на d-link, просто реших да сe оръся за по-истинска камера (в случая от Hikvision) и определено нещата придобиха смисъл, защото се бях отчаял с тези глупости. Днес си взех новата камерка, разликата е с порядъци. Просто защото снима в Full HD, има разни благинки като цифров denoising, WDR, backlight compensation и тем подобни. Съответно разликата в ефективността на калпавите алгоритми за разпознаване на пушеци, разчитане на регистрационни табели и проследяване на движение просто работят - без да се правят 1000 зависими от сцената хакове.

Да не говорим за другото - имат истински ONVIF support. Сега прекрасната D-link DCS-5222L камера която официално е compliant, неофициално не е. Тъй като имам ssh достъп, разбирам и много неща. Например защо малоумния WS-Discovery майкрософтски протокол, който е в основата на откриването на устройства в мрежата не работи - на камерата има демон, който слухти за multicast заявките и segfault-ва когато получи пакет - това с ВСИЧКИ версии на фърмуера. Поради тази причина d-link-ската камера не може да се открие в мрежата по този начин, който уж е стандартизиран. Следващата част - ако отеба autodiscovery частта и директно запитам d-link-ската камера какво подържа, ми се връща едно, но на практика е съвсем друго. Hikvision просто работи като хората.

Което ме хвърля в блатото, защото сега виждам колко много възможности има и трябва да кодя, за да ги наваксвам. Примерно целият ми OpenCV median flow алгоритъм за проследяване на движение се обезсмисля - камерата го прави учудващо добре и аз получавам нотификация ако обект мине дефинирана линия. Това спестява егати бруталното изчислително време. Друго - камерата подържа адекватно Device командите и сега мога по желание да вдигам fps и bitrate на видеото при нужда. Представи си - засича се движение, вдигаме фреймрейта и битрейта, връткаме PTZ моторите и снимаме.

Възможности има много - примерно камерата има слот за SD карта. Защо да не записва там докато нямаме свързаност и после да дърпаме сниманото (ONVIF протокола го позволява). Това има ограничени приложения, но смислени въпреки това, в случаите в които губим мрежова свързаност.

Но най-много се накефих на инфрачервените сензори, които нямат много общо с тайванските боклуци и наистина осмислят нещата, особено в FullHD резолюция.

(http://s21.postimg.org/4fl2etus6/dran.jpg)

Изображението е чисто и разпознаването на лица в нощен режим е доста по-работещо.

PTZ глупостите се връткат с порядъчно по-добра скорост па макар и като максимални градуси да е по-лимитирано.


Другото, което мисля да експериментирам (и това е хардуерна хакерия) е с alarm I/O-то на камерата. Има един вход на който ако се подаде напрежение над 2 волта, се тригерва аларма. Мисля да почна с прости неща, не разни датчици, а просто обикновен прекъсвач. Може да звучи тъпо, но представи си паник бутон, който веднага насочва камерата към мястото на паник бутона и увеличава битрейта, фреймрейта и оттамкачеството на записа - би било полезно.

Накратко съм очарован - можело значи да работи и сега драмата ми е какво да правя със всичко това след като работи като хората :(

Накратко съм очарован - можело значи да работи и сега драмата ми е какво да правя със всичко това след като работи като хората :(

ами направи го самоходно  :P

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

а за тези които искат - може направо да си го купят - не само лица разпознава ами и емоции ..че даже може и такси да  ти извика  >:D
https://www.youtube.com/watch?v=HQtIlxe_ZkY

П.П. Пък ако хакнеш т'ва на комшийката ще може да си я гледаш колкото искаш докато се къпе...
 [_]3 [_]3 [_]3

Докъде стигна с разпознаването на рег. номера?
Това тук дали ще помогне в смисъл дали е лесно да се портва за GPU
https://github.com/openalpr/openalpr

О, това е готово отпреди "извънредното събитие" (роди ни се второ чаве). Оттогава прогресът е много бавен, защото почти нямам никакво свободно време да се занимавам. Обаче вече има някакво просветление, та се надявам скоро да ми се отвори повече време за каквито и да били занимания.

А иначе имах някакви тестови видеа от тогава:

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

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

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


P.S

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

Като цяло обаче се съмнявам да има огромно подобрение. Макар че с по-високи резолюции нещата ще се променят. Апропо, резолюцията е ключова в случая, има огроооомна разлика в качеството на разпознаването между 640x480 и 1280x960 примерно - но и на двете видеа правим сметките върху scale-нато на 640x480 видео, поради performance причини. Та оптимизации трябва да се правят определено - не знам дали портването върху GPU на част от сметките ще са част от тях.

P.S 2:

https://github.com/openalpr/openalpr

Разгледах го - ползва tesseract, което е лошо хрумване (понеже това беше и при мен първото хрумване, сам да си OCR-вам буквите и цифрите първоначално ми се видя шокираща идея). Ужасно бавно е това, дори да имаш гениален алгоритъм за локализация на табелата и да ти вади наистина само табели, без false positives. Самия tesseract е много тежко нещо, това е OCR софтуер за общо ползване, не е предвиждано да разпознава текст във видео в реално време.

Другото много лошо нещо на тесеракта е че с него ще видиш голям зор да разчиташ "малките" табели (тези квадратните които поставят на мотори или на определени автомобили където няма място за тях - пример с Алфа Ромео) - там номера е на два реда и tesseract-а ще се види в чудо.

tesseract-а между другото не върши и супер добра работа ако не е трениран изрично с DIN-1451 шрифта който се използва при европейските табели.

Както и да е, сам да си OCR-ваш се оказа далеч не толкова сложно нещо (макар че заклевам се тренирането на моделите е най-досадното нещо на този свят). В смисъл не става без да почетеш малко как се правят тези неща, но от друга страна не е чак такъв rocket science. А opencv ти дава наготово инструментариума.

Дай боже всекиму такава радост  [_]3
и второто ли е момиче (не знам защо съм останал с впечатлението че първото е женско)
ако е така... не ми се мисли - почвай още от сега да внасяш в банкова сметка ..или почвай да копаш битпари :-)

Аз питах само информативно, че отдавна не си се разписвал нещо - благодаря за информацията.

http://www.linux.org.ru/news/opensource/12808776 - излезе първата версия на аналога на OpenCV, DCV 0.1.
DCV е написан на езика D. Поддържа работа със статични изображения и видео.