2024. március 28., csütörtök

Gyorskeresés

[SVS_14] Október 16-17.

Írta: | Kulcsszavak: SRV . surveyor . SVS

[ ÚJ BEJEGYZÉS ]

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.

Copyright © 2000-2024 PROHARDVER Informatikai Kft.