Akik tudják, mit takar az OpenCV, azoknak nem kell bemutatnom: [link]

Most röviden leírom, milyen érdekes dolgokat fedeztem fel pár függvénnyel kapcsolatban.

Az OpenCV-ben rengetek függvény van sok mindenre, de előfordulhat, hogy mi szeretnénk kézzel valamit számolni az egyes pixeleken, de OpenCV-ben nincs rá függvény.

Először is, az OpenCV teljesítményét kézzel nem fogjuk elérni, de néhány dolog valamiért pluszba belassít.
(OpenCV teljesítmény: egyszer végre tényleg bele kéne másznom a kódjába, hogy hogyan valósítják meg ezt, mert nagyon jól jönne )

Itt egy példa, végig akarunk menni minden pixelen:

Itt egy kép:
cv::Mat imgmat(cv::Size(640,480),CV_8UC3);

Ezen akarunk végigmenni:
for(int row=0; row<imgmat.rows; row++)
{
for(int col=0; col<imgmat.cols; col++)
{

}
}

Két féle módon férhetünk hozzá az adott pixelhez:
1. a beépített függvény:

Olvasás:
unsigned char b = imgmat.at<cv::Vec3b>(row,col)[0]; // blue
unsigned char g = imgmat.at<cv::Vec3b>(row,col)[1]; // green
unsigned char r = imgmat.at<cv::Vec3b>(row,col)[2]; // red

Ez a kis animáció kb. összefoglalja, milyen pofákat vágtam

Szerencsére a többi nem volt már olyan vészes.

Bejegyzés késett 11 napot, de sebaj.

Új hordozható számítógépet kellett vásárolnom, mert úgy néz ki, az elkövetkezendő 2 évben (ha minden jól megy), ingáznom kell majd Bp. és Szeged között.

A követelmények a követezők voltak:
+ Hosszú akkumulátor üzemidő
+ Könnyű gép
+ Kicsi gép
+ És a külseje se legyen azé ronda

Ezeknek felelt meg az Asus 1215B.

Sem a netbookot magát, sem a teljesítményét nem mutatom be, mert ezt már két PH! cikkben is megtették:
[link1] [link2]

Épp ezért lett személyes bejegyzés, mert ez egy gyakorlatilag egy élménybeszámoló lesz.

Elég kalandosan érkezett meg a csomag. Házhoz szállítást kértem, mert nem akartam ezért 1 nap szabit kivenni, és kedvem se volt elmenni a cég telephelyére, hogy személyesen átvegyem.

A rendelésnél direkt leírtam, hogy a megadott szállítási cím a munkahelyem, és egész biztosan 10:30 és 18:00 között leszek ott.

Pár napi szenvedés van ebben a screenshotban.
Részletek: LGPL-s FFmpeg-t kellett az OpenCV-vel megetetni fordításkor linux alatt, de nem nagyon akart sikerülni, de végre rájöttem a nyitjára.

Pár kód későbbre, mert továbbra se vagyok teljesen kész.

GTK teszt:

#include <iostream>
#include "cv.h"
#include "highgui.h"

using namespace std;

int main (int argc, char *argv[])
{
cout << "Hello world!" << endl;
cvNamedWindow("g");
cvWaitKey();
cvDestroyWindow("g");
return 0;
}

FFmpeg teszt

int main()
{
cvNamedWindow( "Example2", CV_WINDOW_AUTOSIZE );
CvCapture* capture = cvCreateFileCapture( "/home/elrood/Documents/video.avi" );
IplImage* frame;

while(1) {
frame = cvQueryFrame( capture );
if( !frame ) break;
//cvSaveImage("/home/elrood/Documents/foo.png", frame);
cvShowImage( "Example2", frame );
char c = cvWaitKey(33);
if( c == 27 ) break;
}

A következő néhány bejegyzés a LeJOS-nak lesz szentelve.

Pár szóban mi is ez az egész:
A LeJOS egy kicsi virtuális gép, amit a Lego NXT-re portoltak. A LeJOS előnyei (forrás a weboldal, had ne fordítsam le ):

+ Object oriented language (Java)
+ Preemptive threads (tasks)
+ Arrays, including multi-dimensional
+ Recursion
+ Synchronization
+ Exceptions
+ Java types including float, long, and String
+ Most of the java.lang, java.util and java.io classes
+ A Well-documented Robotics API

A LeJOS használatához firmware-t is kell majd frissíteni (későbbi bejegyzés).

A LeJOS mellett a további firmware-k és programozási eszközök:

Gyári fw. + (National Instruments) NXT-G

Forrás: [link]

Véget ért a XXX. Jubileumi Országos Tudományos Diákköri Konferencia Informatika Tudományi Szekciója, amin én is részt vettem mint előadó. A program. Mi hétfő 15:40-kor adtunk elő.

A helyszín [+]

[+]

Végre valamit sikerült elvégezni . Aki ismer tudja miről beszélek.

Állásinterjúkra már nagyon kíváncsi vagyok.

Újra itt . Folytatódik a 57 napja leadott szakdolgozat további fejlesztése.

GAMF-t befejeztem, diplomára jeles kerül, irány a munkaerőpiac! (jaj )

KÉPAF2011-re a cikk: [pdf]

A távolság probléma meg lett oldva, ennek nagyon örültem (lásd előző poszt).

Fejmozgatás

A szakdolgozathoz 3 kérdést kaptam, ezek közül az egyik, hogy mi történne, ha nem lehetne mozgatni a robot fejét.

Először egy kis ismétlés:

Lényegében a bal képen található (x0,y0) pixelhez úgy keressük meg a párosítást, hogy elindulunk a jobb oldali kép (x0,y0) pixeléből, és végignézünk egy tartományt, hogy melyik pixel illik rá legjobban a bal oldalon található pixelre.
Két fontos paraméter látható a képen:
minDisparity: (x0,y0) ponthoz mennyire térjünk el vízszintesen (ezt a továbbiakban nem bátjuk)
numberOfDisparities: hány pixel legyen az a tartomány, amin keresünk. (továbbiakban NofD)

Ez a bejegyzés több nap eseményeit meséli el, csak már nem emlékszem, mit mikor csináltam.

Ha még emlékeztek rá, a múltkori bejegyzésben azon agyaltam, hogy a tényleges és számított távolságok miért nincsenek még köszönőviszonyban sem.

Három ötletem volt a hibára:
1. kalibráció
2. a disparity map -> 3D megvalósításnál valami nem stimmel az OpenCV-ben
3. Vetítési hiba

Berakom megint a számolt és tényleges távolságokat:

Elkezdtem a próbálgatást, először a vetítési hiba jelenséget akart leellenőrizni magasabb felbontással. Eredetileg 320x240-es képeket használtam, most kipróbáltam 640x480-on. A sebesség se volt borzasztó lassú.
Ehhez az elmozdulásokat számoló BM függvényt is újra be kellett állítani.

Eredmény:

Ha megfigyelitek, akkor látható, hogy szinte teljesen ugyanaz a 320x240-en mértekkel, így vetítési hiba kizárva.

Próbálgattam a kalibrációt, mert rendes fizikai pontok 3D-s adatait kell megadni kalibrálás előtt (gondoltam én, de az egy másik függvény és másra való). Itt is elszenvedtem 1-2 napot, de nem sikerült használható új kalibrációt csinálnom.

December 10., még 0 nap

Lejárt az idő, végre, szakdoga leadva, befogadva, most már csak azon kell izgulni, nehogy elkeverjék .
Kemény 4 hónap volt, főleg leírni ezt az egészet úgy, hogy az előző két hétben betegeskedtem.

A blogolás bevált, így emlékeztem a bakikra, amiket bele kell írni a dogába és a teszteredmények publikálása is hasznos volt, mert így megvoltak.
Nem is beszélve néhány képernyőmentésről, amit egyszerűen nem találok a vinyón, de itt megvoltak.

Tehát csak tanácsolni tudom, hogy aki diplomamunkát, szakdolgozatot ír, az blogoljon (nyilvánosan, vagy csak magának).

A szakdolgozatból tervezek ide is egy rövidebb cikket, de azt majd február fele.

Bár szakdolgozat leadva, a történetnek még nincs vége!

A dolgozat egy része el lett küldve cikként a KÉPAF 2011 konferenciára, ami január 25-28. között lesz (persze pont ezen a héten van a záróvizsga...).
A cikket befogadták, de javítani kell még rajta és pár kérdést meg kell felelni.

Október 21., még 49 nap

Hétfőn sikeresen félreértettem a konzulensemet. Nem azt mondta, hogy csináljam meg jobbra, majd balra a 3D-s ponthalmazt, majd abból szűrjek, hanem azt, hogy fogjam a két disparity mapot és abból szűrjek, majd a bal oldali képre csináljam meg a 3D-s ponthalmazt.

A jobb kép 3D-s ponthalmazával az a baj, hogy gyakorlatilag nem nyertem semmit azzal, hogy ki lett számolva. Látszódik persze minden ami kell, de nincs kapcsolat a bal és a jobb halmaz Z értékei között (ami a távolság), nem lehet felhasználni szűrésre. Ha mégis kézzel belövöm a szűrést, akkor bármilyen változtatásnál újra ki kéne kézzel számolni mindent és újra belőni.

Az a terv, hogy "megengedő" BM-t eresztek rá a jobb és a bal képre, majd a nem egyező disparity értékeket törlöm, így a fals adatok kiszóródnak.

Először is tartok egy kis oktatást .

Miért is csinálom ezt.

Ugye mi is így látunk, hogy a két szemből érkező képekből az agyunk rakja össze a 3D-t. Ha közelebb rakjuk az ujjunk a szemünkhöz és pislogunk felváltva, akkor látjuk, hogy jobban "mozog" az ujjunk két pislantás között, míg ha távol van, kevésbé. Magyarán minél nagyobb az elmozdulás, annál közelebb van a tárgy.

Október 20., még 50 nap

Az 15. bejegyzésben írtam, hogy balra rosszul lát és ezzel kezdeni kell valamit. Közben rájöttem, hogy azzal nem lehet mit kezdeni, hiszen a kamerák rögzítettek és jobbra is ez a probléma, hogy van egy sáv, amire nincs illesztés.

Több megoldási lehetőség kínálkozik:
1. A robot akkor fordul, mikor még biztonságosan megállapítható, hogy mehet-e balra vagy jobbra, ha szemben akadály van.
Hátrány: szerintem elég csúnyán néz ki, hogy a tárgy előtt nagyon messze már fordul, kicsi teremben meg körbe-körbe forgolódik.
2. A robot használja a fejét, így közelebb engedhetem a tárgyhoz és mégis biztonságosabban megállapítható merre induljon.
Hátrány: konzulensnek nem tetszik .
3. 1. pontban leírtak a javítása. Eddig csak a bal képre volt megállapítva a 3D-s koordináták, most meglesz állapítva a jobb oldalra is, így kicsit biztosabb lesz a 3D-s térkép megállapítása.
Hátrány: ugyanazt mint az elsőnek, csak kicsit talán közelebb lehet engedni.

3. pontbelit el is kezdtem tesztelni. BM-mel van egy baj, csak balra illeszt. Szerencsére nem volt túl nagy probléma megcsinálni az ellenkezőjét. Felcseréltem a két képet a függvényben, és kicsit alakítottam a beállításokon:

BMState->minDisparity=-90;
BMState->uniquenessRatio=60;

Október 18., még 52 nap

A robot következőt fogja csinálni: megy, míg túl közel nem kerül egy tárgyhoz, aztán elfordul valamerre, aztán tovább halad. Megpróbálok egy elég nagy tesztpályát készíteni, ami teli lesz szórva dobozokkal.

Az adatok megfelelőek, megkaptam a zöld jelzést, most már pontos adatok alapján kidolgozhatom azt az algoritmust, ami a fenti cselekvést meg tudja csinálni.

Persze ezzel vannak gondok, mert jelenleg a bal képre készül el a 3D-s ponthalmaz, ezért balra rosszabbul lát. A másik probléma, hogy a kamerák távol vannak, kicsi a látószög. E két nagyobb probléma miatt a robot kénytelen lesz látványosan hamarabb fordulni.
Van két ötlet ennek a leküzdésére, majd később leírom.

Csináltam egy képsorozatot, ahol centivel szépen lemértem minden távolságot, elkezdtem a kapott OpenCV eredményeket hozzárendelni a valósághoz.

Ígértem egy olyan képet is, ahol nem merőlegesen, hanem élével szemben áll egy doboz a robottal, íme:

Október 16., még 54 nap

Feljegyzés, az 1. és 2. képsorozat 54:50-s fejpozíciónál készültek

Ma csak egy fejlesztés történt, a párhuzamosan végrehajtható dolgokat külön threadbe raktam. A sebesség fontos . Mérések holnap, mert lámpafénynél eléggé ugrálnak az eredmények, de így is látható gyorsulás. Threadbe rakáson kívül van még egy lehetőség a gyorsításra: kiszedem a megjelenítést. A rektifikált kép és a látható disparity kép előállítása is időbe telik.

VS2008 is tud szép hibákat irkálni:

Pedig a parancsot az msdn oldaláról néztem, és csak a kernel32.dll volt megadva függésnek.

Debug módban nem ilyeneket kéne feldobnia...

Október 17., még 53 nap

Hibaüzenetek folytatása, most SmartSVN:

Semmi változás előtte, program újraindításánál már jó

Október 11., még 59 nap

Csak kiderült, hogy valami nem stimmel.
A teszthez használt képekkel van egy nagy baj: a sakktábla.
Ugyanis a BM párokat keres a két kép között, a sakktábla mintái pedig ismétlődnek, így mindig a bal szélén találja meg (ha balról kezdi, nem néztem utána) a keresett pontot, hiába van az mondjuk a sakktábla jobb szélén. Pontosan ezért volt egy kupacban minden talált pont, aaaaaah.

Első körben saját képek kellettek, amiket lementek a programmal, mert robottal rohangászva nem lehet mindig ugyanolyan képeket csinálni.

Rectify és remap a menüből átköltözött ide, a képmentést egyelőre a normálhoz raktam.

Gondoltam a kép neveket a rand() nevű csoda függvénnyel teszem különbözővé, hát nem eléggé random . Később átjavítom időbélyegre.

Második körben csináltam egy külön projektet, hogy a BM és egyéb teszteket elvégezzem, mert az eddigiek teli voltak szemetelve marhaságokkal.

A terv az, hogy egyelőre megpróbálom a BM-ből kihozni azt, amit lehet. Ha sikerül, és az FPS 1 lesz vagy afelett, akkor meghagyjuk, és ha még van idő, akkor próbálom meg felgyorsítani ritka illesztéssel.

Szeptember 20., még 80 nap

Ebben a postban kicsit benéztem, OpenCV a C-s és a C++-s rész is 2.1-s: [link].

Következő lépés: A két képből 3D-s adatokat nyerni.

Október 8., még 62 nap

Visszatértem, elég sokat szenvedtem a 3D-s adatokkal eddig.
Elvileg az OpenCV-ben van egy függvény, cvReprojectImageTo3D, amivel elvileg rögtön 3D-s ponthalmaz nyerhető a cvFindStereoCorrespondenceBM eredményéből. Itt egy bizonyíték.

Sajnos nálam valami nem klappol. Most a különböző próbálgatásoknak a beállításai és eredményei lesznek felsorolva.

Először is kellett két, ami mindig ugyanaz, és van sztereókalibráció, ezért az OpenCV példák közti képet használtam. A különböző verziók között csak a változásokat írom le.