x

25.5.2011 20:30 | xxx | poslední úprava: 7.10.2011 20:01

x        

Komentáře

[chrono]

Správu farebných profilov tam robíš pri 8 bitoch, alebo priamo v double?

[kralyk z abclinuxu]

Operácie nad floatmi sú omnoho pomalšie

Ale ty tam máš double. Operace nad floatama jsou pomalejší než celočíselý, ale operace nad double precision jsou obvykle afaik ještě pomalejší...

[Kvakor]

... proto se v dávných časech grafik bez jakékoliv akcelerace na podobné věci (např. 3D engine prvního Dooma) používala fixed point aritmetika, kde se např. 32bitové číslo bralo jako horní šesnáctibitová celá část a druhých dolních šestnáct bitů jako děleno 65536.

Dneska by se to už nevyplatilo, ale pokud to někoho zajíma, na Rootu je seriál Fixed point arithmetic.

[Bluebear]

Na intelích procesorech by rychlost výpočtů s floaty a doubly měla být shodná (FPU to všechno převádí interně na long double). Samozřejmě u velkého množství dat je třeba vzít v úvahu cache.

Nevím ae, jak jsou na tom jiné typy CPU, třeba ARM...

[Suchý čert]

Pokud se ale místo FPU použije SSE/AVX, tak tam může být výrazný rozdíl.

[mirec]

S tou pamäťovou náročnosťou by som si ťažkú hlavu nerobil, pri floatoch sa do 512MB RAM zmestí zhruba 45Mpix obrázok (uznávam, že niektorým nemusí stačiť, ale vo väčšine prípadov sa to dá prehrýzť).

[Bluebear]

Fuj

Ono se to vejde, ale je to totéž, jako přes obrazovku velkým písmem napsat "jsem naprostý amatér". Kromě toho to bude strašně pomalé a dokonale to propláchne všechny cache od procesoru až případně po swap.

[Peter S.]

Zaujímava tema, aj ked trochu mi chýba kontext. To v akom programe píšeš? Alebo to je niečo všeobecné windowsovské? Ten jazyk je C#? (nie je to podstatné, v podstate sa +- dá uhádnuť čo si v tom robil)

Vstupom je predpokladám RGB obrázok v int 0-255 - teda štandartne jpg a podobné formáty, správne?
gammu neriešiš?
nie sú rozdielné výsledky oproti defaultnému saturovaniu dané hlavne iným algoritmom?

Ak som správne pochopil algoritmus, tak použitím floatu sa vyhneš dvom zaukruľovaniam - a to pri výpočte grey (priemeru RGB, môže to vyjsť ako x, x.3333 alebo x.6666) a následne finálnej hodnoty kanála, kde sa navyše vo vzorci použije už zaokrúlené gray.
Nevraviac o tom že pri int sa zaokruľovanie deje dosť primitívne - smerom dole pri kladných číslach - čo je dalšia strata presnosti.
Takže double je podľa mna zbytočné, inak máš samozrejme pravdu, floatmi zachárniš nejaké informácie...

Prečo si sa rozhodol vytvárať 2D array veľkosti obrázka, jednoduché iterovanie a prepisovanie pixelov si nezvažoval? Ale je problém s rýchlosťou čítania a zápisu do image (alebo ako sa to ten objekt volá.....)? Windows neumožnuje načítavať obrázok po riadkoch/stlpcoch- tým by si sa vyhol alokácii veľkého množstva pamäte, a rýchlosť by možno až tak neutrpela...

 

 

[zulu]

Super :D

[__dark__]

Výkon zabiješ hlavně použitím funkcí jako SetPixel() a GetPixel(). Jinak double je podle mě zbytečný typ, stačí float nebo 32-bit integer v rozsahu 2^31 (aby se dobře dělilo). Adobe photoshop používá 16bitový integer a rozsah kanálu je od 0 do 2^15. Je to z důvodu rychlosti a využití SIMD.

[Bluebear]

Výkon zabiješ hlavně použitím funkcí jako SetPixel() a GetPixel().

Přesně.

Obávám se ale, že pokud jde primárně o rychlost, resp. pokud má být rychlost opravdu ďábelská, tak bude nutné sestoupit na úroveň někde mezi C a assemblerem, použít MMX/SSEn instrukce, zvážit použití cache a měřit, optimalizovat, měřit a optimalizovat...

[__dark__]

Jinak další věc. V počítačové grafice se při použití reálných čásel používá rozsah [0, 1], včetně. Moc nechápu tvůj rozsah 0-255. To je tak všechno

[Jiří Němec]

Za pár let možná objevíte HDR, myslím opravdové HDR, ne tonemapping, kterému lidé říkají HDR. Pak zjistíte že photoshop funguje v 32bit/kanál už věčnost a v 8bit/kanál je dnes pouze exportní formát. Jinak ty operace co provádíte se dají krásne paralelizovat, škoda že jsou některé jazyky v téhle oblasti asi 30 let pozadu...

[Grunt]

Tohle je kravina. Samozřejmě že veškeré studiové nářadí používá floaty min od 32-bitů výše (třeba Audacity defalutně 32-bit float, ImageMagick 16-bit), ale na takové to domácí žvýkání jsou nejefektivnější filtry implementované na bitové úrovni (bitové posuny, negace, …) a u něčeho takového je nesmysl bavit se o nějakých bitových hloubkách.

[Bluebear]

Pozor, floatové výpočty jsou zrádné. Nedávno jsem na to narazil (taky při zpracovávání obrazu). Jakýkoli zlomek, který nemá ve jmenovateli mocninu dvojky (včetně jednoduchých jako 1.5), se zkresluje při každém výpočtu.

Vím, že je to obecná znalost, ale ne vždycky si člověk uvědomí v plné hrůze, jak moc velká je ta chyba při sérii výpočtů. Pokud jde o zachování maxima informací, doporučuji aspoň zvážit použití celočíselné aritmetiky, klidně i nad 32-bitovými čísly.

[Peter S.]

v tomto prípade stačí presnosť na 2 desatinné miesta, výsledok sa aj tak zaokruhľuje na int v rozmedzí 0-255

[Grunt]

Je někde výstup? Kostky (resp. teda bloky) rozhodně nejsou výstupem kvantizace. Jinak nechápu proč se zas vymýšlí kolo když ImageMagick je to s námi již cca.100 let.