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ó
Lezajlott az ígért teszt, körülmények:
Robot frissen feltöltve, a program virtualpc-ben futó VS2008 alatt futott debug módban. BM defaulton, cvReprojectImageTo3D() van.
(Magyarázat: példa vdispre, példa pairre)
*: vdisp és pair kiszámolva
**: vdisp és pair nincs kiszámolva
Kupak
320x240Q1 | Normál | 9.1-9.5 FPS
320x240Q1 | 1 szál* | 5.3-5.5 FPS
320x240Q1 | Több szál* | 8.8-9.0 FPS
320x240Q1 | Több szál** | 8.9-9.0 FPS
Egy statikus részt nézve
320x240Q1 | Normál | 3.8 FPS
320x240Q1 | 1 szál* | 2.9 FPS
320x240Q1 | Több szál* | 3.4-3.5 FPS
320x240Q1 | Több szál** | 3.5-3.7 FPS
A sima résznél nem látható nagy változás, látszik, hogy jelenleg a feldolgozás rövidebb ideig tart, mint a képek lehívása, később ez változhat, és ott már látványosabb lesz az 1-több szál közötti különbség. Jó példa erre a kupakos teszt, ott kisebb a kép, rövidebb ideig tart a lehívás, és az 1 szál felére lassította. Megjelenítés kihagyása is ad egy kis pluszt.
Akkor elkezdődtek az új tesztek. Fogtam a régen letöltött python scriptet és átalakítottam úgy, hogy argumentumban adhassak meg filenevet és ne a kódban kelljen folyton átírogatni. Így most már bármit 3 oszlopba tudok rendezni (eddig az opencv csak CV_32FC3-t (=32bites float, 3 csatorna) rakta abba, mást nem), és be tudom egyszerűen adni a matlabnak.
Először is megnéztem, hogy ha CV_16S-be hozom létre a dispet és a 3D-s képet, akkor mit kapok. A kapott 3D-s ponthalmaz sajnos használhatatlan, marad a CV_32F.
Az előző poszt végén írt aggodalmam miatt fogtam 3D-s ponthalmazt, és kicsit átalakítottam. A ponthalmaz 2D-s mátrix, egy pontjában 3 csatornás. Eddig a cvReprojectImageTo3D() töltötte fel az egészet, így a 3 csatorna tartalma: 1.: X, 2.: Y, 3.: Z. Ezt adtam be a matlabnak és jelenítettem meg az előző postokban.
Most: Z értéke maradt, X-t és Y-t viszont kicseréltem a mátrixban elfoglalt pozícióra és így jelenítettem meg matlabbal.
Disp mátrixnál is ezt csináltam, csak az eleve 1 csatornás volt, most csináltam belőle 3 csatornásat.
Eredmények
Most csak a 1.6-s képpárt töltöm fel.
Nem forgattam el a képeket, a kép bal felső sarka 0;0-n van.
#1.6. képpár
Default BM beállítás.
Pair
vdisp
3D#1
3D#2
3D#3
disp#1
disp#2
disp#3
#1.6. képpár
BMState->minDisparity=20;
BMState->uniquenessRatio=60;
Pair
vdisp
3D#1
3D#2
3D#3
disp#1
disp#2
disp#3
Értékelés
Kisebb elmászásoktól eltekintve minden a helyén volt.
Nagy kő esett le a szívemről . Ugyanis a múltkori post végén szereplő félelmem, hogy a koordináták össze vissza vannak hamisnak bizonyult. A kiszámolt X és Y értékeket figyelmen kívül hagyhatom, elég lesz csak a sor, oszlop és Z értékekkel foglalkoznom. Az eredeti ötlet, a felosztás és/vagy szűrés megvalósítható lesz.
Most csak egy képpárt töltöttem fel így nem látszik, de az értékek "mozgása" is rendben van.
Külön érdekes a disp mátrix, az értékek "mozgása" itt is oké. Mivel a disp mátrix ilyen szép, és követhetőek a történések, ezért lehet nem is lesz szükség a kiszámolt 3D-s ponthalmazra.
Miért fontos ez? Nem kell meghívni a cvReprojectImageTo3D()-t, ami kiszámolja a 3D-s ponthalmazt, így újabb processzoridőt lehet nyerni.
Azt hiszem maradnak ezek az eljárások az egyszerű távolságok meghatározására. Csinálni fogok egy olyan képsorozatot, ahol szépen minden le lesz mérve, hogy a kapott adatokhoz távolságot tudjak rendelni.