이 기사는 bmp 그래픽 형식이 어떻게 보이는지에 관한 것입니다. 이는 가장 간단한 형식 중 하나이지만 이 형식에는 다양한 변형이 있기 때문에 모든 사항이 명확하지는 않습니다. 그러니 물 붓는 것을 멈추고 시작합시다.
형식 구조
bmp 형식(BitMaP - 비트맵 또는 러시아어로 비트 배열이라는 단어에서 유래)은 Windows OS에서 읽고 표시하기 매우 쉬운 압축되지 않은(주로) 이미지로, 도움이 되는 특수 API 기능이 있습니다.
먼저 데이터를 bmp 형식으로 그래픽으로 표현해 보겠습니다(MSDN에서 가져온 사진).
처음에는 파일 헤더(BITMAPFILEHEADER)가 있습니다. 다음과 같이 설명됩니다.
bf유형파일 형식을 결정합니다. 여기서 그는 BM이어야 합니다. 텍스트 편집기(또는 16진수 편집기)에서 BMP 파일을 열면 처음 두 문자가 BM(아마도 짐작하셨겠지만 BitMap이라는 단어에서 유래)임을 알 수 있습니다.
bf크기파일 자체의 크기(바이트)입니다. 엄밀히 말하면 계산해야 하는데(권장) 파일 크기를 잘못 설정했는데(고의는 아니었지만 :)) 문제도 없었고(ACDSee는 문제 없이 읽었고, 내 프로그램은 작동했습니다), 추천하지 않습니다. 의도적으로 잘못 작성하면 갑자기 이 크기를 실제 크기와 비교하여 bmp가 아닌 다른 크기로 결정하는 성실한 프로그램이 나타납니다. 이상적으로 모든 프로그램은 가짜가 아닌 실제 bmp인지 확인하기 위해 먼저 bfType에 "BM"(따옴표 제외)이 포함되어 있는지 확인하고 두 번째로 bfSize가 파일 크기와 같은지 확인해야 합니다.
bfReserved1 및 bfReserved2예약되어 있으며 0이어야 합니다.
bfOffBits. 이는 이 구조에서 가장 중요한 필드 중 하나입니다. 그림을 설명하는 파일의 시작 부분(또는 MSDN에서 말하는 "BITMAPFILEHEADER 구조의 시작 부분")을 기준으로 비트맵 자체가 시작되는 위치를 보여줍니다. 즉, 배열의 시작 부분에 도달하려면 다음과 같이 작성해야 합니다.
typedef 구조체 태그BITMAPINFOHEADER
{
DWORD biSize;
LONG 이중 너비;
LONG 이중 높이;
WORD 복엽면;
WORD biBitCount;
DWORD 이중압축;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClr사용됨;
DWORD biClr중요;
) BITMAPINFOHEADER, * PBITMAPINFOHEADER;
바이사이즈구조 자체의 크기입니다. 다음과 같이 초기화해야 합니다. bih.biSize = sizeof(BITMAPINFOHEADER);
여기서 다시 bih가 다음과 같이 선언되었다고 가정합니다. BITMAPINFOHEADER bih;
이중 너비 및 이중 높이이미지의 너비와 높이를 각각 픽셀 단위로 설정합니다.
복엽 비행기평면 수를 지정합니다. 지금은 항상 1로 설정되어 있습니다.
비트카운트- 픽셀당 비트 수입니다. 이에 대해서는 아래에서 더 자세히 이야기하겠습니다.
이중압축압축 유형을 나타냅니다. bmp가 갑자기 압축된다는 사실에 놀라거나 두려워하지 마세요. 저는 개인적으로 압축된 bmp를 본 적이 없습니다(그러나 그것이 존재하지 않는다고 말하는 것은 아닙니다). 압축이 없으면 이 플래그를 BI_RGB로 설정해야 합니다. 이 기사에서는 압축되지 않은 형식에 대해 이야기하므로 다른 플래그는 나열하지 않겠습니다. Windows 98부터 BI_JPEG 옵션이 나타났기 때문에 JPEG와 PNG 파일에도 동일한 구조가 사용되는 것 같습니다. 이 사진은 JPEG와 BI_PNG, PNG라는 것을 보여줍니다(Jpeg 형식에 대해서는 전혀 모릅니다. 저는 MSDN에 작성된 내용을 토대로 이러한 결론을 내렸습니다.
바이사이즈이미지이미지의 크기를 바이트 단위로 나타냅니다. 이미지가 압축되지 않은 경우(즉, 이전 필드가 BI_RGB로 설정됨) 여기에 0을 써야 합니다. biXPelsPerMeter그리고 biYPelsPerMeter비트맵(래스터)이 출력될 최종 장치의 수평 및 수직 해상도(미터당 픽셀 수)를 각각 나타냅니다. 애플리케이션은 이 값을 사용하여 리소스 그룹에서 원하는 장치에 가장 적합한 비트맵을 선택할 수 있습니다. 사실 bmp 형식은 본질적으로 하드웨어 독립적인 래스터입니다. 즉, 얻은 것의 모양이 이 래스터가 투영되는 대상에 의존하지 않는 경우입니다. 예를 들어, 그림은 모니터 화면에 그려지든 프린터로 인쇄하든 상관없이 동일하게 보입니다. 그러나 장치의 해상도는 다르며 이러한 매개 변수가 사용되는 것은 사용 가능한 사진 중에서 가장 적합한 사진을 선택하는 것입니다.
biClr사용됨테이블에서 사용되는 색상 수를 결정합니다. 이 값이 0이면 래스터는 biBitCount 값에서 허용하는 최대 색상 수를 사용합니다. 이는 압축된 이미지에만 해당됩니다. biClrUsed가 0이 아니고 biBitCount가 16보다 작은 경우 biClrUsed는 사용 가능한 그래픽 엔진 또는 장치 드라이버 색상의 현재 수를 결정합니다. biBitCount가 16보다 크거나 같으면 biClrUsed는 현재 시스템 팔레트를 최적화하는 데 사용되는 색상표의 크기를 결정합니다.
biClr중요- 중요한 색상의 개수입니다. 그림을 묘사하는 데 필요한 색상 수를 결정합니다. 이 값이 0(보통 그렇듯이)이면 모든 색상이 중요한 것으로 간주됩니다.
BMP 형식의 유형
모든 유형의 bmp 형식 조건부로팔레트와 비팔레트의 두 가지 유형으로 나눌 수 있습니다. 즉, 팔레트가 특정 형식으로 사용되는지 여부입니다. 팔레트는 팔레트 프리 형식일 수도 있지만 여기서는 사용되지 않습니다. 팔레트리스 bmps에서는 특정 위치부터 시작하여 파일에 포함된 비트에서 색상이 직접 계산됩니다. 그리고 팔레트에서 각 바이트는 하나 이상의 픽셀을 나타내며 바이트(또는 비트) 값은 팔레트의 색상 인덱스입니다. 우선 가능한 옵션을 비교하는 표를 제공하겠습니다. 그림 유형(팔레트 또는 팔레트 프리)은 픽셀당 제공되는 비트 수, 즉 BITMAPINFOHEADER 구조의 biBitCount 값에 따라 달라집니다.
| 비트카운트 | 팔레트 또는 비팔레트 형식 | 가능한 최대 색상 수 | 노트 | 1 | 팔레트 | 2 | 반드시 흑백일 필요는 없지만 두 가지 색상의 팔레트 사진입니다. 래스터 비트(바로 아래)가 재설정되면(0과 동일) 이는 팔레트의 첫 번째 색상이 이 위치에 있어야 하고, 설정된 경우(1과 동일) 두 번째 색상이 이 위치에 있어야 함을 의미합니다. | 4 | 팔레트 | 16 | 각 바이트는 2픽셀을 나타냅니다. 다음은 MSDN의 예입니다. 이미지의 첫 번째 바이트가 0x1F이면 이는 두 개의 픽셀에 해당하고 첫 번째 색상은 팔레트의 두 번째 색상(카운트다운이 0부터 시작하기 때문입니다)이고 두 번째 픽셀은 다음과 같습니다. 팔레트의 16번째 컬러. | 8 | 팔레트 | 256 | 가장 일반적인 옵션 중 하나입니다. 그러나 동시에 가장 간단한 것입니다. 팔레트는 1KB를 차지합니다(하지만 계산하지 않는 것이 좋습니다). 1바이트는 하나의 색상입니다. 또한 그 값은 팔레트의 색상 번호입니다. | 16 | 팔레트 없음 | 2^16 또는 2^15 | 이것은 가장 혼란스러운 옵션입니다. 팔레트가 없다는 사실부터 시작하겠습니다. 즉, 래스터의 모든 2바이트(1개의 WORD 단어)가 하나의 픽셀을 고유하게 정의합니다. 하지만 무슨 일이 일어나는지는 이렇습니다. 16비트가 있고 3가지 색상 구성 요소(빨간색, 녹색, 파란색)가 있습니다. 하지만 16은 3으로 나누어지기를 원하지 않습니다. 따라서 여기에는 두 가지 옵션이 있습니다. 첫 번째는 16비트가 아닌 15비트를 사용하는 것입니다. 그런 다음 각 색상 구성 요소에 대해 5비트가 있습니다. 이 방법으로 우리는 최대 2^15 = 32768 색상을 사용할 수 있고 삼중 R-G-B = 5-5-5를 얻을 수 있습니다. 그러나 16개 중 전체 비트가 헛되이 낭비됩니다. 그러나 우리의 눈은 모든 색상 중에서 녹색을 더 잘 인식하므로 이 비트 중 하나를 녹색 구성 요소에 할당하기로 결정했습니다. 삼중 R-G-B = 5-6-5이므로 이제 2^16 = 65536 색상을 사용할 수 있습니다. 그러나 가장 불쾌한 점은 두 옵션을 모두 사용한다는 것입니다. MSDN에서는 사용되는 색상 수를 구별하기 위해 BITMAPINFOHEADER 구조의 biClrUsed 필드를 이 값으로 채울 것을 제안합니다. 각 구성 요소를 선택하려면 다음 마스크를 사용해야 합니다. 5-5-5 형식의 경우: 파란색 구성요소의 경우 0x001F, 녹색 구성요소의 경우 0x03E0, 빨간색의 경우 0x7C00입니다. 5-6-5 형식의 경우: 각각 0x001F - 파란색, 0x07E0 - 녹색 및 0xF800 빨간색 구성 요소입니다. | 24 | 팔레트 없음 | 2^24 | 그리고 이것은 가장 간단한 형식입니다. 여기서 3바이트는 3가지 색상 구성요소를 정의합니다. 즉, 바이트당 하나의 구성 요소입니다. 간단히 RGBTRIPLE 구조를 읽고 rgbtBlue, rgbtGreen, rgbtRed 필드를 사용합니다. 그 순서대로 갑니다. | 32 | 팔레트 없음 | 2^32 | 여기서 4바이트는 3개의 구성 요소를 정의합니다. 단, 1바이트는 사용되지 않습니다. 예를 들어 알파 채널(투명도)에 사용할 수 있습니다. 이 경우 다음과 같이 설명되는 RGBQUAD 구조를 사용하여 래스터를 읽는 것이 편리합니다. |
BMP 형식의 데이터 저장
자, 이제 가장 흥미로운 부분에 이르렀습니다. BITMAPFILEHEADER 및 BITMAPINFOHEADER 구조 다음에는 팔레트가 옵니다. 또한 형식에 팔레트가 없으면 존재하지 않을 수도 있지만 이에 의존해서는 안됩니다. 사실 제가 bmp 형식을 막 이해하기 시작했을 때 한 책에서 해당 형식에 팔레트가 없으면 팔레트가 전혀 없다는 내용을 읽었습니다. 심지어 두 장의 그림도 있었습니다 - 형식 다이어그램: 하나는 팔레트가 있고 다른 하나는 팔레트가 없습니다. 그리고 그 당시 나는 bmp 파일을 가지고 부지런히 동작하는 프로그램을 작성하고 있었습니다. 그리고 들어오는 이미지를 256색에서 24비트(있는 경우)로 임시 파일로 변환해야 했습니다. 그리고 저는 24비트 팔레트를 만들지 않았습니다(BITMAPFILEHEADER 구조의 bfOffBits는 sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER)의 합과 같았고 들어오는 24비트 팔레트는 변경되지 않은 채로 두었습니다. 256색 래스터를 사용하면 모든 것이 가능합니다. 필요한 부분 대신 아래쪽에 쓰레기가 표시되는 24비트 이미지를 발견하기 전까지는 원본 파일의 크기를 비교할 때까지 무엇이 잘못되었는지 즉시 이해하지 못했습니다. 팔레트가 없었다면 거기에 있었어야 하는 이론적 차이는 정확히 1KB였습니다. 따라서 팔레트가 있는지 여부에 의존하지 말고 그 크기에 의존하지 마십시오. (내가 본 모든 사진의 팔레트 크기는 256색 또는 1Kb였지만) 항상 bfOffBits를 사용하여 파일을 통해 래스터의 시작 부분으로 이동합니다. 팔레트는 RGBQUAD 구조의 배열입니다. 모든 색상이 팔레트에 사용되는 것은 아니지만(예: 16개만) 팔레트 A 256 * 4 = 1024에 256개의 필드가 할당되는 경우가 많습니다. 4는 RGBQUAD 구조의 크기, 즉 동일한 1KB입니다. 획득된다.
팔레트 바로 뒤에는 래스터 자체가 옵니다. 여기서 상황이 더욱 혼란스러워집니다. 먼저, 여기서는 형식에 따라 위의 표에 표시된 대로 픽셀을 설명합니다. 또한 색상 구성 요소의 값(팔레트가 없는 경우)을 포함하거나 팔레트 배열의 인덱스가 될 수도 있습니다. 그림 자체는 한 줄씩 기록됩니다. 둘째, 그림이 거꾸로 보입니다. 즉, 맨 아래 줄이 먼저 기록되고 그 다음 두 번째 줄이 맨 위까지 기록됩니다. 그리고 세 번째로, 위에 적힌 대로 래스터 선의 크기가 4의 배수가 아닌 경우에는 선의 길이가 문단의 배수가 되도록 1~3개의 빈(0) 바이트로 채워집니다. 이것이 가장 불쾌한 일입니다. 사실은 각 형식에 대해 이 빈 바이트 수를 조정해야 한다는 것입니다. (비록 팔레트의 일부를 거기에 쓰고 싶지만 어쨌든 이 바이트를 건너뛰고 아무도 없는 경우 추가 "0" 변수를 만들고 싶지 않습니다. 필요합니다). 어떤 형식에 대해 줄 끝에 몇 바이트를 추가해야 하는지 보여주는 공식이 포함된 표를 제공합니다. 여기서 Width 변수는 짐작할 수 있듯이 이미지의 너비를 의미합니다. 이 모든 공식은 실험적으로 확립되었습니다. 가장 많이 사용되는 형식에 대해서만 예를 들어 보겠습니다. 나머지는 직접 작성하셔도 됩니다.
예제 프로그램
모든 소스를 다운로드할 수 있습니다. 여기서는 많이 쓰지 않겠습니다. 그냥 주석으로 기능을 설명하겠습니다.
안녕하세요 1. bmp 형식의 사진을 생성합니다.
여기서 단색 그림이 생성됩니다. 이러한 기능에는 bmp 8, 16 및 24비트 생성이라는 세 가지 예가 있습니다. 16비트용으로만 드리겠습니다.
// 5-5-5와 같은 bmp 형식 16비트의 그림을 만들어 보겠습니다. 이는 단순히 단색입니다.
void CreateBmp555(char * fname, WORD 색상)
{
h파일을 처리합니다.
DWORD RW;
int i, j;
// 필요한 구조를 선언합니다.
비트맵 파일 헤더 bfh;
BITMAPINFOHEADER bih;
바이트 팔레트[1024]; // 팔레트
// 35 x 50 픽셀의 이미지를 만들어 보겠습니다.
정수 너비 = 35 ;
int 높이 = 50 ;
memset(팔레트, 0, 1024); // 팔레트에는 0이 있습니다. 채우세요.
memset (&bfh, 0 , sizeof (bfh) ) ;
Bfh.bfType = 0x4D42 ; // 이것이 bmp "BM"임을 나타내자
bfh.bfOffBits = sizeof(bfh) + sizeof(bih) + 1024; // 팔레트는 1Kb를 차지하지만 사용하지 않을 것입니다.
bfh.bfSize = bfh.bfOffBits +
sizeof(색상) * 너비 * 높이 +
높이 * ((sizeof (색상) * 너비) % 4 ) ; // 최종 파일의 크기를 계산합니다.
memset (&bih, 0 , sizeof (bih) ) ;
bih.biSize = sizeof(bih); //그렇게 돼야지
bih.biBitCount = 16 ; // 픽셀당 16비트
bih.biClrUsed = 32768 ; // 우리는 5-5-5를 사용합니다
bih.biCompression = BI_RGB; // 압축하지 않고
bih.biHeight = 높이;
bih.biWidth = 너비;
bih.biPlanes = 1 ; // 1이어야 함
// 나머지 필드는 0으로 유지됩니다.
HFile = CreateFile(fname, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL);
if (hFile == INVALID_HANDLE_VALUE)
반품 ;
// 헤더 쓰기
WriteFile(hFile, & bfh, sizeof (bfh) , & RW, NULL ) ;
WriteFile(hFile, & bih, sizeof (bih) , & RW, NULL ) ;
// 팔레트 작성
WriteFile(hFile, 팔레트, 1024, &RW, NULL);
(i = 0; 나는<
Height;
i++
)
{
(j = 0 ; j<
Width;
j++
)
{
WriteFile (hFile, & color, sizeof (color) , & RW, NULL ) ;
}
// 테두리에 맞춰 정렬
WriteFile(hFile, Palette, (sizeof (color) * Width) % 4 , & RW, NULL ) ;
}
닫기핸들(hFile) ;
}
색상 - 그림 색상. 이 변수의 값은 첫 번째 표에 따라 채워져야 합니다. 예를 들어 ACDSee에서 결과 그림을 볼 수 있습니다. 방금 Photoshop에서 열려고 했는데 이 형식에서는 읽을 수 없는 것으로 나타났습니다. :).
예 2. 그림을 8비트(256색)에서 24비트로 변환합니다.
BOOL Convert256To24(char * fin, char * fout)
{
비트맵 파일 헤더 bfh;
BITMAPINFOHEADER bih;
int 너비, 높이;
RGBQUAD 팔레트[ 256 ] ;
바이트 * inBuf;
RGBTRIPLE * outBuf;
hIn, hOut을 처리합니다.
DWORD RW;
DWORD OffBits;
int i, j;
HIn = CreateFile(fin, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
if (hIn == INVALID_HANDLE_VALUE)
거짓을 반환합니다;
HOut = CreateFile(fout, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL);
if (hOut == INVALID_HANDLE_VALUE)
{
닫기핸들(hIn);
거짓을 반환합니다;
}
// 데이터 읽기
파일 읽기(hIn, & bfh, sizeof (bfh) , & RW, NULL ) ;
파일 읽기(hIn, & bih, sizeof (bih) , & RW, NULL ) ;
ReadFile(hIn, Palette, 256 * sizeof (RGBQUAD) , & RW, NULL ) ;
// 포인터를 래스터의 시작 부분으로 설정합니다.
SetFilePointer(hIn, bfh.bfOffBits, NULL, FILE_BEGIN) ;
너비 = bih.biWidth ;
높이 = bih.biHeight ;
OffBits = bfh.bfOffBits ;
// 메모리 할당
inBuf = 새로운 BYTE [너비];
outBuf = 새로운 RGBTRIPLE [너비];
// 헤더 채우기
bfh.bfOffBits = sizeof(bfh) + sizeof(bih); // 팔레트를 쓰지 말자
bih.biBitCount = 24 ;
bfh.bfSize = bfh.bfOffBits + 4 * 너비 * 높이 + 높이 * (너비 % 4 ); // 파일 크기
// 나머지는 변경되지 않습니다.
// 헤더 쓰기
WriteFile (hOut, & bfh, sizeof (bfh) , & RW, NULL ) ;
WriteFile (hOut, & bih, sizeof (bih) , & RW, NULL ) ;
// 변환을 시작해보자
(i = 0; 나는<
Height;
i++
)
{
ReadFile(hIn, inBuf, 너비, & RW, NULL);
(j = 0 ; j<
Width;
j++
)
{
outBuf[ j].rgbtRed = 팔레트[ inBuf[ j] ] .rgbRed ;
outBuf[ j].rgbtGreen = 팔레트[ inBuf[ j] ] .rgbGreen ;
outBuf[ j].rgbtBlue = 팔레트[ inBuf[ j] ] .rgbBlue ;
}
WriteFile (hOut, outBuf, sizeof (RGBTRIPLE) * 너비, & RW, NULL ) ;
// 정렬을 위한 쓰레기 쓰기
WriteFile(hOut, 팔레트, 너비 % 4 , & RW, NULL ) ;
SetFilePointer(hIn, (3 * 너비) % 4, NULL, FILE_CURRENT) ;
}
inBuf 삭제;
outBuf 삭제;
닫기핸들(hIn);
CloseHandle(hOut);
TRUE를 반환합니다.
}
소스 파일과 대상 파일의 이름이 각각 함수에 전달되어야 합니다.
BMP 파일을 열 때 발생하는 문제의 가장 일반적인 원인은 단순히 컴퓨터에 적절한 응용 프로그램이 설치되어 있지 않기 때문입니다. 이 경우 BMP 형식의 파일을 제공하는 응용 프로그램을 찾아서 다운로드하고 설치하는 것으로 충분합니다. 이러한 프로그램은 아래에서 사용할 수 있습니다.
검색 시스템
파일 확장자를 입력하세요
돕다
단서
우리 컴퓨터가 읽지 못하는 파일의 일부 인코딩된 데이터는 때때로 메모장에서 볼 수 있다는 점에 유의하십시오. 이런 방식으로 텍스트나 숫자 조각을 읽습니다. 이 방법이 BMP 파일의 경우에도 작동하는지 확인할 가치가 있습니다.
목록에 있는 애플리케이션이 이미 설치되어 있으면 어떻게 해야 합니까?
설치된 응용프로그램이 BMP 파일에 자동으로 연결되어야 하는 경우가 많습니다. 이런 일이 발생하지 않으면 BMP 파일을 새로 설치된 응용 프로그램과 수동으로 연결할 수 있습니다. BMP 파일을 마우스 오른쪽 버튼으로 클릭한 다음 사용 가능한 목록에서 "기본 프로그램 선택" 옵션을 선택하세요. 그런 다음 "보기" 옵션을 선택하고 즐겨 사용하는 응용 프로그램을 찾아야 합니다. 입력된 변경 사항은 "확인" 옵션을 사용하여 승인되어야 합니다.
BMP 파일을 여는 프로그램
윈도우
맥 OS
왜 BMP 파일을 열 수 없나요?
BMP 파일 문제에는 다른 원인이 있을 수도 있습니다. 때로는 BMP 파일을 지원하는 소프트웨어를 컴퓨터에 설치해도 문제가 해결되지 않는 경우가 있습니다. BMP 파일을 열고 작업할 수 없는 이유는 다음과 같습니다.
레지스트리 항목의 부적절한 BMP 파일 연결
- 우리가 연 BMP 파일의 손상
- BMP 파일 감염(바이러스)
- 컴퓨터 리소스가 너무 부족함
- 오래된 드라이버
- Windows 레지스트리에서 BMP 확장 제거
- BMP 확장을 지원하는 프로그램의 불완전한 설치
이러한 문제를 해결하면 BMP 파일을 자유롭게 열고 작업할 수 있습니다. 컴퓨터에 여전히 파일 문제가 있는 경우 정확한 원인을 파악하는 전문가의 도움을 받아야 합니다.
내 컴퓨터에 파일 확장자가 표시되지 않습니다. 어떻게 해야 합니까?
표준 Windows 시스템 설정에서 컴퓨터 사용자는 BMP 파일 확장자를 볼 수 없습니다. 이는 설정에서 성공적으로 변경할 수 있습니다. "제어판"으로 이동하여 "보기 및 개인 설정"을 선택하세요. 그런 다음 "폴더 옵션"으로 이동하여 "보기"를 열어야 합니다. "보기" 탭에는 "알려진 파일 형식의 확장자 숨기기" 옵션이 있습니다. 이 옵션을 선택하고 "확인" 버튼을 클릭하여 작업을 확인해야 합니다. 이 시점에서 BMP를 포함한 모든 파일의 확장자는 파일 이름별로 정렬되어 나타나야 합니다.
발표
BMP 래스터 이미지 파일 형식
BMP(비트맵 파일, 장치 독립적 비트맵 파일 형식)는 디스플레이 장치와 별도로 디지털 비트맵 이미지를 저장하는 데 사용되는 비트맵 파일입니다. 이 파일 형식은 이전에 Microsoft Windows 및 OS/2에서 사용되었습니다. "래스터"라는 용어는 프로그래머의 비트맵 아이디어에서 유래되었습니다. BMP 이미지는 일반적으로 압축되지 않거나 무손실 압축됩니다(예: 파일에 중복 데이터가 있기 때문에 ZIP 또는 RAR 사용). 오늘날 JPG는 선호되는 이미지 형식입니다. 주로 BMP의 파일 크기가 크기 때문에 파일을 다운로드, 전송 또는 업로드할 때 문제나 지연이 발생할 수 있기 때문입니다.
BMP 파일에 대한 기술 정보
BMP 파일은 데이터 압축, 색상 프로필 또는 알파 채널 없이 다양한 크기, 색상 및 색상 심도의 2D 이미지로 저장됩니다. BMP 이미지는 장치 독립적인 비트맵(DIB) 형식으로 저장됩니다. 즉, 이미지에는 시스템 사양이 아닌 색상이 있습니다. 이는 일부 BMP 이미지가 컴퓨터에 따라 다르게 보이는 이유를 설명합니다. BMP 이미지는 컴퓨터와 TV 화면을 포함한 모든 장치에서 볼 수 있습니다. 특허가 부족하여 이 이미지 유형이 다양한 장치에서 널리 사용되는 형식이 되었습니다.
BMP 형식에 대한 추가 정보
| 파일 확장자 | .bmp |
| 파일 카테고리 | |
| 예시 파일 | (2.7MiB) (487.85KiB) |
| 관련 프로그램 | 어도비 포토샵 MS 페인트 마이크로소프트 사진 편집기 화필 |
