[include(틀:그래픽 포맷)] [목차] == 개요 == '''비트맵 디지털 그림'''을 저장하는 데 쓰이는 그림 파일 포맷이다. == 상세 == 특히 마이크로소프트 [[Windows]], [[OS/2]] 운영 체제에서 널리 쓰인다. 줄여서 비트맵, 또 장치 독립 비트맵의 경우 DIB(Device-independent Bitmap), 장치 종속적인 경우는 DDB(Device-dependent Bitmap)라고 한다. 수많은 그래픽 사용자 인터페이스는 자체 내장 그래픽 하부 시스템에서 비트맵을 사용한다. 이를테면, 마이크로소프트 윈도와 OS/2 플랫폼의 GDI 하부 시스템은 .BMP, .DIB의 파일 [[확장자]] 이름을 가진다. 기본적으로 1~24비트의 색을 표현할 수 있으며, 알파 채널을 포함한 32비트 포맷이 [[GDI]]+가 도입된 [[Windows XP]]에서 발표되었다.[* [[한글과컴퓨터 한컴오피스]] 2007 이상 버전이 이 형식을 사용해서 프로그램 로고를 출력한다. 그 이전까지는 24비트 BMP 사용.] 일반적으로 데이터를 압축하지 않고 사용되지만, RLE 압축 방식도 지원한다. 간단하게 말하면 [[그림판]] 파일. 다른 그림 파일형식과 달리 '''파일압축을 전혀 하지 않아''' [[크고 아름다운]] 파일 크기를 자랑한다. [[인터넷 익스플로러]]를 제외한 [[웹 브라우저]]에서는 이미지로 인식하지 않는 경우가 많아서 뭣도 모르는 인터넷 초보자들이 이 형식으로 게시판에 그림을 올렸다가 낭패 보는 경우가 대부분[* 웹 브라우저는 원래 범용적으로 GIF, JPG, PNG 이외의 파일은 잘 지원하지 않는다. IE는 제작사가 마이크로소프트이기 때문에 지원하는 것.]. 이 때문에 인터넷 상에서는 거의 버려지다시피하는 형식이다. 하지만 사실상 압축을 하지 않는다는 특징때문에 [[RAW(파일)|RAW]] 방면에서는 어느정도 사용되고 있다. 한편 압축하지 않는 점이 오히려 속도에 도움이 되기도 하는데 압축을 푸는 데 걸리는 시간과 필요한 CPU의 성능이 더 추가되기 때문. 압축 푸는 과정이 없어서 파일 읽는 시간이 짧으면서 CPU 성능 점유율이 낮다는 장점 덕분에 간간히 2D게임에도 쓰이곤 한다. 주로 스프라이트라고 불리는 한 파일에 여러 모션이 들어있는 방식으로 쓰이는 편. 3D 그래픽의 [[텍스처]] 포맷으로 사용하기도 하지만, 이미 90년대 말부터 GPU에서 바로 사용이 가능한 텍스처 압축 전용 포맷(DXTC 등)들이 표준화되기 시작하였기 때문에 생각보다 사용 빈도는 낮았다. 물론 해당 텍스처 압축 포맷들은 [[손실 압축 포맷]]이라 도트류의 그림이나 UI와의 상성이 별로라 이쪽에서는 사용되기도 했지만. 참고로 BMP 형식은 그림을 가장 아래쪽부터 저장하는 특징이 있다. 그래서 일부 프로그램은 BMP 파일을 불러오면 상하가 반전된다. BMP 파일 1개의 크기가 4[[GiB]](4,294,967,296 바이트)를 넘게 저장할 수 없다. 후술할 파일 헤더에서 자체 파일 크기를 적을 수 있는 길이가 4바이트밖에 되지 않기 때문이다.[* 4바이트 모두 FF로 채우면 0xFFFFFFFF이 되는데, [[십진수]]로 나타내면 4,294,967,296가 된다.] == 헤더의 구조 == BMP 파일을 16진수 편집기를 통해 까보면 어떤 정체를 알 수 없는 숫자들이 맨 처음에 나열되어 있는데, 잘 보면 어떤 파일이든 처음 몇몇 숫자들의 구조는 같다는 공통점이 있다. 이를 [[헤더]]라고 한다. '''비트맵 파일 헤더 (BITMAPFILEHEADER)''' ||<:>시작 위치 ||<:>크기 ||<:>설 명 || || 0 || 2 || BMP 파일임을 식별할 때 사용되는 매직 넘버.[br] Hex 에디터로 확인 해 보면 'B' (0x42) 'M' (0x4D) 을 확인할 수 있다. || || 2 || 4 || 모든 헤더를 포함한 BMP 파일의 전체 크기. 리틀 엔디언으로 표기되어 있다. Hex 에디터에서 1E 27 00 00 로 나온다면 10,014Byte || || 6 || 2 ||<|2> 예약된 값. 실제 사용하지 않지만 응용 프로그램에 따라 다른 값이 저장될 수 있다. || || 8 || 2 || || 10 || 4 || 비트맵 데이터가 시작되는 위치 (Offset) || '''비트맵 정보 헤더 (BITMAPINFOHEADER)''' ||<:>시작 위치 ||<:>크기 ||<:>설 명 || || 14 || 4 || 이 헤더의 크기 (40Byte) || || 18 || 4 || 비트맵 가로 화소 (미터당 화소, 부호 있는 정수형) || || 22 || 4 || 비트맵 세로 화소 (미터당 화소, 부호 있는 정수형) || || 26 || 2 || 사용하는 색상 판의 수. 1 로 고정 || || 28 || 2 || 한 화소당 비트의 수. 4, 8 일 경우 색상 테이블이 있는지 확인해야 한다.[br] 16, 24, 32 일 경우 거의 모든 색상을 사용할 수 있기 때문에 일반적으로 색상 테이블이 사용되지 않는다 || || 30 || 4 || 압축 방식. 흔히 접할 수 있는 BMP 의 경우 0 이 대부분이다. || || 34 || 4 || 화소 데이터의 총 크기. 파일의 총 크기가 아니다! || || 38 || 4 || 이미지의 가로 해상도 (미터당 화소, 부호 있는 정수형) || || 42 || 4 || 이미지의 세로 해상도 (미터당 화소, 부호 있는 정수형) || || 46 || 4 || 사용한 색상 수 || || 50 || 4 || 중요한 색상 수. 일반적으로 0 || == 용량 계산법 == 비압축 포맷이기 때문에, --굳이 알 필요는 없지만-- 용량 계산이 꽤나 간단하다. 일단 계산 공식은 [math(whb \times 1024^{-n})] * w(width): 이미지의 가로 픽셀 수. * h(height): 이미지의 세로 픽셀 수. * b(bits): 픽셀 하나를 표현하는데 사용한 비트 수. RGB는 24비트, ARGB는 32비트이다. R8-G8-B8로 나누어 사용하는데, 255가 이진법으로 11111111이기 때문. * 8로 나누는 이유는 1바이트 = 8비트이기 때문이다. w * h * b까지 하면 이미지를 표현하는 데 사용된 '''총 비트 수'''가 구해지는데, 이를 바이트로 환산하려면 8로 나눠야 한다. * 킬로, 메가 등의 접두어를 붙이려면 2의 10배수 제곱으로 나누면 된다. 2의 10제곱으로 나누면 킬로바이트, 2의 20제곱으로 나누면 메가바이트로 환산되는 식. 예를 들어보자. 640x480 크기의 24비트 비트맵 이미지가 있다. 이 이미지의 용량은 '''640px * 480px * 24bits / 8 = 92만 1600 바이트 = 900 kB'''로 계산할 수 있다. 또한, 계산 공식에서 알 수 있듯이 용량은 사용 비트 수(쉽게 말해서 색 품질)에 비례하므로 16비트 이미지는 같은 사이즈의 24비트 이미지의 3분의 2, 256색 이미지는 3분의 1의 용량을 차지한다. 다만 실제로 비트맵 파일을 만들어서 비교해 보면 약간의 오차가 있다. 이는 실제 비트맵 파일에는 헤더 등 다른 정보도 추가되기 때문이다. 특히 8비트 인덱스 컬러 포맷이라면 데이터 영역 앞에 색상 테이블이 추가되기 때문에 용량 차이가 더 날 수 있다. == 비트 할당법 == 8비트까지는 그래픽 툴에서 특정 색을 직접 지정하거나 운영 체제에서 정한 "팔레트[* Palette. 물감 짜놓고 쓰는 그 팔레트의 개념 맞다.]"를 사용하는데, 이를 인덱스 컬러(Indexed Color)라고 한다. 그러다가 16비트 이상의 이미지부터 비트를 적당히 3등분(?)하여 사용하게 된다. * '''16비트:''' R5 G5 B5 X1 or R5 G6 B5 * '''24비트:''' R8 G8 B8 * '''32비트:''' A8 R8 G8 B8 (A는 알파) [* BMP에서 32비트는 잘 사용하지 않는 규격이다.] [[분류:파일 형식]]