Pre svega da objasnim do koske, da ne bi bilo vise nikakvih nagadjanja ...

Ovo sluzi za video nadzor (na netu takav softver zovu 'motion detection software' ili 'video surveillance' i sl. (inace downloadovao sam dosta slicnih i nijedan ne obradjuje nepravilne regione na slici)

A da bi svima bilo u potpunnosti jasno ocemu se radi ja cu da opisem sta programce u stvari radi :

Pomocu VFW pristupam drajveru capture kartice (na koju je inace zakacena CCD kamera), imam jedan prozor u kome se vidi slika sa kamere (live). 
Kako programce radi? Pa prosto - Uzmem jedan frejm, zapamtim ga kao byte niz, pa onda uzmem drugi i njega isto zapamtim kao byte niz. Sada treba da samo da ta dva niza brzo uporedim jer mora da ima najmanje 10 poredjenja u sekundi (10 fps mora da obradjuje) da bi detekcija promene na slici bila kvalitetna.

Gde su tu nepravilni regioni u matrici? E, pa to su zone koje mogu da se oznace na slici za nadgledanje. Znaci ako imamo recimo deo prostorije koji hocemo da nadgledamo oznacimo ga na slici i samo ce on biti nadgledan. 
Jedan prost primer primene : Postavite kameru da gleda na vas auto na parkingu i selektujete zonu na slici koja pokriva samo vas automobil, pa ako lopovi nesto pokusaju imate signalizaciju i u usput sve frejmove u toku detekcije kod nagura u AVI fajl koji mozete da koristite kao neki dokaz, a ako komsija ciji je auto pored vaseg, istera svoj auto sa parkinga - to se nece uzeti u obzir jer ste na slici odredili tacnu zonu koja se nadgleda.

Zasto sam trazio da pixeli unutar poligona budu 0, a van njega 1? 
Zato sto je moja ideja sledeca :

n = broj pixela na kompletnoj slici sa kamere (ako je slika 640*480 => n=640*480)
dim prvi(n) - niz u kome je zapamcen prvi frejm za poredjenje
dim drugi(n) - niz u kome je zapamcen drugi frejm za poredjenje
dim zona(n) - niz u kome su markirani sa 0 oni koji se porede, sa 1 koji se ne porede (moze i true i false ili bilo koja dva razlicita broja), a kad bi ovaj niz stavio u bafer za sliku dobili bi monohromatski prikaz prethodno utvrdjenih poligona.
svi ovi nizovi su naravno iste duzine
petlja za poredjenje :

brojrazlpix = 0
for i=1 to n
if zona(i) =0 then  ' znaci piksel je u poligonu pa mozemo da izvrsimo poredjenje frejmova	
if prvi(i)=drugi(i) then
brojrazlpix = brojrazlpix + 1 ' br. razlicitih pixela
endif
endif
next

Prema broju razlicitih pixela moze se odrediti da li se nesto desilo u regionu koji se nadleda ili ne, i naravno moze se podesiti osetljivost detekcije.
Znaci, regioni su pre nadgledanja odredjeni, kako ? Na osnovu vasih odgovora imam sada vise ideja pa cu neku da uoblicim.
Ja sam inace najpre u jednom picture box-u (koji ima iste dimenzije u pixelima kao i slika sa kamere) stavio jedan frejm sa kamere, pa preko nacrtao nekoliko poligona crne boje pomocu Line komande, pa sam posle koristio GetPixel da utvrdim koje su boje svakog pixela i na taj nacim dobio niz zona(n). Veoma prost udarac, da prostije ne moze biti, a i VB moze da zavrsi poneki poso, a ?

E ima tu jos jedan zesci problem : 
Slika sa kamere ima sneg (sum, noise)! Bas tako, kao ono kad imate los prijem na TV-u samo ne u toj meri. Maltene nije primetan osim ako bas ne zagledate, ali za poredjenje je primetan i te kako. Znaci ako je slika u 16 bita paleti, za svaki pixel se koristi dva bajta za boju pixela. Sum (noise) prouzrokuje da se boja svakog pixela menja u nekom manjem rasponu, sto znaci da se promene manifestuju najvise u nizem bajtu za opis boje pixela.
Da bi anulirao sum ja radim sledece :
ako je pixel od dva bajta, 
visibajt nizibajt
01000100 01111010 
onda maskiram nizi bajt ovako :
nizibajt
01111010 xor 11000000

i to donekle umanji sum(noise) ali ne potpuno, ma makar ako u poredjenju gledam samo vise bajtove sum je i dalje tu. Ja inace snimim neku srednju vrednost suma ali sto je veci sum, detekcija promene na slici je sve tupavija.
Posto to nikako za sada nemogu da resim, mislim da problem lezi u RGB vrednostima pixela, ali neznam kako da ih dokucim iz 16-bitnog broja. E, kada bi to znao bilo bi mnogo lakse.

Zbog ovog suma (mislim da se to zove sum kvantizacije koji prouzrokuje sam capture chip, u mom slucaju BT878) probao sam nekoliko capture kartica i kamera da utvrdim da nije do toga, ali sve imaju koliko toliko suma.

E, sve ovo (inace dosta komplikovanije) sad pokusavam da ubacim u VC++ DLL, iz razloga sto VB nemoze dovoljno brzo da odradi frejmove koji su u velikim rezolucijama.
Nego necu sad o tome, jer ako posle svih onih objasnjenja ne uspem da se izborim sa jednom petljom u VC++ onda i nisam za VC++.

pitanje1: kako dobiti maksimalno tacne RGB vrednosti iz 16-bitnog broja ???
(za sada necu da pitam kako bi to islo iz 24 ili 32 bita, ili iz nekog od kompresovanih YUV formata) :)

Funkcija za sva ova poredjenja je, kao sto sam rekao, u VC++ DLL-u. Tu funkciju ja pozivam iz callback funkcije koja se okida svaki put kada se video baferu od capture kartice napuni novi frejm. Znaci, oko 10 puta u sekundi, ako sam stavio da mi frame rate bude toliko, ali pozeljno je i vise i nikako manje.

pitanje2: Sta se desava ako se callback okine ponovo dok je poredjenje (u DLL-u) u toku ???
Znaci fn u DLL-u jos nije zavrsila poso, a stize novi callback koji zove opet istu fn.
Kako da ovo sinhronizujem ???