Kamera color bar

[gorankg]

Radim sa nekom malom kamerom pa sam za test pokupio sa njenog interfejsa color bar koji ona moze da generise. Zanima me da li je ovo na slici korektan bar s obzirom da na prelazima izmedju boja nemam ostru ivicu vec dve susedne boje imaju jedan uzan pojas u kome su izmesane? Rekao bih da mi taj prelaz nije dobar a to bi znacilo i da imam gresku negde u softveru. Inace, dokumentacija za samu kameru je bas oskudna pa taj podatak nisam mogao da nadjem.

[mikikg]

Pogledaj ovde:
https://stackoverflow.com/questions/4382...-all-wrong
https://forum.arduino.cc/index.php?topic=159557.390
https://forum.arduino.cc/index.php?topic=159557.405

Mozda je tako i dobro, bar za tu kamericu.

Sve se tu vrti oko formata jednog pixela, jedan pixel ima definiciju RGB gde se svaka boja predstavlja sa predefinisanom duzinom (npr 4bit, 7bit, 8bit) i tako postoje razliciti formati za boju boju kao npr RGB565 gde R zauzima 5 bita, G zauzima 6 bita i B zauzima 5 bita, ukupno 16 bitna paleta boja za jedan pixel, ta kemera radi u tom modu.
Cela slika u RAW modu su samo redom poredjani pixeli, svaki pixel sa svojom bojom od 16bit i to je to.

Sad da li je test patern tako fabricki napravljen, moguce, jer da bi ovako "zbrljao" nesto moras da se potrudis, ne moze samo od sebe da se stvori ona "medju" boja, neko (kamerica) je upisala to tako sa tim bojama pixela.

Max RGB vrednosti su ti dobre i to bi trebalo da bude OK.

[mikikg]

BTW: Ja sad nesto radi isto sa grafikom i koristim format ARGB_8888, tu ima dodatno ovo "A" tj "Alpha channel", to definise "providnost" pixela (kao u providnom PNG) pa sad samo mozes da zamislis sta se dalje sa tim "providnostima" radi
Svaki taj pixel ulazi u "fragment shader", to je specialan program pisan u GLSL koji se izvrsava na grafickoj kartici i koji sve sto radi je samo da izracuna boju za taj jedan jedini pixel a da bi je izracunao to kalkulise od Kulina Bana, uzima poziciju svetla/boje/intenzitet, pa onda refleksija od susednih tamo nekih obejakata (Ray Tracing) pa jos gomila nekih stvari koja se racuna u realnom vremenu samo za jedan pixel ... pa onda to sve za X*Y pixela pa to sve jedno 50 puta u sekundi ...

Isto tako postoji i "vertex shader" koji se samo bavi racunom jednog jedinog vertexa (dimenzija/pozicija u prostoru) i tako jedno 250.000 za neku prosecnu scenu i to sve kuva sa 50 frejmova u sekundi. Inace workflow u 3D grafici je prvo "vertex shader" skuva oblik onoga sto hoces da vidis i to ulazi kroz pipeline u "fragment shader" koji to rasterizuje/boji i pretvara u konkretnu sliku.

[gorankg]

 
Nemam ja mesta za RGB888. Resursi su mi prilicno jadni. Koristim YUV422. Najgore je sto po netu nalazim iste ovakve slike za kolor bar a mislim da nije dobar. Po meni to treba da bude jasno  diferencirano po bojama bez preklapanja. E sad ovo sto ja dobijam moze da bude posledica da ne citam dobro sa kamere a to me brine. Zato rekoh da priupitam ovde, mozda se neko zezao sa tim.

[mikikg]

Meni to lici da je OK, kazem ti ne moze toliko da se zabrlja software (mislim ko zna ali je mala verovatnoca).
Prvi indikator je taj da imas punu boju za svaku komponentu (R, G, B, maksimalne vrednosti R=0b1111, G=0b11, B=0b11) sto znaci da su ti svi bitovi lepo poredjani, da nije tako imam bi totalno promasene boje svuda.
Sto se tice preklapanja, opet po logici ako su boje u pixelu dobro slozene to ne moze da se nikako desi sa nekom greskom u programu, dakle to je tako "izaslo" iz kamere.

[gorankg]

Ma radi dobro, izgleda da bar izlazi takav iz kamere. Fotografije su OK a postavka je STM32L432 + kamera OV7670 sa FIFO RAM. Idemo dalje...

[mikikg]

Odlicno, sad prelazis u domen ciste matematike, racunanje tih boja. contrast, B/W, threshold ...