Názory k článku
Grafický formát BMP - používaný a přitom neoblíbený

BMP muze mit i 32 bpp, byt je to v zasade nestandardni a problematicke (ale vyskytuji se).

Jj, mam tu 32bit BMP s validni alfou i 32 bit BMP kde neni alfa, ale jen aligment 0.

R.

No mohou byt i 16-ti bitove, ty uz celkem standardni jsou (videl jsem jich hodne).

Muzete prosim uvest odkaz na par obrazku, rad bych si prozkousel funkcionalitu nekolika prohlizecu a grafickych editoru (Win i Lin) na 16-bitovych bpp.

Treba na adrese http://entropymine.com/jason/bmpsuite/ lze stahnout sadu BMP v ruznych formatech na testovani.
16 bit BMP soubory maji v hlavicce hodnotu biCompression na BI_BITFIELDS a za hlavickou jsou potom ulozeny bitove masky pro RGB. Teoreticky lze pouzit jakekoliv masky, ale vetsina programu zvladne jen 5-5-5 a 5-6-5 rozlozeni bitu.

Mockrat dekuju, uvidime, jak si s temi obrazky prohlizeci programy poradi...

Jesli jsem to v clanku prehledl tak sorry, ale to ze se do WinAPI obrazek musi davat vertikalne otoceny neni tak uplne pravda. Pro radu (asi i vetsinu) funknci se mu da zadat 'zaporna' vyska, tedy -100 napriklad, a pak se tech 100 scan radku zadava 'normalnim' zpusobem :) Je to popsane i nekde v SDK a cloveku tohle dokaze usetrit dost prace, protoze aby system bezel kvuly jednomu portu do widli 'obousmerne' stoji hrozne prace (sice mame makra, ale dost to zneprehledni kod). A pripadne live obraceni zace CPU...

R.

Ano, ale u nekterych funkci to stale dela problemy, zejmena u klasicke SetDIBitsToDevice(). U StretchDIBits() uz ne, ale zdrzeni zpusobene opacnym obrazkem je znacne. Moc dobre vim o cem mluvim, kdyz jsem zobrazoval video pomoci WinAPI, tak se "nucene" obraceny obrazek vykresloval tak 5x pomaleji, nez pri neobraceni. U CreateDIBSection() to obraceni vsak nefunguje vubec.

A ktere API jsou uplne bez problemu ? Aneb neni nad rozsireni nekterych fci typu "| 1" u HANDLE typu.

Ja jsem s nima problem nemel a byly i bezproblemove kompatibilni, a to zejmena prave tebuo zminovana SetDIBitsToDevice (~desitky tisic instalaci softu na vsech moznych i nemoznych win verzi). A co se tohodle toho tyce, tak nikdy nebyl reportovan zadny bug. Dokonce jsem nepozoroval ani zadny rychlosni rozdil.

Docela by mne zajimaly detajly, ikdyz uz po WIN zas tak moc primarne neprogramuju. Jesli mas minutku, budu rad jesli se podelis :)

R.

Pravda, s WinAPI jsem take mel problemy, ale zejmena to bylo spatnou dokumentaci (typicky se v ni nepopisovaly mezni stavy a rozdily mezi ruznymi verzemi Windows).

Problem se zobrazovanim je hlavne s tou rychlosti, nacital jsem video (pres nami vyvijenou PCI kartu pomoc bus-master prenosu) a zobrazoval pomoci WinAPI. Prvni problem je se zarovnanim obrazovych radku, ale to se da se skripenim zubu vyresit firmwarem na karte. Dale s obracenim obrazku, to karta nezvladne a musi se to resit volanim SetDIBitsToDevice. Mozna to bylo ovladaci, ale na technologickych PC bylo obraceni obrazku pres SetDIBitsToDevice opravdu dost pomale a nedarilo se zobrazovat cely video tok.

Nakonec jsem obrazky obracel sam, ale dovedete si asi predstavit, co to v realu udela z cachkou :-(

Nekde mam vysledky nejakych mereni, sice nejsem u sveho PC, ale zkusim to najit a tady odpublikovat.

Spise teoreticky je problem se specifikaci obdelniku, ktery se ma vykreslovat - obrazek se sice vykresluje zdola nahoru, ale obdelnik je zadany presne naopak. Obrazky najdete v knizce Charlese Petzolda (asi se nesmi v elektronicke podobe distribuovat, ale zkuste google:"petzold .chm").

Tak jsem ty vysledky konecne nasel, mrknete se na to:

Operace                Funkce            1bpp 8bpp 24bpp
Přímé zobrazení        SetDIBitsToDevice  493  344   47 
Změna měřítka          StretchDIBits      142  252  128 
Horizontální zrcadlení StretchDIBits       17   36   11 
Vertikální zrcadlení   StretchDIBits       20   51   13 
Přímé zobrazení        DrawDibDraw        493  344   49 
Změna měřítka          DrawDibDraw        141  248  208 

Je vypsan pocet zobrazeni bitmapy za sekundu na systemu Celeron 900MHZ, 256MB RAM, GeForce MX200, obrazky mely rozliseni 756x287 pixelu. Samozrejme nejpomalejsi je horizontalni zrcadleni, ale i vertikalni je o dost pomalejsi.

Zajimave take je, ze DrawDibDraw() je stejne rychle jako SetDIBitsToDevice(), i kdyz by se podle dokumentace melo jednat o dost rychlejsi funkci.

V tabulce je pouze StretchDIBits() a opravdu na to toto bylo testovano.

Člověče nešťastná, GDI je na zobrazování videa zcela nevhodný nástroj. Když už to dělám, tak použiju BitBlt, který je i podle MSDN rychlejší, než SetDIBitsToDevice; nebo ještě lépe používám DDB. Ale správně je samozřejmě použít DirectDraw, resp. dnes Direct3D, což je o řád rychlejší. Kdyby přehrávače médií zobrazovaly přes GDI, moc multimédií bychom ve Windows neužili :)

To všechno samozřejmě vím, ale je zde několik "ale":

- BitBlt nemůžu použít, protože nemám formát kompatibilní s platným kontextem. A použít něco na způsob CreateCompatibleBitmap a potom BitBlt vyjde ještě hůře než SetDIBitsToDevice. Na "rychlé" bitmapy jsou zde funkce začínající na Draw...., ale jak jsem ukázal na tabulkách, tak v našem případě jsou stejně rychlé, jako ty klasické WinAPI. Opakuji, bitmapy dostávám z PCI karty, s žádným DDB si hrát tedy nebudu, protože to stejné za mě udělá SetDIBitsToDevice.

- můžete mi prosím ukázat, jak zobrazit bitmapu v našem formátu (740x287@grayscale) pomocí DirectX? Samozřejmě je možné nahodit grayscale/paletový grafický režim, ale to nebude fungovat na všech počítačích, resp. ne všechny drivery umí 8bpp, takže sice přímý přístup do obrazové paměti mám, ale samotná zobrazovací smyčka je pomalejší než ono haněné SetDIBitsToDevice. Nehledě na to, že "ruční" přepočet mi zatíží CPU a to je věc, které se prostě musím zbavit, vše potřebuju hodit na grafickou kartu.

Nakonec mě připadlo nejjednodušší celé slavné Directy i GDI prostě obcházet a zapisovat přímo do obrazové paměti. Třeba pro průmyslové počítače to není problém, tam stejně nikomu nebude vadit, že se bude obrazová paměť natvrdo přepisovat. A driver pro takovouto blbůstku je trapně jednoduchý: stačí zjistit počáteční adresu Video RAM (ehm, stejně bývá konstantní) z konfiguračních registrů PCI a potom tam nahrnout pixely naprosto stejným způsobem jako v případě Directů (bez obezliček typu Lock apod.)

Pokud mluvíme o průmyslových počítačích, tak není problém používat drivery, které 8bpp umí. Dále u DirectX se nabízí možnost použít textury ve formátu D3DFMT_P8 (8-bit color indexed).

Přímý zápis do paměti by byla alternativa, tedy pokud driver umí 8bpp, jinak bude mít překlad velmi podobné problémy, jaké zmiňujete.

No problem s temi drivery prave je, ja jsem ty pocitace nevybiral a pouzita deska mela nejaky Intelacky cipset, ktery i pri 8bpp mel mezi pixely padding. Ale to uz je jedno, zeptam se tedy jinak: dneska uz neni nutne, aby byla hodnota "lPitch" delitelna osmi? Pokud uz to neni podminkou (v dobe, kdy jsem na tomto projektu delal, se jeste pouzival samostatny DirectDraw), tak s Directy problem nebude.

S tim primym zapisem mate naprostou pravdu, jedina vyhoda byla absence volani Lock/Unlock.

lPitch se týká pouze DirectDraw, ale přiznám se, že detaily dynamických textur jsem nestudoval. Každopádně cokoliv bude rychlejší, než GDI.
Doporučil bych se podívat na DirectX SDK.

Prave ze ten problem s lPitch muze cele slavne Directy odstavit, resp. odstavit funkci Blt a BltFast.

Ja jsem dostaval z PCI zarizeni video ve formatu 740x287 pixelu. S tim neni problem, driver mi zaridil ulozeni do kontinualni pameti, tj. za 740 pixelem 1 radku nasledoval 1 pixel ze druheho radku apod. Problem vsak je, ze takto vytvorenou pixmapu NENI DirectX schopen prenest pomoci Blt ci BltFast a to proto, ze lPitch neni delitelny 8, ale jen 4. Proto bych musel:

a) celou pixmapu pomoci movu "rozsekat" na jednotlive radky a mezi ne vlozit 4 dorovnavaci byty. To mi vsak zatizi CPU, ktery je tam proto, aby nad bitmapou provadel nejake vypocty.

b) budu pixmapu prenaset sam bez pouziti Blt a BltFast, to vsak prinasi stejny problem jako bod a), ale je pravda, ze zatizeni je o 50% mensi. Jedine, v cem mi tady Directy pomuzou, je nastaveni grafickeho rezimu a funkce Lock a Unlock.

c) pouziju SetDIBitsToDevice, protoze ten vyzaduje zarovnani pouze na 4 byty (dword). Zatizeni CPU byva male (zalezi na driveru), ale nastava zde ten zminovany problem s otocenim pixmapy, popr. se zpomalenim pri otaceni.

Idealni reseni v tomto pripade neexistuje, snad jen zmena rozliseni videa, resp. prenosu celeho problemu na FPGA, ktere se na PCI karte nachazi.

Za daných okolností bych buď použil to Direct3D (a data bych mu dával jako dynamickou texturu), nebo bych opravdu bitmapu přenášel sám za pomocí DirectDraw (dnes už zastaralého, v DX tuším 8 už není). Výhodou DirectDraw oproti přímému zápisu do videopaměti je lock, absence problémů s adresací, a běh na veškerém DX kompatibilním HW. Samozřejmě objít problém změnou velikosti/alignmentu videa na té PCI kartě se přímo nabízí.

"Ve WinAPI se však používá "klasické" a přirozenější orientace souřadnic, které rostou od levého horního rohu směrem doprava a dolů"

Prirozenejsi je to mozna pro toho, kdo se narodil s monitorem misto papiru, ale za mych mladych let se vsechny grafy kreslili s pocatkem souradnic vlevo dole :-)

No ale zase se (alespoň latinkou) píše zleva doprava a shora dolů, ne? Já s tímhle konceptem problém nemám. Koneckonců, když máš okno, taky se do něj plní widgety od titulku dolů a nikdy ne naopak, takže levý horní bod mi opravdu přijde přirozenější. Je ale fakt, že zvyklý ze školy na kreslení grafů, jsem si taky myslel, že se pojede odspodu, ale tato úvaha je v daném kontextu podle mě prostě nelogická.

Cekal jsem tuto reakci :-) Pro lidi z IT je vsak opacna orientace myslim prirozena, vychazi uz z technologie zobrazovani a castecne i tisku. Ostatne i televize vykresluje obraz odshora dolu. A ze matematika neni konzistentni, to prece vsichni vi :-)

Ano, jsa odkojen uz na zakladni skole a zacatku gymplu mym CBM +4, mel jsem nemale problemy v descriptive (a pozdeji i fyzice) s otocenymi soustavami souradnic :-{
Dodnes mi dela problemy neco "spachat" v Corelu, ktery ma 0,0 vlevo dole.

Corel ma souradnice 0,0 vlevo dole??? Nikdy jsem si toho nevsiml. Znicil jste mi zivot!

;-)

A neda se to nejak otocit? Corel sice znam jen z rychliku, ale treba v AutoCADu neni problem souradny system jednoduse zmenit.

Dokonce ve 3D. ;-)

Pockej, pockej! Ja vyrustal se ZX pod polstarem a tam byl pocatek grafickeho rezimu taky vlevo dole (prikaz PLOT). A aby to nematlo, tak textovy rezim zas zacinal vlevo nahore (AT). Podle toho taky rutiny (spolu s velmi zajimavym skakavym usporadanim video pameti s pocatecnim bodem vlevo nahore) pro vypis znaku na obrazovku vypadaly.

A co se tyce televize... Docela urcite prvni televize vykreslovaly od zdola nahoru, protoze obrazovky byly hodne dlouhe a staly na spicce stinitkem nahoru a lidi se proto divali na obraz do zrcadla. Takze od zdola nahoru, i kdyz vlastne od nas ke zdi, a k tomu jeste vzhuru nohama.

O tech televizich jsem to nevedel, diky za informaci. Ja jsem cetl historii jeste starsich pristroju, zajimavy je napriklad Nipkovuv kotouc (jestli se tomu tak rikalo).

Speccy je docela vyjimka, treba Atarko i Komous mely plot 0,0 vlevo nahore. Ale hadat o tom, co je prirozenejsi, se nemuzu, bo jsem s jednim spektristou (zdravim Pettyho!) uzavrel mezi Atari a Speccym mir na vecne casy :-)))

Dobry den,

myslim ze by bylo vhodne dodat ze existuji take jine struktury hlavicky, napr. BITMAPV4HEADER a BITAMPV5HEADER. Novejsi programy pod Windows tyto rozsirene struktury mohou vyuzivat a je potreba s tim pocitat.

Format z OS/2 se take lisi vlastne jen strukturou pouzitou v hlavicce (ma mene polozek) a paletou ktera nema doplnene polozky o rezervovane hodnoty. Ty jsou tam zrejme pridany kvuli zarovnani na sudy pocet, stejne jako se doplnuji radky v souboru).

Popis je napriklad na:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmaps_2w1f.asp

Ano mate pravdu. Temto rozsirenim se budu venovat v dalsi casti, stejne jako zpusobu "zakontejnerovani" JPEGu a PNG do formatu BMP.

K čemu je dobrý článek popisující formát BMP ?? To už to tady vážně tak upadá, že se popisují věci dávno popsané... ?

Pro mě.

No napriklad proto, ze se v mem clanku o GIFu nekolik ctenaru ozvalo, ze by uvitali serial o grafickych formatech. Ale nebojte, po BMP se zacnu zabyvat necim mnohem zajimavejsim, nez primitivni rastry.

Ja bych taky od "Paji" clanek zrovna o beempecku necekal, nicmene je tak dobre napsany (jako vsechny ostatni), ze jsem si ho rad precetl.

Pravdou je, ze kdyz sem naposled potreboval neco ukladat ciste rastrove, tak jsem sahnul po tga formatu, ktery asi nebude o moc lepsi, ale aspon se tam nemusi resit to zarovnavani ;)

Me pripadne TGA o dost lepsi, minimalne v tom, ze se vsechny potrebne udaje o obrazku vlezou do 18bytove hlavicky a neni treba zpracovavat tu silenou hlavicku BMP. Take neni problem pracovat s grayscale obrazky, coz se zrovna me pro nektere aplikace hodi. TGA je jeden z mala formatu, ktere grayscale nativne podporuji.

moja laicka uvaha ohladom poradia farieb v palete :
poradie BGR v bitovej palete je mozno aj logicke (kedze pouziva little endian).
v big endian by bolo totiz poradie 0RGB (vratane uvodnej konstanty 0, teda "prirodzene"), po otoceni do little endian je z toho BGR0 (na prvy pohlad neprirodzene, ale pritom logicke :-) )

Ano, na PC je to logicke, ale v clanku jsem na to musel upozornit, uz jenom proto, ze starsi aplikace produkujici 24bpp BMP nekdy kanaly prevraci. Takze pri programovani je zapotrebi si davat pozor, hlavne pri implementaci funkci typu setColor(index, r, g, b) apod.

Když se občas (naštěstí velmi zřídka) dostanu na nějakou stránku a najednou se mi tam začne načítat obrázek(y) od spodu, tak už je mi to jasné a v duchu se ptám autora webu: PROČ? (Nebo podobně když se načítá xx JPG obrázků v plné velikosti, ale s rozměry náhledu). Poprvé mi to přišlo vtipné, to jsem ještě nevědělo co jde, ale teď už to rád nevidím :)

Jo a viděl jsem to zatím jen v Opeře, takže nevím, jestli ostatní prohlížeče taky načítají odspoda nebo až celý obrázek najednou...

Asi nejlepším důvodem použití BMP je jeho značná "blbuvzdornost" a možnost práce bez komprimace, které umožňují poměrně snadný grafický výstup z programu (poměrně snadno vyrobím podprogram, který mi vypočte pořadové číslo byte, vztahujícího se k bodu na x-tém sloupci a y-tém řádku). Dělat něco takového v .png znamená ještě navíc zohledňovat to, že ta data jsou uložena komprimovaná.
Takže je to formát volby, pokud mi má vylézt z programu nějaký bitmapový obrázek (který se už dá následně na cokoli převést).
A když jsem měl v DOSu 720kB RAM, tak jsem si nemohl dovolit celý ten obrázek vytvářet v paměti.

Zkuste misto toho pouzit TGA, hlavicka je jeste mnohem jednodussi (18 byte), "blbuvzdornost" :-) vetsi a krome toho se nemusi zarovnavat radky na 32 bitu.

Hmmm ... ja kdyz jsem prvne potreboval generovat obrazky v linuxu, tak jsem je vytvoril v pameti a pote otevrel pipe do programu convert z ImageMagick a nasypal to do nej jako raw. Dokonale primitivni, zadna komprimace, zarovnani ... a na disk se obrazek muze ulozit v libovolnem formatu. Ale stejne si myslim, ze to neni nejlepsi reseni - casem jsem se proto naucil jak se ImageMagick pouziva primo (jako knihovna).

"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%.

Několik poznámek: Windows interně používají DDB (Device Dependent Bitmap) a DIB (Device Independent Bitmap). Driver zařízení raději pracuje s DDB (drasticky zjednodušeno). DDB je hlavička obsahující rozměry bitmapy, velikost, šíře v bytech (dělitelná dvěmi, protože alignment), a vlastní obrázek v barvách vlastních danému zařízení (třeba 1-bit barva, 24-bit barva). DDB je tedy svázán se zařízením, pro které je určen. DIB je naopak nezávislý, a lze ho rastrovat na jakémkoliv zařízení (dekomprimovat, převést paletu, aplikovat barevné profily atd.). DIB může ukládat data ve formátu bottom-up (OS/2 style) i top-down. DIB umí i transparency a alpha channel.
BMP je DIB uložený na disk. Toto lze udělat přímo z API, a není k tomu třeba znalosti formátu BMP/DIB. Výhodou BMP je hlavně rychlý překlad na DDB, rychlé zobrazení. Vzhledem k roku vzniku a jeho účelu nemá smysl jej srovnávat s GIF, PNG apod. Srovnání je možné řekněme s formáty XBM, XPM a TGA.

Položky palety jsou zřejmě 4-bytové kvůli alignmentu - na některých platformách (třeba Alpha) nelze adresovat byte, který neleží na adrese dělitelné dvěma. Ale vyjma typu tagRGBQUAD existuje i tagRGBTRIPLE, který má opravdu jen RGB (fyzicky BGR). Oboje je deklarováno ve Wingdi.h, není třeba si pamatovat pořadí barev :)

Pravda, díky za upřesnění DIB/DDB. DDB jsem se v článku nezabýval, v kontextu grafických formátů to IMHO nemá smysl (DDB se většinou na disk neukládá, právě kvůli tomu D-dependent, na ukládání se jedná o málo trvalou informaci).

Porovnávat BMP s GIF a PNG (i JPEG apod.) smysl samozřejmě má, protože ho někteří uživatelé používají pro obdobnou činnost - prezentaci obrázků na Webu (ehm...), ukládání "svých" grafických výtvorů apod.

Opravdu je překlad DIB (BMP) na DDB tak rychlý? No neřekl bych, je prakticky stejně rychlý, jako z kteréhokoli jiného formátu, pokud tedy už bitmapa není uložena v paměti. A v případě velkých obrázků je spíše rychlejší konverze z něčeho komprimovaného (i když BMP může "zakontejnerovat" třeba i JFIF).