2022. szeptember 29., csütörtök

Gyorskeresés

[SVS_9] Szeptember 1-2.

Írta: | Kulcsszavak: SRV . surveyor . SVS

[ ÚJ BEJEGYZÉS ]

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.

Hozzászólások

(#1) Cucuska2


Cucuska2
őstag

Szerintem a Sobel a legjobb.

Rock and stone, to the bone! Leave no dwarf behind!

(#2) Elrood válasza Cucuska2 (#1) üzenetére


Elrood
őstag

Valóban, de canny-nek az a lénylege, hogy az él 1 pixel széles, thresholddal lehet javítgatni.

Sobel gyakorlatilag csak derivál.

''The spice exists on only one planet in the entire universe. A desolate, dry planet with vast deserts. The planet is Arrakis, also known as DUNE.''

(#3) Cucuska2 válasza Elrood (#2) üzenetére


Cucuska2
őstag

Most milyen célokra akarod használni a élfelismerést?

Rock and stone, to the bone! Leave no dwarf behind!

(#4) Elrood válasza Cucuska2 (#3) üzenetére


Elrood
őstag

Konzulensem kért meg rá, hogy teszteljem le, melyik a gyorsabb, a roboté, vagy a pc-n futó (és mekkora terhelést okoz).

Igazából majd sarokdetektálásra lesz leginkább szükségem.

''The spice exists on only one planet in the entire universe. A desolate, dry planet with vast deserts. The planet is Arrakis, also known as DUNE.''

További hozzászólások megtekintése...
Copyright © 2000-2022 PROHARDVER Informatikai Kft.