Hát amíg megkapjuk azt a "második pillantást", addig is hozzáfűzném, hogy amennyire én tudom, az emberi (és általában a fejlett) szem nem képpontokkal operál az agy felé, hanem már egy előfeldolgozást végez. Tehát az agyunk már objektumokat kap meg, a szem előzőleg bizonyos műveleteket már elvégzett.
Ha innen nézzük a dolgot, akkor már "sokkal" könnyebb a dolgunk, mert elég ha absztrakt modellekkel dolgozunk, nem kell azon aggódni hogy belefér-e a távolságmérés abba a pár pixelbe.

Láttam is már ilyen (fél-) megoldásokat, ami a kamera oldalán igyekezett egyszerűsíteni a látottakat, direkt robotos alkalmazások számára. Ilyen volt a színes foltok, háromszögek keresése, a csontváz egyszerűsítés, stb. Természetesen a valódi képet is el lehetett kérni a kamerától.

Ha nem egy kőbe vésett koncepcióról beszélünk, akkor szerintem inkább egy ilyen rendszert kellene górcső alá venni, és nem brute-force módon nekimenni a pixel2pixel összehasonlításnak. Robosztusabb is lenne, és a processzoridőt más dolgokra lehetne szánni.


A hallgatás meg ne aggasszon, csak a hideg ellen burkolózunk Szerintem is maradjunk a részletesnél. Mindig élvezettel olvasom amit írsz, mert jó sok tanulnivaló van benne

A másik meglátásom a látással kapcsolatban, hogy ha maradunk az eredeti elgondolásnál, akkor sem a két nyers képet kellene összevetni, hanem mindkét képen a keresett főbb jellemzőkre kellene felvenni egy mondjuk "drótvázat", és elég ezeket összehasonlítani az elemzés végén. Ilyen drótváz lehet mondjuk a toronyóra, mint viszonyítási pont, a drótváz meg a teteje mint háromszög. A végén a két kép két háromszögét elég összevetni, és megvan az eltérés, ebből meg a távolság. Ezzel már egy közepes teljesítményű vas is könnyebben megbírkózna.
Egyébként csak hangosan gondolkodom, lehet cáfolni

No meg van a korrelációs technika, ami ugyan számításigényes, de ugyanakkor megoldja a "pixelenkénti" összehasonlítással kapcsolatos aggodalmakat...

Van abban valami amit mondtál, az "előfeldolgozásban"...

Akkor még egy kis látás: Az emberi szem receptorai két alaptípusból állnak, ezek a pálcikák és csapok. A gerincesek többségében hasonló felépítésű a szem. Az alapvető különbség, hogy melyik típusú receptorból van több. Azok az élőlények amelyeknél a pálcikák vannak túlsúlyban elsősorban éjjeli életmódra vanak berendezkedve, ehhez alkalmazkodott a szemük. Értelemszerűen anappali életmódú élőlények szemében a csapok vannak többségben. Az emberi szem két "filmre" dolgozik. Egy fekete-fehérre és egy színesre. Ez teszi lehetővé, hogy mind nappali, mind éjszakai fényviszonyokhoz elég jól alkalmazkodjunk.

A pálcikák a fény intenzitásra érzékenyek, a három csaptípus pedig felépítésüknél fogva a különböző hullámhosszúságú fény intenzitására (ibolya, zöld, sárga). A fotoreceptorok inhomogén módon helyezkednek el az ideghártyán. A sárgafolt csak csapokat tartalmaz, távolodva a periféria felé csökken a csapok száma és növekszik a pálcikáké. A kép a sárgafoltra fókuszálódik. Az itt kialakult struktúra a színlátást és éleslátást biztosítja. A perifériális eloszlás pedig a mozgásérzékelés és a kontúr, éjjeli látásért felelős. A fotoreceptorokat már elektromos impulzusok hagyják el, ezek a jelek jutnak a gyűjtősejtekbe és a ganglionsejtekbe.

És itt található az az "on-fly" működésmód amit említettél. A ganglionsejtek speciális feladatokat látnak el. A szemből származó idegi kép előfeldolgozásában van nagy szerepük. Ez nagyon sokrétű, de megemlíteném pl. a kontúrdetektálást, alakfelismerést, "képkorrekciót", dinamikus felbontást. Egy másik fontos jelenség az "adattömörítés". A ganglionsejtek által fogadott idegi jelek a látópályán már tömörítve jutnak a látókéregbe. Korábban már írtam róla, hogy az agy több területén jelennek meg a szemből származó információk. Még egy lényeges dolgot említenék: a bal és jobb szem látópályája részlegesen kereszteződik. Minkét szem azonos oldali ideghártya területéről származó idegi impulzusok, az azonos oldali agyfélteke látókérgébe jutnak. Ennek a bonyolult struktúrának köszönhető többek között a kiváló mozgáskordinációnk, jó tájékozódóképességünk.

Hogy objektumot kap-e az agy... Ez egyelőre talány. Mint ahogyan az is, milyen módon generálódik a külvilág modellje az agyon belül.

Miért tűnik lehetetlennek a képpont megtalálása a másik képen? A legfőbb nehézség, hogy kb 10^9 nagyságrendű műveletet kellene elvégezni. A robot mozgása közben a valós idejű feldolgozás óriási teljesítményt ígényelne, a tervezett robotunk pedig nem bír magával vinni egy szuperszámítógépet. A kisebb, de nem elhanyagolható probléma pedig az, hogy egyedi elemeket vizsgálva rengeteg hibás találatunk lenne az egyezőségre.

Mi a megoldás?

Gondoljuk át, hogyan lehetne először is a műveletszámot csökkenteni. Ha biztosak lennénk abban, hogy a bal és jobb oldali képek sorai azonos sorpozícióban vannak, akkor az elmozdulást elégséges lenne csak a soron belül keresni. Máris csökkentettük a műveletszámot kb 10^6-ra. Hát nem egyszerű?!

Mi a helyzet a hibás találatokkal? Ha nem egyedi pontokat, hanem képmátrix csoportot hasonlítunk össze, akkor a hordozott információ komplexebb a kép meghatározott részletére. Ennek a hibás egyezési valószínűsége nagyságrendekkel kisebb mint az egyedi pontoké.

De most nézzük meg mindezt konkrét példán keresztül. A dolgozószobám asztalán összeállítottam egy teszt jelenetet, így a 30.,31.,32. ábrák tartalmát valós környezetben vizsgálhatjuk. (igazából véve eléggé kaotikus egyébként is az asztalom állapota)


33. ábra

A leendő robotszemeket két webkamera alkotja. (34.,35.,36. ábra) A felhasznált típus teljesen lényegtelen, én két közepes minőségű, USB webkamerát alkalmaztam. A kamerákat egy ideiglenes hordozóhoz rögzítettem úgy, hogy a fókusztávolságuk 100 mm legyen. A bázisvonal magasságát megemeltem a "talajhoz" viszonyítva. A térbeli objektumok és a bázisvonal felezőpontjának távolságát rögzítetem, mely értékek a 33. ábrán leolvashatóak. A tesztjelenet képi megfelelői, a bal és jobb oldali kamera látószögéből, a 37. ábra felső két képén látható.

34. ábra

35. ábra

36. ábra

37. ábra

Jut eszembe közben... számtalan elmélet és módszer létezik a képfeldolgozás témakörében. Eszemben sincs cáfolni bármelyik felmerülő ötletet is... Egyszerűen már letettem a voksom e mellett, mégpedig azért, mert a további navigációs koncepciókba nagyon jól illeszkedik. A sárgarigó által felvetett hadver megoldást pedig azért nem követem, mert egy mindenki számára elérhető webkamerára alapoztam a megoldást. Valóban, a fejlettebb rendszerek (és persze drágábbak) már a kamerában megkezdik a képfeldolgozást.

Na, akkor most jön az érdekes rész!
Lássuk mihez kezdünk a kapott képekkel!

En ezt a computer vision tutorialt olvastam el:
Bővebben: Link
eleg alapszinten irjak le benne az alapokat.
De nekem az a bajom, hogy azt sem tudom hogy hogyan (milyen programokkal stb.) kellene elkezdeni egyaltalan egy ilyen kepelemzo algoritmust lekodolni.
A peldakban a RoboRealm celprogramot hasznaljak. Egy ilyen celprogrammal sokkal konnyebb a kepfeldolgozast megoldani.
Azt tudom hogy vannak mas kepfeldolgozast segito konyvtarak bizonyos programnyelvekhez, de ezekrol nem sokat tudok...
Giants, te milyen programnyelven fogod a robotod fejleszteni?

A képeket szemügyre véve több jellemző is felfedezhető. Egyik, a számunkra elsődleges dolog, hogy jól látszik a képeken a diszparitás. A közelebbi objektumok képpontjai nagyobb diszparitást mutatnak, mint a távolabbiaké. Ez az elméletünk szempontjából bíztató eredmény. A másik szembetűnő dolog, hogy a képek között vertikális elcsúszás látható. A képek közötti eltérés - ami nem a diszparitásból ered - viszont meglehetősen befolyásolják a képek felhasználhatóságát. Ezek a jelenségek jól megfigyelhetőek a csésze pereménél.

Hogy egyszerűsíteni tudjuk a képfeldolgozás folyamatát, először transzformációt kell végrehajtanunk a képeken, hogy kiküszöböljül a belső és külső zavaró tényezők hatását. Ilyen belső tényező a kamera mátrix és a torzítási paraméter. A külső tényezők pedig a két kamera kapcsolatában megjelenő forgatási mátrix, eltolási vektor. Ezen kívül még több figyelembe vehető paraméter is létezik. A képtranszformációhoz, amely a két kép soronkénti egybevágóságát biztosítja, egy kalibrácós eljárás alapján meghatározott korrekciós adatokat használunk fel, amelyek az előbb felsorolt zavaró tényezők alapján jellemzik a kamerarendszert és a továbbiakban - ha fix a felépítés - állandónak tekinthetők.

A kalibrációs eljárás alapja, hogy a látótérben különböző pozíciókban kell kalibrációs képeket készíteni, az így létrehozott referencia képek szolgáltatják a számítás alapadatait. Ehhez a művelethez egy sakktábla mintázatú objektumot használunk fel. Lényeges, hogy a folyamat alatt mindkét kameraképen teljes egészében látszódjon az objektum. Zhang és Sturm voltak akik ezt az eljárást kidolgozták és publikálták. A képek feldolgozása monokromtaikus alakban történik, ehhez a kamera R,G,B képeit először át kell alakítani. Az átalakításhoz egy szabványos eljárást alkalmazunk, amely az Y jel értékét az R,G,B jelek súlyozott átlagából származtatja a 38. ábra a. egyenlete szerint.

38. ábra

A folyamat eredményekét kapott mátrixok felhasználásával a rectifikáció olyan képpárt hoz létre, amelyben az egyes sorok megfelelősége adott, és a külső és belső zavaró tényezők hatása korrigált. A 37. ábra alsó két képe már a rektifikáció eredménye. Látható, hogy a referencia vonalként behúzott szakasz mindkét képen azonos képsorban helyezkedik el. Így már alkamas a képpár a megegyező képelemek keresésére.

Most tudok pontosan válaszolni a Fizikus kérdésére. A bal és jobb oldali képeken az egyező képelemek keresése egy úgynevezett SAD (Sum of Absolute Differences) algoritmussal valósíthatóak meg. (38. ábra b. egyenlet) A kereséshez, a referencia képen egy kiválasztott sorban a keresett képelem szűkebb környezetében létrehozunk egy ablakot, amely a képpontokból azonos sor- és oszlopszámú mátrixot képez. Ez tipikusan 5x5, 7x7 képpont. Ez lényegében egy korrelációs technika, ahogyan Gafly már említette. Az algoritmus a mátrix elemeiből képzett csoportjellemzőt keresi a jobb oldali képen, miközben az ablak "végigcsúszik" a sorban. Ahol a hibák abszolút összegének minimuma van, ott maximális az egyezés valószínűsége. A SAD ablak méretétől függően lehet finomítani a mélységi információk kiterjedését. A találatok természetesen tartalmazhatnak hamisakat is. Ennek kiszűrésére például egy elenkező irányú keresést is végezhetünk. A találati helyek diszparitás értéke jelemzi az adott pont mélységi információit. A triangulációs számítások végeredményeként képezzük a diszparitás értékeiből a mélységi mátrixot, amely már valós dimenziójú (pl. mm) információt nyújt az adott képpont bázisponttól való távolságáról. A 39. ábra mutatja be a SAD eljárás lényegét. A bal felső kisebb kép a bal oldali kép SAD ablaka.

39. ábra

A jobb oldali képen végigcsúszó ablakot hasonlítjuk a referencia ablakhoz. Számítások nélkül is látszik a példán, hogy a jobb oldali és az X ablak közül melyik illeszkedése nagyobb. A két képelem távolsága a 0 ponttól L1 a bal és L2 a jobb oldalon. A két érték különbsége az adott képpont diszparitása. Az X ablak referencia ablaktól való eltérése nyilvánvaló, de itt jegyezném meg, hogy a homogén, kevésbé texturált képek esetében ez a módszer nem alkalmazható hatékonyan. Ezért különböző transzformációkkal növeljük a kép texturáltságát.
Összegezve a képfeldolgozás folyamatát az alábbi blokkvázlaton láthatjátok.

40. ábra

Hartley R., Zisserman A. Multiple View Geometry in Computer Vision, 2003
Gary B., Adrian K. Learning OpenCV Computer Vision with the OpenCV Library, 2008
Robert L., OpenCV 2 Computer Vision Application Programming Cookbook, 2011
Taylor & Kleeman, Visual Perception and Robotic Manipulation, 2006
David V., Machine Vision, 1991
Stefan F., Robot Vision, 2005

Kiindulásnak ezeket tudnám ajánlani.

Elég sok gépi látással foglalkozó program fellelhető. Az egyik ismert szoftver a Computer Vision System Toolbox for MATLAB & SIMULINK. Fejlett környezetet biztosít a leggyakrabban alkalmazott képfeldolgozásokhoz. A függvénykönyvtára és a windows operációs rendszer API függvényeinek lehetőségei hatékonyan támogatják az ilyen irányú fejlesztéseket. Én például modellezésre használom elsősorban.

Talán a legismertebb az OpenCV (Open Source Computer Vision) függvénykönyvtár. Nyílt forráskódú, támogatja a C++, C, Python, Java platformokat valamint futtatható Windows, Linux, Android, Mac operációs rendszerek alatt is. Az OpenCV-ben minden megtalálható ami csak szóba jöhet a képfeldolgozás kapcsán. Kifejezetten real-time működésre tevezték. Az összes leírásomban szereplő művelet megfelelője megtalálható benne. Így van egy jó hírem! Nem kell bajlódnod az algoritmusok megírásával.

Mivel ez önmagában "csak" egy library, úgy szükséges hozzá a testreszabott fejlesztői környezet amely szinte tetszőleges lehet. Egy feltétele van, hogy a választott operációs rendszer alatt képes legyen a szükséges nyelvi platformot támogatni. Például nagyon jól lehet vele dolgozni Windows alatt a CodeBlocks IDE-vel, és az MS Visual Studio-val.

Egyébként szerintem nem is kérdéses, hogy melyikkel dolgozom.... én OPERÁCIÓS RENDSZERT használok.

A működési környezet mindig meghatározó a fejlesztői oldalon is. Az robothoz használt hardveren esélyem sem lenne megvalósítani a navigációs funkciókat más operációs rendszerrel, mint Linuxal. Mivel a robotban Debian fut, így én Linux-on, C-ben és Python-ban dolgozom Qt alatt. Persze a demonstrációs képek kidolgozásánál nem ezt használtam, hanem a VS-t.

Tehát: Debian-> Qt-> OpenCV-> C

A fentebb felsorolt könyvek közül kettő éppen az OpenCV-vel foglalkozik.

Most egy válaszút elé érkeztünk. A látás elvi ismertetése után folytathatnám a tényleges megvalósításával is, úgy mint például a részprogramok ismertetésével. Egy másik lehetőség, hogy a továbbiakban hasonló elvi működési szinten végigvesszük az inerciális érzékelők és a szonár alkalmazási módját is és csak aztán térünk rá a programozásra.
Melyiket javasoljátok? Esetleg valami más sorrend?
Fizikustól függetlenül mindenképpen szólni akartam a fejlesztői környezetről is. Ha jónak tartjátok leírom a Debian, Qt, OpenCv teljes telepítésének lépéseit. Így a későbbiekben közvetlenül is ki tudjátok próbálni a programrészeket.

Szia Giants!
Szerintem jobban kovetheto lenne, ha a tobbi erzekelovel folytatnad, es miutan minden hardverelem mukodesevel mindenki tobbe-kevesbe tisztaban van, akkor azutan kovetkezne a programozas es a feladat gyakorlati megvalositasa...

Annyira nem osztom ezt a nézetet, mert ha már idáig eljutottunk, akkor legalább használjuk is fel az eddigieket, meg ami ebből következik. Nem csak ebben a projektben lehet hasznosítani az eddig elmondottakat, és legalább nem is ugrálnánk a témák között.
Viszont mielőtt megvádolna valaki: engem is érdekel a többi rész is

És ha már feljött, én szeretném látni, hogy itthon mit kell felraknom ahhoz a linuxomra, hogy ilyen dolgokkal tudjak játszadozni.

Ne menjünk bele abba a kérdésbe hogy mi az oprenccer, mert sokan kaptak már ezért bicskát a bordájuk közé. Ubuntu rulz

Én is arra szavazok, hogy amit leírtál elméletben, azt próbáljuk ki a gyakorlatban, addig ne menjünk tovább, amíg nem tudjuk, hogy egyáltalán az elmélet valóban működik vagy sem.

Ajánlhatok egy kompromisszumot? Arra gondoltam, hogy a sztereó képfeldolgozással kapcsolatban leírom a fejlesztői környezet telepítését és bemutatok néhány példát is (pl azt amiről beszéltem eddig). Ezután pedig áttérek a többi eszközre. Végül is így átvesszük az összes érzékelőt mielőtt sor kerülne a robot programjának összeállítására. Ha ez így elfogadható, akkor ezel folytatom a hétvégén.

G

Ámen!

Kicsit sikerült megint nagyon eltűnni..

Annyira nem
Már visszatérőben vagyok, kis türelmet és elnézést kérek.

Szia Giants!

Nem kell elnezest kerned, most mindenki ugyis a Magyarokamarson-ra keszul.
De azert mar tukon ulve varom a folytatast...

Elnézést kérni valóban nem kell, elvégre még Giants tesz nekünk szívességet azzal, hogy tágítja a buránkat, amit ezúton is köszönök!
Ámde! Hogy mindeni a versenyre készül, az kicsit túlzás. Igaz, hogy még én is a magam roverjét építgetem, de nem a versenyre
Én nem is tűkön, de egyenesen tűpárnán várom a folytatást!

UP?!?

Relatív

Számíthatunk valami megnyilatkozásra mostanában?

Sziasztok,

megelőztél a kérdéseddel... Igen, egy héten belül folytatom. És szó nincs holmi "kinyilatkoztatásról"...

Lefoglalom a széket jó előre! Nekem ez már izgalmasabb mint az olimpia

Üdvözlök mindenkit,

igaz, a mai nap nem az a bizonyos februári hétvége amelyre a folytatást igértem..

Egy kis személyes információ és a reklám helye: a munkám eléggé lekötött ahhoz, hogy érdemben foglalkozni tudtam volna a robotunkkal. Több telemetriai projecten dolgoztam intenzíven, mely alkalmazásfejlesztések az ACE-en (ÉSZ) alapulnak.

Már harmadik éve dolgozunk munkatársammal az ACE (Adaptive Control Environment) nevű rendszeren. Rövid lényege, hogy magába integrálja a fellelhető kommunikációs platformokat - GSM, réz-, optikai kábel, rádió (XBEE, ZIGBEE MESH network) stb., az adott platformra illeszthető kommunikációs protokollokat - ipari szabványos és szabványon kívüli (PROFIBUS, MODBUS TCP, MODBUS RTU) stb., felhasználói interface-eket (GUI, HMI stb.), Soft-PLC modult, adatbázis szervert.

Létrehozásakor alapvető célunk volt egy rugalmasan alkamazható hardver-szoftver együttes kialakítása. A rendszerünk filozófiája szakít a hagyományos elvekkel és teljesen nyitott architektúrát képez az ipari vezérlők és informatikai eszközök integrációjából. Számos előnnyel rendelkezik a tipikus hard PLC piactársaival szemben.

A hardver független, PLC funkciók leképzésére szolgáló, valósidejű futtató környezete az ipari PC-t nagyteljesítményű PLC-vé alakítja át. A fejlesztői környezet nyújtotta lehetőségeknek köszönhetően a PLC-vezérelt gépek és berendezések programozásához, üzembe helyezéséhez és karbantartásához szükséges összes funkció rendelkezésre áll. A skálázhatósága egyedülálló. Korlátlan TAG-szám, I/O csatorna stb. használható. A chip szintű intervenciótól kezdődően a több tízezer változót kezelő ipari rendszert lehet létrehozni. Az architektúra lehetővé teszi a szükség szerinti erőforrásbővítést, melyek decentralizáltan (földrajzilag) is elhelyezhetőek. Költséghatékonyság szempontjából is páratlan tulajdonságokkal rendelkezik. A már meglévő PLC-s vezérlésekre egyszerűen implementálható. Minden eleme szükség szerint távfelügyelhető, a teljes architektúra transzparens, tetszőleges helyről elérhető (PC, Notebook, okostelefon stb).

A fejlesztői felületen kívül rendelkezik runtime környezettel is amely támogatja a WEB bázisú HMI létrehozását. A rendszerbe integrált adabázismotor real-time adatrögzítést tesz lehetővé. Grafikus megjelenítési és szinte korlátlan feldolgozó képessége tetszőleges feladat megoldására akalmassá teszi. A beépített objektumkészletén kívül, feladatspecifikus osztályok, objektumok beágyazására is lehetőséget nyújt. Tulajdonságait hatékonyan lehet felhasználni szakértői rendszerek létrehozására, öntanuló szabályozó rendszerek kialakítására, integrálva a valós fizikai környezetet az algoritmusok bázisát képező modellekbe.

Remélem nem köveztek meg a reklámért...

Említettem mindezt azért is, mert biztosan vannak érdeklődők a fent érintett témakörben, akikkel igény esetén megosztanám a tapasztalatainkat.

Bevallom nagy levegőt kell venni, hogy ismét megtaláljam a fonalat. Jó hír, hogy a fonál vége megvan, csak fel kell venni: az utolsó elképzelés szerint ismertetem az OpenCV telepítését, alkalmazási példákkal együtt.

G

Megvallom őszintén, a felsorolásból csak a jéghegy csúcsát látom, vagy azt is csak látni vélem. Ha jól sejtem, akkor ez olyasmi, mint amit a seti program is csinál, csak nem kizárólag CPU-k felett rendelkezik, hanem minden féle pc-s és nem pc-s perifériákkal is? Természetesen engem is érdekel a téma, lesz neki saját topic-ja?

Amit összehoztok díjazom, de nem féltek hogy esetleg egy Skynet lesz belőle?

Gombolyítsunk!

Szia! Abszolút érthető a kezdeményezés, de például én mint egyszerű fejlesztő, hol tudok ehhez hozzáférni és mennyibe kerül?

Sziasztok! Bocsánat a belekotyogásért, de: Én biztosan többszálú keresést hajtanék végre többfajta algoritmussal egyszerre. És csak az egyező találatokkal foglalkoznék tovább, valamint pontoznám az algoritmusok találati sebességét. Ez egy jól bevált evolúciós módszer..... A végén a leggyorsabb és legpontosabb marad, a többi mehet a vágóhídra. nyilván nagy műveleti sebesség kell, de ha jó az algoritmus, akkor már csökkenthető a feldolgozási sebesség - egészen a legjobban illesztett feldolgozási sebességig (algoritmus/sebesség páros). Tehát csak a megfelelő módszer megtalálásához kell nagy műveleti sebesség - a tényleges feldolgozáshoz már nem.

Az OpenCv telepítése Ubuntu 10.04 LTS-re

Az eljárás kisebb eltérésekkel más disztribuciók alatt is működik. A környezet megválasztásánál fontos szempont volt, hogy debian alapú OS-t alkalmazzunk, mivel a majdani futtatókörnyezet is debian alapú lesz. Ezzel számos esetleges problémának vesszük elejét.

A telepítés egyes lépéseit nem részletezném, ha kérdésetek lesz térjünk vissza rá.

A telepítési folyamat alapfeltétele, hogy rendelkezzünk egy működő operációs rendszerrel. Az OpenCV telepítése a függőségek előzetes kielégítése után lesz sikeres. Ehhez a következő lépéseket kell megtenni:

A g++ GNU fordító telepítése opcionális

$ sudo apt-get install g++

az esetleges korábbi ffmpeg eltávolítása

$ sudo apt-get remove ffmpeg x264 libx264-dev

opencv függőségek telepítése

$ sudo apt-get install libopencv-dev build-essential checkinstall cmake pkg-config yasm libtiff4-dev libjpeg-dev libjasper-dev libavcodec-dev libavformat-dev libswscale-dev libdc1394-22-dev libxine-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev libv4l-dev
python-dev python-numpy libtbb-dev libqt4-dev libgtk2.0-dev

ffmpeg letöltés

$ wget http://ffmpeg.org/releases/ffmpeg-0.11.1.tar.bz2

ffmpeg kibontás, telepítés

$ tar -xvf ffmpeg-0.11.1.tar.bz2
$ cd ffmpeg-0.11.1/
$ ./configure --enable-gpl --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-nonfree --enable-postproc --enable-version3 --enable-x11grab
$ make
$ sudo make install

?video for linux? letöltés

$ cd ..
$ wget http://www.linuxtv.org/downloads/v4l-utils/v4l-utils-0.8.8.tar.bz2

v4l telepítés

$ tar -xvf v4l-utils-0.8.8.tar.bz2
$ cd v4l-utils-0.8.8/
$ make
$ sudo make install

opencv 2.4.2 letöltés

$ cd ..
$ wget -O OpenCV-2.4.2.tar.bz2
$ http://sourceforge.net/projects/opencvlibrary/files/opencv-unix/2.4...wnload

opencv fordítása, telepítése

$ tar -xvf OpenCV-2.4.2.tar.bz2
$ cd OpenCV-2.4.2
$ mkdir build
$ cd build
$ cmake -D CMAKE_BUILD_TYPE=RELEASE ..
$ make
$ sudo make install

linux környezeti változók beállítása

$ sudo nano /etc/ld.so.conf.d/opencv.conf

adjuk hozzá az utolsó sorban

/usr/local/lib

majd configuráljuk a libraryt

$sudo ldconfig

még egy utolsó módosítás ami gondoskodik a könyvtár eléréséről

$ sudo gedit /etc/bash.bashrc

adjuk hozzá az utolsó sorban

PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
export PKG_CONFIG_PATH

Ezzel befejeztük a telepítés. A beállítások csak újraindulás után lesznek érvényesek így a gépet újra kell indítani.
Ezután kipróbáljuk a telepítés sikerességét. Itt az opencv példa fájljait másoljuk egy tetszőleges könyvtárba, majd lefordítjuk azokat.

$ cd ~
$ mkdir openCV_samples
$ cp OpenCV-2.4.2/samples/c/* OpenCV_samples
$ cd OpenCV_samples/
$ chmod +x build_all.sh
$ ./build_all.sh


Fordítás után kipróbálhatjuk indíthatjuk a tesztet

$ ./facedetect --cascade="/usr/local/share/OpenCV/haarcascades/haarcascade_frontalface_alt.xml" --scale=1.5 lena.jpg

A fenti programrész egy tetszőleges jpg formátumú képen detektálja az arcot. A lena.jpg-t helyettesítve egy saját fotóval meggyőződhetünk a működés ?valódiságáról?.

További tesztet jelenthet az alábbi példaprogram fordítása:

Hozzunk létre egy image.cpp fájlt és másoljuk be az alábbi kódot



az alábbi formában fordíthatjuk:

$ g++ `pkg-config opencv --cflags` image.cpp -o image `pkg-config opencv --libs`

A továbbiakban parancssorból így fordíthatunk minden programot.

A program argumentumában megadott fájlnévvel indíthatjuk:

$ ./image lena.jpg

Mire volt jó mindez? Nem volt szándékomban programozói topikká alakítani az eredeti témát, de a továbbiakban szükségünk lesz megfelelő szoftvereszközökre is. Az opencv egy olyan lehetőséget ad a kezünkbe, mellyel igen széles keretek között lehet képmanipulációt megvalósítani. Többek között a korábban említetteknek megfelelően, segítségével fogom előállítani a sztereó kamerákból nyert képek alapján a mélységi mátrixot.

A telepítés megkönnyítése érdekében mellékelek egy script-et, amelyet elindítva a fenti műveletsort végrehajtja az opencv telepítésével bezárólag. Manuálisan csak a környezeti beállításokat kell megcsinálni.

Szia,

mint korábban is utaltam rá, én az opencv képfeldolgozó könyvtárat választottam. Ebben minden szükséges függvény megtalálható. Fejlesztői évek munkáját és a fellelhető legjobb algoritmusokat "rakták" bele. Mivel nincs szándékom egy fél életet átfogó fejlesztésbe belekezdeni, elfogadom az általa nyújtott lehetőségeket. A project célja egy lehetséges út megmutatása, amely szakaszainak egyéni átírása szabadon választható. A végrehajtási sebességhez fűzném hozzá, hogy érdemes megfigyelni az arcdetektálás végrehajtási idejét. Néhány ms-ot vesz igénybe. Azt jól látod, hogy a megfelelő stratégia megválasztásával csökkenthető a feldolgozási idő ( és nem a sebesség )