BMP

Tabellen nedenfor giver et overblik over felterne. Du kan finde detaljerede oplysninger i sektionerne nedenfor.

Billedbithed (BitCount felt)

BitCount-feltet indeholder antallet af bits pr. pixel. Hvis der er angivet en værdi, der ikke er nul, er dette den reelle bitdybde. Nulindholdet i BitCount-feltet er angivet, hvis pixels er gemt i JPEG- eller PNG-format. Så vil den faktiske bitdybde blive bestemt af disse formater. Bits af rent BMP-format er præsenteret i tabellen nedenfor:

Bemærkninger til tabellen:
1. Kolonnen "BITMAPINFO" viser kun bitdybdeunderstøttelse fra Microsoft.
2. Windows CE 1.0 og 1.01 understøtter kun bitdybder 1 og 2 [14] .
3. GDI+ version 1.0 16-bit farvekanaler kan kun læses, idet de straks konverteres til 8-bit [15] .

I bitdybder på 8 og derunder er farven på en pixel angivet med et indeks i farvetabellen, i højere bits: med en direkte værdi i RGB -farvemodellen . En alfakanal kan eventuelt tilføjes i 16 og 32 bit, og i 64 bit er den permanent til stede.

Tabellen viser kun den bithed, som Microsoft har dokumenteret. Formatet i sig selv indeholder ingen grundlæggende begrænsninger for brugen af ​​bitness, der ikke er nævnt her.

1-bit BMP-filer med ren sort (bit off) og hvid (bit on) kaldes monokrome. Sådanne filer bruges normalt som masker til andre bitmaps. Måske stødte du konstant på netop sådanne 1-bit rastere. Faktisk pålægger Windows Bitmap-formatet ingen begrænsninger for, hvilke farver der vil blive brugt til hver af bitværdierne.

Du kan også støde på følgende bitnavne: CGA for to bit, EGA for fire, HiColor (HighColor) for 16 bit, TrueColor for 24 og 32 bit med gennemskinnelighed, DeepColor for høje bits og muligvis andre. Disse navne går tilbage til udviklingen af ​​farve bitmap-skærme og henviser mere til deres farvedybde . På det tidspunkt, hvor denne artikel blev skrevet (2014), har sådanne navne ikke været brugt i lang tid på grund af den stærke udbredelse af 24-bit enheder (i stedet er farvedybden i bits eller deres antal blot angivet). Og BMP-filer i lavere bitness gemmes i højere grad ikke til visning på CGA- eller EGA-enheder, men for kompakthed sammenlignet med 24-bit og 32-bit formater, hvis der bruges et lille antal farver.

Kompressionsfelt

Separate begrænsede komprimeringsværdier bruges for hver bitgruppe, men samlet set er deres værdier unikke. Microsoft har dokumenteret følgende værdier (tabellen viser navnene på konstanterne fra denne virksomhed):

Farvekort

Farvetabellen er en del af BITMAPINFO-blokken og kan bruges på to måder:

1. Den er nødvendigvis til stede ved bitdybder på 8 og derunder, hvor pixelfarven er specificeret af celleindekset fra den.
2. Ved bitdybder på 8 og derover, hvor farven er angivet med en umiddelbar værdi, er tabellen til stede, hvis der anvendes en header uden CORE-version, hvori ClrUsed-feltet indeholder en værdi, der ikke er nul. Her bruges det allerede til at optimere farver, når der arbejdes med enheder ved hjælp af paletter (dokumentationen fortæller ikke præcist, hvordan optimeringen udføres).

Placeringen af ​​farvetabellen er angivet fra begyndelsen af ​​BITMAPINFO-blokken. Som standard kommer det umiddelbart efter informationsstrukturen (dets usignerede størrelse i bytes kan læses fra det første 32-bit felt). Men mellem strukturen med felter og farvetabellen kan fire-byte bitmasker bruges til at udtrække farvekanaler (gælder kun 16 og 32 bit). De er der kun, hvis informationsstruktur version 3 (Størrelse = 40) bruges, og feltet Komprimering indeholder 3 (BI_BITFIELDS) eller 6 (BI_ALPHABITFIELDS). Derefter skal der tilføjes 12 bytes (hvis BI_BITFIELDS er angivet) eller 16 bytes (hvis BI_ALPHABITFIELDS er angivet) [17] til størrelsen af ​​informationsfelterne . Det viser sig 6 muligheder for placeringen af ​​bordet:

Antallet af celler i tabellen bestemmes af felterne BitCount og ClrUsed. Med bitdybder på 8 og derunder tages det maksimale antal celler i tabellen som 2 bits : 2 i et en-bit raster, 4 i et to-bit et, 16 i et 4-bit et og 256 i et 8. -bid en. I den givne bithed indeholder tabellen altid dette maksimale antal celler, hvis CORE-versionsheaderen (Størrelse = 12) bruges, eller hvis ClrUsed-feltet indeholder 0 i andre versioner. I alle andre tilfælde, uanset bitheden, indeholder tabellen så mange celler som angivet i feltet ClrUsed [18] .

Selve tabellen er en endimensionel matrix, der kan indeholde tre typer celler:

1. 32-bit RGBQUAD struktur . Den bruges, hvis informationsstrukturen fra version 3, 4 eller 5 anvendes i BITMAPINFO. I selve RGBQUAD-strukturen er farven i RGB -modellen angivet i fire byteceller (alle har BYTE WinAPI-typen): rgbBlue (blå) , rgbGreen (grøn), rgbRed (rød ) og rgbReserved (reserveret og skal sættes til nul).
2. 24-bit RGBTRIPLE struktur . Gælder hvis BITMAPINFO starter med en BITMAPCOREHEADER struktur. RGBTRIPLE består af tre byteceller (WinAPI type BYTE), der angiver en farve i RGB -modellen : rgbtBlue (blå), rgbtGreen (grøn) og rgbtRed (rød).
3. 16-bit farveindekser (usignerede heltal) i enhedskontekstens aktuelle logiske palet ( Windows GDI -systemobjekter ). Denne visning er kun tilgængelig, mens applikationen kører. BMP-formatet understøtter ikke en eksplicit indikation af, at en sådan tabel bruges, og derfor giver applikationen selv besked til WinAPI-funktionerne om dette i specielle parametre (normalt DIB_PAL_COLORS-konstanten).

Ikke alle celler kan bruges i hele tabellen, og feltet ClrImportant indeholder antallet af celler fra begyndelsen af ​​tabellen til den sidst brugte (inklusive sig selv). En værdi på 0 i ClrImportant-feltet angiver, at hele tabellen er brugt. Det er bedre at placere de involverede celler helt i begyndelsen af ​​tabellen, og det anbefales at sortere dem i faldende rækkefølge efter vigtighed (i tilfælde af at du bliver nødt til at reducere deres antal).

Masker til at udtrække farvekanalværdier

Hvis billedet er 16 eller 32 bit, kan 32-bit masker specificeres til at udtrække farvekanaler. Dette skyldes, at 16 ikke er et multiplum af 3, og derfor kan bits allokeres på forskellige måder. For nemheds skyld bruger 32-bit billeder 8-bit kanaler, og understøttelse af dem kan derfor virke overflødig. Faktisk her gør masken det muligt at aktivere/deaktivere alfakanalen eller indstille rækkefølgen af ​​komponenterne, der passer dig, og ikke bare justere deres opløsning. Ved anvendelse af masker læses pixelcellen i sin helhed som det tilsvarende maskinord i little-endian.

Tilstedeværelsen af ​​bitmasker afhænger af versionen af ​​informationsfelterne i BITMAPINFO-strukturen og komprimeringsfeltet i den. For CORE-versionen kan vilkårlige masker ikke angives, da der ikke er noget komprimeringsfelt og separate maskefelter. I andre versioner er farvemasker aktiveret, hvis komprimering indeholder 3 (BI_BITFIELDS). Alfakanalmasken bruges altid i version 4 og 5. Da Windows CE ikke understøtter disse to versioner, hvor der er et særligt felt til den, blev værdien 6 (BI_ALPHABITFIELDS) af feltet Komprimering introduceret for den tredje version, som tilføjer både farvemasker og en maske-alfakanal (understøttet siden Windows CE .NET 4.0).

Bitmaskernes position er fast uanset headerversionen: 36 timer i hele filen eller 28 timer fra begyndelsen af ​​BITMAPINFO-blokken. I version 4 og 5 er felter designet specielt til dem placeret på dette sted. I version 3 skal bitmasker være placeret umiddelbart efter informationsfelterne, og de falder således nøjagtigt ind i de tilsvarende felters positioner i ældre versioner. Bemærk venligst, at i den tredje version, hvis der er masker, flyttes farvetabellen 12 eller 16 bytes frem, placeret umiddelbart efter dem. De 4-byte farvemasker er i rækkefølgen rød, grøn, blå. Alfakanalmasken er allerede bag dem.

Microsofts dokumentation gælder kun for ét obligatorisk krav til bitmasker: hver maske skal være sammenhængende. Om tilfældet med skæring af masker siges der, at det er ønskeligt ikke at gøre dette [19] . Microsoft siger også, at det ikke er nødvendigt at bruge alle bits af en pixel [20] . Der er ingen krav til indholdet af ubrugte bits.

Bemærk, at ingen garanterer, at masker bredere end 8 bit kan bruges. Og der bliver ikke sagt noget om sagen, når en kanal vil have en nulmaske (f.eks. når den virkelig ikke bruges). Her er en situation mulig, hvor alle komponenter vil have nul masker, og en alfakanal vil forblive (som i dette tilfælde kan optage alle bits). En farvekanals nulmaske kan fortolkes på to måder: dens værdi tages som nul, eller pixels på denne kanal påvirkes ikke, når der tegnes. Hvis vi tager den første fortolkning med en enkelt alfakanal, så vil alfakanalen i det væsentlige indstille graden af ​​sortfarvning af pixlen. Ud over vage muligheder er der også en interessant. Da kryds ikke er forbudt, er det muligt at sætte alle kanaler til én position og derved få en gråtone .

Noget software har et begrænset sæt understøttede bitmasker. Tabellen nedenfor viser de tilgængelige muligheder i disse begrænsede miljøer:

Tabelnoter:
(a) Disse sæt bruges som standard ved 16 og 32 bit, hvis farveekstraktionsmasker ikke er specificeret.
(b) Dette sæt masker implementerer i sagens natur 16-bit gråtoner.

Pixeldata

I filen kan placeringen af ​​pixeldata findes i OffBits-feltet i BITMAPFILEHEADER-strukturen. Under køretid gemmer applikationen adressen på pixeldataene, hvor det er praktisk. Microsoft-dokumentationen nævner også de såkaldte pakkede bitmaps , som er angivet med en enkelt adresse på BITMAPINFO-blokken. For sådanne bitmaps følger pixeldataene umiddelbart efter overskriften (herunder, ud over informationsfelterne, bitmasker og en farvetabel) [24] .

Størrelsen af ​​pixeldataene i bytes gemmes i feltet SizeImage i BITMAPINFO-strukturen. Det er den "rå" størrelse af den kontinuerlige blok, der indeholder data til dannelsen af ​​pixels (uanset formatet), og ikke en udpakket, der er skrevet der. Som standard skal dette felt indeholde den aktuelle værdi, da det kan bruges til at finde ud af præcis hvor mange bytes der skal læses fra filen for at få pixels. Det er dog lovligt at beholde dette felt nul, når pixel lagres som todimensionelle arrays (når feltet Komprimering indeholder værdien 0 (BI_RGB), 3 (BI_BITFIELDS) eller 6 (BI_ALPHABITFIELDS) [25] ). Så kan størrelsen af ​​pixels, hvis det er nødvendigt, relativt hurtigt beregnes ud fra bitdybden, bredden og højden af ​​rasteret.

Der er tre måder at gemme pixels i Windows Bitmap-formatet (se også afsnittet Kompressionsfelt i denne artikel):

1. 2D array .
2. RLE-kodning (kun for 4 og 8 bit).
3. I JPEG- eller PNG-formater .

Underafsnittene nedenfor beskriver hver af dem separat.

Angivelse af farve og værdi for alfakanalen

For at angive en farve, når den gemmes i BMP-format, uanset hvordan den er angivet, bruges kun heltal uden fortegn. Selve pixelfarven kan indstilles på to måder:

1. Et indeks i farvetabellen (med bitdybder på 8 og derunder).
2. En umiddelbar værdi i RGB-farvemodellen (med bits over 8).

Den anden er nyttig, når farvesættet er ret stort eller uforudsigeligt (f.eks. under billedbehandling). Den første metode giver både et kompakt layout med et lille sæt farver og en vis bekvemmelighed ved styring af de anvendte farver (bare skift farveværdien i paletten). Selve farvetabellen er angivet enten som 16-bit usignerede indekser i systempaletten (se afsnittet " Farvetabel " i denne artikel), eller i RGB som i en pixel, men udelukkende af 8-bit kanalværdier.

Indekset i farvetabellen er cellenummeret i den fra begyndelsen af ​​tabellen (kontinuerlig nummerering, der starter fra nul, bruges). For hver bitdybde er det maksimale indeks grundlæggende begrænset af værdien 2 bitdybde - 1. I virkeligheden er det også begrænset af antallet af elementer i tabellen (detaljer i afsnittet " Farvetabel " i denne artikel). Microsoft har ikke dokumenteret adfærden, når et indeks uden for tabellen er angivet, men GDI tager sort i dette tilfælde.

I bitdybder over 8 er farven på en pixel angivet direkte i RGB-farvemodellen: niveauet af rød, grøn og blå er angivet separat. Nulværdien af ​​enhver af kanalerne betyder det fuldstændige fravær af den tilsvarende skygge, og maksimum: dens fuldstændige tilstedeværelse. Opløsningen af ​​kanalværdierne er variabel, og den har sin egen i hver bitdybde (for specifikke værdier, se afsnittet om lagring af pixels i et todimensionalt array i denne artikel). Samtidig kan der i bitdybder på 16 og 32 ikke kun indstilles vilkårlig opløsning, men også individuel for hver kanal (for eksempel 5 bits for rød og blå, men 6 bit for grøn). På trods af det store antal muligheder for at indstille opløsningen af ​​værdier, siger Microsoft-dokumentationen ikke, hvordan man ændrer opløsningen af ​​en værdi. På grund af dette kan forskellige softwareproducenter få forskellige resultater, når de ændrer bitdybden.

Når du direkte indstiller farven på en pixel, ud over RGB-værdier, giver Windows Bitmap-formatet dig eventuelt også mulighed for at indstille alfakanalværdier . Med hensyn til bithed og kodning af værdier er den identisk med farvekanaler: den har en vilkårlig bithed, og der bruges heltal uden fortegn. Hvad angår værdimatchning, svarer nul til fuld gennemsigtighed, og det maksimale antal tilgængelige svarer til fuld udfyldning.

Todimensionelt array

Pixels af enhver bithed kan lagres i et todimensionalt array. Med denne lagringsmetode indeholder feltet Komprimering værdien 0 (BI_RGB), 3 (BI_BITFIELDS) eller 6 (BI_ALPHABITFIELDS). Hvis CORE-versionens header bruges, gemmes pixels alligevel kun som et todimensionelt array.

I dette layout er rasterpixels skrevet som enkeltpixel vandrette striber, som Microsoft ofte kalder " scanninger " i sin dokumentation (på russisk er det nærmeste ord linjer ). I hukommelsen er disse rækker skrevet i rækkefølge, men med en positiv Højde: startende fra den nederste ( engelsk  bottom-up bitmap ), og med en negativ Højde: helt fra toppen ( engelsk  top-down bitmap ). Inden for hver vandret række skrives pixels kun fra venstre mod højre. Pixels mindre end 8 bits placeres i bytes, der fylder bitsene fra høj til lav, hvilket resulterer i, at de hexadecimale/binære numeriske værdier af pixels ligner outputbilledet mere. Hvis bitdybden er 16 eller 32, så udføres behandlingen af ​​hele maskinord af samme størrelse med rækkefølgen af ​​bit fra lav til høj (little-endian). Rækker, uanset cellestørrelse, skal udfyldes med nuller op til et multiplum af fire bytes størrelse [8] . På grund af dette, med en ikke-multiple billedbredde, kan ubrugte bits eller hele bytes vises i slutningen af ​​rækkerne. Men takket være den garanterede mangfoldighed af rækkestørrelsen kan bearbejdning udføres med 8-, 16- eller 32-bit maskinord, som du vælger. Og Microsoft har stadig følgende tendens i bitdybder større end 8: den blå (blå) komponent er placeret i de nederste bits / første bytes, grøn (grøn) i den næste, og rød (rød) er ældre / længst, og hvis der er en alfakanal, så er den i de mest signifikante bits/sidste bytes.

Diagrammet nedenfor viser arrangementet af pixels i bits mindre end 8 :

stykker	7	6	5	fire	3	2	en	0
1 bit	0	en	2	3	fire	5	6	7
2 bits	0		en		2		3
4 bits	0				en

Ved 16 og 32 bit behandles pixels af maskinord af samme størrelse (forudsat lille-endian byte-rækkefølge), som anvender kanalbitmasker . Hvis der ikke er givet individuelle bitmasker, vil strukturen være som følger. Ved 16 bit tildeles 5 bit til hver kanal. Blå er i de mindst signifikante bits (maske 001F 16 ), grøn er i position 5 (maske 03E0 16 ), rød: startende fra den 10. bit (maske 7C00 16 ), og den mest signifikante resterende bit 15 bruges ikke. Hvis der bruges 32 bit, er hver kanal som standard tildelt en byte (8 bit). Komponenterne er arrangeret på samme måde: blå i de lave bits (maske 0000:00FF 16 ), grøn startende ved bit 8 (maske 0000:FF00 16 ), rød startende ved bit 16 (maske 00FF:0000 16 ), og den høje byte er ikke brugt (den bruges kun som alfakanal, hvis du viser den direkte) [26] . Da det formodes at blive læst i little-endian byte rækkefølge, hvis du læser værdier fra hukommelsen byte for byte, vil de være i samme rækkefølge (blå kommer først).

Med en bitdybde på 24 , har hver kanal en byte, og med en bitdybde på 48 og 64 : et 16-bit maskinord. I alle tre tilfælde går farvekomponenterne i hukommelsen i rækkefølgen: blå, grøn, rød. I 64-bit BMP'er efterfølges farver desuden af ​​en 16-bit alfakanal. Hvis du ønsker at behandle en 64-bit pixel med et enkelt maskinord, så vil i little-endian blå være i de nederste 16 bit, og alfakanalen vil være i de højere. Grøn, henholdsvis, vil være ved siden af ​​rød, og blå - ved siden af ​​alfa. Og du kan se, at i 24 bit svarer pixelformatet til RGBTRIPLE-strukturen fra farvetabellen.

RLE-kodning

Brugen af ​​RLE-kodning af Microsoft er kun dokumenteret for bitdybder 4 og 8. Når det bruges i BITMAPINFO, skal Kompressionsfeltet indeholde 2 (BI_RLE4) ved bitdybde 4 eller 1 (BI_RLE8) med otte-bit pixels. Rasterhøjden skal angives som et positivt tal.

I Windows Bitmap-formatet kan RLE-kodning sammenlignes med tegning med simple kommandoer. Tegningen starter fra den nederste venstre pixel (vær forsigtig: i raster generelt kan den øverste venstre pixel være mere kendt) og fortsætter til højre og op. Pixels uden for bitmapstørrelsen tegnes ikke (dette er ikke nævnt i dokumentationen, men GDI udviser denne adfærd). RLE-instruktioner giver dig mulighed for at afbryde tegningen af ​​en vandret linje, hele billedet, og også flytte tegnemarkøren til en anden position. Som følge heraf kan nogle pixels muligvis ikke tegnes. Dokumentationen giver ikke eksplicit farver til uudtrukne pixels, som følge heraf kan fortolkningen variere: manglende pixels enten forbliver transparente eller får en farve med indeks 0. Hvis vi gør den første antagelse, så kan vi sige, at 4- og 8 -bit-tilstande skyldes, at RLE implicit understøtter gennemsigtighed, men denne adfærd er ikke garanteret.

Billeddannelse under RLE-kodning udføres af kommandoer. Hver kommando skal nødvendigvis begynde med en lige adresse (justeret til en 16-bit grænse). Der er fem kommandoer, som er defineret af et par bytes:

Byte 1 (hex)	Byte 2 (hex)	Beskrivelse
01..FF _ _	00..FF _ _	Start fra den aktuelle position og flyt til højre, tegn så mange pixels som angivet i den første byte. Værdierne for pixels er taget fra den anden byte. I 8-bit BMP'er er hele byten en værdi. I 4-bit tages den højeste nibble fra den på skift, og derefter den laveste nibble (fire bits).
00	00	Flyt markøren til begyndelsen (længst til venstre) af den næste (øverste) vandrette.
00	01	Stop med at tegne (slut nået).
00	02	Flyt markøren til højre og op med værdierne angivet i de næste to bytes. Den første følgende byte indeholder værdien for det vandrette skift, og den næste byte indeholder værdien for det lodrette skift. Begge værdier: heltal uden fortegn (kan ikke flyttes til venstre eller ned).
00	03..FF _ _	Fra den aktuelle position og længere til højre skal du tegne pixels med de værdier, der kommer efter dette par af bytes. Den anden byte af kommandoen indeholder antallet af pixels, der skal males over (nemlig pixels, ikke bytes). I et 8-bit raster tages bytestrømmen som den er. I 4-bit læses nibbles allerede: de øverste 4 bits fra byten for den første pixel, de nederste 4 bits for den næste, og så videre fra efterfølgende bytes. Denne strøm kan ende med et ulige antal bytes, og instruktioner kræver 16-bit justering. Hvis dette sker, tilføjes en ekstra byte (dens indhold er ligegyldigt).

Når højre kant af vandret nås, foretages der ingen oversættelse til den næste. Derfor skal du specifikt indsætte kommandoen for at afslutte rækken. Og som du kan se fra tabellen, tillader kommandosættet dig ikke at bevæge dig ned eller gå tilbage til vandret. Derfor kan du stoppe med at tegne, hvis den øverste kant nås.

Indlejring af data i JPEG- og PNG-formater

Fra og med Windows 98/ME og 2000/XP giver systemfunktioner dig mulighed for at gemme pixels i JPEG- og PNG -formater . Intet er kendt om graden af ​​understøttelse af disse to formater af systemet.

For at indlejre en JPEG eller PNG skal du nulstille feltet BitCount i BITMAPINFO og angive værdien 4 (BI_JPEG) eller 5 (PI_PNG) i komprimering. Værdien af ​​feltet SizeImage vil i dette tilfælde være lig med størrelsen af ​​JPEG- eller PNG-filen, der er indlejret i stedet for pixeldataene, som de er. Bredden og højden i overskriften er allerede angivet for det afkodede billede. Dokumentationen siger ikke direkte noget om fortegn for Højde-feltet for netop dette tilfælde, men det er tilsyneladende nødvendigt at nedskrive en negativ værdi [16] .

Billedopløsning

For at sammenligne dimensionsløse pixels med materialedimensioner bruges felterne XPelsPerMeter og YPelsPerMeter. I disse felter angiver et heltal, hvor mange pixels i dette billede, der falder på en lineær meter, separat vandret (XPelsPerMeter) og vertikalt (YPelsPerMeter). Microsoft erklærede disse to felter for at være en signeret numerisk type, men dokumentationen siger intet om negative værdier. Der siges heller ikke noget om værdien nul, men det er mere logisk at tage den for en ubestemt opløsning, når den er ukendt eller ikke har nogen værdi.

Opløsning er ofte angivet med henvisning ikke til metriske dimensioner, men i dots per inch ( DPI / PPI ). For oversættelse frem og tilbage tages en tomme svarende til 25,4 mm (engelsk tomme). Matematiske formler til konvertering af pixels/tommer (PPI) til pixels/meter (PPM) og omvendt:

Hvis du er interesseret i en nøjagtig heltalsoversættelse, kommer følgende udtryk ud:

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

Efter dem vil der blive afrundet til nærmeste heltal. Hvis du vil runde ned, så lad være med at tilføje halvdelen af ​​divisoren. Hvis du vil op, så tilføj en divisor reduceret med én.

Nedenfor er de forudberegnede PPM-værdier for nogle PPI/DPI'er:

• 96 ppi ≈ 3780 ppm (til Microsoft-skærme)
• 72 ppi ≈ 2835 ppm ( Apple til skærme)
• 150 dpi ≈ 5906 ppm
• 300 dpi ≈ 11811 ppm
• 600 dpi ≈ 23622 ppm

Farverum

I informationsfelterne er hovedfeltet, der angiver farverum, feltet CSType. Dens tilladte værdier er vist i tabellen nedenfor:

Betyder		BITMAPINFO version [27]	Konstant navn	Beskrivelse
hex	Tekst
0	(Ingen)	fire	LCS_CALIBRATED_RGB	Justering baseret på Endpoints, GammaRed, GammaGreen og GammaBlue værdier.
73524742	'sRGB'	fire	LCS_sRGB	sRGB -farverummet bruges .
57696E20	'Vind' [28]	fire	LCS_WINDOWS_COLOR_SPACE	Standard systemplads (sRGB).
4C494E4B	'LINK'	5	PROFILE_LINKED	Farveprofil i en anden fil.
4D424544	'MBED'	5	PROFILE_EMBEDDED	Farveprofilen inkluderet i denne fil.

Microsoft erklærede værdierne af konstanterne ikke som numeriske værdier, men som fire-tegns tekstværdier [29] . I dette tilfælde danner tegnkoderne bytes af en 32-bit værdi (ASCII-koden for tegnet længst til højre er den lave byte, koden for tegnet længst til venstre er den høje byte). Når du ser det binære indhold af en fil som tekst, vil sådanne ASCII-kodede værdier blive vist baglæns (for eksempel "KNIL" i stedet for "LINK").

Slutpunkter og gammaværdier

Windows Bitmap-formatet tillader farvekorrektion ved at angive røde, grønne og blå endepunkter samt gammaværdier . For at gøre dette skal CSType-feltet indeholde værdien 0 (LCS_CALIBRATED_RGB). De korrigerende værdier skrives til felterne Endpoints, GammaRed, GammaGreen og GammaBlue (for andre CSType-værdier ignoreres disse fire felter).

36-byte EndPoints-feltet er en CIEXYZTRIPLE-struktur, der består af tre felter ciexyzRed (rødt slutpunkt), ciexyzGreen (grønt punkt) og ciexyzBlue (blå). Disse tre felter er igen også CIEXYZ-strukturer med tre felter ciexyzX, ciexyzY og ciexyzZ af typen FXPT2DOT30. PXPT2DOT30 er et 32-bit usigneret fikspunktsnummer med 2 høje bits til heltalsdelen og 30 lave bits til brøkdelen.

Gammaværdien skrives til de tilsvarende felter for hver farvekanal separat: GammaRød (rød), GammaGrøn (grøn) og GammaBlå (blå). I erklæringen om informationsstrukturer specificerede Microsoft DWORD-typen for disse felter. Samtidig er der i WinGDI.h-filen en mere passende erklæring af typen FXPT16DOT16 (baseret på den lange type), som er et 32-bit usigneret tal med en brøkdel i de nederste 16 bit og et heltal del i de 16 højere. Det skal bemærkes, at i MSDN, på siderne om BITMAPV4HEADER- og BITMAPV5HEADER- strukturerne, er dette alt, hvad der er sagt. I artiklen om LOGCOLORSPACE-strukturen siges det, at den høje og lave byte skal sættes til nul i lignende felter (faktisk bruges i stedet for 16.16-formatet 8.8-formatet, som er placeret midt i en 32'er -bit celle) [30] .

Nedenfor er værdierne af de ovennævnte fire felter i henhold til sRGB [31] farverum :

Mark	Betyder
	Brøkdel	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
GammaRød GammaGrøn GammaBlå	2,20	0002199A [32]

Farveprofil

I BMP-filen kan en farveprofil om nødvendigt angives enten ved direkte inkludering eller ved et link til en anden fil. Profiler dukkede op i den femte version af BMP, og indtil videre er der kun her felter, der er specielle for dem. Farveprofiler understøttes kun i ICC-format [33] [34] .

Når du bruger farveprofiler, skal du først angive følgende værdier for CSType-feltet:

• 4C494E4B 16 (PROFILE_LINKED) - Hvis en profil bruges i en anden fil.
• 4D424544 16 (PROFILE_EMBEDDED) - hvis profilen er direkte indlejret i BMP.

Under alle omstændigheder specificerer ProfileData-feltet profilforskydningen i bytes fra begyndelsen af ​​BITMAPINFO-blokken. Hvis profilen er indbygget, skal du i ProfileSize angive dens størrelse i bytes (hvis den kan tilsluttes, skal dette felt sættes til nul). Uanset varianten anbefaler Microsoft at placere profilen bag pixeldataene, når de er gemt i en fil, og umiddelbart efter overskriften [35] i RAM, når de interagerer med WinAPI-funktioner .

ICC-formatet bruger overvejende 32-bit celler eller multipla af denne cellestørrelse i sin header [36] . Baseret på dette, hvis profilen er direkte inkluderet i BMP, så anbefales det at gemme den i RAM på en adresse, der er et multiplum af fire bytes.

Når profilen er ekstern, i stedet for dens indhold, placeres en tekststreng med stien til filen i BMP. Det skal være i Windows 1252 single-byte-kodning (standardkodningen for vesteuropæiske sprog) og ende med en null-byte. Dokumentationen siger ikke noget om stikomponentseparatorer, og derfor kan du højst sandsynligt bruge både venstre skråstreger " \ " og "højre" "/" . Stien kan være både relativ og fuld og netværk [35] . Og da en enkelt-byte-kodning bruges til at angive stien, er det ikke nødvendigt at justere denne streng i RAM.

Gengivelsespræferencer

Gengivelsespræferencer ( engelsk  rendering intents ) blev introduceret af International Color Consortium (International Color Consortium) og bestemmer prioriteter i det tilfælde, hvor farverne, når man flytter fra et farveunderrum understøttet af en enhed ( engelsk  gamut ) til et underrum i en anden brugt i billedet, mangler i målet. Der er også en definition fra ICC, som definerer gengivelsespræferencer som stilen til at kortlægge farveværdier fra en billedbeskrivelse til en anden (original på engelsk: "style of mapping farveværdier fra en billedbeskrivelse til en anden" ) [37 ] . Microsoft har inkluderet et særligt Intent-felt i BMP-formatet, som kan tage værdier helt i henhold til ICC-specifikationen. For mere information henvises der derfor til konsortiets dokumentation, hvis seneste version kan downloades fra color.org [38] . Hos Microsoft er disse præferencer kort beskrevet i artiklen Rendering Intents om MSDN.

Præferencen er angivet i Intent-feltet i BITMAPINFO-blokken og er kun tilgængelig med den 5. version af informationsfelterne. Værdierne kan være som følger:

Betyder	Konstant navn for BMP	ICC navn	Microsoft navn	Konstant fra fil Icm.h	Konstant for DEVMODE
en	LCS_GM_BUSINESS	mætning	Grafisk	INTENT_SATURATION(2)	DMICM_SATURATE(1)
2	LCS_GM_GRAPHICS	medierelativ kolorimetrisk	bevis	INTENT_RELATIVE_COLORIMETRIC(1)	DMICM_COLORIMETRIC(3)
fire	LCS_GM_IMAGES	perceptuelle	billede	INTENT_PERCEPTUAL(0)	DMICM_CONTRAST(2)
otte	LCS_GM_ABS_COLORIMETRIC	ICC-absolut kolorimetrisk (relativ kolometrisk)	Match	INTENT_ABSOLUTE_COLORIMETRIC(3)	DMICM_ABS_COLORIMETRIC(4)

Microsoft har erklæret mindst tre sæt konstanter for denne egenskab, som er forskellige i deres betydning og bruges forskellige steder [39] . Her er de, hvis du hurtigt skal sammenligne dem. Værdierne af konstanterne foran med "INTENT_" er nøjagtig de samme som dem, der bruges i ICC-profilfilerne [40] . Konstanterne foran med "DMICM_" er deklareret i filen WinGDI.h for DEVMODE-strukturen. "LCS_GM_" konstanterne, der bruges i BMP, er deklareret der og er primært beregnet til LOGCOLORSPACE strukturen. Der er også navne på printeregenskaber. De ligner dem i kolonnen "Microsoft Name", men med "Graphics" og "Pictures".

Standardværdien, som primært er egnet til fotos og billeder, kan være 4 (LCS_GM_IMAGES). Som sådan anbefales det af både Microsoft [41] og ICC [42] .

Et eksempel på et C-program

Følgende program åbner en 24-bit BMP-fil i et XWindow, farvedybden skal være 32-bit, men det virker ikke på en lavere farvegengivelse, da det komplicerer eksemplet:

/* Kompileret med linjen: 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" /* BMP header definitioner her som beskrevet tidligere i denne artikel (strukturer skal være 2-byte pakket!) */ statisk XImage * CreateImageFromBuffer ( Display * , usigneret tegn * , int , int ); main ( int argc , char * argv []) { Display * dis ; Vindue vinder ; /* Vores vindue */ XEvent begivenhed ; /* Udviklingen */ GC gc ; /* Grafikkontekst */ XImage * billede ; int n , bredde , højde , fd , størrelse ; usigneret char * data ; BITMAPFILEHEADER bmp ; BITMAPINFOHEADER inf ; char * buf ; if ( arg < 2 ) { perror ( "brug: xtest fil.bmp \n " ); udgang ( 1 ); } if (( fd = åben ( argv [ 1 ], O_RDONLY )) == -1 ) { printf ( "Fejl ved åbning af bitmap \n " ); udgang ( 1 ); } læs ( fd , & bmp , sizeof ( BITMAPFILEHEADER )); læs ( fd , & inf , størrelse på ( BITMAPINFOHEADER )); bredde = inf . biWidth ; højde = inf . biHøjde ; if (( dis = XOpenDisplay ( getenv ( "DISPLAY" ))) == NULL ) { printf ( "Kan ikke oprette forbindelse til X-server:%s \n " , strerror ( errno )); udgang ( 1 ); } win = XCreateSimpleWindow ( dis , RootWindow ( dis , DefaultScreen ( dis )), 0 , 0 , width , height , 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 )); /* Nogle gange er dette sted ikke udfyldt i strukturen */ if ( inf . biSizeImage == 0 ) { /* Beregn størrelsen */ størrelse = bredde * 3 + bredde % 4 ; størrelse = størrelse * højde ; } andet { størrelse = inf . biSizeImage ; } buf = malloc ( størrelse ); if ( buf == NULL ) { perror ( "malloc" ); udgang ( 1 ); } printf ( "størrelse =%d bytes tildelt \n " , størrelse ); /* Flyt til begyndelsen af ​​selve billedet */ lseek ( fd , bmp . bfOffBits , SEEK_SET ); /* Læs i buffer */ n = læst ( fd , buf , størrelse ); printf ( "størrelse =%d bytes læst \n " , n ); image = CreateImageFromBuffer ( dis , buf , width , height ); /* Slet bufferen - vi har ikke brug for den længere */ fri ( buf ); XMapWindow ( dis , vinde ); XSelectInput ( dis , win , ExposureMask | KeyPressMask ); mens ( 1 ) { XNextEvent ( dis , & begivenhed ); if ( hændelse . xany . vindue == vinde ) { switch ( hændelse . type ) { case Expose : XPutImage ( dis , win , gc , image , 0 , 0 , 0 , 0 , image -> width , image -> height ); bryde ; case Tastetryk : if ( XLookupKeysym ( & begivenhed . xkey , 0 ) == XK_q ) { XDestroyImage ( billede ); XCloseDisplay ( dis ); lukke ( fd ); exit ( EXIT_SUCCESS ); } bryde ; standard : bryde ; } } } } /* Opretter et Ximage fra en BMP-fil, da BMP-billedet er gemt på hovedet * og spejlsløjfe løser dette */ XImage * CreateImageFromBuffer ( Display * dis , usigneret char * buf , int width , int height ) { int dybde , skærm ; XImage * img = NULL ; int i , j ; int numBmpBytes ; størrelse_t antalImgBytes ; int32_t * imgBuf ; int ind = 0 ; int linje ; int temp ; int ih , iw ; /* Række- og kolonnenumre for at afspejle */ int ny_ind ; /* Nyt indeks */ skærm = DefaultScreen ( dis ); depth = DefaultDepth ( dis , skærm ); temp = bredde * 3 ; linje = temp + bredde % 4 ; /* Længde af streng inklusive justering */ numImgBytes = ( 4 * ( bredde * højde )); imgBuf = malloc ( antalImgBytes ); /* Størrelse tildelt for BMP i filen, inklusive justering */ numBmpBytes = linje * højde ; for ( i = 0 ; i < numBmpBytes ; i ++ ) { usigneret int r , g , b ; /* Spring over polstring */ if ( i >= temp && ( i % line ) >= temp ) fortsætte ; b = buf [ i ]; i ++ ; g = buf [ i ]; i ++ ; r = buf [ i ]; /* Beregn et nyt indeks til at afspejle lodret */ iw = ind % bredde ; ih = ind / bredde ; new_ind = iw + ( højde - ih - 1 ) * bredde ; imgBuf [ ny_ind ] = ( r | g << 8 | b << 16 ) << 8 ; ind ++ ; } img = XCreateImage ( dis , CopyFromParent , dybde , ZPixmap , 0 , ( char * ) imgBuf , width , height , 32 , 0 ); XInitImage ( img ); /* Rækkefølgen af ​​bits og bytes på pc'en skal være som denne */ img -> byte_order = MSBFirst ; img -> bitmap_bit_order = MSBFirst ; returner img ; }

Se også

• ICO (Filformat)  er et relateret format fra Microsoft til lagring af ikoner og musemarkører.

Noter

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  (engelsk) - 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 og DirectX. Graphics Programming (For Professionals), 2006, s. 183.
7. ↑ Se afsnittet "Bemærkninger" i artiklen " BITMAPV5HEADER-struktur Arkiveret 21. marts 2014 på Wayback Machine " på MSDN.
8. ↑ 1 2 Se afsnittet "Bemærkninger" i artiklen " BITMAPINFO-struktur Arkiveret 27. februar 2014 på Wayback Machine " på MSDN.
9. ↑ Se " Bitmap Header Types Archived September 22, 2014 at the Wayback Machine " på MSDN.
10. ↑ Versionsoplysningerne er hentet fra Microsoft Windows SDK-hjælpen, der er bundtet med Microsoft Visual Studio 2008 og Embarcadero RAD Studio 2010 (Kravafsnittet i artikler om disse strukturer).
11. ↑ Se afsnittene "Krav" i " BITMAPCOREHEADER Arkiveret 16. september 2014 på Wayback Machine " og " BITMAPINFOHEADER Arkiveret 19. april 2014 på Wayback Machine " til Windows Mobile 6.5 på MSDN.
12. ↑ Feltnavnet "bV4V4Compression" fordoblet med "V4" er angivet i dokumentationen og strukturdeklarationen i WinGDI.h-filen (se f.eks. " BITMAPV4HEADER-struktur Arkiveret 11. oktober 2013 på Wayback Machine " på MSDN.).
13. ↑ 1 2 3 Microsoft annoncerede Gamma*-felter som DWORD, men GDI har en speciel type til sådanne felter, FXPT16DOT16.
14. ↑ Se afsnittet "Bemærkninger" af BITMAPINFOHEADER Arkiveret 19. april 2014 på Wayback Machine (under "Windows Mobile 6.5") på MSDN.
15. ↑ Se afsnittet "Bemærkninger" i artiklen " Image Pixel Format Constants Arkiveret 4. maj 2014 på Wayback Machine " (under "GDI+") på MSDN.
16. ↑ 1 2 3 MSDN har sætningen "Hvis bV5Height er negativ, hvilket indikerer en top-down DIB , skal bV5Compression være enten BI_RGB eller BI_BITFIELDS." (oversættelse: "Hvis bV5Height er negativ, hvilket betyder en top-down DIB, så skal bV5Compression være enten BI_RGB eller BI_BITFIELDS" ). Det er måske ikke præciseret her, at dette kun gælder for RLE-kodning, da et af eksemplerne på at tegne et JPEG-raster angiver nøjagtig en negativ højde (se efter linjen "bmi.bmiHeader.biHeight" i artiklen Testing a Printer for JPEG eller PNG Support Arkiveret kopi 14. november 2013 på Wayback Machine " på MSDN).
17. ↑ Vær forsigtig. I MSDN-artiklen " BITMAPINFOHEADER Archived April 19, 2014 on the Wayback Machine " for Windows Mobile 6.5, indeholder biClrUsed feltbeskrivelsen sætningen "Hvis biBitCount er lig med 16 eller 32, starter den optimale farvepalet umiddelbart efter de tre DWORD-masker." (oversættelse: " Hvis biBitCount er 16 eller 32, så starter den optimale farvepalet umiddelbart efter de tre DWORD-masker "). I samme artikel ovenfor, i beskrivelsen af ​​biCompression-feltet, står der "Specificerer, at bitmap'et ikke er komprimeret, og at farvetabellen består af tre DWORD-farvemasker..." og nedenfor ligner det "består af fire DWORD-farvemasker " (oversættelser: "Specificerer, at bitmap'et ikke er komprimeret, og at farvetabellen består af tre farvede DWORD-masker" og " består af fire-farvede DWORD-masker "). Lignende information er indeholdt i artiklen " BITMAPINFOHEADER struktur Arkiveret 9. februar 2014 på Wayback Machine " til Windows 9x/NT. Alt dette kan fortolkes på en sådan måde, at der i bitdybder på 16 og 32 bag informationsfelterne (BITMAPINFOHEADER-strukturen) nødvendigvis er tre 32-bit masker til at udtrække farvekanalværdier. Desuden, hvis komprimering indeholder 3 (BI_BITFIELDS) eller 6 (BI_ALPHABITFIELDS), tilføjes tre eller fire flere lignende masker efter dem, som igen optager farvetabellen, hvilket gør det umuligt at bruge 16-bit indekser af optimale farver i den logiske palette (evt. i dette tilfælde skal biClrUsed være 6 eller 8, og biClrImportant skal være 0, så yderligere masker ikke ved et uheld behandles som indekser i paletten).
    I virkeligheden er tingene noget anderledes.
18. ↑ MSDN-dokumentationssiden " Bitmap Header Types Archived September 22, 2014 at the Wayback Machine " har sætningen "Bitmaps, der er 1, 4 eller 8 bpp, skal have en farvetabel med en maksimal størrelse baseret på bpp." (oversættelse: "Bitmaps med en bitdybde på 1, 4 eller 8 skal indeholde en farvetabel med en maksimal størrelse svarende til bitheden." ). Dette er helt klart en fejl, og forfatteren har anvendt betingelserne for CORE-strukturen, som faktisk burde have et maksimum (se afsnittet "Bemærkninger" i artiklen " BITMAPCOREINFO-struktur Arkiveret 3. maj 2015 på Wayback Machine "), på alle andre versioner af strukturerne. I en anden artikel " BITMAPINFO struktur Arkiveret 24. juni 2014 på Wayback Machine " om farvetabellen står der "Antallet af poster i arrayet afhænger af værdierne af biBitCount og biClrUsed medlemmer af BITMAPINFOHEADER strukturen." (oversættelse: "Antallet af elementer i arrayet afhænger af værdierne af felterne biBitCount og biClrUsed i BITMAPINFOHEADER-strukturen" ) og i artiklerne i strukturerne version 3, 4, 5 (se f.eks. " BITMAPV5HEADER-struktur Arkiveret 11. oktober 2013 på Wayback-maskinen ”) i beskrivelsen af ​​BitCount-feltet, “bmiColors-medlemmet af BITMAPINFO indeholder op til 256 poster” er skrevet overalt (på samme måde for andre bitnumre; oversættelse af sætningen: “den bmiColors BITMAPINFO medlem indeholder op til 256 poster” ).
19. ↑ Se f.eks. beskrivelserne af bit 16 og 32 for bV5BitCount-feltet i artiklen " BITMAPV5HEADER structure Archived 11 October 2013 at the Wayback Machine " på MSDN.
20. ↑ På MSDN og Microsoft Windows SDK-hjælpen har artiklen " BITMAPINFOHEADER structure Archived February 9, 2014 at the Wayback Machine " den forvirrende sætning "Alle bits i pixlen behøver ikke at blive brugt." (oversættelse: " Brug ikke alle bits i en pixel "). Dette er en tastefejl (de skrev "har" i stedet for "behov"), som mangler i en lignende blok i artiklen om den femte version Arkiveret 11. oktober 2013 på Wayback Machine (i den fjerde mangler denne sætning).
21. ↑ Disse oplysninger kan findes i Microsoft Windows SDK-hjælpen, der følger med de vigtigste IDE'er.
22. ↑ Se " Image Pixel Format Constants Archived May 4, 2014 at the Wayback Machine " på GDI+ på MSDN.
23. ↑ Se " PixelFormat Enumeration Archived June 23, 2013 at the Wayback Machine " om .NET Framework 1.1 på MSDN.
24. ↑ Se " Bemærkninger arkiveret 24. juni 2014 på Wayback Machine " i "BITMAPINFO"-artiklen på MSDN.
25. ↑ Dokumentationen (for eksempel artiklen " BITMAPV5HEADER-struktur Arkiveret 11. oktober 2013 på Wayback Machine " på MSDN) siger, at nul størrelse kan angives med en værdi på 0 (BI_RGB) for feltet Kompression. Dette gælder naturligvis også for værdierne 3 (BI_BITFIELDS) og 6 (BI_ALPHABITFIELDS), da de kun gør en forskel i den interne struktur af pixels, og ikke i deres størrelse.
26. ↑ Grundlæggende en-til-en som i RGBQUAD-strukturen brugt i farvetabellen.
27. ↑ På MSDN nævner artiklen " BITMAPV4HEADER structure Archived 11 October 2013 at the Wayback Machine " kun én CSType-feltværdi (LCS_CALIBRATED_RGB). For en komplet liste over tilgængelige værdier for version 4 og 5, se Brug af strukturer i WCS 1.0 Arkiveret 3. maj 2015 på Wayback Machine .
28. ↑ Der er endnu et mellemrum efter "Win".
29. ↑ Brugen af ​​denne stil med konstante værdier kun i CSType-feltet er højst sandsynligt resultatet af indflydelsen fra ICC-specifikationen, hvor 32-bit tags får lignende værdier i farveprofilfiler . 
30. ↑ Se afsnittet "Bemærkninger" i artiklen " LOGCOLORSPACE Structure Archived 14 April 2013 at the Wayback Machine " på MSDN.
31. ↑ Numre taget fra " A Standard Default Color Space for the Internet - sRGB Archived August 20, 2011 at the Wayback Machine ". Alle værdier blev rundet op, hvis den allerførste kasserede højre bit blev sat.
32. ↑ Med den lave byte sat til nul, vil værdien være 00001A00 16 (rundet op).
33. ↑ Dette format er beskrevet i ICC.1:2010-specifikationen, hvortil der findes et link i slutningen af ​​denne artikel.
34. ↑ Se afsnittet "Bemærkninger" i artiklen " BITMAPV5HEADER-struktur Arkiveret 11. oktober 2013 på Wayback Machine " på MSDN.
35. ↑ 1 2 Se Brug af strukturer i WCS 1.0 Arkiveret 3. maj 2015 på Wayback Machine på MSDN.
36. ↑ Se afsnit "7.2 Profiloverskrift" i ICC.1:2010-specifikationen.
37. ↑ Definitionen er givet i ICC.1:2010-specifikationen i afsnit 3.1.27 på s. 21.
38. ↑ I version 4.3 af specifikationen (senest i skrivende stund) er dette emne dækket udførligt i afsnittene "0.4 Gengivelseshensigter" (i indledningen; s. 8), "6.2 Gengivelseshensigt" (i hovedindholdet; s. 26) og "D. 6 Diskussion af kolorimetriske hensigter" (i bilag; s. 109).
39. ↑ De konstante afbildninger er taget fra Icm.h-filen (kommenteret blok lige over "INTENT_" konstanterklæringerne).
40. ↑ Se afsnit "7.2.15 Rendering hensigtsfelt (bytes 64 til 67)" i ICC-specifikationen.
41. ↑ Se afsnittet "Picture Intent" i artiklen " Rendering Intents Archived September 18, 2012 at the Wayback Machine " på MSDN.
42. ↑ I specifikationen nederst på side 41.

Litteratur

Microsoft (MSDN og SDK)

Microsoft Windows SDK  er et udviklersæt, der inkluderer hjælp og C++-filer. Om emnet for denne artikel er filerne WinGDI.h og Icm.h relevante, hvorfra værdierne af konstanterne blev taget i første omgang. Den seneste version af dette sæt kan downloades gratis fra Microsofts websted (version 6.0 og 7.1 blev brugt i denne artikel).

Microsoft har ikke særskilt specifik dokumentation specifikt til BMP-formatet. Men dens strukturer og andre elementer er beskrevet i GDI-undersystemet. Denne beskrivelse er i hjælpen, der er inkluderet i ovenstående SDK, og også på MSDN . Desuden er det i sidstnævnte til stede for forskellige platforme og uafhængigt i Visual Studio-hjælpen. I de fleste tilfælde er oplysningerne identiske, men nogle steder kan der være lidt flere fakta (f.eks. har SDK-hjælpen flere oplysninger om Windows-support).

For grundlæggende oplysninger, se GDI-hjælpen til Windows 9x- og NT-platformene. Links til sider i dette afsnit, der kun henviser til formatet og ikke til WinAPI-funktionerne til at arbejde med det:

• " Bitmap-klassifikationer " - beskrivelse af hardware-afhængige og enhedsuafhængige bitmaps.
• " Bitmap Storage " er en generel beskrivelse af BMP-filformatet.
• " Bitmap Header Types " - en oversigt over BMP header versioner.
• " Bitmap Compression " er en beskrivelse af RLE-kodning.
• « Bitmap Structures » - et afsnit med beskrivelser af strukturer med felter. For nemheds skyld, direkte links til nøglen:
  • BITMAPFILEHEADER
  • BITMAPCOREHEADER
  • BITMAPINFOHEADER
  • BITMAPV4HEADER
  • BITMAPV5HEADER

Windows Compact 2013 (CE 6.0) og Mobile 6.5 platformene har kun beskrivelser af tre strukturer, men for disse platforme:

• BITMAPFILEHEADER
• BITMAPCOREHEADER
• BITMAPINFOHEADER

Links til andre sider fra MSDN relateret til BMP-formatet:

• " Billedpixelformatkonstanter " - GDI+ pixelformatkonstanter.
• " PixelFormat Enumeration " er en beskrivelse af værdierne for den PixelFormat optalte type for .NET Framework 1.1 (tidligste version).
• " Brug af strukturer i WCS 1.0 " - om de strukturer, der bruges i farvestyring i Windows.
• " Rendering Intents " - Beskrivelse af gengivelsespræferencer.

Andre

ICC-farvestyringsspecifikationen giver oplysninger om farveprofiler (inklusive ICC-filformatet) samt gengivelsespræferencer. Denne specifikation kan downloades fra den officielle hjemmeside for konsortiet color.org . I skrivende stund er den seneste version 4.3 (december 2010). Direkte links til PDF fra ICC's websted:

• Specifikation ICC.1:2010 (Profil version 4.3.0.0) "Billedteknologi farvestyring - Arkitektur, profilformat og datastruktur".
• Fejl i forhold til specifikationen (fundet fejl og tastefejl; offentliggjort 24. september 2013).

mediebeholdere
Video/lyd	3gp ASF AVI Bink DMF DPX EVO FLV MP4 MPEG MPEG-PS MPEG-TS MXF Matroska (MKV) Ogg Media Ogg Hurtig tid RIFF RealMedia Smacker VOB WebM WMV kompression sammenligning
Lyd	AIFF ABE A.U. DSD DXD FLAC MLP MP3 SHN WAV WMA kompression sammenligning
musik	MIDI ( KAR ) tracker musik
Raster	DNG FPX FLIF HEIF ICER ICO ILBM JBIG2 JBIG JPEG XR (HD-foto) JPEG / JP2 / JPEG-LS MNG EXR PCX PNG PSD PNM Rå TIFF TGA WBMP WebP XCF PGF Animeret: APNG , GIF Tabsfri: BMP Inklusive tabsgivende komprimering: BPG
Vektor	SWF AI CDR EPS PS SVG VRML EMF WMF X3D XPS 3D: 3DS Animeret: SVG
Kompleks	CGM DJVu PDF