RGB->YUV (diskuse)

[XSSds]

Mozem poprosit x86-16 a x86-128 bitovu verziu?

[Jardík]

Můžete

[User682]

zdravim,

dam Vam jenom inspiraci na hledani, ale ne reseni.

Kdysi jsem prochazel git repositar ffmpeg projektu a je tam vcelku dost asembleru na ruzne konverze. Mozna, ze tam je neco co hledate.

gf

[Miriam]

Ahoj, ještě pořád nemáš holku? Moje nabídka stále platí, nezajdem někam na drink?

[Josef Kufner]

Řekl bych, že ta první otázka je vzhledem k obsahu zápisku celkem zbytečná

[Miriam]

Jsem slušná holka, né děvka. K tomu patří i formality ;)

[Miriam]

A vlastně bych už měla jít spát. Tak pa a brou noc

[blizzz]

Áno, určite si holka ale s kokotom :D

[XSSds]

Ba dum tsss ... LOL True Story :D

[blizzz]

čo tým chcel básnik povedať?

[munich machine]

Ha - ha - ha.

[Josef Kufner]

Však to samozřejmě. Jsem tím ani nic nevhodného nemyslel

[Jardík]

Promiň, ale já nemůžu, mám poruchu osobnosti. Leda bys chtěla pejska, kterého bys ráda krmila a zbytek dne bys si ho nevšímala aby si mohl vklidu omílat, že je život zbytečnej a že nemá smysl chodit do práce, protože za chození do práce musíš platit nadlidem u koryta.

[Vskutečnosti Saýc]

Premyslim jak rychle by o zvladla CUDA.

[Miloslav Ponkrác]

Moc tomu nerozumím a proto se předem omlouvám za blbosti.

Ale pokud vím, v tomto systém je U a V barevná složka, která se odvozuje od jasové složky.

Tedy po výpočtu jasové složky stačí:

U = konstanta * (B - Y')

V = konstanta * (R - Y')

Přijde mi zbytečné rozepisovat to násobením přes plnou transformační matici.

[Miloslav Ponkrác]

U = 0,4921 * (B - Y')

V = 0,8773 * (R - Y')

[Josef Kufner]

Jo, jo... a na Wikipedii je těch (podobně jednoduchých) vzorečků spousta.

Btw, pár desítek let staré televize tenhle převod počítají analogově a stíhají to v reálném čase

[Miloslav Ponkrác]

Analogové operace jsou mnohonásobně rychlejší a efektivnější než digitální operace. V tomto případě je to i primitivní elektronický obvod.

Ale hw obvod navržený na míru by to spočítal i digitálně v reálném čase.

Ostatně to, že analogové obvody mají vyšší rychlosti i kapacitu (ale nižší odolnost proti šumu a ztrátě informací) už je znovuobjeven. Takové SSD disky a flashky už v zásadě nezaznamenávají informaci digitálně (pokud nejsou SLC) ale v zásadě analogově (MLC). Navyšuje to kapacitu, ale zhoršuje stabilitu uložených dat a rychleji to ztrácí data.

Kromě šumu je analogová technika ve všech vlastnostech o mnoho řádů napřed. To co se dá v analogové technice vyřešit součástkami za 10 Kč, na vyřešení stejné operace v digitální technice je potřeba stroj za sto tisíc dolarů a ještě bude pokulhávat za analogem.

Analogová elektronika je dokonce schopná řešit diferenciální rovnice v reálném čase.

[Martin Mareš]

Kromě šumu je analogová technika ve všech vlastnostech o mnoho řádů napřed. To co se dá v analogové technice vyřešit součástkami za 10 Kč, na vyřešení stejné operace v digitální technice je potřeba stroj za sto tisíc dolarů a ještě bude pokulhávat za analogem.

Pokud si vyberete jednu z těch několika málo operací, které se dají analogově snadno realizovat, tak ano

Ale rád se nechám přesvědčit – stačí, když ukážete, jak jednoduše analogově spočítat RSA

[pc2005]

No já nevím, není náhodou MLC pouze soustava o jiném základu než 2?

BTW ono záleží na rychlosti. S operačníma zesilovačema bys měl docela problém pro rychlost operací frekvencí xGHz. Resp ty operáky by asi nestály 10Kč.

[ustp]

Trochu demagogie s tema ssd. MLC bunky pouzivaj vic napetovejch urovni, ale porad ukladaj digitalni data.

[Ondrej 'SanTiago' Zajicek]

Presne tak, 'digitalni' obvykle znaci, ze vyznamy jsou prirazene diskretnim urovnim, nikoliv ze tech urovni musi byt pouze 2. Pouziti vice diskretnich urovni neni neobvykle (napr. 100Mbps a 1Gbps ethernet).

[pc2005]

Vlastně i výstup z DAC by byl před low pass filtrem diskrétní.

[Ondrej 'SanTiago' Zajicek]

To vicemene ano, ale nemel diskretne definovane urovne.

[pc2005]

No leda přes dílky z nějakého Vref.

[kralyk z abclinuxu]

Hmm, tohle bylo lepší než obvyklé statě o C++

[Agent]

Možná trochu OT, ale připomělo mi to, jak v Amáru vycházel návod na videotitulkovač někdy v polovině 90 let. Bedna plná integráčů a jediný co to umělo byly titulky. Netrvalo dlouho a takováto udělátka ztratila smysl. Jediná výhoda možná byla, že to bylo levnější než tehdejší PC s MPEG2 kartou.

[Vskutečnosti Saýc]

No staci si vsimnout, ze jardik zpracuje tricetisekundove video za necele ctyri sekundy, coz na realny cas spokojene staci.

[Miloslav Ponkrác]

Nikdo se ani slovem nevyjádřil, že jardík nestíhá v reálném čase.

Možná by si stačilo všimnout, že řeč byla o tom, že jakýsi předpotopní televizáč to stíhá v reálném čase.

A možná by si stačilo všimnout, že nebyla jakákoli zmínka o jardíkovi, jeho algoritmu ani srovnávání rychlostí.

Jinak řečeno, chápání psaného textu, nic moc. Doučte se to, studente a trénujte.

[Vskutečnosti Saýc]

Mozna by si stacilo vsimnout, na ktery prispevek odpovidam. Napoveda: neni to ten Vas.

[Jardík]

Mým výsledkem má být yuv420, pro každé 4 pixely (2x2) je tam jeden U a jeden V. Takže když mám pro 4 pixely už 4 Y', tak abych mohl použít ten vzorec řekněme pro U, musel bych nejdříve zprůměrovat B hodnoty pro ty 4 pixely, zprůměrovat Y hodnoty pro ty pixely a použít vzorec.

Momentálně to dělám tak, pro každý pixel vypočítám Y, zprůměruju rgb hodnoty pro 2x2 sousední pixely a spočtu U. Pravděpodobně by mi použítí "jednodušší" vzorce v tomto případě moc nepomohlo. Leda bych U nepočítal z průměrů ale pouze z jednoho pixelu, ale pak bych asi nedostal hezký výsledek.

[Miloslav Ponkrác]

Jak jsem psal, nerozumím tomu do detailu.

Nemusíte průměrovat nic, prostě hodnoty sečtete a to bude 4× požadovaná hodnota. Konstanty podle toho upravíte.

Rovnou se přiznám, že kódy v článku jsme moc neluštil. Chybí mi další informace jako definice struktury a vůbec nějaké komentáře, takže jsem to jenom přelétl.

Něčemu málo rozumím, ale ne celku. Nerozumím přesně v jakém formátu a rozsahu chodí vstupní RGB data.

Ale jednu věc vím zcela určitě. Volba lepšího algoritmu a pohrání si s matematikou dává mnohem větší zrychlení, než ďábelsky kódovat nanosekundy pomocí asm. Možná se ukáže, že to není k ničemu.

Určitě bych si vzal základní „atom“, tedy nejmenší pravidelný rámec, který mám vyrobit. Nejdříve bych si pohrál matematicky, pak by se snažil převést do bajtových operací tak, aby se to šikovně optimalizovalo. Neoptimalizoval bych jeden bod, ale celý nejmenší blok, který se pravidelně opakuje.

Mám trochu pocit z článku, že náhodně hledáte vzorce a že v matematice plavete a tak se snažíte ďábelsky kódovat ty nanosekundy.

Pochopit ty vzorce je jednoduché. Transformační matice s převodem na int počítání a posun je dělána právě pro SIMD, kde jsou tyhle nadbytečné operace vcelku zdarma. I proto Vám v klasickém C vyšel mnohem pomalejší algoritmus, protože jste tam rval věci optimalizované pro SIMD operace.

[Jardík]

Tenhle obrázek z wiki je můj výstupní formát.

Vstup jsou za sebou jdoucí pixely B8G8R8A8 s tím, že celý obraz je vzhůru nohama (tak ho vrátí glReadPixels).

[Miloslav Ponkrác]

Snad rozumím. Pro jistotu popíšu:

V zásadě se tedy kódují po čtveřicích pixelů. U každé čtveřice pixelů (čtverec 2×2 body) se spočítá Y', tedy vyjdou čtyři bajty Y'. Dále se ale pro celou čtveřici pixelů spočítá jen jedno U a následně jedno V.

Celá čtveřice bodů, které přijdou jako 16 bajtů RGBA se zakódují do šesti bajtů Y'1, Y'2, Y'3, Y'4, U, V.

Analogová hodnota Y' se pohybuje v rozsahu od 0 do 1, a transformuje se do bajtu Y' jako hodnota od 16 do 235. Hodnoty pod 16 a nad 235 se nepoužívají a těchto hodnot nemohou uložené bajty Y' nikdy nabýt.

[Miloslav Ponkrác]

Co takhle?

Spočítat pro každou čtveřici pixelů Y':

Y' = (66R + 129G + 25B) >> 8 + 16;

Ale algoritmus bych přepsal takto:

===============================================

Varianta 1 pro extrémní šetření pamětí:

a) Udělal bych si 128 KB velkou předpočítanou tabulku, tedy pole o 64 K prvcích, každý prvek by obsahovat 2 bajtovou hodnotu.

index_1 = B + 256 * G; pole_1[index_1] = (16 * 256 + 25 * B + 129 * G);

b) Udělal bych si druhou 512 B velkou předpočítanou tabulku:

index_2 = R; pole_2[index_2] = (66 * R);

c) Výsledné Y' bych spočítal jako:

Y' = (pole_1[index_1] + pole_2[index_2]) >> 8;

===============================================

Nejrychlejší varianta 2 pro zabrání 16 MB RAM (dnes mají počítače několik GB RAM):

a) předpočítanou tabulku pro převod:

index = B + 256 * G + 65536 * R (tedy nic počítat nemusíte, pouze použijete bajty B,G,R tak jak na intel procesorech leží) pole[index] = výsledná hodnota Y' bajtu

[kutr]

Jak jsem psal, nerozumím tomu do detailu. Ale jednu věc vím zcela určitě. Volba lepšího algoritmu a pohrání si s matematikou dává mnohem větší zrychlení, než ďábelsky kódovat nanosekundy pomocí asm. Možná se ukáže, že to není k ničemu.

Jenže Jardík obvykle jde cestou předčasné optimalizace a ukazuje nám proč se nemá dělat. (viz. jeho starší blog kde ďábelsky optimalizoval v ASM, až se dostal na stejný čas jako naivní C program)

[Miloslav Ponkrác]

Mě naučili, co to je skutečná optimalizace, a jak efektivně matematické záležitosti a algoritmy mohou fungovat až na vysoké škole.

Do té doby jsem také optimalizoval asm.

Jenže díky bohu za to. Protože jsem se naučil optimalizovat algoritmy pro procesor a programovací jazyky a pak později i na úrovni algoritmů.

To je mimochodem z jeden důvodů, proč je dobré udělat vysokou školu. Naučíte se spoustu věcí, na které nikdy nepřijdete (protože Vás k tomu nikdo nebude nutit a protože to nikdo kolem vás nebude znát). Uděláte skok o desítky let dopředu oproti stavu kdy se budete učit pouze praxí.

Jardík si možná prošlápne cestu jak se to dělat nemá, ale jako vedlejší efekt se naučí být machr v postalgoritmické optimalizaci. Navíc ho to baví.

Časem na to přijde a bude machr po všech stránkách.

Nemůžete být v něčem dobří, pokud nejdete občas vedlejšími cestami, neděláte chyby a nevyzkoušíte si i co nefunguje.

Ale Jardíkův zápal se mi strašně líbí.

[anon]

Fajnovy posledni odstavce.

Kazdopadne s tou vs nemohu souhlasit - me vs co se tyka odbornych znalosti dala temer nic. Nadruhou stranu jsem mel hromadu volnyho casu ve kterem jsem mohl sam nabrat hodne cenych zkusenosti h oboru I mimo. I kdyz vlastne kurzy mimo it mi daly zabrat no it me akorat trapilo ze to vsecho jsem se naucil sam uz pred x rokama a kdy jako budem delat neco zajimavyho.

[Kvakor]

Kdyby to bylo YUV na RGB, tam to jsem před lety dělal a někde jsem našel a přepsal rutinu, která mohutně používá přetpočítané tabulky a ve vnitřením cyklu je jenom sčítaní, bitové posuvy a vytažení hodnoty z tabulky. Rozdíl mezi verzí co v cyklu počítala podle vzorečku a tou s předpočítanými tabulkami byl tenkrát asi o řád. Na druhou stranu, dnešní procesory jsou vůči pamětem tak rychlé, že násobení může vyjít levněji než načtení hodnoty z paměti. I tak budu komentovat jen céčkovou část:

Aby se vyhodilo násobení z hlavniho cyklu, stačilo by předpočítat si dopředu tabulky pro každou hodnotu Y, Cr a Cb místo násobení uvnitř maker RGB_TO_YCbCrJPEG_* a pošoupnout všechno doprava až v okamžiku, kdy se ukládá finální hodnota (popř. to procpat ještě přes nějakou tabulku, co by dělala clipping). Dá se tím i zaokrouhlovat, pokud se dobře nastaví konstanta, co se přičítá před posuvem.

Nebo možná udělat "unrolling" toho chroma subsamplingu a vecpal do něj i počítání luminance, protože mám pocit, že by to méně zaplácávalo cache - pokud už je některá hodnota z paměti načtená, měla by být využitá až "do mrtě". A to pošoupnutí ">> 2" u onoho supsamplingu se mi také moc nelíbí, protože to se může bez ztráty kytičky udělat až na konci a získámé tím trochu vyšší přenost.

No a ještě bych nejspíš držel dva ukazatele do RGB pole from, pošouplé o th->stride a jenom je inkrementoval, protože i když z toho překladač udělá nepřímé adresování, stále to bude sahat do paměti. To samé i u výsledného Y a th->yw.

[Miloslav Ponkrác]

Já bych reálně počítal Y' z RGB.

Pak bych udělal předpočítané tabulky (B,Y')->U a (R,Y')->V.

[Bedňa]

Jardíku držím palce.

[mirec]

Držím palec. Práve riešim real time renderovanie OpenGL do YUV streamu s následným enkódovaním do MPEG2 a vysielaním cez rtmp.

[Miloslav Ponkrác]

Tak jsem prostudoval ITU dokument.

Pochopil jsem, proč se výpočet počítá transformační maticí a nikoli odčítáním. Protože výsledné Y' je jen přibližným zaokrouhlením a celý výpočet se počítá na integerech jako fixed point čísla.

Použití bajtu Y' by přidalo do výpočtu zaokrouhlovací chybu (výsledek by se mohl lišit o jedničku nahoru nebo dolů od skutečné hodnoty). Výpočet by se tedy musel prováděl na 16bitovém integeru namísto 8bitovém bajtu.

Tedy výpočet Y' by pak do výpočtu U a V vstoupit jako celé fixed point číslo (16bitový integer) – tedy Y' před rotací doprava o 8 bitů.

[Duff]

Pro výpočet pomocí procesoru by se to dalo pěkně paralelizovat. Matice by se rozdělila na počet částí jako procesorů/jader.

A ještě lepší možnost je to počítat pomocí grafiky a pixel shaderů. I na smartfounech to půjde v reálném čase 30 snímků za sekundu.