BMP

Níže uvedená tabulka poskytuje přehled polí. Podrobné informace naleznete v sekcích níže.

Bitness obrázku (pole BitCount)

Pole BitCount obsahuje počet bitů na pixel. Pokud je tam uvedena nenulová hodnota, jedná se o skutečnou bitovou hloubku. Pokud jsou pixely uloženy ve formátu JPEG nebo PNG, je uveden nulový obsah pole BitCount. Potom bude skutečná bitová hloubka určena těmito formáty. Bity čistého formátu BMP jsou uvedeny v tabulce níže:

Poznámky k tabulce:
1. Sloupec "BITMAPINFO" zobrazuje podporu bitové hloubky pouze od společnosti Microsoft.
2. Windows CE 1.0 a 1.01 podporují pouze bitové hloubky 1 a 2 [14] .
3. GDI+ verze 1.0 16bitové barevné kanály lze pouze číst a okamžitě je převést na 8bitové [15] .

V bitových hloubkách 8 a nižších je barva pixelu označena indexem v tabulce barev, ve vyšších bitech přímou hodnotou v barevném modelu RGB . Alfa kanál lze volitelně přidat v 16 a 32 bitech, v 64 bitech je trvale přítomen.

Tabulka ukazuje pouze bitness, který Microsoft zdokumentoval. Samotný formát neobsahuje žádná zásadní omezení pro použití jakýchkoli zde neuvedených bitů.

1bitové soubory BMP s čistě černou (bit off) a bílou (bit on) se nazývají monochromatické. Takové soubory se obvykle používají jako masky pro jiné bitmapy. Možná jste neustále naráželi právě na takové 1bitové rastry. Formát Windows Bitmap ve skutečnosti neklade žádná omezení na to, jaké barvy budou použity pro jednotlivé bitové hodnoty.

Můžete se také setkat s následujícími názvy bitů: CGA pro dva bity, EGA pro čtyři, HiColor (HighColor) pro 16 bitů, TrueColor pro 24 a 32 bitů s průsvitností, DeepColor pro vysoké bity a případně další. Tyto názvy pocházejí z vývoje barevných bitmapových displejů a odkazují spíše na jejich barevnou hloubku . V době, kdy byl tento článek napsán (2014), se takové názvy již dlouho nepoužívaly kvůli silnému rozšíření 24bitových zařízení (místo toho je jednoduše uvedena barevná hloubka v bitech nebo jejich počet). A soubory BMP s nižší bitovou bitvou se ve větší míře ukládají nikoli pro zobrazení na zařízeních CGA nebo EGA, ale pro kompaktnost ve srovnání s 24bitovými a 32bitovými formáty při použití malého počtu barev.

Kompresní pole

Pro každou skupinu bitů se používají samostatné omezené hodnoty komprese, ale v souhrnu jsou jejich hodnoty jedinečné. Microsoft zdokumentoval následující hodnoty (v tabulce jsou uvedeny názvy konstant od této společnosti):

Vzorník barev

Tabulka barev je součástí bloku BITMAPINFO a lze ji použít dvěma způsoby:

1. Je nutně přítomen v bitových hloubkách 8 a nižších, ve kterých je barva pixelu určena indexem buňky z něj.
2. V bitových hloubkách 8 a vyšších, ve kterých je barva indikována okamžitou hodnotou, je tabulka přítomna, pokud je použita hlavička jiné než CORE verze, ve které pole ClrUsed obsahuje nenulovou hodnotu. Zde se již používá k optimalizaci barev při práci se zařízeními pomocí palet (v dokumentaci není přesně řečeno, jak se optimalizace provádí).

Pozice tabulky barev je určena od jejího začátku bloku BITMAPINFO. Standardně přichází hned za informační strukturou (její velikost bez znaménka v bajtech lze přečíst z prvního 32bitového pole). Ale mezi strukturou s poli a tabulkou barev lze pro extrakci barevných kanálů použít čtyřbajtové bitové masky (platí pouze pro 16 a 32 bity). Jsou zde pouze v případě, že je použita informační struktura verze 3 (Velikost = 40) a pole Komprese obsahuje 3 (BI_BITFIELDS) nebo 6 (BI_ALPHABITFIELDS). Potom je třeba k velikosti informačních polí přidat 12 bajtů (pokud je zadáno BI_BITFIELDS) nebo 16 bajtů (pokud je zadáno BI_ALPHABITFIELDS) [17] . Ukazuje se 6 možností umístění stolu:

Počet buněk v tabulce je určen poli BitCount a ClrUsed. Při bitové hloubce 8 a méně se maximální počet buněk v tabulce bere jako 2 bity : 2 v jednobitovém rastru, 4 ve dvoubitovém rastru, 16 ve 4bitovém rastru a 256 v 8 - bit jedna. V dané bititě tabulka vždy obsahuje tento maximální počet buněk, pokud je použita hlavička verze CORE (Velikost = 12) nebo pokud pole ClrUsed obsahuje v jiných verzích 0. Ve všech ostatních případech bez ohledu na bitovou hodnotu tabulka obsahuje tolik buněk, kolik je uvedeno v poli ClrUsed [18] .

Tabulka samotná je jednorozměrné pole, které může obsahovat tři typy buněk:

1. 32bitová struktura RGBQUAD . Používá se, pokud je v BITMAPINFO použita informační struktura verze 3, 4 nebo 5. V samotné struktuře RGBQUAD je barva v modelu RGB uvedena ve čtyřech bajtových buňkách (všechny mají typ BYTE WinAPI): rgbBlue (modrá) , rgbGreen (zelená), rgbRed (červená) a rgbReserved (rezervovaná a musí být nastavena na nulu).
2. 24bitová struktura RGBTRIPLE . Platí, pokud BITMAPINFO začíná strukturou BITMAPCOREHEADER. RGBTRIPLE se skládá ze tří bajtových buněk (WinAPI typu BYTE), které určují barvu v modelu RGB : rgbtBlue (modrá), rgbtGreen (zelená) a rgbtRed (červená).
3. 16bitové indexy barev (celá čísla bez znaménka) v aktuální logické paletě kontextu zařízení ( systémové objekty Windows GDI ). Toto zobrazení je dostupné pouze při spuštěné aplikaci. Formát BMP nepodporuje explicitní označení použití takové tabulky, a proto na to aplikace sama upozorní funkce WinAPI ve speciálních parametrech (obvykle konstanta DIB_PAL_COLORS).

V celé tabulce nelze použít všechny buňky a pole ClrImportant obsahuje počet buněk od začátku tabulky po poslední použitou (včetně sebe). Hodnota 0 v poli ClrImportant znamená, že je použita celá tabulka. Zapojené buňky je lepší umístit na úplný začátek tabulky a doporučuje se seřadit je v sestupném pořadí podle důležitosti (v případě, že musíte snížit jejich počet).

Masky pro extrahování hodnot barevného kanálu

Pokud je obraz 16 nebo 32 bitů, lze pro extrakci barevných kanálů zadat 32bitové masky. Je to proto, že 16 není násobkem 3, a proto mohou být bity přiděleny různými způsoby. Pro pohodlí používají 32bitové obrázky 8bitové kanály, a proto se jejich podpora může zdát nadbytečná. Ve skutečnosti zde maska ​​umožňuje povolit / zakázat alfa kanál nebo nastavit pořadí komponent, které vám vyhovuje, a nejen upravit jejich rozlišení. Při použití masek je buňka pixelu čtena celá jako odpovídající strojové slovo v little-endian.

Přítomnost bitových masek závisí na verzi informačních polí struktury BITMAPINFO a pole Komprese v ní. Pro verzi CORE nelze zadat libovolné masky, protože neexistuje pole Komprese a samostatná pole masky. V jiných verzích jsou masky barev povoleny, pokud komprese obsahuje 3 (BI_BITFIELDS). Maska alfa kanálu se vždy používá ve verzích 4 a 5. Protože Windows CE nepodporuje tyto dvě verze, ve kterých je pro ně speciální pole, byla pro třetí verzi zavedena hodnota 6 (BI_ALPHABITFIELDS) pole Komprese, který přidává jak barevné masky, tak maskovací alfa kanál (podporovaný od Windows CE .NET 4.0).

Pozice bitových masek je pevná bez ohledu na verzi záhlaví: 36 h v celém souboru nebo 28 h od začátku bloku BITMAPINFO. Ve verzích 4 a 5 se na tomto místě nacházejí pole určená přímo pro ně. Ve verzi 3 by se bitové masky měly nacházet hned za informačními poli, a tak přesně spadají do pozic odpovídajících polí ve starších verzích. Vezměte prosím na vědomí, že ve třetí verzi, pokud existují masky, je tabulka barev posunuta o 12 nebo 16 bajtů dopředu, umístěná bezprostředně za nimi. 4bajtové barevné masky jsou v pořadí červená, zelená, modrá. Maska alfa kanálu je již za nimi.

Dokumentace společnosti Microsoft se vztahuje pouze na jeden povinný požadavek na bitové masky: každá maska ​​musí být souvislá. O případu průniku masek je tam řečeno, že je žádoucí to nedělat [19] . Microsoft také říká, že není nutné používat všechny bity pixelu [20] . Neexistují žádné požadavky na obsah nepoužitých bitů.

Všimněte si, že nikdo nezaručuje, že lze použít masky širší než 8 bitů. A nic se neříká o případě, kdy jakýkoli kanál bude mít nulovou masku (například když se opravdu nepoužívá). Zde je možná situace, kdy všechny komponenty budou mít nulové masky a zůstane jeden alfa kanál (který v tomto případě může obsadit všechny bity). Nulová maska ​​barevného kanálu může být interpretována dvěma způsoby: její hodnota je brána jako nula, nebo pixely tohoto kanálu nejsou při kreslení ovlivněny. Pokud vezmeme první interpretaci s jediným alfa kanálem, pak alfa kanál v podstatě nastaví stupeň zčernání pixelu. Kromě vágních možností je tu i jedna zajímavá. Vzhledem k tomu, že křižovatky nejsou zakázány, je možné nastavit všechny kanály do jedné polohy a tím získat stupně šedi .

Některý software má omezenou sadu podporovaných bitových masek. Níže uvedená tabulka uvádí možnosti dostupné v těchto omezených prostředích:

Poznámky k tabulce:
(a) Tyto sady se standardně používají při 16 a 32 bitech, pokud nejsou specifikovány masky pro extrakci barev.
(b) Tato sada masek ve své podstatě implementuje 16bitové stupně šedi.

Pixelová data

V souboru lze polohu pixelových dat nalézt v poli OffBits struktury BITMAPFILEHEADER. Za běhu aplikace ukládá adresu pixelových dat tam, kde je to vhodné. V dokumentaci Microsoftu jsou také zmíněny tzv. sbalené bitmapy , které jsou označeny jedinou adresou bloku BITMAPINFO. U takových bitmap následují pixelová data bezprostředně za záhlavím (včetně, kromě informačních polí, bitových masek a barevné tabulky) [24] .

Velikost pixelových dat v bajtech je uložena v poli SizeImage struktury BITMAPINFO. Je tam zapsána „surová“ velikost toho souvislého bloku, který obsahuje data pro tvorbu pixelů (bez ohledu na formát), a ne nějaký rozbalený. Ve výchozím nastavení musí toto pole obsahovat aktuální hodnotu, protože jej lze použít k přesnému zjištění, kolik bajtů by se mělo ze souboru přečíst, abychom získali pixely. Je však legální ponechat toto pole nulové při ukládání pixelů jako dvourozměrných polí (když pole Komprese obsahuje hodnotu 0 (BI_RGB), 3 (BI_BITFIELDS) nebo 6 (BI_ALPHABITFIELDS) [25] ). Pak lze velikost pixelů v případě potřeby poměrně rychle vypočítat na základě bitové hloubky, šířky a výšky rastru.

Existují tři způsoby, jak uložit obrazové body ve formátu Windows Bitmap (viz také část Kompresní pole v tomto článku):

1. 2D pole .
2. RLE kódování (pouze pro 4 a 8 bitů).
3. Ve formátech JPEG nebo PNG .

Níže uvedené podsekce popisují každou z nich samostatně.

Určení barvy a hodnoty alfa kanálu

K určení barvy při uložení ve formátu BMP se bez ohledu na to, jak je specifikována, používají pouze celá čísla bez znaménka. Samotnou barvu pixelu lze nastavit dvěma způsoby:

1. Index v tabulce barev (s bitovou hloubkou 8 a nižší).
2. Okamžitá hodnota v barevném modelu RGB (s bity nad 8).

Druhý je užitečný, když je sada barev poměrně velká nebo nepředvídatelná (například při zpracování obrazu). První metoda poskytuje jak kompaktní rozvržení s malou sadou barev, tak určité pohodlí při správě použitých barev (stačí změnit hodnotu barvy v paletě). Samotná tabulka barev je specifikována buď jako 16bitové indexy bez znaménka v systémové paletě (viz část " Tabulka barev " v tomto článku), nebo v RGB jako v pixelu, ale výhradně pomocí 8bitových hodnot kanálu.

Index v tabulce barev je číslo buňky v ní od začátku tabulky (používá se souvislé číslování od nuly). Pro každou bitovou hloubku je maximální index zásadně omezen hodnotou 2 bitová hloubka - 1. Ve skutečnosti je omezen i počtem prvků v tabulce (podrobnosti v sekci " Tabulka barev " tohoto článku). Společnost Microsoft nezdokumentovala chování, když je zadán index mimo tabulku, ale GDI v tomto případě bere černou barvu.

V bitových hloubkách nad 8 je barva pixelu indikována přímo v barevném modelu RGB: úroveň červené, zelené a modré je indikována samostatně. Nulová hodnota kteréhokoli z kanálů znamená úplnou absenci odpovídajícího odstínu a maximum: jeho úplnou přítomnost. Rozlišení hodnot kanálu je variabilní a má své vlastní v každé bitové hloubce (konkrétní hodnoty naleznete v části o ukládání pixelů ve dvourozměrném poli tohoto článku). Přitom v bitových hloubkách 16 a 32 lze nastavit nejen libovolné rozlišení, ale i individuální pro každý kanál (např. 5 bitů pro červenou a modrou, ale 6 bitů pro zelenou). Navzdory velkému množství možností nastavení rozlišení hodnot není v dokumentaci Microsoftu uvedeno, jak změnit rozlišení hodnoty. Z tohoto důvodu mohou různí výrobci softwaru získat různé výsledky při změně bitové hloubky.

Při přímém nastavování barvy pixelu, kromě hodnot RGB, umožňuje formát Windows Bitmap volitelně také nastavit hodnoty alfa kanálu . Pokud jde o bitovou hodnotu a kódování hodnot, je shodný s barevnými kanály: má libovolnou bitovou hodnotu a používají se celá čísla bez znaménka. Pokud jde o shodu hodnot, nula odpovídá úplné průhlednosti a maximální dostupný počet odpovídá úplnému vyplnění.

Dvourozměrné pole

Pixely libovolné bitové hodnoty mohou být uloženy ve dvourozměrném poli. Při této metodě ukládání obsahuje pole Komprese hodnotu 0 (BI_RGB), 3 (BI_BITFIELDS) nebo 6 (BI_ALPHABITFIELDS). Pokud se použije hlavička verze CORE, pak jsou pixely stejně uloženy pouze jako dvourozměrné pole.

V tomto rozložení jsou rastrové pixely zapsány jako jednopixelové vodorovné pruhy, které Microsoft ve své dokumentaci často nazývá „ skenuje “ (v ruštině je nejbližší slovo lines ). V paměti jsou tyto řádky zapsány v pořadí, ale s kladnou Výška: počínaje od spodního ( anglicky  bottom-up bitmap ) a se zápornou Height: od samého vrcholu ( anglicky  top-down bitmap ). V každém vodorovném řádku jsou pixely zapsány pouze zleva doprava. Pixely menší než 8 bitů jsou umístěny v bajtech a vyplňují bity od nejvyšší k nejnižší, což má za následek hexadecimální/binární číselné hodnoty pixelů podobnější výstupnímu obrázku. Pokud je bitová hloubka 16 nebo 32, pak je zpracování prováděno celými strojovými slovy stejné velikosti s pořadím bitů od nízké po vysokou (little-endian). Řádky bez ohledu na velikost buňky musí být doplněny nulami až do násobku čtyř bajtů velikosti [8] . Z tohoto důvodu se při nenásobné šířce obrázku mohou na konci řádků objevit nevyužité bity nebo celé bajty. Ale díky zaručené násobnosti velikosti řádku lze zpracování provádět s 8-, 16- nebo 32-bitovými strojovými slovy, jak si vyberete. A Microsoft má stále následující trend v bitových hloubkách větších než 8: modrá (modrá) složka je umístěna v nižších bitech / prvních bajtech, zelená (zelená) v dalších a červená (červená) je starší / nejvzdálenější, a pokud existuje alfa kanál, pak je v nejvýznamnějších bitech/posledních bajtech.

Níže uvedený diagram ukazuje uspořádání pixelů v bitech menších než 8 :

bitů	7	6	5	čtyři	3	2	jeden	0
1 bit	0	jeden	2	3	čtyři	5	6	7
2 bity	0		jeden		2		3
4 bity	0				jeden

Při 16 a 32 bitech jsou pixely zpracovávány strojovými slovy stejné velikosti (za předpokladu pořadí bajtů little-endian), která aplikují masky bitů kanálu . Pokud nejsou zadány žádné jednotlivé bitové masky, bude struktura vypadat následovně. Při 16 bitech je každému kanálu přiřazeno 5 bitů. Modrá je v nejméně významných bitech (maska ​​001F 16 ), zelená je na pozici 5 (maska ​​03E0 16 ), červená: začíná od 10. bitu (maska ​​7C00 16 ) a zbývající nejvýznamnější bit 15 se nepoužívá. Pokud je použito 32 bitů, pak je standardně každému kanálu přiřazen bajt (8 bitů). Komponenty jsou uspořádány podobně: modrá v nízkých bitech (maska ​​0000:00FF 16 ), zelená začínající bitem 8 (maska ​​0000:FF00 16 ), červená začínající bitem 16 (maska ​​00FF:0000 16 ) a horní bajt je nepoužívá se (používá se jako alfa kanál, pouze pokud jej zobrazíte přímo) [26] . Protože se předpokládá, že se čte v pořadí bajtů little-endian, pokud čtete hodnoty z paměti bajt po bajtu, budou ve stejném pořadí (modrá bude na prvním místě).

S bitovou hloubkou 24 má každý kanál bajt a s bitovou hloubkou 48 a 64 : 16bitové strojové slovo. Ve všech třech případech v paměti jdou barevné složky v pořadí: modrá, zelená, červená. V 64bitových BMP jsou barvy navíc následovány 16bitovým alfa kanálem. Pokud chcete zpracovat 64bitový pixel jedním strojovým slovem, pak v little-endian blue bude spodních 16 bitů a alfa kanál bude ve vyšších. Zelená bude vedle červené a modrá - vedle alfa. A můžete vidět, že ve 24 bitech formát pixelů odpovídá struktuře RGBTRIPLE z tabulky barev.

RLE kódování

Použití kódování RLE společností Microsoft je zdokumentováno pouze pro bitové hloubky 4 a 8. Při použití v BITMAPINFO musí pole Komprese obsahovat 2 (BI_RLE4) při bitové hloubce 4 nebo 1 (BI_RLE8) s osmibitovými pixely. Výška rastru musí být zadána jako kladné číslo.

Ve formátu Windows Bitmap lze kódování RLE přirovnat ke kreslení pomocí jednoduchých příkazů. Kreslení začíná od levého dolního pixelu (pozor: v rastrech obecně může být levý horní pixel známější) a pokračuje doprava a nahoru. Pixely mimo velikost bitmapy nejsou vykresleny (toto není uvedeno v dokumentaci, ale GDI vykazuje toto chování). Instrukce RLE umožňují přerušit kreslení vodorovné čáry, celého obrázku a také přesunout kreslící kurzor na jinou pozici. V důsledku toho se některé pixely nemusí vykreslit. Dokumentace výslovně neuvádí barvy pro nevykreslené pixely, v důsledku čehož se může interpretace lišit: chybějící pixely buď zůstanou průhledné, nebo získají barvu s indexem 0. Pokud uděláme první předpoklad, pak můžeme říci, že 4- a 8 -bitové režimy díky RLE implicitně podporují transparentnost, ale toto chování není zaručeno.

Tvorba obrazu při RLE kódování se provádí příkazy. Každý příkaz musí nutně začínat sudou adresou (zarovnanou na 16bitovou hranici). Existuje pět příkazů, které jsou definovány dvojicí bajtů:

Bajt 1 (hexadecimálně)	Bajt 2 (hexadecimálně)	Popis
01..FF _ _	00..FF _ _	Počínaje aktuální pozicí a pohybem doprava nakreslete tolik pixelů, kolik je určeno v prvním bajtu. Hodnoty pro pixely jsou převzaty z druhého bajtu. V 8bitových BMP je celý bajt hodnotou. Ve 4bitech se z něj postupně odebírá nejvyšší nibble a poté nejnižší nibble (čtyři bity).
00	00	Přesuňte kurzor na začátek (zcela vlevo) další (horní) horizontály.
00	01	Zastavit kreslení (dosaženo konce).
00	02	Posuňte kurzor doprava a nahoru o hodnoty zadané v následujících dvou bytech. První následující bajt obsahuje hodnotu pro horizontální posun a další bajt obsahuje hodnotu pro vertikální posun. Obě hodnoty: celá čísla bez znaménka (nelze je posunout doleva ani dolů).
00	03..FF _ _	Z aktuální pozice a dále doprava nakreslete pixely s hodnotami, které následují za tímto párem bajtů. Druhý bajt příkazu obsahuje počet pixelů, které se mají překreslit (jmenovitě pixely, nikoli bajty). V 8bitovém rastru se bajtový proud bere tak, jak je. Ve 4bitech se již čtou nibble: horní 4 bity z bajtu pro první pixel, spodní 4 bity pro další atd. z následujících bajtů. Tento proud může končit lichým počtem bajtů a instrukce vyžadují 16bitové zarovnání. Pokud k tomu dojde, přidá se další bajt (na jeho obsahu nezáleží).

Po dosažení pravého okraje vodorovné roviny se neprovádí žádný posun na další. Proto je potřeba konkrétně vložit příkaz k ukončení řádku. A jak můžete vidět z tabulky, sada příkazů vám neumožňuje posunout se dolů nebo vrátit se do vodorovné polohy. Proto můžete přestat kreslit, pokud dosáhnete horního okraje.

Vkládání dat ve formátech JPEG a PNG

Počínaje Windows 98/ME a 2000/XP vám systémové funkce umožňují ukládat pixely ve formátech JPEG a PNG . O míře podpory těchto dvou formátů systémem není nic známo.

Chcete-li vložit JPEG nebo PNG, musíte resetovat pole BitCount v BITMAPINFO a zadat hodnotu 4 (BI_JPEG) nebo 5 (PI_PNG) v Compression. Hodnota pole SizeImage se v tomto případě bude rovnat velikosti souboru JPEG nebo PNG, který je vložen na místo obrazových dat tak, jak je. Šířka a výška v záhlaví jsou již uvedeny pro dekódovaný obrázek. O znaménku pole Výška pro tento konkrétní případ dokumentace přímo nic neříká, ale zřejmě je nutné zapsat zápornou hodnotu [16] .

Rozlišení obrázku

Pro porovnání bezrozměrných pixelů s rozměry materiálu se používají pole XPelsPerMeter a YPelsPerMeter. V těchto polích celé číslo udává, kolik pixelů v tomto obrázku připadá na jeden lineární metr, samostatně horizontálně (XPelsPerMeter) a vertikálně (YPelsPerMeter). Microsoft deklaroval tato dvě pole jako číselný typ se znaménkem, ale dokumentace neříká nic o záporných hodnotách. O hodnotě nula se také nic neříká, ale je logičtější ji brát jako neurčité rozlišení, když je neznámá nebo nemá žádnou hodnotu.

Rozlišení se často uvádí ne s odkazem na metrické rozměry, ale v bodech na palec ( DPI / PPI ). Pro posun tam a zpět se bere palec rovný 25,4 mm (anglický palec). Matematické vzorce pro převod pixelů/palec (PPI) na pixely/metr (PPM) a naopak:

Pokud máte zájem o přesný celočíselný překlad, pak vyjdou následující výrazy:

PPM = (PPI * 5000 + 64) / 127 PPI = (PPM * 127 + 2500) / 5000

Po nich se zaokrouhlí na nejbližší celé číslo. Pokud chcete zaokrouhlit dolů, nepřidávejte polovinu dělitele. Pokud chcete nahoru, přidejte dělitel zmenšený o jedna.

Níže jsou uvedeny předem vypočítané hodnoty PPM pro některé PPI/DPI:

• 96 ppi ≈ 3780 str./min (pro monitory Microsoft)
• 72 ppi ≈ 2835 ppm ( Apple pro monitory)
• 150 dpi ≈ 5906 str./min
• 300 dpi ≈ 11811 str./min
• 600 dpi ≈ 23 622 str./min

Barevný prostor

V informačních polích je hlavním polem určujícím barevný prostor pole CSType. Jeho povolené hodnoty jsou uvedeny v tabulce níže:

Význam		BITMAPINFO verze [27]	Konstantní jméno	Popis
hex	Text
0	(Ne)	čtyři	LCS_CALIBRATED_RGB	Úprava na základě hodnot Endpoints, GammaRed, GammaGreen a GammaBlue.
73524742	'sRGB'	čtyři	LCS_sRGB	Je použit barevný prostor sRGB .
57696E20	"Vyhrát" [28]	čtyři	LCS_WINDOWS_COLOR_SPACE	Výchozí systémový prostor (sRGB).
4C494E4B	'ODKAZ'	5	PROFILE_LINKED	Barevný profil v jiném souboru.
4D424544	'MBED'	5	PROFILE_EMBEDDED	Barevný profil obsažený v tomto souboru.

Microsoft deklaroval hodnoty konstant nikoli jako číselné hodnoty, ale jako čtyřznakové textové hodnoty [29] . V tomto případě tvoří kódy znaků bajty 32bitové hodnoty (kód ASCII znaku zcela vpravo je dolní bajt, kód znaku nejvíce vlevo je horní bajt). Při prohlížení binárního obsahu souboru jako textu se takové hodnoty zakódované v ASCII zobrazí pozpátku (například „KNIL“ spíše než „LINK“).

Koncové body a hodnoty gama

Formát Windows Bitmap umožňuje korekci barev zadáním červených, zelených a modrých koncových bodů a také hodnot gama . K tomu musí pole CSType obsahovat hodnotu 0 (LCS_CALIBRATED_RGB). Opravné hodnoty se zapisují do polí Endpoints, GammaRed, GammaGreen a GammaBlue (u ostatních hodnot CSType jsou tato čtyři pole ignorována).

36bajtové pole EndPoints je struktura CIEXYZTRIPLE, která se skládá ze tří polí ciexyzRed (červený koncový bod), ciexyzGreen (zelený bod) a ciexyzBlue (modrý). Tato tři pole jsou zase také CIEXYZ struktury se třemi poli ciexyzX, ciexyzY a ciexyzZ typu FXPT2DOT30. PXPT2DOT30 je 32bitové číslo s pevnou řádovou čárkou bez znaménka se 2 vysokými bity pro celočíselnou část a 30 nízkými bity pro zlomkovou část.

Hodnota gama se zapisuje do příslušných polí pro každý barevný kanál zvlášť: GammaRed (červená), GammaGreen (zelená) a GammaBlue (modrá). V deklaraci informačních struktur Microsoft pro tato pole specifikoval typ DWORD. Zároveň je v souboru WinGDI.h vhodnější deklarace typu FXPT16DOT16 (na základě typu long), což je 32bitové číslo bez znaménka se zlomkovou částí v dolních 16 bitech a celé číslo. část v 16 vyšších. Je třeba poznamenat, že v MSDN je na stránkách o strukturách BITMAPV4HEADER a BITMAPV5HEADER vše řečeno. V článku o struktuře LOGCOLORSPACE je řečeno, že v podobných polích by měl být vysoký a nízký bajt nastaven na nulu (ve skutečnosti je místo formátu 16.16 použit formát 8.8, který je umístěn uprostřed 32 -bitová buňka) [30] .

Níže jsou uvedeny hodnoty výše uvedených čtyř polí podle barevného prostoru sRGB [31] :

Pole	Význam
	Zlomkové	hex
EndPoints.ciexyzRed.ciexyzX	0,64	28F5C28F
EndPoints.ciexyzRed.ciexyzY	0,33	151EB852
EndPoints.ciexyzRed.ciexyzZ	0,03	01EB851F
EndPoints.ciexyzGreen.ciexyzX	0,30	13333333
EndPoints.ciexyzGreen.ciexyzY	0,60	26666666
EndPoints.ciexyzGreen.ciexyzZ	0,10	06666666
EndPoints.ciexyzBlue.ciexyzX	0,15	0999999A
EndPoints.ciexyzBlue.ciexyzY	0,06	03D70A3D
EndPoints.ciexyzBlue.ciexyzZ	0,79	328F5C29
GammaRed GammaGreen GammaBlue	2.20	0002199A [32]

Barevný profil

V souboru BMP lze v případě potřeby určit barevný profil buď přímým zahrnutím, nebo odkazem na jiný soubor. Profily se objevily v páté verzi BMP a zatím pouze zde jsou pro ně speciální pole. Barevné profily jsou podporovány pouze ve formátu ICC [33] [34] .

Při použití barevných profilů musíte nejprve zadat následující hodnoty pro pole CSType:

• 4C494E4B 16 (PROFILE_LINKED) - Pokud je profil použit v jiném souboru.
• 4D424544 16 (PROFILE_EMBEDDED) - pokud je profil přímo vložen do BMP.

V každém případě pole ProfileData určuje posun profilu v bajtech od začátku bloku BITMAPINFO. Pokud je profil vestavěný, pak v ProfileSize musíte zadat jeho velikost v bajtech (pokud je připojitelný, pak by toto pole mělo být nastaveno na nulu). Bez ohledu na variantu Microsoft doporučuje umístit profil za pixelová data při uložení do souboru a hned za nadpis [35] v RAM při interakci s funkcemi WinAPI .

Formát ICC používá ve své hlavičce převážně 32bitové buňky nebo násobky této velikosti buňky [36] . Na základě toho, pokud je profil přímo zahrnut v BMP, pak se doporučuje uložit jej do RAM na adresu, která je násobkem čtyř bajtů.

Pokud je profil externí, místo jeho obsahu je do BMP umístěn textový řetězec s cestou k souboru. Musí být v jednobajtovém kódování Windows 1252 (standardní kódování pro západoevropské jazyky) a končit nulovým bajtem. Dokumentace neříká nic o oddělovačích komponent cesty, a proto s největší pravděpodobností můžete použít obě levá lomítka " \ " a "pravá" "/" . Cesta může být jak relativní, tak úplná a síťová [35] . A protože se při specifikaci cesty používá jednobajtové kódování, není nutné tento řetězec zarovnávat v paměti RAM.

Předvolby vykreslování

Předvolby vykreslování ( anglicky  rendering intents ) zavedlo International Color Consortium ( International Color Consortium) a určují priority v případě, kdy při přechodu z barevného podprostoru podporovaného jedním zařízením ( anglicky  gamut ) do podprostoru jiného jsou barvy použito na obrázku, chybí v cíli. Existuje také definice z ICC, která definuje předvolby vykreslování jako styl mapování barevných hodnot z jednoho popisu obrázku do druhého (originál v angličtině: „style of mapping color values ​​​​from one image description to other“ ) [37 ] . Microsoft zahrnul speciální pole Intent ve formátu BMP, které může nabývat hodnot zcela podle specifikace ICC. Pro více informací se proto prosím podívejte do dokumentace konsorcia, jejíž nejnovější verzi lze stáhnout z color.org [38] . V Microsoftu jsou tyto preference stručně popsány v článku Rendering Intents na MSDN.

Předvolba je uvedena v poli Záměr bloku BITMAPINFO a je dostupná pouze s 5. verzí informačních polí. Hodnoty mohou být následující:

Význam	Konstantní název pro BMP	Název ICC	Jméno Microsoft	Konstanta ze souboru Icm.h	Konstanta pro DEVMODE
jeden	LCS_GM_BUSINESS	nasycení	Grafický	INTENT_SATURATION(2)	DMICM_SATURATE(1)
2	LCS_GM_GRAPHICS	média-relativní kolorimetrický	důkaz	INTENT_RELATIVE_COLORIMETRIC(1)	DMICM_COLORIMETRIC(3)
čtyři	LCS_GM_IMAGES	percepční	obrázek	INTENT_PERCEPTUAL(0)	DMICM_CONTRAST(2)
osm	LCS_GM_ABS_COLORIMETRIC	ICC-absolutní kolorimetrický (relativní kolometrický)	Zápas	INTENT_ABSOLUTE_COLORIMETRIC(3)	DMICM_ABS_COLORIMETRIC(4)

Microsoft pro tuto charakteristiku deklaroval minimálně tři sady konstant, které se liší svým významem a používají se na různých místech [39] . Zde jsou pro případ, že byste je potřebovali rychle porovnat. Hodnoty konstant s předponou „INTENT_“ jsou přesně stejné jako hodnoty použité v souborech profilu ICC [40] . Konstanty s předponou "DMICM_" jsou deklarovány v souboru WinGDI.h pro strukturu DEVMODE. Konstanty "LCS_GM_" používané v BMP jsou tam deklarovány a jsou určeny především pro strukturu LOGCOLORSPACE. Existují také názvy vlastností tiskárny. Jsou podobné těm ve sloupci "Název Microsoftu", ale s "Grafika" a "Obrázky".

Výchozí hodnota, která je vhodná především pro fotografie a obrázky, může být 4 (LCS_GM_IMAGES). Jako takový jej doporučuje jak Microsoft [41] , tak ICC [42] .

Příklad programu v C

Následující program otevře 24bitový soubor BMP v XWindow, barevná hloubka musí být 32bitová, ale nefunguje při nižším barevném podání, protože to komplikuje příklad:

/* Kompilováno s řádkem: cc -o xtest xtest.c -I/usr/X11R6/include -L/usr/X11R6/lib -lX11 -lm */ #include <X11/Xlib.h> #include <X11/Xutil.h> #include <X11/Xatom.h> #include <X11/keysym.h> #include <stdlib.h> #include <stdio.h> #include <errno.h> #include <sys/stat.h> #include <unistd.h> #include <fcntl.h> #include <math.h> #include "bitmap.h" /* Definice záhlaví BMP zde, jak je popsáno dříve v tomto článku (struktury musí být sbalené po 2 bajtech!) */ statický XImage * CreateImageFromBuffer ( Display * , unsigned char * , int , int ); main ( int argc , char * argv []) { Displej * dis ; výhra okna ; /* Naše okno */ XEvent událost ; /* Vývoj */ GC gc ; /* Grafický kontext */ XImage * obrázek ; int n , šířka , výška , fd , velikost ; unsigned char * data ; BITMAPFILEHEADER bmp ; BITMAPINFOHEADER inf ; char * buf ; if ( arg < 2 ) { chyba ( "použijte: soubor xtest.bmp \n " ); výstup ( 1 ); } if (( fd = open ( argv [ 1 ], O_RDONLY )) == -1 ) { printf ( "Chyba při otevírání bitmapy \n " ); výstup ( 1 ); } čtení ( fd , & bmp , sizeof ( BITMAPFILEHEADER )); read ( fd , & inf , sizeof ( BITMAPINFOHEADER )); šířka = inf . biWidth ; výška = inf . biVýška ; if (( dis = XOpenDisplay ( getenv ( "DISPLAY" ))) == NULL ) { printf ( "Nelze se připojit X server:%s \n " , strerror ( errno )); výstup ( 1 ); } win = XCreateSimpleWindow ( dis , RootWindow ( dis , DefaultScreen ( dis )), 0 , 0 , šířka , výška , 5 , BlackPixel ( dis , DefaultScreen ( dis )), WhitePixel ( dis , DefaultScreen ( dis ))); XSetStandardProperties ( dis , win , argv [ 1 ], argv [ 0 ], None , argv , argc , NULL ); gc = DefaultGC ( dis , DefaultScreen ( dis )); /* Někdy toto místo není ve struktuře vyplněno */ if ( inf . biSizeImage == 0 ) { /* Vypočítejte velikost */ velikost = šířka * 3 + šířka % 4 ; velikost = velikost * výška ; } jinak { velikost = inf . biSizeImage ; } buf = malloc ( velikost ); if ( buf == NULL ) { chyba ( "malloc" ); výstup ( 1 ); } printf ( "velikost = %d přidělených bajtů \n " , velikost ); /* Přesun na začátek samotného obrázku */ lseek ( fd , bmp . bfOffBits , SEEK_SET ); /* Načíst do vyrovnávací paměti */ n = čtení ( fd , buf , velikost ); printf ( "velikost = %d přečtených bytů \n " , n ); image = CreateImageFromBuffer ( dis , buf , width , height ); /* Smažte vyrovnávací paměť - již ji nepotřebujeme */ zdarma ( buf ); XMapWindow ( dis , win ); XSelectInput ( dis , win , ExposureMask | KeyPressMask ); zatímco ( 1 ) { XNextEvent ( dis , & událost ); if ( event . xany . window == win ) { switch ( event . type ) { případ odhalit : XPutImage ( dis , win , gc , obrázek , 0 , 0 , 0 , 0 , obrázek -> šířka , obrázek -> výška ); zlomit ; pouzdro KeyPress : if ( XLookupKeysym ( & event . xkey , 0 ) == XK_q ) { XDestroyImage ( obrázek ); XCloseDisplay ( dis ); zavřít ( fd ); exit ( EXIT_SUCCESS ); } zlomit ; výchozí : zlomit ; } } } } /* Vytvoří Ximage ze souboru BMP, protože obrázek BMP je uložen obráceně * a zrcadlená smyčka to opraví */ XImage * CreateImageFromBuffer ( Display * dis , unsigned char * buf , int width , int height ) { int hloubka , obrazovka ; XObrázek * img = NULL ; int i , j ; int numBmpBytes ; size_t numImgBytes ; int32_t * imgBuf ; int ind = 0 ; int řádek ; int teplota ; int ih , iw ; /* Čísla řádků a sloupců podle */ int nový_ind ; /* Nový index */ obrazovka = DefaultScreen ( dis ); hloubka = DefaultDepth ( dis , obrazovka ); teplota = šířka * 3 ; čára = teplota + šířka % 4 ; /* Délka řetězce včetně zarovnání */ numImgBytes = ( 4 * ( šířka * výška )); imgBuf = malloc ( numImgBytes ); /* Velikost přidělená pro BMP v souboru, včetně zarovnání */ numBmpBytes = řádek * výška ; for ( i = 0 ; i < numBmpBytes ; i ++ ) { bez znaménka int r , g , b ; /* Přeskočit odsazení */ if ( i >= temp && ( i % line ) >= temp ) pokračovat ; b = buf [ i ]; i ++ ; g = buf [ i ]; i ++ ; r = buf [ i ]; /* Vypočítat nový index tak, aby se odrážel svisle */ iw = ind % šířka ; ih = ind / šířka ; new_ind = iw + ( výška - ih - 1 ) * šířka ; imgBuf [ new_ind ] = ( r | g << 8 | b << 16 ) << 8 ; ind ++ ; } img = XCreateImage ( dis , CopyFromParent , hloubka , ZPixmap , 0 , ( char * ) imgBuf , šířka , výška , 32 , 0 ); XInitImage ( img ); /* Pořadí bitů a bajtů na PC by mělo být takto */ img -> byte_order = MSBFirst ; img -> bitmap_bit_order = MSBFirst ; návrat img ; }

Viz také

• ICO (File Format)  je příbuzný formát od společnosti Microsoft pro ukládání ikon a kurzorů myši.

Poznámky

1. ↑ 1 2 3 http://fileformats.archiveteam.org/wiki/BMP
2. ↑ https://www.iana.org/assignments/media-types/image/bmp
3. ↑ Leonard S. Windows Image Media Types  (anglicky) - IETF , 2016. - 12 s. doi : 10.17487/RFC7903
4. ↑ http://www.digitalpreservation.gov/formats/fdd/fdd000189.shtml
5. ↑ https://msdn.microsoft.com/en-us/library/dd183391.aspx
6. ↑ Evchenko A. I. OpenGL a DirectX. Grafické programování (pro profesionály), 2006, s. 183.
7. ↑ Viz část „Poznámky“ v článku „ Struktura BITMAPV5HEADER Archived 21 March 2014 at the Wayback Machine “ na MSDN.
8. ↑ 1 2 Viz část „Poznámky“ v článku „ Struktura BITMAPINFO Archivováno 27. února 2014 na Wayback Machine “ na MSDN.
9. ↑ Viz " Bitmap Header Types Archived 22. září 2014 na Wayback Machine " na MSDN.
10. ↑ Informace o verzi jsou převzaty z nápovědy Microsoft Windows SDK, která je součástí sady Microsoft Visual Studio 2008 a Embarcadero RAD Studio 2010 (část Požadavky v článcích o těchto strukturách).
11. ↑ Viz sekce "Požadavky" v " BITMAPCOREHEADER Archived 16. září 2014 na Wayback Machine " a " BITMAPINFOHEADER Archived 19. dubna 2014 na Wayback Machine " pro Windows Mobile 6.5 na MSDN.
12. ↑ Název pole „bV4V4Compression“ zdvojený s „V4“ je uveden v dokumentaci a deklaraci struktury v souboru WinGDI.h (viz například „ Struktura BITMAPV4HEADER Archived 11 October 2013 at Wayback Machine “ na MSDN.).
13. ↑ 1 2 3 Microsoft oznámil pole Gamma* jako DWORD, ale GDI má pro taková pole speciální typ, FXPT16DOT16.
14. ↑ Viz část "Poznámky" v BITMAPINFOHEADER Archivováno 19. dubna 2014 na Wayback Machine (pod "Windows Mobile 6.5") na MSDN.
15. ↑ Viz část „Poznámky“ v článku „ Konstanty formátu obrazových pixelů archivované 4. května 2014 na Wayback Machine “ (pod „GDI+“) na MSDN.
16. ↑ 1 2 3 MSDN obsahuje větu "Pokud je bV5Height záporná, což znamená shora dolů DIB , bV5Compression musí být buď BI_RGB nebo BI_BITFIELDS." (překlad: "Pokud je bV5Height záporná, označující DIB shora dolů, pak bV5Compression musí být buď BI_RGB nebo BI_BITFIELDS" ). Možná zde nebylo objasněno, že se to týká pouze kódování RLE, protože jeden z příkladů kreslení rastru JPEG označuje přesně zápornou výšku (hledejte řádek „bmi.bmiHeader.biHeight“ v článku Testování tiskárny pro JPEG nebo Podpora PNG Archivovaná kopie 14. listopadu 2013 na Wayback Machine “ na MSDN).
17. ↑ Buďte opatrní. V článku MSDN " BITMAPINFOHEADER Archived 19. April 2014 on the Wayback Machine " pro Windows Mobile 6.5 obsahuje popis pole biClrUsed větu "Pokud se biBitCount rovná 16 nebo 32, optimální paleta barev začíná hned po třech maskách DWORD." (překlad: " Pokud je biBitCount 16 nebo 32, pak optimální paleta barev začíná hned po třech maskách DWORD "). Ve stejném článku výše, v popisu pro pole biCompression, je napsáno „Udává, že bitmapa není komprimována a že tabulka barev se skládá ze tří barevných masek DWORD…“ a níže je to podobné jako „sestává ze čtyř barevných masek DWORD “ (překlady: „Udává, že bitmapa není komprimována a že tabulka barev se skládá ze tří barevných masek DWORD“ a „ sestává ze čtyř barevných masek DWORD “). Podobné informace jsou obsaženy v článku " Struktura BITMAPINFOHEADER Archived 9. února 2014 na Wayback Machine " pro Windows 9x/NT. To vše lze interpretovat tak, že v bitových hloubkách 16 a 32 za informačními poli (struktura BITMAPINFOHEADER) jsou nutně tři 32bitové masky pro extrakci hodnot barevných kanálů. Navíc, pokud komprese obsahuje 3 (BI_BITFIELDS) nebo 6 (BI_ALPHABITFIELDS), pak se za ně přidají další tři nebo čtyři podobné masky, které zase zabírají tabulku barev, a znemožňují tak použití 16bitových indexů optimálních barev v logickém paleta (možná v tomto případě v biClrUsed musí být 6 nebo 8 a biClrImportant musí být 0, aby další masky nebyly náhodně zpracovány jako indexy v paletě).
    Ve skutečnosti se věci mají poněkud jinak.
18. ↑ Stránka dokumentace MSDN " Bitmap Header Types Archived 22 September 2014 at Wayback Machine " obsahuje větu "Bitmapy, které mají 1, 4 nebo 8 bpp, musí mít tabulku barev s maximální velikostí založenou na bpp." (překlad: "Bitmapy s bitovou hloubkou 1, 4 nebo 8 musí obsahovat tabulku barev s maximální velikostí odpovídající bitové." ). Toto je zjevně chyba a autor aplikoval podmínky struktury CORE, která by skutečně měla mít maximum (viz sekce „Poznámky“ v článku „ Struktura BITMAPCOREINFO Archived 3 May 2015 at the Wayback Machine “), na všechny ostatní verze struktur. V jiném článku " Struktura BITMAPINFO Archived 24 June 2014 at the Wayback Machine " o tabulce barev říká "Počet položek v poli závisí na hodnotách členů biBitCount a biClrUsed struktury BITMAPINFOHEADER." (překlad: „počet prvků v poli závisí na hodnotách polí biBitCount a biClrUsed struktury BITMAPINFOHEADER“ ) a v článcích struktur verze 3, 4, 5 (viz např. „ Struktura BITMAPV5HEADER Archivováno 11. října 2013 na Wayback Machine “) v popisu pole BitCount je všude napsáno „člen bmiColors BITMAPINFO obsahuje až 256 záznamů“ (podobně jako pro jiná čísla bitů; překlad fráze: „the Člen bmiColors BITMAPINFO obsahuje až 256 záznamů” ).
19. ↑ Viz například popis bitů 16 a 32 pro pole bV5BitCount v článku „ Struktura BITMAPV5HEADER Archived 11 October 2013 at the Wayback Machine “ na MSDN.
20. ↑ V nápovědě MSDN a Microsoft Windows SDK obsahuje článek „ Struktura BITMAPINFOHEADER Archived 9. února 2014 na Wayback Machine “ matoucí větu „Všechny bity v pixelu nemusí být použity.“ (překlad: " Nepoužívejte všechny bity v pixelu "). Jedná se o překlep (napsali „mít“ místo „potřebovat“), který chybí v podobném bloku v článku o páté verzi Archived 11, 2013 on Wayback Machine (ve čtvrté tato věta chybí).
21. ↑ Tyto informace lze nalézt v nápovědě Microsoft Windows SDK, která je součástí hlavních IDE.
22. ↑ Viz „ Image Pixel Format Constants Archived 4 May 2014 at Wayback Machine “ na GDI+ na MSDN.
23. ↑ Viz „ PixelFormat Enumeration Archived 23. června 2013 na Wayback Machine “ o .NET Framework 1.1 na MSDN.
24. ↑ Viz " Poznámky archivované 24. června 2014 na Wayback Machine " v článku "BITMAPINFO" na MSDN.
25. ↑ Dokumentace (například článek „ Struktura BITMAPV5HEADER Archived 11. října 2013 na Wayback Machine “ na MSDN) říká, že pro pole Komprese lze zadat nulovou velikost s hodnotou 0 (BI_RGB). To samozřejmě platí i pro hodnoty 3 (BI_BITFIELDS) a 6 (BI_ALPHABITFIELDS), protože se liší pouze ve vnitřní struktuře pixelů, nikoli v jejich velikosti.
26. ↑ V podstatě jedna ku jedné jako ve struktuře RGBQUAD použité v tabulce barev.
27. ↑ Na MSDN článek „ Struktura BITMAPV4HEADER Archived 11 October 2013 at the Wayback Machine “ zmiňuje pouze jednu hodnotu pole CSType (LCS_CALIBRATED_RGB). Úplný seznam dostupných hodnot pro verze 4 a 5 najdete v tématu Použití struktur ve WCS 1.0 archivované 3. května 2015 na Wayback Machine .
28. ↑ Po "Win" je další mezera.
29. ↑ Použití tohoto stylu konstantních hodnot pouze v poli CSType je pravděpodobně výsledkem vlivu specifikace ICC, ve které jsou 32bitovým značkám přidělovány podobné hodnoty v souborech barevných profilů . 
30. ↑ Viz část „Poznámky“ v článku „ LOGCOLORSPACE Structure Archived 14 April 2013 at the Wayback Machine “ na MSDN.
31. ↑ Čísla převzata z „ Standardní výchozí barevný prostor pro Internet – sRGB archivováno 20. srpna 2011 na Wayback Machine “. Všechny hodnoty byly zaokrouhleny nahoru, pokud byl nastaven úplně první vyřazený pravý bit.
32. ↑ S dolním bytem nastaveným na nulu bude hodnota 00001A00 16 (zaokrouhleno nahoru).
33. ↑ Tento formát je popsán ve specifikaci ICC.1:2010, odkaz na který je na konci tohoto článku.
34. ↑ Viz část „Poznámky“ v článku „ Struktura BITMAPV5HEADER Archived 11. října 2013 na Wayback Machine “ na MSDN.
35. ↑ 1 2 Viz Používání struktur ve WCS 1.0 Archivováno 3. května 2015 na Wayback Machine na MSDN.
36. ↑ Viz část „7.2 Hlavička profilu“ ve specifikaci ICC.1:2010.
37. ↑ Definice je uvedena ve specifikaci ICC.1:2010 v sekci 3.1.27 na str. 21.
38. ↑ Ve verzi 4.3 specifikace (nejnovější v době psaní tohoto článku) je toto téma rozsáhle pokryto v sekcích "0.4 Rendering intents" (v úvodu; str. 8), "6.2 Rendering intent" (v hlavním obsahu; s. 26) a „D. 6 Diskuse o kolorimetrických záměrech“ (v přílohách; s. 109).
39. ↑ Mapování konstant jsou převzata ze souboru Icm.h (komentovaný blok přímo nad deklaracemi konstant "INTENT_").
40. ↑ Viz část "7.2.15 Pole záměru vykreslení (byty 64 až 67)" specifikace ICC.
41. ↑ Viz část „Picture Intent“ v článku „ Rendering Intents Archived 18. září 2012 na Wayback Machine “ na MSDN.
42. ↑ Ve specifikaci dole na straně 41.

Literatura

Microsoft (MSDN a SDK)

Microsoft Windows SDK  je sada pro vývojáře, která obsahuje soubory nápovědy a soubory C++. K tématu tohoto článku jsou relevantní soubory WinGDI.h a Icm.h, ze kterých byly především převzaty hodnoty konstant. Nejnovější verzi této sady lze zdarma stáhnout z webu společnosti Microsoft (v tomto článku byly použity verze 6.0 a 7.1).

Společnost Microsoft nemá samostatnou specifickou dokumentaci speciálně pro formát BMP. Jeho struktury a další prvky jsou však popsány v rámci subsystému GDI. Tento popis je v nápovědě, která je součástí výše uvedené sady SDK a také na webu MSDN . Navíc je v druhém případě přítomen pro různé platformy a nezávisle v nápovědě Visual Studia. Ve většině případů jsou informace totožné, ale na některých místech může být trochu více faktů (například nápověda SDK obsahuje více informací o podpoře Windows).

Základní informace naleznete v nápovědě GDI pro platformy Windows 9x a NT. Odkazy na stránky v této části, které odkazují pouze na formát, nikoli na funkce WinAPI pro práci s ním:

• " Bitmap Classifications " - popis bitmap závislých na hardwaru a zařízení.
• " Bitmap Storage " je obecný popis formátu souboru BMP.
• " Bitmap Header Types " - přehled verzí BMP záhlaví.
• " Komprese bitmapy " je popis kódování RLE.
• « Bitmapové struktury » - sekce s popisy struktur s poli. Pro usnadnění použijte přímé odkazy na klíč:
  • BITMAPFILEHEADER
  • BITMAPCOREHEADER
  • BITMAPINFOHEADER
  • BITMAPV4HEADER
  • BITMAPV5HEADER

Platformy Windows Compact 2013 (CE 6.0) a Mobile 6.5 mají pouze popisy tří struktur, ale pro tyto platformy:

• BITMAPFILEHEADER
• BITMAPCOREHEADER
• BITMAPINFOHEADER

Odkazy na další stránky z MSDN související s formátem BMP:

• " Image Pixel Format Constants " - Konstanty formátu pixelů GDI+.
• " PixelFormat Enumeration " je popis hodnot výčtového typu PixelFormat pro .NET Framework 1.1 (nejstarší verze).
• " Using Structures in WCS 1.0 " - o strukturách používaných při správě barev ve Windows.
• " Rendering Intents " - Popis předvoleb vykreslování.

Ostatní

Specifikace správy barev ICC poskytuje informace o profilech barev (včetně formátu souboru ICC) a také o předvolbách vykreslování. Tuto specifikaci lze stáhnout z oficiálních stránek konsorcia color.org . V době psaní tohoto článku je nejnovější verze 4.3 (prosinec 2010). Přímé odkazy na PDF z webu ICC:

• Specifikace ICC.1:2010 (verze profilu 4.3.0.0) „Správa barev obrazové technologie – architektura, formát profilu a datová struktura“.
• Errata ke specifikaci (nalezeny chyby a překlepy; publikováno 24. září 2013).

kontejnery na média
Video/Audio	3gp ASF AVI Bink DMF DPX EVO FLV MP4 MPEG MPEG-PS MPEG-TS MXF Matroska (MKV) Ogg Media Ogg Rychlý čas RIFF RealMedia Mlaskavá pusa VOB WebM WMV komprese srovnání
Zvuk	AIFF OPICE A.U. DSD DXD FLAC MLP MP3 SHN WAV WMA komprese srovnání
Hudba	MIDI ( KAR ) tracker music
Rastrové	DNG FPX FLIF HEIF ICER ICO ILBM JBIG2 JBIG JPEG XR (fotografie HD) JPEG / JP2 / JPEG-LS MNG EXR PCX PNG PSD PNM Drsný TIFF TGA WBMP WebP XCF PGF Animované: APNG , GIF Bezeztrátový: BMP Včetně ztrátové komprese: BPG
Vektor	SWF AI CDR EPS PS SVG VRML EMF WMF X3D XPS 3D: 3DS Animovaný: SVG
Komplex	CGM Djvu PDF