BMP 파일 포맷

**BMP 파일 포맷**은 비트맵 디지털 그림을 저장하는 데 쓰이는 그림 파일 서식이다.특히, 마이크로소프트 윈도우, OS/2 운영 체제에 널리 쓰인다. 줄여서 **비트맵**, 또 장치 독립 비트맵의 경우 **DIB 파일 서식**이라고 한다. 래스터 그래픽스 이미지 파일 형식으로, 특히 마이크로소프트 윈도우 및 OS/2 운영 체제에서 디스플레이 장치(예: 그래픽스 어댑터)와 독립적으로 비트맵 디지털 이미지를 저장하는 데 사용된다.

BMP 파일 포맷은 다양한 색 깊이로 2차원 디지털 이미지를 저장할 수 있으며, 선택적으로 데이터 압축, 알파 채널 및 색 프로파일을 포함할 수 있다. 윈도우 메타파일 (WMF) 사양은 BMP 파일 포맷을 포함한다.

## 장치 독립적 비트맵과 BMP 파일 포맷

마이크로소프트는 다양한 내부 표현을 가진 장치와 애플리케이션 간에 비트맵을 교환하는 데 도움을 주기 위해 다양한 색 깊이의 컬러 비트맵에 대한 특정 표현을 정의했다. 이를 장치 독립적 비트맵(DIB)이라고 불렀고, 이들의 파일 형식은 DIB 파일 형식 또는 BMP 이미지 파일 형식이라고 불린다.

마이크로소프트 지원에 따르면: 장치 독립적 비트맵(DIB)은 다양한 색 해상도로 장치 독립적 비트맵을 정의하는 데 사용되는 형식이다. DIB의 주요 목적은 비트맵을 한 장치에서 다른 장치로 이동할 수 있도록 하는 것이다(따라서 이름의 장치 독립적 부분). DIB는 시스템에 비트맵 객체(애플리케이션에 의해 생성됨...)로 나타나는 장치 종속적 비트맵과 대조적으로 외부 형식이다. DIB는 일반적으로 메타파일(주로 StretchDIBits() 함수 사용), BMP 파일, 그리고 클립보드( 데이터 형식)로 전송된다.

다음 섹션에서는 BMP 파일 또는 DIB에 저장된 데이터에 대해 자세히 설명한다. 이것이 표준 BMP 파일 형식이다. 일부 애플리케이션은 마이크로소프트 문서와 호환되지 않는 비트맵 이미지 파일을 생성한다. 또한 모든 필드가 사용되는 것은 아니다; 사용되지 않는 필드에는 0 값이 발견될 것이다.

## 파일 구조
비트맵 이미지 파일은 고정 크기 구조(헤더)와 미리 정해진 순서로 나타나는 가변 크기 구조로 구성된다. 이 파일 형식의 오랜 진화로 인해 이러한 구조 중 여러 가지 버전이 파일에 나타날 수 있다.

다이어그램 1을 참조하면, 비트맵 파일은 다음 순서로 구조로 구성된다:

### 메모리의 DIB
메모리에 로드된 비트맵 이미지 파일은 DIB 데이터 구조가 된다. 이는 윈도우 GDI API의 중요한 구성 요소이다. 메모리 내 DIB 데이터 구조는 BMP 파일 형식과 거의 동일하지만, 14바이트 비트맵 파일 헤더를 포함하지 않으며 DIB 헤더로 시작한다. 메모리에 로드된 DIB의 경우, 색상표는 명시적인 RGB 색상 정의 대신 현재 실현된 팔레트에 대한 인덱스를 구성하는 16비트 항목으로 구성될 수도 있다(추가 간접 수준). 모든 경우에 픽셀 배열은 4바이트의 배수인 메모리 주소에서 시작해야 한다. 메모리에 로드된 비압축 DIB의 경우, 선택적 색상 프로필 데이터는 색상표 바로 뒤, 그리고 간격1과 픽셀 배열 앞에 위치해야 한다 (다이어그램 1과는 다르게).

간격1과 간격2의 크기가 0일 때, 메모리 내 DIB 데이터 구조는 관습적으로 "압축 DIB"라고 불리며 DIB 헤더의 시작을 가리키는 단일 포인터로 참조될 수 있다. 모든 경우에 픽셀 배열은 4바이트의 배수인 메모리 주소에서 시작해야 한다. 경우에 따라 픽셀 배열의 메모리 주소를 4바이트의 배수로 강제하기 위해 색상표의 항목 수를 조정해야 할 수도 있다. 메모리에 로드된 "압축 DIB"의 경우, 선택적 색상 프로필 데이터는 다이어그램 1에 묘사된 대로(gap1=0 및 gap2=0) 픽셀 배열 바로 뒤에 와야 한다. "압축 DIB"는 윈도우 클립보드 API 함수뿐만 아니라 일부 윈도우 패턴 브러시 및 리소스 함수에도 필요하다.

### 비트맵 파일 헤더
이 바이트 블록은 파일 시작 부분에 있으며 파일을 식별하는 데 사용된다. 일반적인 애플리케이션은 파일이 실제로 BMP 파일이고 손상되지 않았는지 확인하기 위해 이 블록을 먼저 읽는다. BMP 파일 형식의 처음 2바이트는 ASCII 인코딩에서 문자 "B" 다음에 문자 "M"이다. 모든 정수 값은 리틀 엔디언 형식(즉, 최하위 바이트 우선)으로 저장된다.

#### DIB 헤더 (비트맵 정보 헤더)
이 바이트 블록은 이미지에 대한 자세한 정보를 애플리케이션에 알려주며, 이는 이미지를 화면에 표시하는 데 사용될 것이다. 이 블록은 윈도우와 OS/2에서 내부적으로 사용되는 헤더와도 일치하며 여러 가지 다른 변형이 있다. 이들 모두는 크기를 지정하는 dword (32비트) 필드를 포함하므로 애플리케이션이 이미지에서 어떤 헤더가 사용되는지 쉽게 결정할 수 있다. 다른 헤더가 존재하는 이유는 마이크로소프트가 DIB 형식을 여러 번 확장했기 때문이다. 새로운 확장 헤더는 이전 헤더 대신 일부 GDI 함수와 함께 사용될 수 있으며, 더 많은 기능을 제공한다. GDI가 비트맵 파일을 로드하는 기능을 지원하기 때문에, 일반적인 윈도우 애플리케이션은 그 기능을 사용한다. 이로 인한 한 가지 결과는 그러한 애플리케이션의 경우, 지원하는 BMP 형식이 실행 중인 윈도우 버전에서 지원하는 형식과 일치한다는 것이다. 자세한 내용은 아래 표를 참조하라.

윈도우 2.x BITMAPCOREHEADER는 OS/2 1.x BITMAPCOREHEADER(위 표에 표시됨)와 이미지 너비 및 높이 필드가 부호 없는 정수가 아니라 부호 있는 정수라는 한 가지 세부 사항에서 다르다.

 이후 버전은 이전 버전의 헤더 끝에 필드를 추가하기만 한다.
예를 들어: 는 에 필드를 추가하고, 는 에 필드를 추가한다.

통합 알파 채널은 미등록 와 문서화된 (윈도우 95 이후)에서 도입되었으며, 윈도우 XP 로그인 및 테마 시스템과 마이크로소프트 오피스(2000 버전 이후)에서 사용된다. 어도비 포토샵 7 버전 이후 및 어도비 플래시 MX 2004 버전 이후(당시에는 매크로미디어 플래시로 알려짐)와 같은 일부 이미지 편집 소프트웨어에서 지원된다. 또한 김프, 구글 크롬, 마이크로소프트 파워포인트 및 마이크로소프트 워드에서도 지원된다.

호환성 때문에 대부분의 애플리케이션은 파일을 저장할 때 이전 DIB 헤더를 사용한다. **윈도우 2000 이후 OS/2가 더 이상 지원되지 않으므로, 현재 일반적인 윈도우 형식은  헤더이다.** 다음 표에서 그 설명을 참조하라. 모든 값은 명시적으로 언급되지 않는 한 부호 없는 정수로 저장된다.

압축 방식 (오프셋 30)은 다음 중 하나일 수 있다:

OS/2 2.x (IBM 문서에서는 )는 24바이트가 추가된다:

하프토닝 알고리즘 (오프셋 60)은 다음 중 하나일 수 있다:

### 색상표
색상표(팔레트)는 BMP 파일 헤더, DIB 헤더, 그리고  헤더에 BI_BITFIELDS (12바이트) 또는 BI_ALPHABITFIELDS (16바이트) 옵션이 사용된 경우 선택적 세 개 또는 네 개의 비트마스크 뒤에 바로 BMP 이미지 파일에 나타난다. 따라서 그 오프셋은 의 크기와 DIB 헤더의 크기(선택적 세 개 또는 네 개의 비트 마스크에 대한 12-16바이트 추가)를 합한 값이다.
참고: 윈도우 CE에서는  헤더가 biCompression 멤버에서 BI_ALPHABITFIELDS 옵션과 함께 사용될 수 있다.

팔레트의 항목 수는 2n (여기서 n은 픽셀당 비트 수)이거나 헤더에 지정된 더 작은 숫자이다 (OS/2  헤더 형식에서는 전체 크기 팔레트만 지원된다). 대부분의 경우, 색상표의 각 항목은 파랑, 녹색, 빨강, 0x00 순서로 4바이트를 차지한다 (예외는 아래 참조). 이는 의 biBitCount 구조 멤버에서 인덱싱된다.

색상표는 이미지에서 사용되는 색상을 나열하는 바이트 블록(테이블)이다. 인덱스 색상 이미지의 각 픽셀은 이 테이블에 의해 설명되는 단일 색상의 인덱스인 비트 수(1, 4 또는 8)로 설명된다. 인덱스 색상 비트맵에서 색상 팔레트의 목적은 각 인덱스 값이 어떤 실제 색상에 해당하는지 애플리케이션에 알리는 것이다. 비인덱스(비팔레트화) 비트맵에서 색상표의 목적은 제한된 색상 표시 기능을 가진 장치에서 최적화를 위해 비트맵이 사용하는 색상을 나열하고, 나중에 다른 픽셀 형식으로 변환 및 팔레트화를 용이하게 하는 것이다.

색상표의 색상은 일반적으로 항목당 4바이트 ARGB32 형식으로 지정된다. OS/2 와 함께 사용되는 색상표는 항목당 3바이트 RGB24 형식을 사용한다. 메모리에 로드된 DIB의 경우, 색상표는 선택적으로 2바이트 항목으로 구성될 수 있다. 이 항목은 명시적인 RGB 색상 정의 대신 현재 실현된 팔레트에 대한 인덱스를 구성한다.

마이크로소프트는 1bpp, 4bpp, 8bpp 인덱스 색상 이미지에 대해  및 에 유효한 알파 채널 비트 마스크의 존재를 금지하지 않는데, 이는 색상표 항목이 RGBQUAD.rgbReserved 멤버를 통해 [8.8.8.[0-8].0-8] 형식을 사용하여 알파 구성 요소를 지정할 수도 있음을 나타낸다. 그러나 마이크로소프트 문서의 일부 버전은 RGBQUAD.rgbReserved 멤버가 "0이어야 한다"고 명시하여 이 기능을 허용하지 않는다.

위에서 언급했듯이, 픽셀이 픽셀당 16비트(16bpp) 형식(및 그 이상)일 때는 색상표가 일반적으로 사용되지 않는다. 이러한 비트맵 이미지 파일에는 일반적으로 색상표 항목이 없다. 그러나 마이크로소프트 문서(2010년 11월 16일 현재 MSDN 웹사이트)는 16bpp(및 그 이상)의 경우, 제한된 색상 표시 기능을 가진 장치에서 최적화를 위해 색상 목록을 저장하기 위해 색상표가 존재할 수 있다고 명시하고 있으며, 그러한 경우 이 색상표에는 인덱스 팔레트 항목이 없다고도 명시한다. 이는 필수 팔레트 항목과 선택적 색상 목록을 구분하지 않으면 모순처럼 보일 수 있다.

### 픽셀 저장
비트맵 픽셀을 나타내는 비트는 행(스트라이드 또는 스캔 라인이라고도 함)에 압축되어 있다. 각 행의 크기는 패딩을 통해 4바이트(32비트 DWORD)의 배수로 반올림된다.

높이가 1보다 큰 이미지의 경우, 여러 개의 패딩된 행이 연속적으로 저장되어 픽셀 배열을 형성한다.

한 줄의 픽셀을 저장하는 데 필요한 총 바이트 수는 다음과 같이 계산할 수 있다:
\text{RowSize} = \left\lceil\frac { \text{BitsPerPixel} \cdot \text{ImageWidth}}{32}\right\rceil \cdot 4 = \left\lfloor\frac { \text{BitsPerPixel} \cdot \text{ImageWidth}+31}{32}\right\rfloor \cdot 4,

2<sup><var>n</var></sup> 색상을 가진 n비트/픽셀(bpp) 이미지에서 픽셀 배열을 저장하는 데 필요한 총 바이트 수는 각 행의 크기를 4바이트의 배수로 반올림하는 효과를 고려하여 다음과 같이 계산할 수 있다.

\text{PixelArraySize} = \text{RowSize} \cdot |\text{ImageHeight}|

#### 픽셀 배열 (비트맵 데이터)
픽셀 배열은 픽셀별로 이미지를 설명하는 32비트 DWORD 블록이다. 일반적으로 픽셀은 왼쪽 하단 모서리에서 시작하여 왼쪽에서 오른쪽으로, 그리고 이미지의 하단에서 상단으로 행별로 "상향식"으로 저장된다. 가 사용되지 않는 한, 압축되지 않은 윈도우 비트맵은 이미지 높이 값이 음수인 경우 상단에서 하단으로 저장될 수도 있다.

원본 OS/2 DIB에서, 허용되는 색상 깊이 값은 1, 4, 8, 24비트/픽셀(bpp)이었다.
현대 DIB 헤더는 픽셀당 1, 2, 4, 8, 16, 24, 32비트(bpp)의 픽셀 형식을 허용한다. GDI+는 픽셀당 64비트도 허용한다.

행의 길이를 4바이트의 배수로 맞추기 위해 패딩 바이트(반드시 0은 아님)를 행 끝에 추가해야 한다. 픽셀 배열이 메모리에 로드될 때, 각 행은 4의 배수인 메모리 주소에서 시작해야 한다. 이 주소/오프셋 제한은 메모리에 로드된 픽셀 배열에만 필수적이다. 파일 저장 목적의 경우, 각 행의 크기만 4바이트의 배수여야 하며 파일 오프셋은 임의적일 수 있다. 너비가 1인 24비트 비트맵은 행당 3바이트의 데이터(파랑, 녹색, 빨강)와 1바이트의 패딩을 가지며, 너비가 2인 경우는 6바이트의 데이터와 2바이트의 패딩, 너비가 3인 경우는 9바이트의 데이터와 3바이트의 패딩, 너비가 4인 경우는 12바이트의 데이터와 패딩이 없다.

#### 압축
* 인덱스 색상 이미지는 4비트 또는 8비트 RLE 또는 허프먼 1D 알고리즘으로 압축될 수 있다.
* OS/2 2 24bpp 이미지는 24비트 RLE 알고리즘으로 압축될 수 있다.
* 16bpp 및 32bpp 이미지는 **항상 압축되지 않은 상태로 저장된다.**
* 모든 색상 깊이의 이미지는 원하는 경우 압축 없이 저장할 수 있다.

#### 픽셀 형식

* 픽셀당 1비트(1bpp) 형식은 2가지 고유한 색상(예: 흑백)을 지원한다. 픽셀 값은 각 비트에 저장되며, 첫 번째(가장 왼쪽) 픽셀은 첫 번째 바이트의 최상위 비트에 있다. 각 비트는 2가지 색상 테이블에 대한 인덱스이다. 설정되지 않은 비트는 첫 번째 색상 테이블 항목을 참조하고, 설정된 비트는 마지막(두 번째) 색상 테이블 항목을 참조한다.
* 픽셀당 2비트(2bpp) 형식은 4가지 고유한 색상을 지원하며 1바이트당 4픽셀을 저장하며, 가장 왼쪽 픽셀은 두 개의 최상위 비트에 있다(윈도우 CE만 해당:). 각 픽셀 값은 최대 4가지 색상 테이블에 대한 2비트 인덱스이다.
* 픽셀당 4비트(4bpp) 형식은 16가지 고유한 색상을 지원하며 1바이트당 2픽셀을 저장하며, 가장 왼쪽 픽셀은 더 중요한 니블에 있다. 각 픽셀 값은 최대 16가지 색상 테이블에 대한 4비트 인덱스이다.
* 픽셀당 8비트(8bpp) 형식은 256가지 고유한 색상을 지원하며 1바이트당 1픽셀을 저장한다. 각 바이트는 최대 256가지 색상 테이블에 대한 인덱스이다.
* 픽셀당 16비트(16bpp) 형식은 65536가지 고유한 색상을 지원하며 2바이트 워드당 1픽셀을 저장한다. 각 워드는 픽셀의 알파, 빨강, 녹색, 파랑 샘플을 정의할 수 있다.
* 픽셀당 24비트(24bpp) 형식은 16,777,216가지 고유한 색상을 지원하며 3바이트당 1픽셀 값을 저장한다. 각 픽셀 값은 픽셀의 빨강, 녹색, 파랑 샘플(RGBAX 표기법에서 8.8.8.0.0)을 정의한다. 구체적으로는 파랑, 녹색, 빨강 순서(각 샘플당 8비트)이다.
* 픽셀당 32비트(32bpp) 형식은 4,294,967,296가지 고유한 색상을 지원하며 4바이트 DWORD당 1픽셀을 저장한다. 각 DWORD는 픽셀의 알파, 빨강, 녹색, 파랑 샘플을 정의할 수 있다.

어떤 비트가 어떤 샘플을 정의하는지에 대한 모호성을 해결하기 위해, DIB 헤더는 특정 비트필드를 제공하며, 이는 픽셀 내 특정 비트 그룹이 특정 채널에 속하는 것을 정의하는 비트 마스크이다. 다음 다이어그램은 이 메커니즘을 정의한다:

비트필드 비트 마스크에 의해 정의된 샘플 필드는 연속적이고 중복되지 않아야 하지만, 샘플 필드의 순서는 임의적이다. 가장 보편적인 필드 순서는 알파, 파랑, 녹색, 빨강(MSB에서 LSB)이다. 빨강, 녹색, 파랑 비트 마스크는 DIB 헤더의 압축 멤버가 BI_BITFIELDS로 설정된 경우에만 유효하다. 알파 비트 마스크는 DIB 헤더에 존재하거나 DIB 헤더의 압축 멤버가 BI_ALPHABITFIELDS로 설정된 경우 유효하다(윈도우 CE만 해당).

### RGB 비디오 서브타입
위에서 설명된 BITFIELD 메커니즘은 수만 가지의 다양한 픽셀 형식을 정의할 수 있지만, 실제로는 몇 가지 형식만 사용된다. 모든 팔레트 형식 RGB8, RGB4, RGB1 (위 표에서 노란색으로 표시됨, `dshow.h`.MEDIASUBTYPE 이름으로 정의됨):

버전 2.1.4 FFmpeg은 (자체 용어로) BMP 픽셀 형식 bgra, bgr24, rgb565le, rgb555le, rgb444le, rgb8, bgr8, rgb4_byte, bgr4_byte, gray, pal8, monob를 지원했다. 즉, bgra는 투명도가 지원되는 유일한 픽셀 형식이었다.

[섬네일|upright=0.6|[#예제 1|예제 1 2×2 픽셀 비트맵, 픽셀당 24비트 인코딩]]

### 예제 1

다음은 픽셀 형식 RGB24인 2×2 픽셀, 24비트 비트맵(윈도우 DIB 헤더 )의 예시이다.


파일:Bmp_format2.svg|frame|right|예제 2 4×2 픽셀 비트맵, 픽셀당 32비트 인코딩
rect  50  50 100 100 0,0: blue 0000FF FF
rect 100  50 150 100 0,1: green 00FF00 FF
rect 150  50 200 100 0,2: red FF00000 FF
rect 200  50 250 100 0,3: white FFFFFF FF
rect  50 100 100 150 1,0: blue 0000FF 7F, half transparent
rect 100 100 150 150 1,1: green 00FF00 7F, half transparent
rect 150 100 200 150 1,2: red FF0000 7F, half transparent
rect 200 100 250 150 1,3: white FFFFFF 7F, half transparent
default Netpbm#투명도
desc top-left


### 예제 2
다음은 알파 채널에 불투명도 값이 있는 4×2 픽셀, 32비트 비트맵(윈도우 DIB 헤더 )의 예시이며, 픽셀 형식은 ARGB32이다.

비트맵 데이터가 이미지의 왼쪽 하단 모서리에서 시작한다는 점에 유의하라.

## BMP 형식의 사용
BMP 파일 형식의 단순성, 윈도우 및 기타 환경에서의 광범위한 친숙도, 그리고 이 형식이 비교적 잘 문서화되어 있고 오픈 포맷이라는 사실은 BMP를 많은 운영 체제의 이미지 처리 프로그램이 읽고 쓸 수 있는 매우 일반적인 형식으로 만든다. ICO 및 CUR 파일은 BITMAPINFOHEADER로 시작하는 비트맵을 포함한다.

많은 구형 그래픽 사용자 인터페이스는 내장 그래픽 하위 시스템에서 비트맵을 사용했다. 예를 들어, 마이크로소프트 윈도우 및 OS/2 플랫폼의 GDI 하위 시스템에서 사용되는 특정 형식은 윈도우 및 OS/2 비트맵 파일 형식이며, 일반적으로 파일 확장자 `.BMP`로 이름이 지정된다.

대부분의 BMP 파일은 압축이 없거나(또는 팔레트화된 이미지에 대한 일반적으로 낮은 비율의 런 렝스 부호화) 파일 크기가 비교적 크지만, 많은 BMP 파일은 중복 데이터를 포함하기 때문에 ZIP과 같은 비손실 데이터 압축 알고리즘으로 상당히 압축될 수 있다. RAR과 같은 일부 형식은 이러한 데이터의 효율적인 압축을 위해 특별히 고안된 루틴을 포함하기도 한다.

## 관련 형식

X 윈도 시스템은 흑백 이미지에 유사한 XBM 형식을 사용하고, 색상 이미지에는 XPM(픽셀맵)을 사용한다. 또한 다른 정보 없이 원시 데이터를 저장하는 다양한 "원시" 형식도 있다. 포터블 픽스맵(PPM) 및 트루비전 TGA 형식도 존재하지만, 덜 자주 사용되거나 특정 목적(예: TGA는 투명도 정보를 포함할 수 있음)으로만 사용된다.

## 각주

## 외부 링크
* BMP - 텀즈

분류:그래픽 파일 포맷
분류:마이크로소프트 윈도우 멀티미디어 기술