| 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!
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! :)
|
