Hírek | Archívum | Fórum | IRC | Amiga | AmigaOS | FAQ | RSS

 - Fórumok - Regisztráció - Keresés - Statisztika - Szabályzat - Pegasos.hu fórum
forum.amigaspirit.hu / Fejlesztés / C hasznosságok
Szerző Üzenet
AliveMOon
Tag

# Elküldve: 2013. Jan. 25. 00:15 - Szerkesztve: alivemoon


Ide lehetne általánosabb C forrásokat megosztani

Kezdem egy for ciklus YUV2RGB konverterrel, webkamerához hasznos:

U4 (4byte-os unsigned, a LW3D SDK-ból lestem el valamikor és megtetszett)
F4 ( sima float )
F8 (double )
stb...



for( U4 *p_s = p_src, *p_e = p_s + h*(w/2); p_s < p_e; p_s++ )
{
yuv = *p_s;

u = (yuv & 0xff00) >> 8;
y0 = (yuv & 0xff);
y1 = (yuv & 0xff0000) >> 16;
v = (yuv & 0xff000000) >> 24;

u -= 0x80;
v -= 0x80;

r = g = b = y0*0x253f - 0x253f0;
r += 0x3312*v;
g += 0xc83*u - 0x1a04*v;
b += 0x4093*u;


*p_d =
(( r <= 0x2000 ) ? 0 : ( ( r >= 0x200000 ) ? 0xff0000 : ((r << 3 )&0xff0000) ))
| (( g <= 0x2000 ) ? 0 : ( ( g >= 0x200000 ) ? 0xff00 : ((g >> 5 )&0xff00) ))
| (( b <= 0x2000 ) ? 0 : ( ( b >= 0x200000 ) ? 0xff : ((b >> 13 )&0xff) ))
| 0xff000000;
// ez most olyan adatot szolgáltat amit textura feltöltésre szoktam használni


p_d++;


r = g = b = y1*0x253f - 0x253f0;
r += 0x3312*v;
g += 0xc83*u - 0x1a04*v;
b += 0x4093*u;

*p_d =
(( r <= 0x2000 ) ? 0 : ( ( r >= 0x200000 ) ? 0xff0000 : ((r << 3 )&0xff0000) ))
| (( g <= 0x2000 ) ? 0 : ( ( g >= 0x200000 ) ? 0xff00 : ((g >> 5 )&0xff00) ))
| (( b <= 0x2000 ) ? 0 : ( ( b >= 0x200000 ) ? 0xff : ((b >> 13 )&0xff) ))
| 0xff000000;

p_d++;

}

dh1
Mr. DTP

# Elküldve: 2013. Jan. 25. 00:21


Uristen, mi lesz, en ide nem fogok tudni irni ... vege a szep floodolos eletnek :)

Bocs ... :)

Spenot
Tag

# Elküldve: 2013. Jan. 25. 17:28


Pedig megpróbálhattál volna kirobbantani egy color space flame wart :)

Chain-Q
Divatamigás

# Elküldve: 2013. Jan. 27. 22:44 - Szerkesztve: charlie


Flamewar? ... Hat tulajdonkeppen... Ezzel a rutinnal van nehany problemam.... :)

1., Eloszor is a leforditasahoz hianyoznak a helyi valtozok tipusai, en kiprobaltam es kb. 1 orat szoptam, mire kiderult, hogy az r, g, b valtozoknak signednek kell lenni, maskepp elbassza a kepet.

2., A konverzio szinhelyessege is hagy kivannivalokat maga utan (jobbra az eredeti, balra konverzio utan)...


3., Endian problemas a ki es bemenet is. LE/BE rendszereken mas sorrendben keri a bemenetet (VYUY vs. YUYV) es mas formatumu lesz a kimenet (RGBA vs. ABGR), hiszen longintben olvassa es irja a memoriat.

4., A szaturacio atom lassu, es nem arra az esetre van optimalizalva, ami a legtobbszor elofordul, vagyis egy szaturaciot nem igenylo pixelnel is dupla elagazas van benne. (Egyebkent csak ennek az esetnek az atrendezesevel 20%-ot gyorsitottam rajta az i7-es MacBookomon, bar a PegasosII-n nem gyorsult, gondolom ott mar ez a rutin is memoria-limitalt.)

5., Ha kozelebbrol megvizsgalod a szaturacios rutinokat rajossz, hogy a rutin 2^24-3 szinnel dolgozik, mert ha barmelyik szinkomponens 1, akkor azt mar 0-ra szaturalja. :)

6., En nem ertek a color space conversionhoz, sem a vektor matekhoz, de a libswscale-ben ennel ranezesre ezerszer optimalizaltabb YUV-RGB rutinok vannak, amik raadasul x86-on, PPC-n es ARM-on is kepesek hasznalni a modern CPU-k SIMD egysegeit...

AliveMOon
Tag

# Elküldve: 2013. Jan. 28. 04:11 - Szerkesztve: alivemoon


Egy sorban akartam kifejteni.
Ellenőrzésből kell mind a kettő, ha később éselnék akkor fel lehetne cserélni de nem akartam. Elöbb a 0 késöbb a nagyobb érték, talán így érthetőbb.

Az értékekkel egyébként lehet játszani, ahogy tetszik.

Ékes példa rá a curiosity-ről közzétett képek egyikén láttam, hogy keletkezik egy fekete pacni a képben, pedig látszik, hogy ott fehér akart lenni de nincsen benne ez a kis plusz művelet, mert úgy gondolták az olyan ritka!

Itt!

A legjobbak is tévednek néha, hát még én :)

AliveMOon
Tag

# Elküldve: 2013. Jan. 28. 04:28 - Szerkesztve: alivemoon


És nem olyan ritka mint gondolnád, egy tiszta piros pixel például, vagy tiszta zöld, vagy valamelyik permutációjában, sok csatornánál is rögtön kinullázza, vagy 0xff-re tölti ki! Abszolút fekete, amikor rajta hagyom a kupakot a lencsén akkor a leggyorsabb, tény :)

De kösz az tippeket, gondolkodom rajtuk :)

AliveMOon
Tag

# Elküldve: 2013. Jan. 28. 05:21 - Szerkesztve: alivemoon


*p_d =
( r >= 0x200000 ) ? 0xff0000 : ((r << 3 )&0xff0000) )
| ( ( g >= 0x200000 ) ? 0xff00 : ((g >> 5 )&0xff00) )
| ( ( b >= 0x200000 ) ? 0xff : ((b >> 13 )&0xff) )
| 0xff000000;

Végül is tény az alsó határra semmi szükség, egy kis paranoia ?
Hozzá szoktam, hogy kétszer mérek mielőtt csinálok valamit :)

AliveMOon
Tag

# Elküldve: 2013. Jan. 31. 19:35 - Szerkesztve: alivemoon


Nem paranoia volt, nagyon könnyen össze jön, hogy sötétebb szineknél akár minusz is lesz r és g, ezért foltos lesz a kép!

Kell mind két ellenörzés kökeményen!
Tehát az elsö változat a jó!

Chain-Q
Divatamigás

# Elküldve: 2013. Jan. 31. 19:41


Igen, de nem mindegy a ket ellenorzes sorrendje, errol beszeltem, nem arrol hogy ki kell venni az egyiket. :)

AliveMOon
Tag

# Elküldve: 2013. Jan. 31. 20:18 - Szerkesztve: alivemoon


Hát szerintem olyn mindegy, ebben a "?" kontextusban,ha tisztább szinek vanak sok üres és teli csatornáid vannak, nem beszélve ha sok fehér vagy sok sötét, el kell tudni dönteni mind két esetet, mielött konkrétan számolsz.

cmp d0,$2000
bxy kisebb

cmp d0,$200000
byx nagyobb

shift d0,3
and d0,$ff0000
jmp ki

kisebb:
sub d0, d0
jmp ki

nagyob:
move d0, $ff0000

ki:
or d1,d0

valami ilyesmi lesz ígyis úgyis az eredmény

AliveMOon
Tag

# Elküldve: 2013. Feb. 01. 02:18 - Szerkesztve: alivemoon


Egy olyan eszembe jutott, hogy mi lenne ha idöt mérnék, ha nö a konvertálás ideje probál egy másik permutációt,
Ha egyszer lesz kedvem kipróbálom.

Lehet a permutáció variációjábol és a konvertálások idejének diferenciájából, lehet ki lehetne okumlálni fényero korrekcót is :) Jó ez csek egy hirtelen ötlet!

De az is eszembe jutott, ha kevés a közép csatornás akkor az explosure lehetne játszani.

Off:
Király ez az OWB! Tök használható, egésznap ezt használtam böngészésre OS4-en, Farnell, Distrelec, oldalakon alkatrészek után böngésztem simán vette az akadályokat. 733Mhz nem is olyan gáz, nem hasít de használható!

Most jutott eszembe, hogy nem is töltöttem be a PC-n a böngészot :)

dh1
Mr. DTP

# Elküldve: 2013. Feb. 01. 10:53


Az Off-ot nyugodtan megirhatod az OS4 topicban! :)

forum.amigaspirit.hu / Fejlesztés / C hasznosságok
 
 

Powered by online community script miniBB™ © 2001-2019