3.1 그래픽스/영상 데이터 형 3.2 널리 사용되는 파일 형태 제3장 그래픽스와 영상 데이터 표현 3.1 그래픽스/영상 데이터 형 3.2 널리 사용되는 파일 형태 2009-2학기 멀티미디어시스템

표 3.1: 매크로미디어 디렉터(macromedia Director) 파일 형태 3.1 그래픽스/영상 데이터 형 멀티미디어에서 사용되는 다수의 파일 형태들은 지속적으로 증가해 오고 있다. 예로써 표 3.1은 널리 사용되는 제품인 Macromedia Director에서 쓰이는 파일 형태의 항목을 보여준다. 표 3.1: 매크로미디어 디렉터(macromedia Director) 파일 형태 2009-2학기 멀티미디어시스템

1비트 영상 각 화소는 단일 비트(0혹은 1)로 저장이되므로 이진 영상(binary image)이라고도 한다. 이러한 영상은 컬러를 포함하고 있지 않으므로 1비트 단색(monochrome) 영상이라고도 한다. 그림 3.1에서는 1비트 단색 영상을 보여주고 있다(멀티미디어 학자들은 이 영상을 “Lena”라고 부른다-이 영상은 알고리즘을 증명하는 데 많이 이용되는 표준 영상이다). 2009-2학기 멀티미디어시스템

그림 3.1: 단색 1비트 Lena 영상 2009-2학기 멀티미디어시스템

3.1.2 8비트 회색 등급 영상 각 화소가 0에서 255 사이의 회색 값(gray value)을 가지고 있다. 각 화소는 하나의 바이트에 의해 표현이 된다; 예를 들면, 어두운 화소는 10의 값을 가질 수 있을 것이고, 밝은 화소는 230의 값을 가질 수 있을 것이다. 비트맵(bitmap): 그래픽스/영상 데이터를 표시하는 화소 값의 이차원 배열 영상의 해상도(image resolution)는 디지털 영상에서 화소의 개수를 나타낸다(높은 해상도는 항상 더 나은 화질을 가져온다). 분명히 어떠한 영상에서 높은 해상도는 1,600×1,200이 될 수 있을 것이고 반면 낮은 해상도는 640×480이 될 수 있을 것이다. 2009-2학기 멀티미디어시스템

프레임 버퍼(frame buffer): 비트맵 저장을 위해 이용되는 하드웨어 비디오 카드(실제로는 그래픽 카드)는 이러한 목적에 쓰인다. 비디오 카드의 해상도는 영상에서 원하는 해상도와 일치할 필요는 없지만 이용 가능한 비디오 카드 메모리가 충분하지 않으면 데이터는 디스플레이를 위해서 RAM으로 옮겨져야 한다. 8비트 영상은 1비트 비트플레인(bitplane)의 집합으로 생각할 수 있다. 여기서 각 플레인은 “고도(elevation)”의 높이 단계에서의 영상의 1비트 표현으로 구성된다. 만약 영상의 화소가 어느 비트 단계에서 0이 아닌 값을 가지면 그 단계에서 비트는 켜진다. 그림 3.2는 비트플레인의 개념을 도식적으로 보여준다. 2009-2학기 멀티미디어시스템

그림 3.2: 8비트 회색도 영상의 비트플레인 2009-2학기 멀티미디어시스템

멀티미디어의 표현 각 화소는 보통 한 바이트(0에서 255사이의 값)로 저장된다. 따라서 640×480의 회색도 영상은 300킬로바이트의 저장 공간을 필요로 한다(640×480=307,200). 그림 3.3에서 Lena 영상이 다시 나오지만, 이번에는 회색도 영상이다. 만일 임의의 한 영상을 프린팅(print)하고자 한다면, 명암 해상도(intensity resolution)를 공간 해상도(spatial resolution)로 바꾸는 디더링(dithering)의 기본 전략이 이용된다. 2009-2학기 멀티미디어시스템

그림 3.3: 회색도 Lena 영상 2009-2학기 멀티미디어시스템

디더링 1비트 프린터에서 프린팅 함에 있어 디더링은 더 큰 점 패턴을 계산하는데 쓰인다. 이러한 어둡거나 밝은 화소 값을 정확하게 표현하는 만족할만한 패턴은 0에서 255까지의 값과 상응한다. 주된 전략은 한 화소 값을 더 큰, 이를테면 2×2나 4×4 크기의 패턴으로 대치하는 것이다. 이러한 프린팅되는 점의 개수는 중간조 프린팅(halftone printing)에서 사용하는 가변 크기의 잉크 디스크와 비슷하다(예: 신문 인쇄). 작거나 큰 검은 잉크 점을 이용해 음영을 표시하는 중간조 프린팅은 아날로그 처리이다. 예를 들어 다음과 같은 2×2 디더링 행렬을 사용한다면, 2009-2학기 멀티미디어시스템

명암값이 디더링 행렬의 원소값 보다 크면 그 원소 위치에 점을 찍는다. 즉, 각 화소를 n×n 행렬의 점으로 대치한다. 먼저 0..255의 영상값을 256/5의 (정수) 나눗셈에 의해 새로운 0..4 범위로 재배치 할 수 있다. 그리고 나서, 예를 들어, 화소 값이 0이라면 2×2 영역 안에 아무것도 찍지 않는 출력을 낸다. 하지만 화소 값이 4라면 네 점을 모두 프린팅한다. 법칙: 명암값이 디더링 행렬의 원소값 보다 크면 그 원소 위치에 점을 찍는다. 즉, 각 화소를 n×n 행렬의 점으로 대치한다. 디더링된 영상에 대하여 영상의 크기는 훨씬 크다는 것에 유의하라. 이를테면, 각 화소를 4×4 점 배열에 의해 대치되므로 16배만큼 큰 영상이 만들어진다. 2009-2학기 멀티미디어시스템

슬기로운 기교로 이러한 문제를 극복할 수 있다. 다음과 같은 4×4 디더링 행렬을 쓰고자 한다고 가정하자. 순서 디더링은 명암 단계가 화소 위치에서 특정 행렬 원소 값보다 크면 프린터 출력 비트가 찍히게끔 구성되어 있다. 그림 3.4(a)는 Lena 회색도 영상을 보여주고 있다. 순서 디더링 변환 영상은 그림 3.4(b)에서, Lena 오른쪽 눈의 세부 묘사는 그림 3.4(c)에서 보여주고 있다. 2009-2학기 멀티미디어시스템

n×n 디더링 행렬에 대한 순서 디더링 알고리즘은 다음과 같다: 2009-2학기 멀티미디어시스템

(a): 8비트 회색 영상 “lenagray.bmp”. (b): 디더링 변환 영상. (c): 디더링 변환 영상의 세부 표사. 그림 3.4: 디더링 회색도 영상. (a): 8비트 회색 영상 “lenagray.bmp”. (b): 디더링 변환 영상. (c): 디더링 변환 영상의 세부 표사. 2009-2학기 멀티미디어시스템

3.1.3 영상 데이터 형 가장 보편적인 그래픽스와 영상 파일 형태에 대한 데이터 형- 24비트 컬러와 8비트 컬러. 다음으로 파일 형태에 대해 논의한다. 많은 형태가 클로스 플랫폼(cross-platform)인 반면 몇 가지 형태는 특정 하드웨어/운영체제 플랫폼으로 제한된다. 몇 가지 형태가 클로스 플랫폼이 아니더라도 변환 어플리케이션으로 한 시스템에서 다른 시스템으로 인식과 해석이 가능하다. 대부분의 영상 형태는 큰 영상 파일의 저장 공간 크기를 줄이기 위한 압축(compression) 기법의 편차를 통합한다. 압축 기법은 무손실(lossless)과 손실(lossy)로 분류할 수 있다. 2009-2학기 멀티미디어시스템

24 비트 컬러 영상 24비트 컬러 영상에서 각 화소는 보통 RGB를 표시하는 세 바이트로 표현된다. 이 형태는 256×256×256, 혹은 총 16,777,216개의 색 조합을 지원한다. 하지만 이러한 유연성은 저장에 불이익을 유발한다: 640×480의 24비트 컬러 영상은 압축을 하지 않을 경우 921.6 킬로바이트의 저장 공간을 필요로 한다. 중요한 점: 많은 24비트 컬러 영상이 각 픽셀마다 특수 효과 정보(예: 투명도)를 나타내는 α(alpha) 값을 저장하기 위한 여분의 바이트를 포함하여 실제로는 32비트의 영상으로 저장된다는 것이다. 그림 3.5는 Microsoft Windows BMP 형태의 24비트 영상인 forestfire.bmp 영상을 보여준다. 그리고 이 영상의 red, green, blue 채널에서의 회색계 영상도 보여주고 있다. 2009-2학기 멀티미디어시스템

그림 3. 5: 높은 해상도의 컬러 영상과 분리된 R, G, B 컬러 채널 영상 그림 3.5: 높은 해상도의 컬러 영상과 분리된 R, G, B 컬러 채널 영상. (a): 24비트의 컬러 영상 “forestfire.bmp”의 예. (b, c, d): 이 영상의 R, G, B 컬러 채널. 2009-2학기 멀티미디어시스템

8 비트 컬러 영상 많은 시스템은 화면 영상을 만들에 내는 데 8비트의 컬러 정보(소위 “256컬러”)만을 사용하도록 만들 수 있다. 이러한 영상 파일들은 컬러 정보를 저장하기 위해 참조표(lookup table)의 개념을 사용한다. 기본적으로 각 영상은 직접적으로 컬러의 값을 저장하지 않고, 특정 컬러를 색인할 수 있는 참조표 내의 인덱스를 3바이트 값으로 가지게 된다. 그림 3.6에서는 forestfire.bmp 영상의 3차원 히스토그램을 보여주고 있다. 2009-2학기 멀티미디어시스템

그림 3.6: “forestfire.bmp”의 3차원 RGB 컬러 히스토그램. 2009-2학기 멀티미디어시스템

그림 3.7에서는 결과 영상을 GIF 형태의 8비트 영상으로 나타내었다. 24비트 영상을 8비트 영상으로 표현할 시 상당한 저장 공간의 절약에 주목하라: 640×480 8비트 영상이 300 킬로바이트를 필요로 하는 반면, 24비트 컬러영상은 921.6 킬로바이트의 저장공간을 필요로 한다(어떠한 압축기능도 없는 경우). 그림 3.7: 8비트 칼라 영상의 예. 2009-2학기 멀티미디어시스템

컬러 참조표 8비트 컬러 영상에서 사용된 개념은 각 화소에 대해 단지 인덱스나 코드값만을 저장하는 것이다. 즉, 값 25를 저장한 하나의 화소는 단지 컬러 참조표(Color lookup table, LUT)에서 25번째 열을 가리킨다. 그림 3.8: 8비트 컬러 영상에 대한 컬러 LUT. 2009-2학기 멀티미디어시스템

컬러 피커(color picker)는 상당히 큰 블록으로(혹은 반 연속적인 색의 범위로) 구성되어 있어서 마우스의 클릭으로 그 색이 가리키는 것을 선택한다. 현실적으로 컬러 피커는 팔레트의 칼라를 보여주는데 이는 0에서 255의 값의 지표와 관계가 있다. 그림 3.9는 컬러 피커의 개념을 보여주고 있다. 만약 사용자가 2의 값을 가지는 컬러 블록을 선택한다면 그 색은 청록색을 의미 하고 이는 RGB값으로 (0, 255, 255)를 가지게 된다. 아주 간단한 그림의 처리는 간단하게 색의 표를 변화시키는 것으로 가능하다: 이것을 컬러 사이클링(color cycling) 혹은 팔레트 애니메이션(palette animation)라고 한다. 2009-2학기 멀티미디어시스템

그림 3.9: 8비트 칼라에 대한 칼라 피커: 각 칼라 피커의 각 블록은 칼라 LUT의 한 행에 대응된다. 2009-2학기 멀티미디어시스템

그림 3. 10(a)는 24비트의 칼라의 Lena 영상을 보여주고 있으며 그림 3 그림 3.10(a)는 24비트의 칼라의 Lena 영상을 보여주고 있으며 그림 3.10(b)는 같은 영상을 5비트로 줄여 디더링한 결과를 보여주고 있다. 그림 3.10(c)는 왼쪽 눈 부분을 확대해서 보여주고 있다. 그림 3.10: (a): 24비트 칼라 영상 “lena.bmp”. (b): 칼라 디더링 버전. (c): 디더링 버전을 확대한 그림. 2009-2학기 멀티미디어시스템

컬러 참조표를 만드는 방법 24비트 칼라를 8비트 칼라 색인으로 만드는 가장 올바른 방법은 각각의 차원에서 동일한 얇은 조각으로 RGB 큐브를 나누는 것이다. 각각의 나온 결과에서 중앙이 칼라 LUT의 중심으로 되고, RGB의 0..255 범위에서 적당한 범위로의 단순한 크기 조정이 8비트 코드를 만들어 내게 된다. 인간은 B보다 R이나 G에 더 민감하기 때문에 총 8비트를 만들기 위해 R과 G의 범위를 0..255에서 3비트인 0..7의 범위로 줄일 수 있고 B는 2비트인 0..3의 범위로 줄일 수 있다. R과 G를 축소시키기 위해 간단히 R과 G의 바이트 값을 (256/8=)32에 의해서 나눌 수 있고 나머지는 잘라 버린다. 그 후 영상에서 각 화소는 그것의 8비트 색인에 의해 교체되고 칼라 LUT는 24비트 칼라를 생성하는데 일조하게 된다. 2009-2학기 멀티미디어시스템

이러한 형태의 과정은 밀집된 근접색의 군집 사이에서의 구분이 절실히 필요한 비트에 집중될 수 있다. 중간값 잘라내기 알고리즘(median-cut algorithm): 이러한 칼라 범위 줄임 문제에서 더 나은 작업을 하는 간단한 대응 해결책 이 개념은 R 바이트 값을 정렬하고, 그것들의 중간값을 찾는 것이다; 그리고 중간값보다 더 작은 값은 “0” 비트로 레이블링하고 중간값보다 더 큰 값은 “1” 비트로 레이블링한다. 이러한 형태의 과정은 밀집된 근접색의 군집 사이에서의 구분이 절실히 필요한 비트에 집중될 수 있다. 0..255의 위치에서 총계를 보여주는 히스토그램을 사용함으로 인해서 중간값을 찾는 것이 쉽게 가시화될 수 있다. 그림 3.11은 forestfire.bmp 영상의 R바이트에 대한 히스토그램을 수직선으로 그려진 중간값과 동시에 보여주고 있다. 2009-2학기 멀티미디어시스템

그림 3. 11: 24비트 칼라 영상 “forestfire 그림 3.11: 24비트 칼라 영상 “forestfire.bmp”에 대한 R바이트의 히스토그램은 모든 화소에 대해 “0” 혹은 “1”비트 레이블로 된다. 제작된 칼라 테이블 인덱스의 두 번째 비트에 대해 R의 중간값보다 적은 R 값을 취하고 G 값의 중간값보다 적거나 큰 G 값에 따라 0이나 1로 화소를 레이블링한다. 8비트에 대한 R, G, B에 대해 계속하면 칼라 LUT 8비트 인덱스가 만들어진다. 2009-2학기 멀티미디어시스템

3.2 널리 사용되는 파일 형태 8비트 GIF: 네트워크 브라우저에 의해 처음으로 승인된 영상 형태로서 WWW와 HTML 생성 언어와의 역사적 연관 때문에 가장 중요한 파일 형태 중의 하나. JPEG: 현재 가장 중요하고 보편적인 파일 형태. 2009-2학기 멀티미디어시스템

GIF GIF 표준: (이것은 매우 단순하면서도 공통 요소들이 많기 때문에 조사해 본다.) 오직 8비트(256) 칼라 영상만으로 제한되며, 이것이 받아들일 수 있는 칼라를 내는 한 거의 구별되지 않는 칼라의 영상에 적합하다(예를 들면 그래픽스나 그림). GIF 표준은 인터레이싱(interlacing)-4패스 디스플레이 과정에 의해 넓게 띄워진 행에서의 화소를 연속적으로 디스플레이하는 것-을 지원한다. GIF는 실제적으로 두 가지 종류가 있다. GIF87a: 원조 사양. GIF89a: 이후 버전. 데이터내부의 Graphics Control Extension 블록을 통해서 간단한 애니메이션(animation)을 지원하고, 지연 시간(delay time), 투명도 색인(transparency index) 등의 간단한 제어를 제공한다. 2009-2학기 멀티미디어시스템

GIF87 표준 사양에 있어서 GIF87 파일의 일반적인 파일 형태는 그림 3.12에서 보는 바와 같다. 2009-2학기 멀티미디어시스템

화면 서술자는 파일 안에 모든 영상이 속해있는 속성의 집합으로 구성되어있다. GIF87 표준에 따라 그림 3 2009-2학기 멀티미디어시스템

컬러 맵(color map)은 그림 3. 14처럼 간단한 형태로 구성되어 있다 컬러 맵(color map)은 그림 3.14처럼 간단한 형태로 구성되어 있다. 그런데 실제 표의 길이는 화면 서술자에서 주어진 것처럼 2(pixel+1) 이다. 그림 3.14: GIF 컬러 맵. 2009-2학기 멀티미디어시스템

파일 내의 각 영상은 그림 3.15에 정의된 것처럼 각각의 영상 서술자를 가진다. 그림 3.15: GIF 영상 서술자. 2009-2학기 멀티미디어시스템

그림 3.16: GIF 4 패스 인터레이스 디스플레이의 행 순서. 만약 “인터레이스(interlace)” 비트가 국부적인 영상 서술자 내에 구성된다면, 영상의 열들은 4 패스 순서로 표현된다(그림 3.16). 그림 3.16: GIF 4 패스 인터레이스 디스플레이의 행 순서. 2009-2학기 멀티미디어시스템

다음과 같이 처음 32바이트의 번역된 문자들을 볼 수 있다: 특정한 GIF 영상을 봄으로써 실제적으로 파일 헤더가 어떻게 작동을 하는지 조사할 수 있다. 그림 3.7은 8비트 칼라 GIF 영상이고, UNIX에서 다음과 같이 명령어를 치면: 다음과 같이 처음 32바이트의 번역된 문자들을 볼 수 있다: 파일 헤더의 나머지 부분을 해독하기 위해서 16진수를 이용하면: 결과는 다음과 같다. od -c forestfire.gif | head -2 G I F 8 7 a ＼208 ＼2 ＼188 ＼1 ＼247 ＼0 ＼0 ＼6 ＼3 ＼5 J ＼132 ＼24 | ) ＼7 ＼198 ＼195 ＼ ＼128 U ＼27 ＼196 ＼166 & T od -x forestfire.gif | head -2 4749 4638 3761 d002 bc01 f700 0006 0305 ae84 187c 2907 c6c3 5c80 551b c4a6 2654 2009-2학기 멀티미디어시스템

JPEG JPEG: 영상 압축에 있어서 현재 가장 중요한 표준. 예제로서 그림 3.17은 화질 계수 Q=10%인 forestfire 영상을 보여주고 있다. 이 영상은 원래 크기의 1.5%에 불과하다. 비교해 보면, Q=75%인 JPEG 영상은 원래 크기의 5.6%의 영상 크기를 산출하는 반면 이 영상의 GIF 버전은 압축하지 않은 영상 크기의 23.0% 정도로 압축한다. 2009-2학기 멀티미디어시스템

그림 3.17: 사용자에 의해 설정된 낮은 품질의 JPEG 영상. 2009-2학기 멀티미디어시스템

PNG PNG: Portable Network Graphics의 약어 PNG 파일의 특별한 특징은 다음을 포함한다:  GIF 표준을 대신하는 것을 의미하고, 탁월한 방법으로 그것을 확장한다 PNG 파일의 특별한 특징은 다음을 포함한다: 48비트까지의 칼라 정보를 지원한다-이것은 매우 큰 증진이다. 칼라 영상의 정확한 디스플레이를 위해 감마 보정 정보를 포함하고 있으며, 투명도 조절을 위한 알파 채널 정보도 가지고 있다. 각 8×8 영상 블록을 통한 일곱 개의 경로를 통해 한번에 몇 개의 화소를 보여줌으로써 2차원 방식으로 화소들을 디스플레이 한다. 2009-2학기 멀티미디어시스템

TIFF TIFF: Tagged Image File Format의 약어 추가적 정보의 부착(“태그” 라고 언급되는)을 위한 지원은 엄청난 융통성을 제공한다: 가장 중요한 태그는 형태를 알리는 것이다: 압축의 형 등이 저장된 영상에서 일반적으로 사용되고 있다. TIFF는 많은 다른 형태의 영상을 저장할 수 있다: 1비트, 회색 등급, 8비트, 24비트 RGB 등 TIFF는 근본적으로 무손실 형태지만, 새로운 JPEG 태그는 JPEG 압축을 선택할 수 있게 한다. TIFF 형태는 1980년대 Aldus 회사에 의해 발전되었으며, 나중에 마이크로소프트사에 의해 지원되었다. 2009-2학기 멀티미디어시스템

EXIF EXIF(Exchange Image File)는 디지털 카메라를 위한 영상 파일 형태다: 압축된 EXIF 파일은 JPEG 형태의 기준선으로 사용된다. 카메라에 대한 정보와 촬영 조건(플래쉬, 노출, 광원, 화이트 밸런스, 장면의 형태)을 저장할 수 있고 칼라 보정 알고리즘을 위한 프린터에서도 사용할 수 있기 때문에, 고품질의 프린팅을 위한 다양한 태그(TIFF보다 더 많음)를 사용할 수 있다. 또한 EXIF 표준은 디지털 영상과 함께 동반된 오디오에 대한 파일 형태 사항도 포함한다. 그리고 FlashPix (Kodak에 의해 처음 개발)로 변환하기 위해 필요한 태그 정보 역시 지원한다. 2009-2학기 멀티미디어시스템

그래픽 애니메이션 파일(Graphics Animation Files) 몇몇의 두드러진 형태들은 비디오 (영상의 연속)에 맞서 그래픽 애니메이션 (즉, 그림이나 그래픽 삽화의 연속)을 저장하는 것을 목표로 한다. 차이점: 애니메이션이 비디오 파일보다 자원 요구가 훨씬 적다. FLC는 애니메이션 혹은 움직이는 그림 파일 형태중의 하나이며 처음에 Animation Pro.에 의해 만들어졌다. 또 따른 형태인 FLI는 FLC와 유사하다. GL은 좀더 나은 질의 움직이는 그림을 만들어 낸다. GL 애니메이션 역시 대체로 크기가 큰 파일을 취급할 수 있다. 많은 오래된 형태: animated GIF89 파일 뿐만 아니라 DL이나 Amiga IFF 파일, Apple Quicktime 파일. 2009-2학기 멀티미디어시스템

PS와 PDF 포스트스크립트는 조판 위한 중요한 언어이고, 많은 고성능 프린터는 포스트스크립트 번역기를 가지고 있다. 포스트스크립트는 픽셀에 기초를 두기보다는 벡터에 기초를 둔 영상 언어이다: 페이지 요소들은 기본적으로 벡터의 표현들로 정의되어진다. 포스트스크립트는 벡터 혹은 구조적인 그래픽스뿐만 아니라 문자를 포함한다. GL 비트맵 영상도 출력파일에 포함되어 있다. 요약된 포스트스크립트 파일(Encapsulated PostScript files)은 다른 문서 속에 있는 포스트스크립트 파일을 위해 일정량의 정보를 추가한다. 2009-2학기 멀티미디어시스템

4. 포스트스크립트 페이지 서술 언어는 그 자체로 압축을 제공하지는 않는다; 사실 포스트스크립트 파일은 ASCII 코드로 저장된다. 다른 문자+그림 언어들은 포스트스크립트로 대체되기 시작했다: Adobe system 사는 Portable Document Format (PDF) 파일 형태 속에 LZW 압축을 포함시켰다. 영상을 포함하지 않는 PDF 파일은 다른 LZW 기반의 압축 도구를 사용하는 파일처럼, 대략 2:1 혹은 3:1 정도의 압축률을 가진다. 2009-2학기 멀티미디어시스템

다른 JPEG 형태 마이크로소프트 윈도우: WMF(Windows MetaFile): 마이크로소프트 윈도우즈 운영체제 환경을 위한 고유의 벡터 파일 형태이다: 윈도우 환경의 운영프로그램에 내재된 그래픽스 장치 인터페이스(Graphics Device Interface, GDI)의 함수를 호출하는 집합으로 구성되어 있다. WMF 파일이 “동작중”일 때(일반적으로 윈도우즈의 PlayMetaFile() 함수를 사용할 때) 표현될 그래픽이 묘사된다. WMF파일들은 표면상으로 장치 독립적이고 사이즈에 제한이 없다. 2009-2학기 멀티미디어시스템

PAINT는 근본적으로 MacPaint 프로그램에 사용되었고 초기에는 단지 1비트의 단색 영상에 사용되었다. 마이크로소프트 윈도우: BMP: 비트맵(BitMap-BMP)은 마이크로소프트의 Paint나 다른 프로그램을 사용함에 있어서 마이크로소프트 윈도우즈를 위한 주요한 시스템 표준 그래픽 파일 형태이다. BMP 표준에는 많은 다른 형태가 있다. 매킨도시: PAINT와 PICT: PAINT는 근본적으로 MacPaint 프로그램에 사용되었고 초기에는 단지 1비트의 단색 영상에 사용되었다. PICT는 구성되어진 그래픽들을 저장하기위해 MacDraw(벡터에 기반한 드로우잉 프로그램)에 사용된다. X 윈도우: PPM: X 윈도우즈 시스템을 위한 그래픽 형태이다. PPM은 24비트의 칼라 비트맵을 지원하며 xv와 같은 많은 공용 변역의 그래픽 편집기를 이용하여 다룰 수 있다. 2009-2학기 멀티미디어시스템