Názory k článku
Rastrový grafický formát ICO

zdá se mi, že od verze WinXP byl do ikon nějak implementován alpha kanál, neví někdo jak je to realizováno?

Pres to vkladane BMP. BMPcka uz alfa kanal zvladaji, takze je to mozne vyuzit. Jak se zmixuje alfa kanal s AND-bitmapou vsak netusim, muselo by se to vyzkouset.

Dobrý den,
mám pocit, že u 32bit ikon se AND bitmapa ignoruje (ona by stejně měla být prázdná).

BTW: Ve Windows Vista umožnili do ICO souborů vkládat PNG soubory :-D To aby ikony ve velikosti 256x256x32bit nezabíraly 250KB...
Ukázkové soubory s PNG a v porovnání s původním 32bit alphakanálem: http://www.iconempire.com/info/vista-icons.htm

Nemá snad Vista ty ikony v úplně jiném formátu, vektorové?

hm, to je fajn, ale nějak se mi nedaří vygooglovat podrobnější popis formátu ikony s alfa kanálem, Microsoft to docela úspěšně tají...

Spíš Microsoft podezřívám z lenosti než z utajování. Na stejný problém (nemožnost najít "dokumentaci") jsme narazili, když byla na webu objevena ikona s neprázdnou AND bitmapou v místech, kde byl použit Alpha kanál. Jestli so dobře vybavuji, tak Windows tyto ikony zobrazí bez ohledu na AND bitmapu.

Problematické ikony se nacházely na adrese: http://customize.ru/icons_suites.html (skupina Longhorn Drives)
Více informací k problému v diskuzním fóru Servant Salamandera: http://forum.altap.cz/viewtopic.php?p=6164#6164


Odpověď na druhý dotaz: Ikony ve Vistách jsou stále bitmapy - jenže obřích rozměrů 256x256 pixelů (tato velikost je kvůli omezení BYTE v ICO formátu uložena jako 0 krát 0) - v takovém rozlišení se Vám v 1280x1024 vejdou jen 4 vedle sebe v 1600x1200 je to ikon 6. Protože nikdo nebude používat tak obrovské ikony, jsou dobrým zdrojem pro zmenšování.

Ty zmíněné animace jsou podporovány ve velmi podobném formátu .cur .

Mate pravdu. Na ten format se jeste podivame v castech venovanych souborovym formatum urcenym pro uschovu animaci.

jako ikonku webu doporucuju spis PNG, ico je moc velky, zbytecne zvysuje trafik... PNG podporuji vsechny prohlizece krome IE...

Problem je, ze ten PNG by se mel posilat v zavislosti na vlastnostech klientskeho zarizeni. Napriklad pro nektere mobily nema smysl posilat PNG v truecolor o velikosti 32x32 pixelu, ale staci mensi obrazek s mene poctem barev.

Prave v tom ma ICO vyhodu - v jednom souboru o velikosti radove kB se prenese vice obrazku. Pokud by se melo prenaset vice PNG ke klientu, bude to objemnejsi a pomalejsi - kazde PNG znamena novy HTTP dotaz (ten ma sam tak 200 bytu).

Jeste je dobre dat pozor na to, aby PNG nemely 256 barev, to uz je lespi pouzit truecolor PNG - samotna paleta ma 768 bytu, to je mnohdy vic, zpakovaby pocet pixelu.

ICO je moc velké v případě, že obsahuje víc obrázků. Pokud bude obsahovat pouze jeden obrázek (jako PNG), nebude o moc větší.

Objem přenesených dat se dá snížit gzip kompresí, formát ICO je celkem dobře komprimovatelný.

U ikony JavaCup.ico je uvedena velikost 1640 bytů. Nějak se k ní nemohu dopočítat:

40 (hlavička) + 16*4 (paleta) + 48*48/2 (XOR-bitmapa) + 48*48/8 (AND-bitmapa) = 1544 (96 bytů chybí)

Možná to bude souviset s mým problémem. Na http://php.vrana.cz/favicon.ico mám ikonu (vygenerovanou tuším pomocí IrfanView): width=16, height=16, bitcount=24, length=872.

40 (hlavička) + 16*16*3 (XOR-bitmapa) + 16*16/8 (AND-bitmapa) = 840 (32 bytů chybí)

Bližším prozkoumáním jsem zjistil, že chybějících 32 bytů je umístěno v AND-bitmapě - každý nový řádek začíná na bytu dělitelném čtyřmi. Pokud bychom toto pravidlo vztáhli na JavaCup.ico, tak součet rázem taky vychází, takže předpokládám, že to bude ono.

Škoda, že o tom v článku není žádná zmínka, v odkazovaných dokumentech jsem našel také pouze zavádějící informace (jako že velikost AND-bitmapy = šířka*výška/8).

Moje opomenutí: sice jsem v článku na jednom místě psal, že se jedná o vložené windowsovské bitmapy (uložené v kontejneru s koncovkou .BMP), ale už jsem nedal odkaz na předchozí části tohoto seriálu. Formát .ICO je vlastně taky kontejner na bitmapy

Máte naprostou pravdu - všechny řádky v jakékoli win. bitmapě (v tomto případě pojmenovaných AND a XOR) jsou zarovnány na celistvé čtyři byty. U XOR-bitmap se na to vlastně skoro nikdy "nepřijde", protože je jejich velikost mocninou dvou a i u šestnáctibarevných bitmap je výsledek dělitelný čtyřmi, ale u AND-bitmap tento problém může nastat.

jenom dotaz: je mozne ze jsem to spatne pochopil, ale z tohohle clanku mi prijde ze barvy jsou ukladany v poradi cervena, modra a pote zelena… ale v popisu struktury RGBQuad je to obracene… jak to tedy je?