"Další zdroj neúspornosti můžeme vidět na příkladu obrázků obsahujících barvovou paletu. Pro každé místo v barvové paletě jsou rezervovány čtyři byty místo dostačujících bytů tří. Poslední byte však není možné (podle platné specifikace) použít pro jiné účely, tedy ani pro alfa-kanál (průhlednost)."
Tak to ma fakt zaujíma ako chce autor uložiť alfakanál do farebnej palety 8 bitového borázku, keď paleta obsahuje len 4*256 (a z toho 256 voľných) bajtov?!
BMP okrem farebných režimov uvedených v článku podporuje aj
15,16 a 32 bitový režim. V praxy sa, ale používa len 24 a 32 bitový režim. 24 bitové BMP je po odstránaní hlavičky v podstate obyčajné RAW-ko. BMP síce podporuje 8 bitový alfakanál, ale len v 32bit-ovom režime. Väčšina programov ho bohužiaľ ignoruje. To že je obrázok otočený hore nohami, sa nedá považovať za nevýhodu stačí jednoducho otočiť cyklus:
for y := Height -1 downto 0 do
u iných formátov(TIFF atd) zasa treba vymeniť(u každého pixelu) červený kanál za modrý, u BMP tento problém odpadá.
No, ten alfa kanal by byl ulozeny stejne, jako barvy v obrazku (de facto dalsi tri kanaly) - v palete by byl pouze vyber alfa slozek. Pro obrazky weboveho formatu (nejednotne pozadi) se to hodi vice nez max. jedna pruhledna barva u GIFu. Mimochodem, takto s paletou muze pracovat i PNG.
Problem s otocenim je prave pri nacitani a ukladani obrazku, nebo Vam nevadi, ze misto jednoho fread()/fwrite() jich musite ve smycce zavolat treba 768? Nehlede na to, ze si tim "perfektne" rozhazite obsah cache. U nekterych aplikaci to treba nevadi, ale treba pri praci s live videem (a ukladanim vybranych snimku) uz ano.
"No, ten alfa kanal by byl ulozeny stejne, jako barvy v obrazku (de facto dalsi tri kanaly) - v palete by byl pouze vyber alfa slozek. Pro obrazky weboveho formatu (nejednotne pozadi) se to hodi vice nez max. jedna pruhledna barva u GIFu. Mimochodem, takto s paletou muze pracovat i PNG."
Teoreticky je to možné, v praxi to imho nemá zmysel používať, čím viac úrovní priehladnosti by Ste použili v kombinácii s jednou farbou tým menej farieb by sa Vám zmestilo do palety. Takže všetkých 256 úrovní priehľadnosti by bolo možné použiť iba u jednofarebného obrázka.
"Problem s otocenim je prave pri nacitani a ukladani obrazku, nebo Vam nevadi, ze misto jednoho fread()/fwrite() jich musite ve smycce zavolat treba 768? Nehlede na to, ze si tim "perfektne" rozhazite obsah cache. U nekterych aplikaci to treba nevadi, ale treba pri praci s live videem (a ukladanim vybranych snimku) uz ano."
Tento problém som v praxy ešte nezažil. Načítavať jednotlivo každý pixel z disku by bolo neefektívne, a u väčších obrázkov by načítavanie trvalo aj niekoľko minút. Celý obrázok(snímok) najprv načítavam do pamäte(napr. ako pole pixelov) a až potom pristupujem k jednotlivým pixelom(alebo riadkom napr. pomocou Bitmap.ScanLine). A z hľadiska efektívnosti je úplne jedno či sa cyklus začína z hora na dol alebo z dola na hor.
Praveze neni jedno, jestli cyklus z pameti cte "nahoru" nebo "dolu". Zkuste se podivat na funkci dnesnich pameti (DDR a spol.). Ono totiz neni pravda, ze tyto pameti dokazou data cist/zapisovat rychlosti napsanou na cipu (treba 100MHz). To plati pouze pri sekvencnim cteni dat, a to se stoupajicimi adresami. A samozrejme je tady cache, kterou zpetnym ctenim rozhazite - vyprazdni se mnohem vice stranek, ktere se posleze nevyzaduji.
Treba u PNG jsem videl obrazky se 256 barvami, resp. ty obrazky mely 64 barev a kazda mela ctyri urovne pruhlednosti. Pro nektere aplikace ty ctyri urovne dostacuji, napriklad na Webu pro prechod mezi obrazkem a pozadim. A uspora dat byla docela velka, cca 30%.
