BMP

Alla oleva taulukko tarjoaa yleiskatsauksen kentistä. Löydät yksityiskohtaiset tiedot alla olevista osioista.

Kuvan bittimäärä (BitCount-kenttä)

BitCount-kenttä sisältää bittien määrän pikseliä kohden. Jos siellä ilmoitetaan nollasta poikkeava arvo, tämä on todellinen bittisyvyys. BitCount-kentän nollasisältö ilmoitetaan, jos pikselit on tallennettu JPEG- tai PNG-muodossa. Sitten todellinen bittisyvyys määräytyy näiden formaattien mukaan. Puhtaan BMP-muodon bitit on esitetty alla olevassa taulukossa:

Huomautuksia taulukkoon:
1. "BITMAPINFO"-sarake näyttää bittisyvyyden tuen vain Microsoftilta.
2. Windows CE 1.0 ja 1.01 tukevat vain bittisyvyyttä 1 ja 2 [14] .
3. GDI+ versio 1.0 16-bittisiä värikanavia voidaan vain lukea, jolloin ne muunnetaan välittömästi 8-bittisiksi [15] .

Kun bittisyvyys on 8 ja sitä pienempi, pikselin väri ilmaistaan ​​väritaulukon indeksillä, korkeammissa biteissa: suoralla arvolla RGB -värimallissa . Alfa-kanava voidaan valinnaisesti lisätä 16- ja 32-bittisenä, 64-bittisenä se on jatkuvasti läsnä.

Taulukossa näkyy vain bittimäärä, jonka Microsoft on dokumentoinut. Formaatti itsessään ei sisällä mitään perustavanlaatuisia rajoituksia minkään tässä mainitsemattoman bittien käytölle.

1-bittisiä BMP-tiedostoja, joissa on puhdas musta (bitti pois) ja valkoinen (bitti päällä), kutsutaan yksivärisiksi. Tällaisia ​​tiedostoja käytetään yleensä muiden bittikarttojen peitteinä. Ehkä törmäsit jatkuvasti juuri sellaisiin 1-bittisiin rastereihin. Itse asiassa Windowsin bittikarttamuoto ei aseta rajoituksia kullekin bittiarvolle käytettävälle värille.

Saatat myös törmätä seuraaviin bittinimiin: CGA kahdelle bitille, EGA neljälle, HiColor (HighColor) 16 bitille, TrueColor 24 ja 32 bitille läpikuultavalla bitillä, DeepColor korkeille biteille ja mahdollisesti muita. Nämä nimet juontavat juurensa väribittikarttanäyttöjen kehitykseen ja viittaavat enemmän niiden värisyvyyteen . Tämän artikkelin kirjoitushetkellä (2014) tällaisia ​​nimiä ei ole käytetty pitkään aikaan 24-bittisten laitteiden suuren yleisyyden vuoksi (sen sijaan värisyvyys bitteinä tai niiden lukumäärä ilmoitetaan yksinkertaisesti). Ja pienemmällä bittimäärällä olevia BMP-tiedostoja ei tallenneta suuremmassa määrin näyttöä varten CGA- tai EGA-laitteissa, vaan kompaktimmaksi verrattuna 24- ja 32-bittisiin muotoihin, jos käytetään vähän värejä.

Pakkauskenttä

Jokaiselle bittiryhmälle käytetään erillisiä rajoitettuja pakkausarvoja, mutta yhdessä niiden arvot ovat ainutlaatuisia. Microsoft on dokumentoinut seuraavat arvot (taulukossa luetellaan tämän yrityksen vakioiden nimet):

Värikartta

Väritaulukko on osa BITMAPINFO-lohkoa ja sitä voidaan käyttää kahdella tavalla:

1. Se on välttämättä läsnä 8:n ja sitä alhaisemmilla bittisyvyyksillä, joissa pikselin väri määräytyy sen soluindeksin mukaan.
2. Bittisyvyyksillä 8 ja sitä suuremmilla, joissa väriä ilmaisee välitön arvo, taulukko on läsnä, jos käytetään ei-CORE-version otsikkoa, jossa ClrUsed-kenttä sisältää nollasta poikkeavan arvon. Täällä sitä käytetään jo värien optimointiin työskenneltäessä paletteja käyttävien laitteiden kanssa (dokumentaatiossa ei kerrota tarkasti, kuinka optimointi suoritetaan).

Väritaulukon sijainti määritetään sen BITMAPINFO-lohkon alusta alkaen. Oletusarvoisesti se tulee heti tietorakenteen jälkeen (sen etumerkitön koko tavuina voidaan lukea ensimmäisestä 32-bittisestä kentästä). Mutta kentät sisältävän rakenteen ja väritaulukon välillä voidaan käyttää nelitavuisia bitimaskeja värikanavien poimimiseen (koskee vain 16 ja 32 bittiä). Ne ovat olemassa vain, jos käytetään tietorakenteen versiota 3 (koko = 40) ja pakkauskenttä sisältää 3 (BI_BITFIELDS) tai 6 (BI_ALPHABITFIELDS). Sitten tietokenttien kokoon on lisättävä 12 tavua (jos BI_BITFIELDS on määritetty) tai 16 tavua (jos BI_ALPHABITFIELDS on määritetty) [17] . Osoittautuu 6 vaihtoehtoa pöydän sijainnille:

Taulukon solujen lukumäärä määräytyy kenttien BitCount ja ClrUsed mukaan. Kun bittisyvyydet ovat 8 tai vähemmän, taulukon solujen enimmäismääräksi otetaan 2 bittiä : 2 yksibittisessä rasterissa, 4 kaksibittisessä rasterissa, 16 4-bittisessä ja 256 8-bitissä. -pala yksi. Annetussa bittimäärässä taulukko sisältää aina tämän enimmäismäärän soluja, jos käytetään CORE-version otsikkoa (Size = 12) tai jos ClrUsed-kentässä on muissa versioissa 0. Kaikissa muissa tapauksissa, bittimäärästä riippumatta, taulukko sisältää niin monta solua kuin on määritetty kentässä ClrUsed [18] .

Taulukko itsessään on yksiulotteinen taulukko, joka voi sisältää kolmenlaisia ​​soluja:

1. 32-bittinen RGBQUAD -rakenne . Sitä käytetään, jos BITMAPINFOssa käytetään version 3, 4 tai 5 tietorakennetta. Itse RGBQUAD-rakenteessa RGB -mallin väri ilmoitetaan neljän tavun soluissa (kaikilla on BYTE WinAPI-tyyppi): rgbBlue (sininen) , rgbGreen (vihreä), rgbRed (punainen ) ja rgbVarattu (varattu ja se on asetettava nollaan).
2. 24-bittinen RGBTRIPLE -rakenne . Koskee, jos BITMAPINFO alkaa BITMAPCOREHEADER-rakenteella. RGBTRIPLE koostuu kolmesta tavusolusta (WinAPI-tyyppi BYTE), jotka määrittävät värin RGB -mallissa : rgbtBlue (sininen), rgbtGreen (vihreä) ja rgbtRed (punainen).
3. 16-bittiset väriindeksit (allekirjoittamattomat kokonaisluvut) laitekontekstin nykyisessä loogisessa paletissa ( Windows GDI -järjestelmäobjektit ). Tämä näkymä on käytettävissä vain sovelluksen ollessa käynnissä. BMP-muoto ei tue nimenomaista ilmoitusta tällaisen taulukon käytöstä, ja siksi sovellus itse ilmoittaa tästä WinAPI-funktioille erityisillä parametreilla (yleensä DIB_PAL_COLORS-vakio).

Kaikkia soluja ei saa käyttää koko taulukossa, ja ClrImportant-kenttä sisältää solujen lukumäärän taulukon alusta viimeiseen käytettyyn soluun (mukaan lukien itsensä). Arvo 0 ClrImportant-kentässä osoittaa, että koko taulukko on käytössä. On parempi sijoittaa kyseiset solut aivan taulukon alkuun ja on suositeltavaa lajitella ne tärkeysjärjestykseen (jos joudut vähentämään niiden määrää).

Maskit värikanava-arvojen poimimiseen

Jos kuva on 16- tai 32-bittinen, voidaan määrittää 32-bittiset maskit värikanavien poimimiseksi. Tämä johtuu siitä, että 16 ei ole 3:n kerrannainen ja siksi bitit voidaan allokoida eri tavoin. Mukavuuden vuoksi 32-bittiset kuvat käyttävät 8-bittisiä kanavia, ja siksi niiden tuki saattaa tuntua tarpeettomalta. Itse asiassa tässä maski mahdollistaa alfa-kanavan käyttöönoton / poistamisen käytöstä tai sinulle sopivan komponenttien järjestyksen asettamisen, eikä vain säädä niiden resoluutiota. Maskeja käytettäessä pikselisolu luetaan kokonaisuudessaan vastaavana konesanana little-endianissa.

Bittimaskien olemassaolo riippuu BITMAPINFO-rakenteen tietokenttien ja siinä olevan pakkauskentän versiosta. CORE-versiolle ei voi määrittää mielivaltaisia ​​maskeja, koska pakkauskenttää ja erillisiä maskikenttiä ei ole. Muissa versioissa värimaskit ovat käytössä, jos pakkaus sisältää 3 (BI_BITFIELDS). Alfakanavamaskia käytetään aina versioissa 4 ja 5. Koska Windows CE ei tue näitä kahta versiota, joissa sille on erityinen kenttä, pakkauksen arvo 6 (BI_ALPHABITFIELDS) otettiin käyttöön kolmannelle versiolle, joka lisää sekä värimaskit että maskin alfakanavan (tuettu Windows CE .NET 4.0:sta lähtien).

Bittimaskien sijainti on kiinteä otsikkoversiosta riippumatta: 36 h koko tiedostossa tai 28 h BITMAPINFO-lohkon alusta. Versioissa 4 ja 5 erityisesti niille suunnitellut kentät sijaitsevat tässä paikassa. Versiossa 3 bitimaskit tulisi sijoittaa välittömästi tietokenttien jälkeen ja siten ne osuvat täsmälleen vastaavien kenttien paikkoihin vanhemmissa versioissa. Huomaa, että kolmannessa versiossa, jos maskeja on, väritaulukkoa siirretään 12 tai 16 tavua eteenpäin heti niiden jälkeen. 4-tavuiset värinaamarit ovat järjestyksessä punainen, vihreä, sininen. Alfakanavamaski on jo niiden takana.

Microsoftin dokumentaatio koskee vain yhtä pakollista vaatimusta bitmaskeille: jokaisen maskin on oltava vierekkäinen. Naamarien leikkaustapauksesta siellä sanotaan, että tätä ei kannata tehdä [19] . Microsoft sanoo myös, että ei ole välttämätöntä käyttää kaikkia pikselin bittejä [20] . Käyttämättömien bittien sisällölle ei ole vaatimuksia.

Huomaa, että kukaan ei takaa, että yli 8 bitin peitteitä voidaan käyttää. Eikä mitään sanota tapauksesta, jossa millä tahansa kanavalla on nollamaski (esimerkiksi kun sitä ei todellakaan käytetä). Tässä on mahdollista tilanne, jossa kaikilla komponenteilla on nolla maskia ja yksi alfakanava jää jäljelle (joka tässä tapauksessa voi varata kaikki bitit). Värikanavan nollamaski voidaan tulkita kahdella tavalla: sen arvoksi otetaan nolla tai piirtäminen ei vaikuta tämän kanavan pikseleihin. Jos otamme ensimmäisen tulkinnan yhdellä alfa-kanavalla, niin alfa-kanava määrittää olennaisesti pikselin tummenemisasteen. Epämääräisten vaihtoehtojen lisäksi on myös mielenkiintoinen. Koska risteykset eivät ole kiellettyjä, on mahdollista asettaa kaikki kanavat yhteen paikkaan ja siten saada harmaasävy .

Joillakin ohjelmistoilla on rajoitettu joukko tuettuja bitimaskeja. Alla olevassa taulukossa on lueteltu näissä rajoitetuissa ympäristöissä käytettävissä olevat vaihtoehdot:

Taulukon huomautukset:
(a) Näitä joukkoja käytetään oletusarvoisesti 16 ja 32 bittinä, jos värinpoistomaskeja ei ole määritetty.
(b) Tämä maskisarja toteuttaa luonnostaan ​​16-bittisen harmaasävyn.

Pikselitiedot

Tiedostossa pikselitietojen sijainti löytyy BITMAPFILEHEADER-rakenteen OffBits-kentästä. Ajon aikana sovellus tallentaa pikselitietojen osoitteen sinne, missä se on kätevää. Microsoftin dokumentaatiossa mainitaan myös niin sanotut pakatut bittikartat , jotka ilmaistaan ​​yhdellä BITMAPINFO-lohkon osoitteella. Tällaisissa bittikartoissa pikselidata seuraa välittömästi otsikkoa (sisältäen tietokenttien lisäksi bitimaskit ja väritaulukon) [24] .

Pikselitietojen koko tavuina tallennetaan BITMAPINFO-rakenteen SizeImage-kenttään. Sinne kirjoitetaan sen jatkuvan lohkon "raaka" koko, joka sisältää dataa pikselien muodostusta varten (muodosta riippumatta), eikä jotain pakkaamatonta. Oletuksena tämän kentän tulee sisältää nykyinen arvo, koska sen avulla voidaan selvittää tarkalleen kuinka monta tavua tiedostosta tulee lukea pikselien saamiseksi. Tämä kenttä on kuitenkin laillista pitää nollana tallennettaessa pikseleitä kaksiulotteisina taulukoina (kun pakkauskenttä sisältää arvon 0 (BI_RGB), 3 (BI_BITFIELDS) tai 6 (BI_ALPHABITFIELDS) [25] ). Tällöin pikselien koko voidaan tarvittaessa laskea suhteellisen nopeasti rasterin bittisyvyyden, leveyden ja korkeuden perusteella.

On kolme tapaa tallentaa pikseleitä Windowsin bittikarttamuodossa (katso myös tämän artikkelin Pakkauskenttä -osio ):

1. 2D-taulukko .
2. RLE-koodaus (vain 4 ja 8 bittiä varten).
3. JPEG- tai PNG-muodossa .

Alla olevissa alaosissa kuvataan jokainen niistä erikseen.

Alfa-kanavan värin ja arvon määrittäminen

BMP-muodossa tallennetun värin määrittämiseen käytetään vain etumerkittömiä kokonaislukuja riippumatta siitä, miten se on määritetty. Itse pikselin väri voidaan asettaa kahdella tavalla:

1. Indeksi väritaulukossa (bittisyvyydet 8 tai vähemmän).
2. Välitön arvo RGB-värimallissa (bittien ollessa yli 8).

Toinen on hyödyllinen, kun värisarja on melko suuri tai arvaamaton (esimerkiksi kuvankäsittelyn aikana). Ensimmäinen menetelmä tarjoaa sekä kompaktin asettelun pienellä joukolla värejä että jonkin verran mukavuutta käytettyjen värien hallinnassa (muuta vain väriarvoa paletissa). Itse väritaulukko määritellään joko 16-bittisinä etumerkittöminä indekseinä järjestelmäpaletissa (katso tämän artikkelin "Väritaulukko " -osio ) tai RGB-muodossa pikselinä, mutta yksinomaan 8-bittisillä kanavaarvoilla.

Väritaulukon indeksi on siinä oleva solunumero taulukon alusta alkaen (käytetään jatkuvaa nollasta alkavaa numerointia). Kunkin bittisyvyyden maksimiindeksiä rajoittaa pohjimmiltaan arvo 2 bitin syvyys - 1. Todellisuudessa sitä rajoittaa myös taulukon elementtien määrä (yksityiskohdat tämän artikkelin " Väritaulukko " -osiossa). Microsoft ei ole dokumentoinut toimintaa, kun taulukon ulkopuolella oleva indeksi on määritetty, mutta GDI on tässä tapauksessa musta.

Yli 8 bittisyvyydessä pikselin väri näkyy suoraan RGB-värimallissa: punaisen, vihreän ja sinisen taso ilmoitetaan erikseen. Minkä tahansa kanavan nolla-arvo tarkoittaa vastaavan sävyn täydellistä puuttumista ja maksimi: sen täydellistä läsnäoloa. Kanava-arvojen resoluutio on vaihteleva ja sillä on oma jokaisessa bittisyvyydessä (katso tietyt arvot tämän artikkelin kohdasta pikselien tallentamisesta kaksiulotteiseen taulukkoon). Samaan aikaan bittisyvyyksillä 16 ja 32 ei voida asettaa vain mielivaltaista resoluutiota, vaan myös yksittäisiä kullekin kanavalle (esimerkiksi 5 bittiä punaiselle ja siniselle, mutta 6 bittiä vihreälle). Huolimatta arvojen resoluution asetusvaihtoehtojen suuresta määrästä, Microsoftin dokumentaatiossa ei kerrota, kuinka arvon resoluutiota muutetaan. Tästä johtuen eri ohjelmistovalmistajat voivat saada erilaisia ​​tuloksia bittisyvyyttä muuttaessaan.

Kun määrität pikselin värin suoraan, voit RGB-arvojen lisäksi valita Windowsin bittikarttamuodon myös alfakanava- arvojen asettamisen . Bititeettinä ja arvojen koodauksena se on identtinen värikanavien kanssa: sillä on mielivaltainen bittimäärä ja käytetään etumerkittömiä kokonaislukuja. Mitä tulee arvojen yhteensovittamiseen, nolla vastaa täydellistä läpinäkyvyyttä, ja käytettävissä oleva enimmäismäärä vastaa täyttä täyttöä.

Kaksiulotteinen taulukko

Minkä tahansa bittisyyden pikselit voidaan tallentaa kaksiulotteiseen taulukkoon. Tällä tallennusmenetelmällä pakkauskenttä sisältää arvon 0 (BI_RGB), 3 (BI_BITFIELDS) tai 6 (BI_ALPHABITFIELDS). Jos käytetään CORE-version otsikkoa, pikselit tallennetaan joka tapauksessa vain kaksiulotteisena taulukkona.

Tässä asettelussa rasteripikselit kirjoitetaan yhden pikselin vaakajuovina, joita Microsoft usein kutsuu " skannauksiksi " dokumentaatiossaan (venäjäksi lähin sana on rivit ). Nämä rivit kirjoitetaan muistissa järjestyksessä, mutta positiivisella Korkeudella: alkaen alhaalta ( englanniksi  bottom-up bitmap ) ja negatiivisella Korkeudella: ylhäältä ( englanniksi  top-down bitmap ). Jokaisella vaakarivillä pikselit kirjoitetaan tiukasti vain vasemmalta oikealle. Alle 8 bittiä pienemmät pikselit sijoitetaan tavuiksi, jolloin bitit täyttyvät korkeasta matalaan, jolloin pikselien heksadesimaali-/binaarilukuarvot ovat enemmän samankaltaisia ​​kuin lähtökuva. Jos bittisyvyys on 16 tai 32, niin käsittely suoritetaan kokonaisilla samankokoisilla konesanoilla bittien järjestyksessä matalasta korkeaan (little-endian). Rivit, solukoosta riippumatta, on täytettävä nollilla neljän tavun koon kerrannaiseen asti [8] . Tästä johtuen, jos kuvan leveys ei ole useita, rivien lopussa voi näkyä käyttämättömiä bittejä tai kokonaisia ​​tavuja. Mutta taatun rivikoon moninaisuuden ansiosta käsittely voidaan suorittaa 8-, 16- tai 32-bittisillä konesanoilla, kuten valitset. Ja Microsoftilla on edelleen seuraava trendi yli 8 bittisyvyyksissä: sininen (sininen) komponentti sijoitetaan alempiin bitteihin / ensimmäisiin tavuihin, vihreä (vihreä) seuraavaan ja punainen (punainen) on vanhempi / kauimpana, ja jos on alfakanava, silloin se on merkittävimmässä bitissä/viimeisissä tavuissa.

Alla oleva kaavio näyttää pikselien sijoittelun alle 8 bitteinä :

bittiä	7	6	5	neljä	3	2	yksi	0
1 bittiä	0	yksi	2	3	neljä	5	6	7
2 bittiä	0		yksi		2		3
4 bittiä	0				yksi

16- ja 32 - bittisillä pikseleillä käsitellään samankokoisia konesanoja (olettaen, että tavujärjestys on pieni), jotka käyttävät kanavabittimaskeja . Jos yksittäisiä bitimaskeja ei anneta, rakenne on seuraava. 16 bitin kohdalla kullekin kanavalle osoitetaan 5 bittiä. Sininen on vähiten merkitsevissä biteissä (maski 001F 16 ), vihreä on paikassa 5 (maski 03E0 16 ), punainen: alkaen 10. bitistä (maski 7C00 16 ), ja merkittävintä jäljellä olevaa bittiä 15 ei käytetä. Jos käytetään 32 bittiä, jokaiselle kanavalle on oletusarvoisesti määritetty tavu (8 bittiä). Komponentit on järjestetty samalla tavalla: sininen alhaisissa biteissä (maski 0000:00FF 16 ), vihreä alkaen bitistä 8 (mask 0000:FF00 16 ), punainen alkaen bitistä 16 (maski 00FF:0000 16 ), ja korkea tavu on ei käytössä (käytetään alfakanavana vain, jos näytät sen suoraan) [26] . Koska se on tarkoitus lukea pikkutavujärjestyksessä, jos luet arvoja muistista tavu kerrallaan, ne ovat samassa järjestyksessä (sininen tulee ensin).

Bittisyvyydellä 24 jokaisella kanavalla on tavu, ja bittisyvyydellä 48 ja 64 : 16-bittinen konesana. Kaikissa kolmessa tapauksessa värikomponentit menevät muistissa järjestyksessä: sininen, vihreä, punainen. 64-bittisissä BMP:issä värejä seuraa lisäksi 16-bittinen alfakanava. Jos haluat käsitellä 64-bittistä pikseliä yhdellä konesanalla, niin little-endianissa sininen on alemmissa 16 bitissä ja alfakanava korkeammissa. Vihreä on punaisen vieressä ja sininen alfan vieressä. Ja voit nähdä, että 24-bittisenä pikselimuoto vastaa väritaulukon RGBTRIPLE-rakennetta.

RLE-koodaus

Microsoftin RLE-koodauksen käyttö on dokumentoitu vain bittisyvyyksille 4 ja 8. Käytettäessä BITMAPINFO:ssa pakkauskentän tulee sisältää 2 (BI_RLE4) bittisyvyydellä 4 tai 1 (BI_RLE8) kahdeksan bitin pikseleillä. Rasterin korkeus on määritettävä positiivisena numerona.

Windowsin bittikarttamuodossa RLE-koodausta voidaan verrata piirtämiseen yksinkertaisilla komennoilla. Piirtäminen alkaa vasemmasta alakulmasta (ole varovainen: rastereissa yleensä vasen ylempi pikseli voi olla tutumpi) ja etenee oikealle ja ylöspäin. Bittikartan koon ulkopuolella olevia pikseleitä ei piirretä (tätä ei mainita dokumentaatiossa, mutta GDI käyttäytyy tällä tavalla). RLE-ohjeiden avulla voit keskeyttää vaakaviivan piirtämisen, koko kuvan ja siirtää piirtokohdistimen toiseen paikkaan. Tämän seurauksena joitain pikseleitä ei ehkä piirretä. Dokumentaatiossa ei nimenomaisesti esitetä värejä piirtämättömille pikseleille, minkä seurauksena tulkinta voi vaihdella: puuttuvat pikselit joko pysyvät läpinäkyvinä tai saavat värin indeksillä 0. Jos teemme ensimmäisen oletuksen, voidaan sanoa, että 4- ja 8 -bittitilat johtuvat siitä, että RLE tukee implisiittisesti läpinäkyvyyttä, mutta tätä toimintaa ei taata.

Kuvanmuodostus RLE-koodauksen aikana tapahtuu komennoilla. Jokaisen komennon on välttämättä aloitettava parillisella osoitteella (tasattu 16-bittiseen rajaan). On viisi komentoa, jotka määritellään tavuparilla:

Tavu 1 (heksadesimaaliluku)	Tavu 2 (heksadesimaali)	Kuvaus
01..FF _ _	00..FF _ _	Aloita nykyisestä sijainnista ja siirry oikealle, piirrä niin monta pikseliä kuin ensimmäisessä tavussa on määritetty. Pikselien arvot otetaan toisesta tavusta. 8-bittisissä BMP:issä koko tavu on arvo. 4-bitissä siitä otetaan vuorotellen korkein nibble ja sitten alin nibble (neljä bittiä).
00	00	Siirrä kohdistin seuraavan (ylemmän) vaakatason alkuun (vasemmalle).
00	01	Lopeta piirtäminen (loppu saavutettu).
00	02	Siirrä kohdistinta oikealle ja ylöspäin seuraavien kahden tavun arvojen verran. Ensimmäinen seuraava tavu sisältää vaakasiirron arvon ja seuraava tavu pystysiirron arvon. Molemmat arvot: etumerkittömät kokonaisluvut (ei voi siirtää vasemmalle tai alas).
00	03..FF _ _	Piirrä nykyisestä paikasta ja edelleen oikealle pikselit arvoilla, jotka tulevat tämän tavuparin jälkeen. Komennon toinen tavu sisältää ylimaalattavien pikselien määrän (eli pikseleitä, ei tavuja). 8-bittisessä rasterissa tavuvirta otetaan sellaisenaan. 4-bitissä nibbles luetaan jo: ylemmät 4 bittiä tavusta ensimmäiselle pikselille, alemmat 4 bittiä seuraavalle ja niin edelleen seuraavista tavuista. Tämä tietovirta voi päättyä parittomaan määrään tavuja, ja ohjeet vaativat 16-bittisen kohdistuksen. Jos näin tapahtuu, lisätään ylimääräinen tavu (sen sisällöllä ei ole väliä).

Kun vaakatason oikea reuna saavutetaan, ei käännöstä tehdä seuraavaan. Siksi sinun on erityisesti lisättävä komento rivin lopettamiseksi. Ja kuten taulukosta näet, komentosarja ei salli sinun siirtyä alas tai palata vaakatasoon. Siksi voit lopettaa piirtämisen, jos yläreuna saavutetaan.

Tietojen upottaminen JPEG- ja PNG-muodoissa

Windows 98/ME:stä ja 2000/XP:stä alkaen järjestelmätoimintojen avulla voit tallentaa pikseleitä JPEG- ja PNG -muodoissa . Järjestelmän näiden kahden muodon tuesta ei tiedetä mitään.

Jos haluat upottaa JPEG- tai PNG-tiedoston, sinun on nollattava BitCount-kenttä BITMAPINFO-kohdassa ja määritettävä arvo 4 (BI_JPEG) tai 5 (PI_PNG) pakkauskohdassa. SizeImage-kentän arvo on tässä tapauksessa sama kuin JPEG- tai PNG-tiedoston koko, joka on upotettu pikselitietojen tilalle sellaisenaan. Otsikon leveys ja korkeus on jo ilmoitettu dekoodatulle kuvalle. Dokumentaatio ei kerro suoraan mitään Korkeus-kentän etumerkistä tässä tapauksessa, mutta ilmeisesti on tarpeen kirjoittaa negatiivinen arvo [16] .

Kuvan resoluutio

Mitattomien pikselien vertaamiseen materiaalimittoihin käytetään XPelsPerMeter- ja YPelsPerMeter-kenttiä. Näissä kentissä kokonaisluku osoittaa, kuinka monta pikseliä tässä kuvassa putoaa yhdelle lineaarimetrille erikseen vaakasuunnassa (XPelsPerMeter) ja pystysuunnassa (YPelsPerMeter). Microsoft julisti nämä kaksi kenttää allekirjoitetuiksi numeerisiksi tyypeiksi, mutta dokumentaatio ei kerro mitään negatiivisista arvoista. Arvosta nolla ei myöskään puhuta mitään, mutta on loogisempaa ottaa se epämääräiseksi resoluutioksi, kun se on tuntematon tai sillä ei ole arvoa.

Resoluutio määritetään usein viitaten metrimitoihin, vaan pisteinä tuumalle ( DPI / PPI ). Edestakaisin käännöksissä tuuma on yhtä suuri kuin 25,4 mm (englanninkielinen tuuma). Matemaattiset kaavat pikselien/tuuman (PPI) muuntamiseksi pikseleiksi/metriksi (PPM) ja päinvastoin:

Jos olet kiinnostunut tarkasta kokonaisluvun käännöksestä, seuraavat lausekkeet tulevat esiin:

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

Niiden jälkeen pyöristetään lähimpään kokonaislukuun. Jos haluat pyöristää alaspäin, älä lisää puolta jakajasta. Jos haluat ylöspäin, lisää jakaja vähennettynä yhdellä.

Alla on joidenkin PPI/DPI:iden ennalta lasketut PPM-arvot:

• 96 ppi ≈ 3780 ppm (Microsoft-näytöille)
• 72 ppi ≈ 2835 ppm ( Apple näytöille)
• 150 dpi ≈ 5906 ppm
• 300 dpi ≈ 11811 ppm
• 600 dpi ≈ 23622 ppm

Väriavaruus

Tietokentissä väriavaruuden määrittelevä pääkenttä on CSType-kenttä. Sen sallitut arvot on esitetty alla olevassa taulukossa:

Merkitys		BITMAPINFO- versio [27]	Jatkuva nimi	Kuvaus
hex	Teksti
0	(Ei)	neljä	LCS_CALIBRATED_RGB	Säätö perustuu päätepisteisiin, GammaRed-, GammaGreen- ja GammaBlue-arvoihin.
73524742	"sRGB"	neljä	LCS_sRGB	Käytetään sRGB - väriavaruutta .
57696E20	"Voitta" [28]	neljä	LCS_WINDOWS_COLOR_SPACE	Oletusjärjestelmätila (sRGB).
4C494E4B	'LINKKI'	5	PROFILE_LINKED	Väriprofiili toisessa tiedostossa.
4D424544	"MBED"	5	PROFILE_EMBEDDED	Tähän tiedostoon sisältyvä väriprofiili.

Microsoft ei ilmoittanut vakioiden arvoja numeerisiksi arvoiksi, vaan nelimerkkisiksi tekstiarvoiksi [29] . Tässä tapauksessa merkkikoodit muodostavat 32-bittisen arvon tavut (oikeimman merkin ASCII-koodi on alempi tavu, vasemmanpuoleisimman merkin koodi on ylin tavu). Kun tarkastellaan tiedoston binaarisisältöä tekstinä, tällaiset ASCII-koodatut arvot näytetään taaksepäin (esimerkiksi "KNIL" eikä "LINK").

Päätepisteet ja gamma-arvot

Windowsin bittikarttamuoto mahdollistaa värinkorjauksen määrittämällä punaiset, vihreät ja siniset päätepisteet sekä gamma -arvot . Tätä varten CSType-kentän on sisällettävä arvo 0 (LCS_CALIBRATED_RGB). Korjaavat arvot kirjoitetaan Endpoints-, GammaRed-, GammaGreen- ja GammaBlue-kenttiin (muissa CSType-arvoissa nämä neljä kenttää jätetään huomiotta).

36-tavuinen EndPoints-kenttä on CIEXYZTRIPLE-rakenne, joka koostuu kolmesta kentästä ciexyzRed (punainen päätepiste), ciexyzGreen (vihreä piste) ja ciexyzBlue (sininen). Nämä kolme kenttää ovat puolestaan ​​myös CIEXYZ-rakenteita, joissa on kolme FXPT2DOT30-tyyppistä kenttää ciexyzX, ciexyzY ja ciexyzZ. PXPT2DOT30 on 32-bittinen etumerkitön kiinteän pisteen luku, jossa on 2 yläbittiä kokonaislukuosalle ja 30 matalaa bittiä murto-osalle.

Gamma-arvo kirjoitetaan kunkin värikanavan vastaaviin kenttiin erikseen: GammaRed (punainen), GammaGreen (vihreä) ja GammaBlue (sininen). Tietorakenteiden määrittelyssä Microsoft määritti näille kentille DWORD-tyypin. Samaan aikaan WinGDI.h-tiedostossa on tarkoituksenmukaisempi FXPT16DOT16-tyyppinen määritys (pitkän tyypin perusteella), joka on 32-bittinen etumerkitön luku, jonka murto-osa on alemmassa 16 bitissä ja kokonaisluku osa 16 korkeammasta. On huomattava, että MSDN:ssä BITMAPV4HEADER- ja BITMAPV5HEADER- rakenteita koskevilla sivuilla tämä on kaikki mitä sanotaan. LOGCOLORSPACE-rakennetta käsittelevässä artikkelissa sanotaan, että korkea ja matala tavu tulisi asettaa nollaan vastaavissa kentissä (itse asiassa 16.16-muodon sijaan käytetään 8.8-muotoa, joka sijaitsee keskellä 32 -bittinen solu) [30] .

Alla on yllä olevien neljän kentän arvot sRGB [31] -väriavaruuden mukaisesti :

Ala	Merkitys
	Murtoluku	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]

Väriprofiili

BMP-tiedostossa voidaan tarvittaessa määrittää väriprofiili joko suoraan sisällyttämällä tai linkittämällä toiseen tiedostoon. Profiilit ilmestyivät BMP:n viidennessä versiossa, ja toistaiseksi vain täällä on niille erityisiä kenttiä. Väriprofiileja tuetaan vain ICC-muodossa [33] [34] .

Kun käytät väriprofiileja, sinun on ensin määritettävä seuraavat arvot CSType-kenttään:

• 4C494E4B 16 (PROFILE_LINKED) - Jos profiilia käytetään toisessa tiedostossa.
• 4D424544 16 (PROFIILI_EMBEDDED) - jos profiili on upotettu suoraan BMP:hen.

Joka tapauksessa ProfileData-kenttä määrittää profiilisiirtymän tavuina BITMAPINFO-lohkon alusta. Jos profiili on sisäänrakennettu, ProfileSize-kohdassa sinun on määritettävä sen koko tavuina (jos se on kytkettävä, tämän kentän arvoksi tulee asettaa nolla). Vaihteesta riippumatta Microsoft suosittelee profiilin sijoittamista pikselitietojen taakse, kun se tallennetaan tiedostoon, ja välittömästi otsikon [35] jälkeen RAM-muistiin, kun se on vuorovaikutuksessa WinAPI-toimintojen kanssa .

ICC-muoto käyttää otsikossaan pääasiassa 32-bittisiä soluja tai tämän solukoon kerrannaisia ​​[36] . Tämän perusteella, jos profiili sisältyy suoraan BMP:hen, on suositeltavaa tallentaa se RAM-muistiin osoitteeseen, joka on neljän tavun kerrannainen.

Kun profiili on ulkoinen, sen sisällön sijaan BMP:hen sijoitetaan tekstimerkkijono, jossa on tiedoston polku. Sen on oltava yksitavuisella Windows 1252 -koodauksella (Länsi-Euroopan kielten vakiokoodaus) ja sen on päätyttävä nollatavuun. Dokumentaatio ei kerro mitään polun komponenttien erottimista, ja siksi voit todennäköisesti käyttää sekä vasenta kauttaviivaa " \ " että "oikeaa" "/" . Polku voi olla sekä suhteellinen että täydellinen ja verkko [35] . Ja koska polun määrittämisessä käytetään yksitavuista koodausta, tätä merkkijonoa ei tarvitse tasata RAM-muistissa.

Renderöintiasetukset

Kansainvälinen värikonsortio (International Color Consortium) otti käyttöön renderöintiasetukset (englanniksi rendering intents) ja ne määrittävät prioriteetit siinä tapauksessa, että siirryttäessä yhden laitteen tukemasta värialiavaruudesta ( englanniksi gamut )  toisen aliavaruuteen värit ovat käytetty kuvassa, puuttuu kohteesta. ICC:stä on myös määritelmä, joka määrittelee renderöintiasetukset tyyliksi, jolla väriarvot kartoitetaan kuvakuvauksesta toiseen (alkuperäinen englanniksi: "tyyli väriarvojen kartoittamiseksi yhdestä kuvakuvauksesta toiseen" ) [37 ] . Microsoft on sisällyttänyt BMP-muotoon erityisen Intent-kentän, joka voi ottaa arvoja täysin ICC-spesifikaatioiden mukaisesti. Siksi lisätietoja saat konsortion dokumentaatiosta, jonka uusin versio voidaan ladata osoitteesta color.org [38] . Microsoftilla nämä asetukset on kuvattu lyhyesti MSDN :n Rendering Intents -artikkelissa. 

Asetus ilmoitetaan BITMAPINFO-lohkon Tarkoitus-kentässä ja se on käytettävissä vain tietokenttien 5. versiossa. Arvot voivat olla seuraavat:

Merkitys	BMP :n vakionimi	ICC nimi	Microsoftin nimi	Vakio tiedostosta Icm.h	Vakio DEVMODElle
yksi	LCS_GM_BUSINESS	kylläisyys	Graafinen	INTENT_SATURATION(2)	DMICM_SATURATE(1)
2	LCS_GM_GRAPHICS	mediaan suhteellinen kolorimetrinen	todiste	INTENT_RELATIVE_COLORIMETRIC(1)	DMICM_COLORIMETRIC(3)
neljä	LCS_GM_IMAGES	havainnollinen	kuva	INTENT_PERCEPTUAL(0)	DMICM_CONTRAST(2)
kahdeksan	LCS_GM_ABS_COLORIMETRIC	ICC-absoluuttinen kolorimetrinen (suhteellinen kolometrinen)	Ottelu	INTENT_ABSOLUTE_COLORIMETRIC(3)	DMICM_ABS_COLORIMETRIC(4)

Microsoft on ilmoittanut tälle ominaisuudelle ainakin kolme vakiojoukkoa, jotka eroavat toisistaan ​​merkitykseltään ja joita käytetään eri paikoissa [39] . Tässä ne siltä varalta, että sinun on verrattava niitä nopeasti. "INTENT_"-etuliitteellä olevien vakioiden arvot ovat täsmälleen samat kuin ICC-profiilitiedostoissa [40] . Vakiot, joiden etuliitteenä on "DMICM_", ilmoitetaan DEVMODE-rakenteen WinGDI.h-tiedostossa. BMP:ssä käytetyt "LCS_GM_"-vakiot on ilmoitettu siellä ja ne on tarkoitettu ensisijaisesti LOGCOLORSPACE-rakenteeseen. Tulostimen ominaisuuksille on myös nimiä. Ne ovat samanlaisia ​​kuin "Microsoft Name" -sarakkeessa, mutta niissä on "Graphics" ja "Pictures".

Oletusarvo, joka sopii ensisijaisesti valokuville ja kuville, voi olla 4 (LCS_GM_IMAGES). Sellaisenaan sekä Microsoft [41] että ICC [42] suosittelevat sitä .

Esimerkki C-ohjelmasta

Seuraava ohjelma avaa 24-bittisen BMP-tiedoston XWindowissa, värisyvyyden on oltava 32-bittinen, mutta se ei toimi matalammalla värintoistolla, koska se vaikeuttaa esimerkkiä:

/* Käännetty rivillä: cc -o xtest xtest.c -I/usr/X11R6/include -L/usr/X11R6/lib -lX11 -lm */ #include <X11/Xlib.h> #include <X11/Xutil.h> #sisältää <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-otsikkomääritykset tässä artikkelissa aiemmin kuvatulla tavalla (rakenteiden on oltava 2-tavuisia!) */ staattinen XImage * CreateImageFromBuffer ( Display * , unsigned char * , int , int ); main ( int argc , char * argv []) { Näyttö * dis ; Window win ; /* Meidän ikkunamme */ XEvent- tapahtuma ; /* Kehitys */ GC gc ; /* Graafinen konteksti */ XImage * kuva ; int n , leveys , korkeus , fd , koko ; allekirjoittamaton char * data ; BITMAPFILEHEADER bmp ; BITMAPINFOHEADER inf ; char * buf ; if ( arg < 2 ) { perror ( "käytä: xtest file.bmp \n " ); uloskäynti ( 1 ); } if (( fd = avoin ( argv [ 1 ], O_RDONLY )) == -1 ) { printf ( "Virhe bittikartan avaamisessa \n " ); uloskäynti ( 1 ); } lue ( fd , & bmp , koko ( BITMAPFILEHEADER )); lue ( fd , & inf , koko ( BITMAPINFOHEADER )); leveys = inf . biWidth ; korkeus = inf . biHeight ; if (( dis = XOpenDisplay ( getenv ( "DISPLAY" ))) == NULL ) { printf ( "Ei voi muodostaa yhteyttä X-palvelimeen:%s \n " , strerror ( errno )); uloskäynti ( 1 ); } win = XCreateSimpleWindow ( dis , RootWindow ( dis , DefaultScreen ( dis )), 0 , 0 , leveys , korkeus , 5 , BlackPixel ( dis , DefaultScreen ( dis )), WhitePixel ( dis , DefaultScreen ( dis ))); XSetStandardProperties ( dis , win , argv [ 1 ], argv [ 0 ], ei mitään , argv , argc , NULL ); gc = OletusGC ( dis , DefaultScreen ( dis )); /* Joskus tätä kohtaa ei täytetty rakenteessa */ if ( inf . biSizeImage == 0 ) { /* Laske koko */ koko = leveys * 3 + leveys % 4 ; koko = koko * korkeus ; } muu { koko = info . biSizeImage ; } buf = malloc ( koko ); if ( buf == NULL ) { perror ( "malloc" ); uloskäynti ( 1 ); } printf ( "koko =%d tavua varattu \n " , koko ); /* Siirry itse kuvan alkuun */ lseek ( fd , bmp . bfOffBits , SEEK_SET ); /* Lue puskuriin */ n = lue ( fd , buf , koko ); printf ( "koko =%d tavua lue \n " , n ); image = CreateImageFromBuffer ( dis , buf , leveys , korkeus ); /* Poista puskuri - emme tarvitse sitä enää */ ilmainen ( buf ); XMapWindow ( dis , win ); XSelectInput ( dis , win , ExposureMask | KeyPressMask ); kun ( 1 ) { XNextEvent ( dis , & tapahtuma ); if ( tapahtuma . xany . ikkuna == voitto ) { kytkin ( tapahtuma . tyyppi ) { asia Expose : XPutImage ( dis , win , gc , kuva , 0 , 0 , 0 , 0 , kuva -> leveys , kuva -> korkeus ); tauko ; tapaus KeyPress : if ( XLookupKeysym ( & tapahtuma . xkey , 0 ) == XK_q ) { XDestroyImage ( kuva ); XCloseDisplay ( dis ); sulkea ( fd ); poistu ( EXIT_SUCCESS ); } tauko ; oletus : tauko ; } } } } /* Luo Ximagen BMP - tiedostosta , koska BMP - kuva tallennetaan ylösalaisin * ja peilattu silmukka korjaa tämän */ XImage * CreateImageFromBuffer ( Näyttö * dis , unsigned char * buf , int leveys , int korkeus ) { int syvyys , näyttö ; XImage * img = NULL ; int i , j ; int numBmpBytes ; size_t numImgBytes ; int32_t * imgBuf ; int ind = 0 ; int line ; int temp ; int ih , iw ; /* Rivi- ja sarakenumerot vastaavat */ int uusi_ind ; /* Uusi hakemisto */ näyttö = Oletusnäyttö ( dis ); syvyys = OletusSyvyys ( dis , näyttö ); lämpötila = leveys * 3 ; viiva = lämpötila + leveys % 4 ; /* Merkkijonon pituus tasaus mukaan lukien */ numImgBytes = ( 4 * ( leveys * korkeus )); imgBuf = malloc ( numImgBytes ); /* Tiedostossa BMP:lle varattu koko, mukaan lukien tasaus */ numBmpBytes = rivi * korkeus ; for ( i = 0 ; i < numBmpBytes ; i ++ ) { unsigned int r , g , b ; /* Ohita täyte */ if ( i >= lämpötila && ( i % rivi ) > = lämpötila jatkaa ; b = buf [ i ]; i ++ ; g = buf [ i ]; i ++ ; r = buf [ i ]; /* Laske uusi indeksi pystysuunnassa */ iw = ind % leveys ; ih = ind / leveys ; uusi_ind = iw + ( korkeus - ih - 1 ) * leveys ; imgBuf [ uusi_ind ] = ( r | g << 8 | b << 16 ) << 8 ; ind ++ ; } img = XCreateImage ( dis , CopyFromParent , syvyys , ZPixmap , 0 , ( char * ) imgBuf , leveys , korkeus , 32 , 0 ); XInitImage ( img ); /* PC:n bittien ja tavujen järjestyksen tulisi olla tämä */ img -> byte_order = MSBFirst ; img -> bittikartan_bittijärjestys = MSBFirst ; paluu img ; }

Katso myös

• ICO (File Format)  on Microsoftin vastaava muoto kuvakkeiden ja hiiren kohdistimien tallentamiseen.

Muistiinpanot

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  (englanti) - 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 ja DirectX. Grafiikkaohjelmointi (ammattilaisille), 2006, s. 183.
7. ↑ Katso "Huomautukset" artikkelissa " BITMAPV5HEADER rakenne Arkistoitu 21. maaliskuuta 2014 Wayback Machinessa " MSDN:ssä.
8. ↑ 1 2 Katso "Huomautukset" artikkelissa " BITMAPINFO rakenne Arkistoitu 27. helmikuuta 2014 Wayback Machinessa " MSDN:ssä.
9. ↑ Katso " Bitmap Header Types arkistoitu 22. syyskuuta 2014 Wayback Machinessa " MSDN:ssä.
10. ↑ Versiotiedot on otettu Microsoft Windows SDK -ohjeesta, joka on toimitettu Microsoft Visual Studio 2008:n ja Embarcadero RAD Studio 2010:n kanssa (näitä rakenteita käsittelevien artikkelien Vaatimukset-osio).
11. ↑ Katso Vaatimukset osioissa " BITMAPCOREHEADER arkistoitu 16. syyskuuta 2014 Wayback Machinessa " ja " BITMAPINFOHEADER arkistoitu 19. huhtikuuta 2014 Wayback Machinessa " Windows Mobile 6.5:lle MSDN:llä.
12. ↑ Kentän nimi "bV4V4Compression" ja "V4" on lueteltu WinGDI.h-tiedoston dokumentaatiossa ja rakennemäärityksessä (katso esimerkiksi " BITMAPV4HEADER-rakenne Arkistoitu 11. lokakuuta 2013 Wayback Machinessa " MSDN:ssä).
13. ↑ 1 2 3 Microsoft ilmoitti Gamma*-kentistä DWORD-muodossa, mutta GDI:llä on tällaisia ​​kenttiä varten erityinen tyyppi, FXPT16DOT16.
14. ↑ Katso "Huomautukset"-osio BITMAPINFOHEADER Arkistoitu 19. huhtikuuta 2014 Wayback Machinessa (alla "Windows Mobile 6.5") MSDN:llä.
15. ↑ Katso "Huomautukset" artikkelissa " Image Pixel Format Constants Archived 4. toukokuuta 2014 Wayback Machinessa " (kohdassa "GDI+") MSDN:ssä.
16. ↑ 1 2 3 MSDN :ssä on lause "Jos bV5Height on negatiivinen, mikä tarkoittaa ylhäältä alas DIB:tä , bV5Compression on oltava joko BI_RGB tai BI_BITFIELDS." (käännös: "Jos bV5Height on negatiivinen, mikä tarkoittaa ylhäältä alas DIB:tä, bV5Compressionin on oltava joko BI_RGB tai BI_BITFIELDS" ). Tässä ei ehkä ole selvennetty, että tämä koskee vain RLE-koodausta, koska yksi JPEG-rasterin piirtämisen esimerkeistä osoittaa tarkalleen negatiivisen korkeuden (katso rivi "bmi.bmiHeader.biHeight" artikkelista JPEG-tulostimen testaus tai PNG-tuki Arkistoitu kopio 14. marraskuuta 2013 Wayback Machinessa MSDN:ssä).
17. ↑ Ole varovainen. Windows Mobile 6.5: n MSDN-artikkelissa " BITMAPINFOHEADER arkistoitu 19. huhtikuuta 2014 Wayback Machinessa " biClrUsed-kentän kuvaus sisältää lauseen "Jos biBitCount on 16 tai 32, optimaalinen väripaletti alkaa heti kolmen DWORD-maskin jälkeen." (käännös: " Jos biBitCount on 16 tai 32, optimaalinen väripaletti alkaa heti kolmen DWORD-maskin jälkeen "). Saman artikkelin yllä olevassa biCompression-kentän kuvauksessa lukee "Määrittää, että bittikartta ei ole pakattu ja että väritaulukko koostuu kolmesta DWORD-värimaskista…" ja alla on samanlainen kuin "koostuu neljästä DWORD-värimaskista" " (käännökset: "Määrittää, että bittikartta ei ole pakattu ja että väritaulukko koostuu kolmesta värillisestä DWORD-maskista" ja " koostuu neljästä värillisestä DWORD-maskista "). Samanlaisia ​​tietoja on artikkelissa " BITMAPINFOHEADER-rakenne Arkistoitu 9. helmikuuta 2014 Wayback Machinessa " Windows 9x/NT:lle. Kaikki tämä voidaan tulkita siten, että 16 ja 32 bittisyvyyksillä tietokenttien takana (BITMAPINFOHEADER-rakenne) on välttämättä kolme 32-bittistä maskia värikanava-arvojen poimimiseen. Lisäksi, jos pakkaus sisältää 3 (BI_BITFIELDS) tai 6 (BI_ALPHABITFIELDS), niiden jälkeen lisätään kolme tai neljä samanlaista maskia, jotka vuorostaan ​​täyttävät väritaulukon, mikä tekee mahdottomaksi käyttää 16-bittisiä optimaalisten värien indeksejä loogisessa. paletti (mahdollisesti tässä tapauksessa biClrUsedissa täytyy olla 6 tai 8 ja biClrImportantin on oltava 0, jotta lisämaskeja ei vahingossa käsitellä paletin indekseinä).
    Todellisuudessa asiat ovat hieman toisin.
18. ↑ MSDN:n dokumentaatiosivulla " Bitmap Header Types Arkistoitu 22. syyskuuta 2014 Wayback Machinessa " on lause "Bittikartoilla, jotka ovat 1, 4 tai 8 bpp, on oltava väritaulukko, jonka enimmäiskoko perustuu bpp:hen." (käännös: "Bittikartoissa, joiden bittisyvyys on 1, 4 tai 8, on oltava väritaulukko, jonka enimmäiskoko vastaa bittimäärää." ). Tämä on selvästi virhe, ja kirjoittaja on soveltanut CORE-rakenteen ehtoja, joiden pitäisi todellakin olla maksimi (katso "Huomautukset" artikkelissa " BITMAPCOREINFO-rakenne Arkistoitu 3. toukokuuta 2015 Wayback Machinessa "), kaikkiin muihin versiot rakenteista. Toisessa artikkelissa " BITMAPINFO rakenne Arkistoitu 24. kesäkuuta 2014 Wayback Machinessa " väritaulukosta sanotaan "Matriisin merkintöjen määrä riippuu BITMAPINFOHEADER-rakenteen biBitCount- ja biClrUsed-jäsenten arvoista." (käännös: "taulukon elementtien määrä riippuu BITMAPINFOHEADER-rakenteen biBitCount- ja biClrUsed-kenttien arvoista" ) ja rakenneversioiden 3, 4, 5 artikkeleissa (katso esimerkiksi " BITMAPV5HEADER rakenne Arkistoitu 11. lokakuuta 2013 Wayback Machinelle ) BitCount-kentän kuvauksessa "BITMAPINFO:n bmiColors-jäsen sisältää jopa 256 merkintää" on kirjoitettu kaikkialle (samalla tavalla muille bittinumeroille; lauseen käännös: "the bmiColors BITMAPINFO -jäsen sisältää jopa 256 merkintää" ).
19. ↑ Katso esimerkiksi bV5BitCount-kentän bittien 16 ja 32 kuvaukset artikkelista " BITMAPV5HEADER rakenne Arkistoitu 11. lokakuuta 2013 Wayback Machinessa " MSDN:ssä.
20. ↑ MSDN:n ja Microsoft Windows SDK:n ohjeessa artikkelissa " BITMAPINFOHEADER rakenne Arkistoitu 9. helmikuuta 2014 Wayback Machinessa " on hämmentävä lause "Kaikkia pikselin bittejä ei tarvitse käyttää." (käännös: " Älä käytä kaikkia pikselin bittejä "). Tämä on kirjoitusvirhe (he kirjoittivat "on" sanan "tarve" sijaan), joka puuttuu vastaavasta lohkosta artikkelissa, joka koskee viidettä versiota Arkistoitu 11. lokakuuta 2013 Wayback Machinessa (neljännestä tämä lause puuttuu).
21. ↑ Nämä tiedot löytyvät tärkeimpien IDE-laitteiden mukana toimitetusta Microsoft Windows SDK:n ohjeesta.
22. ↑ Katso " Image Pixel Format Constants Archived 4. toukokuuta 2014 Wayback Machinessa " GDI+:ssa MSDN:ssä.
23. ↑ Katso " PixelFormat Enumeration Arkistoitu 23. kesäkuuta 2013 Wayback Machinessa " .NET Framework 1.1:stä MSDN:ssä.
24. ↑ Katso " Huomautukset arkistoitu 24. kesäkuuta 2014 Wayback Machinessa " MSDN:n "BITMAPINFO" -artikkelissa.
25. ↑ Dokumentaatiossa (esimerkiksi artikkelissa " BITMAPV5HEADER rakenne arkistoitu 11. lokakuuta 2013 Wayback Machinessa " MSDN:ssä) sanotaan, että nollakoko voidaan määrittää arvolla 0 (BI_RGB) pakkauskenttään. Ilmeisesti tämä koskee myös arvoja 3 (BI_BITFIELDS) ja 6 (BI_ALPHABITFIELDS), koska ne vaikuttavat vain pikselien sisäiseen rakenteeseen, eivät niiden kokoon.
26. ↑ Pohjimmiltaan yksitellen, kuten väritaulukossa käytetyssä RGBQUAD-rakenteessa.
27. ↑ MSDN:ssä artikkelissa " BITMAPV4HEADER rakenne arkistoitu 11. lokakuuta 2013 Wayback Machinessa " mainitaan vain yksi CSType-kentän arvo (LCS_CALIBRATED_RGB). Täydellinen luettelo versioille 4 ja 5 saatavilla olevista arvoista on artikkelissa Rakenteiden käyttäminen WCS 1.0: ssa. Arkistoitu 3. toukokuuta 2015 Wayback Machinessa .
28. ↑ "Voit" jälkeen on toinen välilyönti.
29. ↑ Tämän vakioarvotyylin käyttö vain CSType-kentässä on todennäköisesti seurausta ICC-spesifikaatiosta, jossa 32-bittisille tunnisteille annetaan samanlaiset arvot väriprofiilitiedostoissa . 
30. ↑ Katso "Huomautukset" artikkelissa " LOGCOLORSPACE Structure Archived 14. huhtikuuta 2013 Wayback Machinessa " MSDN:ssä.
31. ↑ Numerot otettu julkaisusta " Internetin vakiooletusväriavaruus - sRGB Arkistoitu 20. elokuuta 2011 Wayback Machinessa ". Kaikki arvot pyöristettiin ylöspäin, jos ensimmäinen hylätty oikea bitti asetettiin.
32. ↑ Kun alhainen tavu on asetettu nollaan, arvo on 00001A00 16 (pyöristetty ylöspäin).
33. ↑ Tämä muoto on kuvattu ICC.1:2010-spesifikaatiossa, jonka linkki on tämän artikkelin lopussa.
34. ↑ Katso "Huomautukset" artikkelissa " BITMAPV5HEADER rakenne Arkistoitu 11. lokakuuta 2013 Wayback Machinessa " MSDN:ssä.
35. ↑ 1 2 Katso Rakenteiden käyttäminen WCS 1.0:ssa . Arkistoitu 3. toukokuuta 2015 MSDN :n Wayback Machinessa .
36. ↑ Katso kohta "7.2 Profiiliotsikko" ICC.1:2010-spesifikaatiossa.
37. ↑ Määritelmä on annettu ICC.1:2010-spesifikaatiossa kohdassa 3.1.27 sivulla s. 21.
38. ↑ Erittelyn versiossa 4.3 (viimeisin kirjoitushetkellä) tätä aihetta käsitellään laajasti osioissa "0.4 Rendering intents" (johdanto; s. 8), "6.2 Rendering intent" (pääsisällössä; s. 26) ja "D. 6 Kolorimetristen tarkoitusten käsittely" (liitteissä; s. 109).
39. ↑ Vakiokuvaukset on otettu Icm.h-tiedostosta (kommentoitu lohko aivan "INTENT_" vakiomäärittelyjen yläpuolella).
40. ↑ Katso ICC-spesifikaation kohta "7.2.15 Rendering intent field (tavut 64-67)".
41. ↑ Katso "Picture Intent" -osio artikkelista " Rendering Intents Archived 18. September 2012 at the Wayback Machine " MSDN:ssä.
42. ↑ Erittelyssä sivun 41 alalaidassa.

Kirjallisuus

Microsoft (MSDN ja SDK)

Microsoft Windows SDK  on kehittäjäpaketti, joka sisältää ohjeen ja C++-tiedostot. Tämän artikkelin aiheeseen liittyen tiedostot WinGDI.h ja Icm.h ovat merkityksellisiä, joista vakioiden arvot otettiin ensinnäkin. Tämän sarjan uusin versio voidaan ladata ilmaiseksi Microsoftin verkkosivustolta (tässä artikkelissa käytettiin versioita 6.0 ja 7.1).

Microsoftilla ei ole erillistä dokumentaatiota erityisesti BMP-muodolle. Mutta sen rakenteet ja muut elementit on kuvattu GDI-alijärjestelmässä. Tämä kuvaus on ohjeessa, joka sisältyy yllä olevaan SDK:han ja myös MSDN :ään . Lisäksi jälkimmäisessä se on läsnä eri alustoilla ja itsenäisesti Visual Studion ohjeessa. Useimmissa tapauksissa tiedot ovat identtisiä, mutta joissain paikoissa voi olla hieman enemmän faktoja (esimerkiksi SDK-ohjeessa on enemmän tietoa Windows-tuesta).

Katso perustiedot GDI-ohjeesta Windows 9x- ja NT-alustoille. Linkit tämän osion sivuille, jotka viittaavat vain muotoon, eivät sen kanssa työskenteleviin WinAPI-toimintoihin:

• " Bitmap Classifications " - kuvaus laitteistoriippuvaisista ja laitteista riippumattomista bittikartoista.
• " Bitmap Storage " on yleinen kuvaus BMP-tiedostomuodosta.
• " Bitmap Header Types " - yleiskatsaus BMP-otsikkoversioista.
• " Bittikartan pakkaus " on kuvaus RLE-koodauksesta.
• « Bitmap Structures » - osio, jossa kuvataan kenttien rakenteita. Mukavuuden vuoksi suorat linkit avaimeen:
  • BITTIMAPFIHEADERI
  • BITMAPCOREHEADER
  • BITMAPINFOHEADER
  • BITMAPV4HEADER
  • BITMAPV5HEADER

Windows Compact 2013 (CE 6.0)- ja Mobile 6.5 -alustoilla on kuvaukset vain kolmesta rakenteesta, mutta näille alustoille:

• BITTIMAPFIHEADERI
• BITMAPCOREHEADER
• BITMAPINFOHEADER

Linkkejä muille BMP-muotoon liittyville MSDN-sivuille:

• " Image Pixel Format Constants " - GDI+ pikselimuodon vakiot.
• " PixelFormat Enumeration " on kuvaus PixelFormat-luettelotyypin arvoista .NET Framework 1.1:lle (aikaisin versio).
• " Rakenteiden käyttäminen WCS 1.0:ssa " - Tietoja Windowsin värienhallinnassa käytetyistä rakenteista.
• " Rendering Intents " - Kuvaus renderöintiasetuksista.

Muut

ICC-värinhallintamääritykset tarjoavat tietoa väriprofiileista (mukaan lukien ICC-tiedostomuodosta) sekä renderöintiasetuksista. Tämä eritelmä voidaan ladata konsortion color.org viralliselta verkkosivustolta . Kirjoitushetkellä uusin versio on 4.3 (joulukuu 2010). Suorat linkit PDF-tiedostoon ICC:n verkkosivuilta:

• Specification ICC.1:2010 (Profiiliversio 4.3.0.0) "Kuvatekniikan värinhallinta - Arkkitehtuuri, profiilimuoto ja tietorakenne".
• Virhe spesifikaatiossa (virheitä ja kirjoitusvirheitä löydetty; julkaistu 24. syyskuuta 2013).

mediasäiliöt
Video/ääni	3gp ASF AVI Bink DMF DPX EVO FLV MP4 MPEG MPEG-PS MPEG-TS MXF Matroska (MKV) Ogg Media Ogg Nopea aika RIFF RealMedia Smacker VOB WebM WMV puristus vertailu
Audio	AIFF APINA A.U. DSD DXD FLAC MLP MP3 SHN_ WAV WMA puristus vertailu
Musiikki	MIDI ( KAR ) tracker musiikkia
Raster	DNG FPX FLIF HEIF ICER ICO ILBM JBIG2 JBIG JPEG XR (HD-valokuva) JPEG / JP2 / JPEG-LS MNG EXR PCX PNG PSD PNM Raaka TIFF TGA WBMP WebP XCF PGF Animoitu: APNG , GIF Häviötön: BMP Mukaan lukien häviöllinen pakkaus: BPG
Vektori	SWF AI CDR EPS PS SVG VRML EMF WMF X3D XPS 3D: 3DS Animoitu: SVG
Monimutkainen	CGM DjVu PDF