Szeptember 1., még 99 nap
A képfeldolgozással kapcsolatos kódokat átraktam egy új dll-be, hogy jobban elkülönüljenek az ablaktól és a robotvezérlőtől.
Ki kísérleteztem, hogyan rakható egy kamera esetén 2 külön threadbe a kép lehívás, és a sobel feldolgozás. Két kamera esetén már 4 threadről beszélhetünk (bal, jobb lehívás, bal jobb sobel).
Minden rendesen működik, meghozták a várt eredményt. Eredményeket majd holnap.
Szeptember 2., még 98 nap
Canny-val is megcsináltam azt, amit a sobellel tegnap, tehát 1 kamera esetén 1 vagy 2 thread, 2 kamera esetén 1 vagy 4 thread. Sajnos a tegnapi sobeles méréseket dobhattam a kukákba, mert a robotok ma kicsit gyorsabbak voltak, mint tegnap (nem voltak töltve, fizikailag ugyanoda raktam őket, érthetetlen...).
Mérések:
A mérést vpc-ben futó winxp-vel végeztem, ami csak 1 magot lát a processzorból. VS2008 alatt, debug módban futott a program (akár 10-30%-t is megesz így a processzorból). Az FPS kiszámítása úgy történt, hogy 10 másodpercenként összejött framek számát osztotta 10-zel a program, SVS esetén 1 frame, 1 képpárt jelent. A timeoutos részeket nem vettem figyelembe.
Q8: legrosszabb jpeg minőség, Q1: legjobb jpeg minőség
SRV - 1 kamera
10mp avg. Normál Robot edge Sobel 1 t Sobel 2 t Canny 1 t Canny 2 t
320Q8 9.5-9.7 4.9-5.0 6.5-6.7 9.7-10.3 8.6-8.8 9.9-10.4
320Q1 4.6-4.8 3.0-3.2 3.7-4.0 4.3-4.6 4.4-4.5 4.6-4.8
640Q8 2.8-3.0 1.2-1.3 2.1-2.2 2.7-2.8 2.7-2.8 2.9-3.1
SVS - 2 kamera
10mp avg. Normál Robot edge Sobel 1 t Sobel 2 t Canny 1 t Canny 2 t
320Q8 7.1-7.4 4.2-4.4 4.8-5.1 7.7-8.1* 6.6-6.7 7.6-7.9
320Q1 3.5-3.8 2.4-2.6 3.0-3.1 3.5-3.7 3.4-3.7 3.7-3.9
640Q8 2.4-2.5 1.1-1.2 1.5-1.6 2.2-2.3* 2.3 2.4-2.6
* = közel 100%-os cpu
320Q8 esetén nem tudom, miért lett több FPS a canny és a sobel, mint a normál kép. Az FPS növelés mindig a képmegjelenítésnél volt, tehát nem a threadek zavartak be. Valószínűleg az OpenCV képmegjelenítése gyorsult azzal, hogy nem egy 3 csatornás képet kellett megjeleníteni, hanem csupán 1 csatornásat.
A tesztből a következő szűrhető le:
1. A robot saját éldetektálója egyértelműen lassabb.
2. Két thread használatával elérhető a "real-time".
3. A sobel egyértelműen lassabb, pedig a canny függvénye is meghívja, és az elején kb. ugyanazt csinálja, mint az én sobelem, ráadásul sokkal jobban dolgoztatta a CPU-t (1 threades értékeknél látszik igazán). Úgy néz ki, OpenCV-sek jobban implementálták, mint én
.
4. Később lesz rá példa, de a robot belső éldetektálójának a minősége még rosszabb is szerintem.
Akkor legyen pár példa az éldetektálók minőségére különböző jpeg minőségeknél:
A hátteret ne figyeljétek, sajnos ilyen a tapéta, az árnyékokat élnek veszi mindegyik a nagy intenzitásugrás miatt.
Normál kép, 320x240, legrosszabb jpeg minőség
screenshot
Normál kép, 320x240, legjobb jpeg minőség
screenshot
Robot éldetektálója, 320x240, legrosszabb jpeg minőség, threshold: 5
screenshot
Robot éldetektálója, 320x240, legjobb jpeg minőség, threshold: 5
screenshot
Normál képről sobel, 320x240, legrosszabb jpeg minőség
screenshot
Normál képről sobel, 320x240, legjobb jpeg minőség
screenshot
Normál képről canny, 320x240, legrosszabb jpeg minőség, threshold1: 50, threshold2: 150
screenshot
Normál képről canny, 320x240, legjobb jpeg minőség, threshold1: 50, threshold2: 150
screenshot
Sajnos a legjobb és a legrosszabb minőség között látható különbség van. Legrosszabb minőségen jól látszik a blokkos jpeg, ami visszaköszön a sobelen és a canny-n is. Sobelen látszódnak a négyszögek, canny-n meg "szőrösek" az élek.
Canny másik hátránya, hogy két kép között is van különbség, tehát "ugrálnak" az élek, legrosszabb minőségnél ez még rosszabb.
Majd meg kell találni a megfelelő jpeg minőséget, ami kellően gyors, és még nem zavarja össze teljesen majd a sarokdetektálót.
Kiegészítésként eszembe jutott, hogy a thread függvényeket lehet elkülönítem az ablakos programjából, mert nagyon eszik a sorokat és elvileg külön dolgot csinálnak.
