Hva betyr bmp? Hva er filtypen BMP? Hvilket program for å åpne bmp-utvidelsen

BMP(fra engelsk Bitmap bilde) er et rasterbildelagringsformat utviklet av Microsoft.

Et stort antall programmer fungerer med BMP-formatet, siden støtten er integrert i operativsystemene Windows og OS/2. BMP-filer kan ha filtypene .bmp, .dib og .rle. I tillegg er data i dette formatet inkludert i binære RES-ressursfiler og PE-filer.

Microsoft har også utviklet ICO- og CUR-formater for sine behov, som har en struktur som ligner på BMP. I tillegg brukes strukturer fra dette formatet av noen WinAPI-funksjoner i GDI-undersystemet.

Fargedybder i dette formatet kan være 1, 2, 4, 8, 16, 24, 32, 48 biter per piksel, men 2 biter per piksel støttes ikke offisielt. I dette tilfellet, for fargedybder mindre enn 16 biter, brukes en palett med fullfargekomponenter med en dybde på 24 biter.

I BMP-formatet kan bilder lagres som de er eller ved å bruke noen vanlige komprimeringsalgoritmer. Spesielt støtter BMP-formatet RLE-komprimering uten tap av kvalitet, og moderne operativsystemer og programvare tillater bruk av JPEG og PNG (disse formatene er innebygd i BMP som en container).

DIB og DDB

Når du bruker DIB-formatet Enhetsuavhengig bitmap, enhetsuavhengig raster), kan programmereren få tilgang til alle elementene i strukturene som beskriver bildet ved hjelp av en vanlig peker. Men disse dataene brukes ikke til å kontrollere skjermen direkte, siden de alltid er lagret i systemminnet og ikke i dedikert videominne. Pikselformatet i RAM kan avvike fra formatet som må lagres i videominnet for å vise et punkt med samme farge. For eksempel kan DIB-formatet bruke 24 biter for å spesifisere en piksel, og for øyeblikket kan grafikkadapteren operere i HiColor-modus med en fargedybde på 16 biter. I dette tilfellet vil den knallrøde prikken spesifiseres i et maskinvareuavhengig format med tre byte 0x0000ff, og i videominnet med ordet 0xF800. Når du kopierer et bilde til skjermen, vil systemet bruke ekstra tid på å konvertere fargekoder fra 24-bits formatet til videobufferformatet.

Oversikt over filstruktur

BMP-filen består av fire deler:

  1. Filoverskrift (BITMAPFILEHEADER)
  2. Bildetittel (BITMAPINFOHEADER, kan mangle). BITMAPV4HEADER (Win95, NT4.0) BITMAPV5HEADER (Win98/Me, 2000/XP)
  3. Palett (kan mangle)
  4. Selve bildet

BITMAFILEHEADER

Denne strukturen inneholder informasjon om typen, størrelsen og representasjonen av dataene i filen. Størrelse 14 byte.

Typedef struct tagBITMAPFILEHEADER ( WORD bfType; // forskyv 0 byte fra begynnelsen av filen DWORD bfSize; // forskyv 2 byte fra begynnelsen av filen, lengde 4 byte ORD bfReserved1; ORD bfReserved2; DWORD bfOffBits;

// forskyv 10 byte fra begynnelsen av filen, lengde 4 byte

  • ) BITMAPFILEHEADER, * PBITMAPFILEHEADER;
  • WORD-typen må være 16 biter, DWORD- og LONG-typene må være 32 biter, LONG-typen må være signert, og byte-rekkefølgen antas å være liten endian.
  • bfType - filtype, tegn "BM" (i HEX: 0x42 0x4d).
  • bfSize - størrelsen på hele filen i byte.

bfReserved1 og bfReserved2 er reservert og må inneholde nuller.

bfOffBits - inneholder forskyvningen i byte fra begynnelsen av BITMAPFILEHEADER-strukturen til selve bildebitene.

Etter filoverskriften

BITMAPINFOHEADER

Det enkleste overskriftsalternativet. Programmer for Windows NT3.51 og tidligere kan bare bruke denne strukturen. Størrelse 40 byte.

  • 0 - gir mening for Win98/Me/2000/XP. Antall bits per piksel bestemmer JPEG- eller PNG-formatet.
  • 1 - monokromt bilde. bmiColors-medlemmet i BITMAPINFO-strukturen inneholder to elementer. Hver bit av et bilde representerer én piksel; hvis biten er null, har pikselen fargen til det første elementet i bmiColors-tabellen, ellers - fargen til det andre.
  • 4 - seksten-farget bilde. Piksler er definert av 4-bits indekser, hver byte av bildet inneholder informasjon om to piksler - de viktigste 4 bitene for den første, de resterende for den andre.
  • 8 - paletten inneholder opptil 256 farger, hver byte av bildet lagrer en indeks i paletten for én piksel.
  • 16 - hvis biCompression-feltet inneholder verdien BI_RGB, inneholder ikke filen en palett. Hver to byte av bildet lagrer intensiteten til de røde, grønne og blå komponentene til én piksel. I dette tilfellet brukes ikke den mest signifikante biten. 5 biter tildeles for hver komponent: 0RRRRRGGGGGGBBBBB.
    Hvis biCompression-feltet inneholder verdien BI_BITFIELDS, lagrer paletten tre fire-byte verdier som definerer en maske for hver av de tre fargekomponentene. Hver piksel i et bilde er representert av en to-byte verdi som fargekomponenter trekkes ut fra ved hjelp av masker. For WinNT/2000/XP må bitsekvensene til hver komponent følge kontinuerlig, uten å overlappe eller krysse sekvensene til andre komponenter. For Win95/98/Me - bare følgende masker støttes: 5-5-5, hvor masken til den blå komponenten er 0x001F, grønn 0x03E0, rød 0x7C00; og 5-6-5, hvor masken til den blå komponenten er 0x001F, grønn 0x07E0, rød 0xF800.
  • 24 - paletten brukes ikke, hver tre byte av bildet representerer en piksel, en byte for intensiteten til henholdsvis de blå, grønne og røde kanalene.
  • 32 - Hvis biCompression-feltet inneholder verdien BI_RGB, inneholder ikke bildet en palett. Hver fjerde byte av bildet representerer én piksel, én byte for intensiteten til henholdsvis de blå, grønne og røde kanalene. Den viktigste byten til hver quad brukes vanligvis ikke, men tillater lagring av alfakanaldata.
    Hvis biCompression-feltet inneholder verdien BI_BITFIELDS, lagres tre fire-byte fargemasker i paletten - for de røde, grønne og blå komponentene. Hver piksel i et bilde er representert med fire byte. WinNT/2000: komponentmasker må ikke overlappe eller krysse hverandre. Windows 95/98/Me: systemet støtter bare én komprimeringsmodus, helt lik modusen uten komprimering BI_RGB - den viktigste byten av hver fire brukes som en alfakanal, de neste tre er reservert for blå, grønne og røde kanaler, henholdsvis: 0xAARRGGBB.
biCompression Komprimeringstype for komprimerte bilder:
Betydning Identifikator Komprimering
0 BI_RGB ukomprimert bilde
1 BI_RLE8 RLE-komprimering for 8-bits bilder
2 BI_RLE4 RLE-komprimering for 4-bits bilder
3 BI_BITFIELDS bildet er ikke komprimert, paletten inneholder tre 4-byte masker for de røde, grønne og blå fargekomponentene. Brukes til 16 og 32 bits bilder
4 BI_JPEG Win98/Me/2000/XP: JPEG-komprimering
5 BI_PNG Win98/Me/2000/XP: PNG-komprimering
6 BI_ALPHABITFIELDS WinCE: bildet er ikke komprimert, paletten inneholder fire 4-byte masker for de røde, grønne, blå og transparente (alfakanal) fargekomponentene. Brukes til 16 og 32 bits bilder
biSizeImage Bildestørrelse i byte. Kan inneholde null for BI_RGB-bilder. Win98/Me/2000/XP: Hvis biCompression inneholder BI_JPEG eller BI_PNG, spesifiserer biSizeImage størrelsen på BI_JPEG- eller BI_PNG-bildebufferen.
biXPelsPerMeter Horisontal oppløsning i piksler per meter for målenheten. En applikasjon kan bruke denne verdien til å velge fra en gruppe bilderessurser det mest passende bildet for gjeldende enhet. For DPI 96, som er akseptert av Microsoft for skjermer, vil den være lik 3780 (hvis den beregnes ved hjelp av formelen (96 / 25,4) * 1000).
I et pakket bilde følger pikselmatrisen umiddelbart BITMAPINFO-strukturen, biClrUsed må inneholde null eller den faktiske palettstørrelsen.

biClrImportant Antall palettelementer som kreves for å vise bildet. Hvis den inneholder null, er alle indekser like viktige.

BITMAPINFO-strukturen kombinerer BITMAPINFOHEADER og paletten, og gir en fullstendig beskrivelse av dimensjonene og fargene til et bilde.

For å finne paletten i BITMAPINFO-strukturen, må applikasjonen bruke informasjonen som er lagret i biSize som følger:

PColor = ((LPSTR) pBitmapInfo + (WORD) (pBitmapInfo-> bmiHeader.biSize ) );

Rasteret er vanligvis lagret i en vertikal speilet form. Men det er også mulig å lagre rasteret ikke i en vertikal speilet form. Et tegn på at rasteret i BMP ikke er i vertikal speilform spesifiseres av parameteren biHeight.

BITMAPV4HEADER

En utvidet versjon av strukturen beskrevet ovenfor. Win NT 3.51 og tidligere må bruke BITMAPINFOHEADER-strukturen. Win98/Me/2000/XP kan bruke BITMAPV5HEADER-strukturen i stedet for BITMAPV4HEADER-strukturen.

Typedef struct ( DWORD bV4Size; LONG bV4Width; LONG bV4Height; WORD bV4Planes; WORD bV4BitCount; DWORD bV4V4Compression; DWORD bV4SizeImage; LONG bV4XPelsPerMeter; LONG bV4YPelsPerMer; DWORD bV4YPelsPerMeter; maur DWORD bV4GreenMask ;

  • Feltene fra begynnelsen av strukturen til og med bV4ClrImportant har samme formål som de tilsvarende feltene til BITMAPINFOHEADER-strukturen.
  • bV4RedMask - fargemaske for den røde komponenten til hver piksel, brukes bare hvis bV4Compression inneholder BI_BITFIELDS-verdien.
  • bV4GreenMask - fargemaske for den grønne komponenten til hver piksel, brukes bare hvis bV4Compression inneholder BI_BITFIELDS-verdien.
  • bV4BlueMask - fargemaske for den blå komponenten til hver piksel, brukes bare hvis bV4Compression inneholder BI_BITFIELDS-verdien.
  • bV4AlphaMask - maske som definerer alfakanalkomponenten.
  • bV4CSType - definerer fargerommet til bildet.
  • bV4GammaRed - tonekurve for den røde komponenten. Ignorert hvis bV4CSType ikke inneholder en LCS_CALIBRATED_RGB-verdi. Indikert i 16×16 format.
  • bV4GammaGreen - tonekurve for den grønne komponenten. Ignorert hvis bV4CSType ikke inneholder en LCS_CALIBRATED_RGB-verdi.
  • bV4GammaBlue - blå komponenttonekurve. Ignorert hvis bV4CSType ikke inneholder en LCS_CALIBRATED_RGB-verdi.

BITMAPV5HEADER

Win95/NT 4.0: Applikasjoner kan bruke BITMAPV4HEADER. Win NT 3.51 og tidligere må bruke BITMAPINFOHEADER-strukturen.

Typedef struct ( DWORD bV5Size; LONG bV5Width; LONG bV5Height; WORD bV5Planes; WORD bV5BitCount; DWORD bV5Compression; DWORD bV5SizeImage; LONG bV5XPelsPerMeter; LONG bV5YPelsPerClUd bV5ClDbWORDI; V5GreenMask DWORD bV5AlphaMask ; 5HEADER;

For felt fra begynnelsen av strukturen til og med bV5GammaBlue vil kun forskjeller fra tidligere versjoner - BITMAPINFOHEADER og BITMAPV4HEADER bli beskrevet.

  • bV5CSType - definerer fargerommet til bildet, kan ta følgende verdier:
LCS_CALIBRATED_RGB LCS_sRGB LCS_WINDOWS_COLOR_SPACE PROFILE_LINKED PROFILE_EMBEDDED
  • bV5Intent - kan ta følgende verdier:
LCS_GM_ABS_COLORIMETRIC LCS_GM_BUSINESS LCS_GM_GRAPHICS LCS_GM_IMAGES
  • bV5ProfileData - forskyvning i byte fra begynnelsen av strukturen til begynnelsen av profildataene (profilfilnavn, en streng bestående utelukkende av kodetabell 1252 tegn og slutter med null byte). Ignorert hvis bV5CSType inneholder en annen verdi enn PROFILE_LINKED og PROFILE_EMBEDDED.
  • bV5ProfileSize - profildatastørrelse i byte.
  • bV5Reservert - reservert. Inneholder null.

Palett

Paletten kan inneholde en sekvens av fire-byte felt i henhold til antall tilgjengelige farger (256 for et 8-bits bilde). De lave tre bytene i hvert felt bestemmer intensiteten til de røde, grønne og blå komponentene i fargen. Hver piksel i bildet beskrives i dette tilfellet med én byte som inneholder nummeret til palettfeltet der fargen til denne pikselen er lagret.

Hvis en bildepiksel er beskrevet med et 16-bits tall, kan paletten lagre tre to-byte verdier, som hver definerer en maske for å trekke ut de røde, grønne og blå fargekomponentene fra 16-bits pikselen.

En BMP-fil kan ikke inneholde en palett hvis den lagrer et ukomprimert fullfargebilde.

Bildedata

En sekvens av piksler tatt opp i en eller annen form. Piksler lagres rad for rad, fra bunn til topp. Hver bildelinje er polstret med nuller til en lengde som er et multiplum av fire byte.

I bmp-filer med en fargedybde på 24 biter, lagres fargebytene til hver piksel i BGR (blå, grønn, rød) rekkefølge.

I bmp-filer med en fargedybde på 32 biter lagres fargebytene til hver piksel i BGRA-rekkefølge (blå, grønn, rød, alfa)

Bildebitdybde

Avhengig av antall representerte farger, tildeles hvert punkt fra 1 til 48 biter:

  • 1 bit - monokromt bilde (to farger).
  • 2 bits - 4 mulige farger (CGA driftsmoduser) (2-bits modus er ikke offisielt standardisert, men brukes).
  • 4 bits - 16-farget bilde (EGA-driftsmodus).
  • 8 bits (1 byte) - 256 farger, den siste av modusene som støtter indekserte farger (se nedenfor).
  • 16 bits (2 byte) - HiColor-modus, For 5-6-5 = 65536 mulige nyanser, for 5-5-5 = 32768 mulige nyanser.
  • 24 bits (3 byte) - TrueColor. Fordi 3 byte ikke tilordnes godt til potenser av to (spesielt når du lagrer data i minnet, der datajustering på en ordgrense er viktig), brukes ofte et 32-bits bilde i stedet. I TrueColor-modus er hver av de tre kanalene (i RGB-modus) tildelt 1 byte (256 mulige verdier), det totale antallet farger er .
  • 32 biter (4 byte) - denne modusen ligner nesten på TrueColor, den fjerde byten brukes vanligvis ikke, eller alfakanalen (gjennomsiktighet) er plassert i den.
  • 48 bits (6 bytes) - et sjeldent brukt format med økt fargenøyaktighet (16 bits per kanal), støttet av et relativt lite antall programmer og utstyr.

Indekserte farger

Når antall biter er 1 (2 farger), 2 (4 farger), 4 (16 farger) eller 8 (256 farger) per piksel, kan en spesiell indeksert fargemodus brukes. I dette tilfellet indikerer ikke tallet som tilsvarer hver piksel fargen, men tallet på fargen i paletten. Ved å bruke en palett er det mulig å tilpasse bildet til fargene som finnes i bildet. I dette tilfellet er bildet ikke begrenset av spesifiserte farger, men av maksimalt antall farger som brukes samtidig.

Eksempel program

Følgende program åpner en 24-bits BMP-fil i et XWindow, fargedybden skal være 32 biter, det fungerer ikke ved lavere fargegjengivelser, da det kompliserer eksemplet:

/* Kompilert med linjen: cc -o xtest xtest.c -I/usr/X11R6/include -L/usr/X11R6/lib -lX11 -lm */#inkludere #inkludere #inkludere #inkludere #inkludere #inkludere #inkludere #inkludere #inkludere #inkludere #inkludere #include "bitmap.h" /* Her er BMP-hodedefinisjonene som beskrevet ovenfor i denne artikkelen */ statisk XImage * CreateImageFromBuffer(Display*, usignert tegn *, int, int); main(int argc, char * argv ) ( Display * dis; Window win; /* Vårt vindu */ XEvent event; /* Events */ GC gc;/* Grafikkkontekst */< 2 ) { perror ("use: xtest file.bmpXImage * image; int n, bredde, høyde, fd, størrelse; XImage * image; usignert char * data; BITMAPFILEHEADER bmp; BITMAPINFOHEADER inf; røye * buff; hvis (argc \n") ; exit(1);) if ((fd = open(argv[ 1 ] , O_RDONLY) ) == - 1 ) ( printf ("Feil ved åpen punktgrafikk ) ; exit(1); /* Les inn i bufferen */ n = read(fd, buf, størrelse) ; printf("størrelse = %d byte lest\n " , n); image = CreateImageFromBuffer(dis, buf, width, height) ; /* Slett bufferen - vi trenger den ikke lenger */ gratis(buff); XMapWindow(dis, vinn); XSelectInput(dis, win, ExposureMask | KeyPressMask) ; while (1 ) ( XNextEvent(dis, & event) ; if (event.xany .window == win) ( switch (event.type ) ( case Expose: XPutImage(dis, win, gc, image, 0 , 0 , 0 , 0 , image-> width, image-> height ; break ; case KeyPress: if (XLookupKeysym(& event.xkey , 0 ) == XK_q) ( XDestroyImage(image); XCloseDisplay(dis) ; close(fd) ; exit (EXIT_SUCCESS) ;/* Oppretter et Ximage fra en BMP-fil, siden BMP-bildet er lagret opp-ned * og speilvendt - dette korrigeres i loopen */ XImage * CreateImageFromBuffer(Display * dis, usignert char * buf, int width, int height) ( int dybde, skjerm; XImage * img = NULL; int i, j; int numBmpBytes; size_t numImgBytes; int32_t int * img ; int linje;/* Rad- og kolonnenummer for å gjenspeile */< numBmpBytes; i++ ) { unsigned int r, g, b; int ny_ind;/* Ny indeks */ skjerm = DefaultScreen(dis) ; depth = DefaultDepth(dis, skjerm) ; temp = bredde * 3;<< 8 | b << 16 ) << 8 ; ind++; } img = XCreateImage(dis, CopyFromParent, depth, ZPixmap, 0 , (char * ) imgBuf, width, height, 32 , 0 ) ; XInitImage(img) ; linje = temp + bredde % 4 ;/* Strenglengde tar hensyn til justering */

BMP-filformatet (forkortelse for BitMaP) er det opprinnelige rastergrafikkformatet for Windows fordi det samsvarer best med det opprinnelige Windows-formatet som systemet lagrer rastermatrisene i. Filnavnet som oftest brukes i BMP-format er BMP, selv om noen filer har utvidelsen RLE, som står for run length encoding. RLE-utvidelsen til et filnavn indikerer vanligvis at filens rasterinformasjon har blitt komprimert ved hjelp av en av to RLE-komprimeringsmetoder som er gyldige for filer i BMP-format.

I BMP-filer er fargeinformasjonen til hver piksel kodet med 1, 4, 8, 16 eller 24 bits (bits/piksel). Antall bits per piksel, også kalt fargedybde, bestemmer det maksimale antallet farger i et bilde. Et bilde med en dybde på 1 bit/piksel kan bare ha to farger, og med en dybde på 24 bit/piksel – mer enn 16 millioner forskjellige farger.

Diagrammet nedenfor viser strukturen til en typisk BMP-fil som inneholder et 256-farget bilde (8 bits/pikseldybde). Filen er delt inn i fire hovedseksjoner: rastergrafikkfiloverskriften,ften, fargetabellen og selve rastermatrisedataene. Overskriften til en rastergrafikkfil inneholder informasjon om filen, inkludert adressen der rastermatrisen dataområdet begynner. Rasterarrayinformasjonshodet inneholder informasjon om bildet som er lagret i filen, for eksempel høyden og bredden i piksler. Fargetabellen gir RGB (rød, grønn, blå) primærfargeverdier for fargene som brukes i bildet. Programmer som leser og viser BMP-filer, når de bruker videoadaptere som ikke tillater visning av mer enn 256 farger, kan programmert sette slike RGB-verdier i fargepalettene til adapterene for nøyaktig fargegjengivelse.

Formatet til de faktiske rastermatrisedataene i en BMP-fil avhenger av antall biter som brukes til å kode fargedataene for hver piksel. Med et 256-fargerbilde beskrives hver piksel i den delen av filen som inneholder de faktiske rastermatrisedataene med én byte (8 bits). Denne pikselbeskrivelsen representerer ikke RGB-fargeverdier, men fungerer som en peker for å gå inn i filens fargetabell. Således, hvis R/G/B=255/0/0 er lagret som den første RGB-fargeverdien i fargetabellen til en BMP-fil, vil verdien av piksel 0 i raster-arrayet bli tildelt fargen knallrød. Pikselverdier lagres i venstre-til-høyre rekkefølge, og starter (vanligvis) på nederste rad av bildet. Således, i en 256-fargers BMP-fil, er den første byten med raster-array-data indeksen for fargen på pikselen som er plassert i nedre venstre hjørne av bildet; den andre byten representerer indeksen for fargen på pikselen ved siden av høyre, osv. Hvis antallet byte i hver rad er oddetall, legges en ekstra byte til hver rad for å justere rastermatrisedataene på 16-bits grenser .


Ikke alle BMP-filer har en struktur som den som er vist i diagrammet. For eksempel har 16- og 24-bit/piksel BMP-filer ikke fargetabeller; i disse filene karakteriserer pikselverdiene til rastermatrisen direkte RGB-fargeverdiene. De interne lagringsformatene til individuelle deler av filen kan også variere. Raster array-informasjon i noen 16- og 256-fargers BMP-filer kan for eksempel komprimeres ved hjelp av RLE-algoritmen, som erstatter sekvenser av identiske bildepiksler med tokens som spesifiserer antall piksler i sekvensen og deres farge. På Windows kan du jobbe med OS/2-stil BMP-filer som bruker ulike raster array header og fargetabellformater.

Denne artikkelen handler om hvordan bmp-grafikkformatet ser ut. Selv om dette er et av de enklere formatene, på grunn av det faktum at det finnes mange varianter av dette formatet, er ikke alle punkter åpenbare. Så slutt å helle vann, la oss komme i gang.

Format strukturer

Bmp-formatet (fra ordene BitMaP - bitmap, eller, på russisk, bitarray) er et ukomprimert (for det meste) bilde som er ganske enkelt å lese og vise i Windows OS, som har spesielle API-funksjoner som hjelper.

La oss først gi en grafisk representasjon av dataene i bmp (bilde hentet fra MSDN).

I begynnelsen er det en filoverskrift (BITMAPFILEHEADER). Det er beskrevet som følger:

bfType bestemmer filtypen. Her skal han være BM. Hvis du åpner en BMP-fil i en tekstredigerer (eller enda bedre, i en heksadesimal editor), vil du se at de to første tegnene er BM (fra ordet BitMap, som du sikkert allerede har gjettet).
bfStørrelse er størrelsen på selve filen i byte. Strengt tatt bør du beregne det (noe som anbefales), men jeg satte filstørrelsen feil (men ikke med vilje :)) og det var ingen problemer (ACDSee lest uten problemer, programmet mitt fungerte), men jeg anbefaler deg ikke skriv det bevisst feil , plutselig dukker det opp et samvittighetsfullt program som vil sammenligne denne størrelsen med det ekte og bestemme at det ikke er bmp, men noe annet. Ideelt sett bør alle programmer, for å sikre at det er en ekte bmp og ikke en falsk, for det første sjekke at bfType inneholder "BM" (uten anførselstegn), og for det andre at bfSize er lik filstørrelsen .
bfReserved1 og bfReserved2 er reservert og må være null.
bfOffBits. Dette er et av de viktigste feltene i denne strukturen. Den viser hvor selve punktgrafikken begynner i forhold til begynnelsen av filen (eller, som MSDN sier, "fra begynnelsen av BITMAPFILEHEADER-strukturen"), som beskriver bildet. Det vil si, for å være garantert å komme til begynnelsen av matrisen må du skrive:

typedef struct tagBITMAPINFOHEADER
{
DWORD biSize;
LANG biBredde;
LANG biHøyde;
WORD biPlanes;
WORD biBitCount;
DWORD bikomprimering;
DWORD biSizeImage;
LANG biXPelsPerMeter;
LANGE biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrViktig;
) BITMAPINFOHEADER, * PBITMAPINFOHEADER;

biSize er størrelsen på selve strukturen. Den må initialiseres som følger: bih.biSize = sizeof(BITMAPINFOHEADER);
Her vil vi igjen anta at bih er erklært som følger: BITMAPINFOHEADER bih;
biWidth og biHeight angi bredden og høyden på bildet i piksler, henholdsvis.
biPlanes angir antall fly. Foreløpig er den alltid satt til 1.
biBitCount- Antall biter per piksel. Vi snakker mer om dette nedenfor.
bikompresjon angir typen komprimering. Ikke vær overrasket eller redd for at bmp plutselig opplever kompresjon. Jeg personlig har ikke sett mer enn én komprimert bmp (men jeg sier ikke at de ikke eksisterer). Hvis det ikke er noen komprimering, må dette flagget settes til BI_RGB. I denne artikkelen snakker vi om det ukomprimerte formatet, så jeg vil ikke en gang liste opp andre flagg. Det ser ut til at den samme strukturen brukes i JPEG- og PNG-filer, for fra Windows 98 var det alternativer BI_JPEG, som viser at dette bildet er JPEG og BI_PNG, at det er PNG (jeg vet ikke noe om Jpeg-formatet, Jeg har nettopp gjort disse konklusjonene basert på det som er skrevet i MSDN).
biSizeImage angir størrelsen på bildet i byte. Hvis bildet er ukomprimert (det vil si at forrige felt er satt til BI_RGB), skal det skrives en null her. biXPelsPerMeter Og biYPelsPerMeter angir henholdsvis den horisontale og vertikale oppløsningen (i piksler per meter) til den endelige enheten som punktgrafikken (rasteret) skal sendes ut på. En applikasjon kan bruke denne verdien til å velge fra en gruppe ressurser den mest passende punktgrafikken for den ønskede enheten. Faktum er at bmp-formatet i hovedsak er et maskinvareuavhengig raster, det vil si når utseendet til det oppnådde ikke avhenger av hva dette rasteret projiseres på (så å si). Et bilde vil for eksempel se likt ut uansett om det er tegnet på en skjerm eller skrevet ut på en skriver. Men oppløsningen til enhetene er forskjellig, og det er nettopp for å velge det mest passende bildet fra de tilgjengelige at disse parametrene brukes.
biClrUsed bestemmer antall farger som brukes fra tabellen. Hvis denne verdien er null, bruker rasteret det maksimale antallet farger som tillates av biBitCount-verdien. Dette er kun relevant for komprimerte bilder. Hvis biClrUsed ikke er null og biBitCount er mindre enn 16, bestemmer biClrUsed gjeldende antall tilgjengelige grafikkmotor- eller enhetsdriverfarger. Hvis biBitCount er større enn eller lik 16, bestemmer biClrUsed størrelsen på fargetabellen som brukes til å optimalisere den gjeldende systempaletten.
biClrViktig- dette er antallet viktige farger. Bestemmer antall farger som trengs for å avbilde tegningen. Hvis denne verdien er 0 (som den vanligvis er), anses alle farger som viktige.

Typer BMP-format

Alle typer bmp-format betinget kan deles inn i to typer: palett og ikke-palett. Det vil si om paletten brukes i et gitt format eller ikke. Vær oppmerksom på at paletten til og med kan være i palettfrie formater, men den brukes ikke der. I palettfrie bmps beregnes fargen direkte fra bitene som går i filen, med utgangspunkt i et bestemt sted. Og i paletter beskriver hver byte en eller flere piksler, og byte- (eller bit-verdier) er fargeindeksen i paletten. Til å begynne med vil jeg gi en tabell som sammenligner de mulige alternativene. Bildetypen (palett eller palettfri) avhenger av hvor mange biter som gis per piksel, det vil si biBitCount-verdien til BITMAPINFOHEADER-strukturen.

biBitCountPalett eller ikke-palettformatMaksimalt mulig antall fargerNotater 1 Palett2 Et tofarget palettbilde, vel å merke, ikke nødvendigvis svart-hvitt. Hvis rasterbiten (som er like under) tilbakestilles (lik 0), betyr dette at den første fargen fra paletten skal være på dette stedet, og hvis den er satt (lik 1), så den andre. 4 Palett16 Hver byte beskriver 2 piksler. Her er et eksempel fra MSDN Hvis den første byten i bildet er 0x1F, tilsvarer den to piksler, fargen på den første er den andre fargen fra paletten (fordi nedtellingen starter fra null), og den andre pikselen er. den 16. fargen på paletten. 8 Palett256 Et av de vanligste alternativene. Men samtidig de enkleste. Paletten tar opp en kilobyte (men det er bedre å ikke stole på det). Én byte er én farge. Dessuten er verdien fargenummeret i paletten. 16 Ingen palett2^16 eller 2^15Dette er det mest forvirrende alternativet. La oss starte med det faktum at det er palettfritt, det vil si at hver to byte (ett WORD-ord) i rasteret definerer en piksel unikt. Men her er hva som skjer: det er 16 biter, og det er 3 fargekomponenter (rød, grønn, blå). Men 16 ønsker ikke å bli delt på 3. Derfor er det to alternativer her. Den første er å bruke 15 biter i stedet for 16, så er det 5 biter for hver fargekomponent. På denne måten kan vi bruke maksimalt 2^15 = 32768 farger og få en trippel R-G-B = 5-5-5. Men så er en hel bit av 16 bortkastet forgjeves. Men det hender at øynene våre, blant alle farger, oppfatter grønt bedre, så vi bestemte oss for å gi denne ene biten til den grønne komponenten, det vil si at vi får den. trippel R-G-B = 5-6-5, og nå kan vi bruke 2^16 = 65536 farger. Men det mest ubehagelige er at begge alternativene brukes. MSDN foreslår at for å skille hvor mange farger som brukes, fyll biClrUsed-feltet fra BITMAPINFOHEADER-strukturen med denne verdien. For å velge hver komponent må du bruke følgende masker. For 5-5-5 format: 0x001F for blå komponent, 0x03E0 for grønn og 0x7C00 for rød. For 5-6-5-formatet: henholdsvis 0x001F - blå, 0x07E0 - grønn og 0xF800 røde komponenter. 24 Ingen palett2^24 Og dette er det enkleste formatet. Her definerer 3 byte 3 fargekomponenter. Det vil si én komponent per byte. Vi leser ganske enkelt RGBTRIPLE-strukturen og bruker dens rgbtBlue, rgbtGreen, rgbtRed felt. De går i den rekkefølgen. 32 Ingen palett2^32 Her definerer 4 byte 3 komponenter. Men én byte brukes ikke. Den kan for eksempel brukes til alfakanalen (transparens). I dette tilfellet er det praktisk å lese rasteret ved hjelp av RGBQUAD-strukturer, som er beskrevet som følger:

Datalagring i bmp-format

Vel, nå kommer vi til den mest interessante delen. Etter strukturene BITMAPFILEHEADER og BITMAPINFOHEADER kommer paletten. Dessuten, hvis formatet er palettfritt, er det kanskje ikke der, men du bør ikke stole på det. Faktum er at da jeg akkurat begynte å forstå bmp-formatet, leste jeg i en bok at visstnok, hvis formatet er palettfritt, så har det ingen palett i det hele tatt. Det var til og med to bilder - formatdiagrammer: ett med palett, det andre uten. Og på den tiden skrev jeg et program som flittig opererer med bmp-filer. Og jeg måtte konvertere innkommende bilder fra 256 farger til 24-biters (hvis noen) til midlertidige filer. Og jeg lagde rett og slett ikke en palett i 24-bit (bfOffBits fra BITMAPFILEHEADER-strukturen var lik summen av sizeof(BITMAPFILEHEADER) + sizeof (BITMAPINFOHEADER), og lot de innkommende 24-bitsene være uendret. Med 256-fargers raster fungerte som det skulle, før jeg ikke kom over et 24-bits bilde som hadde søppel vist nederst i stedet for den nødvendige delen, forsto jeg ikke umiddelbart hva som var galt før jeg sammenlignet størrelsen på den originale filen med teoretisk en som burde vært der hvis det ikke hadde vært noen palett (selv om alle bildene jeg kom over hadde en palettstørrelse på 256 farger, eller 1Kb), flytter du alltid gjennom filen til begynnelsen av rasteret, ved å bruke bfOffBits. Paletten er en rekke RGBQUAD-strukturer ikke alle farger brukes i paletten (men bare for eksempel 16), da er ofte 256 felter tildelt for paletten A 256 * 4 = 1024, hvor 4 er størrelsen på RGBQUAD-strukturen, det vil si den samme en kilobyte oppnås.

Umiddelbart etter paletten kommer selve rasteret. Det er her ting blir mer forvirrende. For det første beskrives pikslene her som skrevet i tabellen ovenfor, avhengig av formatet. Og de kan selv inneholde verdien av fargekomponentene (for palettfrie), eller de kan være indekser for en palettarray. Selve bildet tas opp linje for linje. For det andre ser bildet ut til å være opp ned. Det vil si at den nederste linjen skrives først, deretter den nest siste linjen, og så videre helt til toppen. Og for det tredje, som skrevet i, hvis størrelsen på rasterlinjen ikke er et multiplum av 4, så fylles den med 1 til 3 tomme (null) byte slik at lengden på linjen er et multiplum av avsnittet. Dette er det mest ubehagelige. Faktum er at for hvert format må du justere dette antallet tomme byte (selv om jeg liker å skrive en del av paletten der, vil jeg bare ikke lage ekstra "null" variabler hvis disse bytene blir hoppet over uansett og ingen trenger dem). Jeg gir en tabell med formler som viser for hvilket format hvor mange byte som skal legges til på slutten av linjen. Der betyr Width-variabelen, som du kanskje gjetter, bredden på bildet. Alle disse formlene ble etablert eksperimentelt. Jeg vil gi et eksempel bare for de mest brukte formatene. For resten kan du skrive det selv.

Eksempel programmer

Du kan laste ned alle kildene jeg vil ikke skrive mye her. Jeg vil bare gi funksjonene med kommentarer.

Hei 1. Lage et bilde i bmp-format.
Her skapes et monokromatisk bilde. Det er tre eksempler på slike funksjoner: å lage bmp 8, 16 og 24 biter. Jeg gir bare for 16-bit.

// La oss lage et bilde i bmp-format 16 biter som 5-5-5, som ganske enkelt vil være monokromatisk
void CreateBmp555(char * fname, WORD-farge)
{
HÅNDTER hFile;
DWORD RW;
int i, j;

// Erklære nødvendige strukturer
BITMAPFILEHEADER bfh;
BITMAPINFOHEADER bih;
BYTE-palett[1024];

// Palett
// La oss ha et bilde på 35 x 50 piksler
int Bredde = 35;

int Høyde = 50; memset(Palett, 0, 1024);
// I paletten har vi nuller, fyll dem

memset (&bfh, 0 , sizeof (bfh) ); Bfh.bfType = 0x4D42 ;
// La oss betegne at dette er bmp "BM" bfh.bfOffBits = størrelse på (bfh) + størrelse på (bih) + 1024 ;
// Paletten tar opp 1Kb, men vi vil ikke bruke den
bfh.bfSize = bfh.bfOffBits +
sizeof(color) * Bredde * Høyde + Høyde * ((størrelse på (farge) * Bredde) % 4 );
// Beregn størrelsen på den endelige filen
memset (& bih, 0 , sizeof (bih) );
bih.biSize = sizeof(bih); // Det er sånn det skal være
bih.biBitCount = 16 ; // Vi bruker 5-5-5
bih.biCompression = BI_RGB;
// Ingen komprimering
bih.biHeight = Høyde;
bih.biWidth = Bredde;
bih.biPlanes = 1 ;

// Bør være 1
// Og de resterende feltene forblir 0
HFile = CreateFile (fname, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL);

if (hFile == INVALID_HANDLE_VALUE)
returnere ;
// Skriv overskriftene

WriteFile (hFile, & bfh, sizeof (bfh) , & RW, NULL );
WriteFile (hFile, & bih, sizeof (bih) , & RW, NULL );
// Skriv paletten< Height; i++ )
{
WriteFile(hFile, Palette, 1024, &RW, NULL);< Width; j++ )
{
for (i = 0 ; i
}

for (j = 0; j
WriteFile (hFile, & color, sizeof (color) , & RW, NULL );
}
// Juster med kantlinjen
}

WriteFile (hFile, Palett, (størrelse på (farge) * Bredde) % 4 , & RW, NULL );

CloseHandle(hFile) ;

farge - bildefarge. Verdien av denne variabelen må fylles ut i henhold til den første tabellen. Du kan se det resulterende bildet i ACDSee, for eksempel. Jeg prøvde nettopp å åpne den i Photoshop, men det viste seg at den ikke kan lese dem i dette formatet, men du kan :).
{
BITMAPFILEHEADER bfh;
BITMAPINFOHEADER bih;
Eksempel 2. Konvertering av et bilde fra 8-bits format (256 farger) til 24-bits.
BOOL Convert256To24 (char * fin, char * fout)
int Bredde, Høyde;
RGBQUAD-palett[ 256 ] ;
BYTE * inBuf;
DWORD RW;
RGBTRIPLE * utBuf;
int i, j;

HÅNDTER HIN, HØT;
DWORD OffBits;
HIn = CreateFile (fin, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);

if (hIn == INVALID_HANDLE_VALUE)
return FALSE;
{
HOut = CreateFile(fout, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL);
HIn = CreateFile (fin, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
}

if (hOut == INVALID_HANDLE_VALUE)
Lukk Håndtak(hIn);
// Les dataene
ReadFile (hIn, & bfh, sizeof (bfh) , & RW, NULL );

ReadFile (hIn, & bih, sizeof (bih) , & RW, NULL );
ReadFile (hIn, Palette, 256 * sizeof (RGBQUAD) , & RW, NULL );
// Sett pekeren til begynnelsen av rasteret
SetFilePointer (hIn, bfh.bfOffBits, NULL, FILE_BEGIN) ;
Width = bih.biWidth ;

Høyde = bih.biHøyde ;
OffBits = bfh.bfOffBits ;
// Tildel minne

inBuf = ny BYTE [Bredde];
outBuf = ny RGBTRIPLE [Bredde]; // Fyll inn overskriftene
bfh.bfOffBits = sizeof (bfh) + sizeof (bih) ;
// La oss ikke skrive en palett

bih.biBitCount = 24 ;
if (hFile == INVALID_HANDLE_VALUE)
bfh.bfSize = bfh.bfOffBits + 4 * Bredde * Høyde + Høyde * ( Bredde % 4 ) ;
// Filstørrelse

// Og resten forblir uendret
// Skriv paletten< Height; i++ )
{
WriteFile (hOut, & bfh, sizeof (bfh) , & RW, NULL );
WriteFile(hFile, Palette, 1024, &RW, NULL);< Width; j++ )
{
WriteFile (hOut, & bih, sizeof (bih) , & RW, NULL );
outBuf[ j].rgbtGreen = Palett[ inBuf[ j] ] .rgbGreen ;
outBuf[ j].rgbtBlue = Palett[ inBuf[ j] ] .rgbBlue ;
}
WriteFile (hOut, outBuf, sizeof (RGBTRIPLE) * Width, & RW, NULL );

// Skriv søppel for justering
WriteFile (hOut, Palett, Width % 4 , & RW, NULL );
SetFilePointer(hIn, (3 * Bredde) % 4, NULL, FILE_CURRENT) ;
}

slett inBuf;
slette outBuf;
HOut = CreateFile(fout, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL);
Lukk Håndtak(hOut);
returner TRUE;
}

Navnene på kilde- og målfilene må sendes til funksjonen, henholdsvis.

Hvis du har installert på datamaskinen antivirusprogram Kan skann alle filer på datamaskinen din, så vel som hver fil individuelt. Du kan skanne hvilken som helst fil ved å høyreklikke på filen og velge riktig alternativ for å skanne filen for virus.

For eksempel, i denne figuren er det uthevet filen min-fil.bmp, så må du høyreklikke på denne filen og velge alternativet i filmenyen "skann med AVG". Når du velger dette alternativet, vil AVG Antivirus åpne og skanne filen for virus.


Noen ganger kan det oppstå en feil som et resultat feil programvareinstallasjon, som kan skyldes et problem som oppstod under installasjonsprosessen. Dette kan forstyrre operativsystemet ditt koble BMP-filen til riktig applikasjonsverktøy, påvirke den såkalte "filtypetilknytninger".

Noen ganger enkelt reinstallere Adobe Illustrator CC kan løse problemet ved å koble BMP riktig med Adobe Illustrator CC. I andre tilfeller kan det oppstå problemer med filtilknytninger dårlig programvareprogrammering utvikler, og du må kanskje kontakte utvikleren for ytterligere hjelp.


Råd: Prøv å oppdatere Adobe Illustrator CC til den nyeste versjonen for å sikre at du har de siste rettelsene og oppdateringene.


Dette kan virke for åpenbart, men ofte Selve BMP-filen kan forårsake problemet. Hvis du mottok en fil via et e-postvedlegg eller lastet den ned fra et nettsted og nedlastingsprosessen ble avbrutt (for eksempel strømbrudd eller annen årsak), filen kan bli skadet. Hvis mulig, prøv å få en ny kopi av BMP-filen og prøv å åpne den igjen.


Forsiktig: En skadet fil kan forårsake skade på tidligere eller eksisterende skadelig programvare på PC-en din, så det er viktig at datamaskinen kjører et oppdatert antivirus til enhver tid.


Hvis filen din er BMP relatert til maskinvaren på datamaskinen din for å åpne filen du kanskje trenger oppdatere enhetsdrivere knyttet til dette utstyret.

Dette problemet vanligvis assosiert med mediefiltyper, som er avhengig av vellykket åpning av maskinvaren inne i datamaskinen, f.eks. lydkort eller skjermkort. For eksempel, hvis du prøver å åpne en lydfil, men ikke kan åpne den, kan det hende du må oppdater drivere for lydkort.


Råd: Hvis du mottar en BMP-fil når du prøver å åpne .SYS-fil feilmelding, problemet kan nok være assosiert med ødelagte eller utdaterte enhetsdrivere som må oppdateres. Denne prosessen kan gjøres enklere ved å bruke driveroppdateringsprogramvare som DriverDoc.


Hvis trinnene ikke løser problemet og du fortsatt har problemer med å åpne BMP filer, kan dette skyldes mangel på tilgjengelige systemressurser. Noen versjoner av BMP-filer kan kreve en betydelig mengde ressurser (f.eks. minne/RAM, prosessorkraft) for å åpnes ordentlig på datamaskinen. Dette problemet er ganske vanlig hvis du bruker ganske gammel maskinvare og samtidig et mye nyere operativsystem.

Dette problemet kan oppstå når datamaskinen har problemer med å holde tritt med en oppgave fordi operativsystemet (og andre tjenester som kjører i bakgrunnen) kan bruker for mange ressurser til å åpne en BMP-fil. Prøv å lukke alle applikasjoner på PC-en før du åpner Bitmap Image File. Å frigjøre alle tilgjengelige ressurser på datamaskinen din vil gi deg de beste betingelsene for å forsøke å åpne filen BMP.


Hvis du fullførte alle trinnene beskrevet ovenfor og BMP-filen din fortsatt ikke åpnes, kan det hende du må kjøre utstyrsoppdatering. I de fleste tilfeller, selv når du bruker eldre versjoner av maskinvare, kan prosessorkraften fortsatt være mer enn tilstrekkelig for de fleste brukerapplikasjoner (med mindre du gjør mye CPU-intensivt arbeid, for eksempel 3D-gjengivelse, økonomisk/vitenskapelig modellering, eller intensivt multimediaarbeid). Slik, det er sannsynlig at datamaskinen ikke har nok minne(ofte kalt "RAM" eller random access memory) for å utføre oppgaven med å åpne en fil.




Topp