ILBM
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
ILBM(Interleaved Bitmap)은 IFF 파일 형식의 구현으로, 이미지 크기, 팔레트, 픽셀 데이터를 포함한 정보를 담고 있다. BMHD, CMAP, BODY 등의 청크(Chunk)로 구성되며, BMHD는 이미지 표시 방식을, BODY는 실제 이미지 데이터를 저장한다. ILBM은 런 렝스 인코딩(RLE)을 사용하여 이미지 데이터를 압축할 수 있으며, 아미가 컴퓨터의 그래픽 기능을 활용하기 위해 설계되어 CAMG 청크를 통해 아미가 디스플레이 모드를 지정할 수 있다. 또한, 애니메이션을 지원하는 ANIM 형식으로 확장되어 ANHD, DLTA 청크를 추가로 정의한다.
더 읽어볼만한 페이지
ILBM - [IT 관련 정보]에 관한 문서 | |
---|---|
개요 | |
![]() | |
종류 | 이미지 파일 형식 |
확장자 | .iff, .lbm |
개발 | 일렉트로닉 아츠 |
발표일 | 1985년 1월 14일 |
장르 | 이미지 파일 형식 |
표준 | EA IFF 85: Standard for Interchange Format |
공개 여부 | 공개 소스 코드 |
컨테이너 | Interchange File Format |
기반 | 없음 |
확장 | 없음 |
설명 | |
이름 | "ILBM" IFF 인터리브 비트맵 (Interleaved Bitmap) |
의미 | 인터리브 비트맵 |
2. 파일 형식
ILBM은 여러 개의 청크(Chunk)로 구성된 IFF 파일 형식의 한 종류이다. 각 청크는 특정한 정보를 담고 있으며, 프로그램은 필요한 청크만 처리하면 된다.[4]
ILBM 파일은 이미지 크기, 팔레트, 픽셀 데이터 등을 포함하여 이미지 편집 프로그램에서 이미지를 표시할 수 있도록 한다. 일부는 페인트 프로그램용 팔레트 역할을 하거나 다른 이미지에 병합되도록 설계되었다.[4]
ILBM에서 'BMHD'(비트 맵 헤더) 등 필수 청크는 'BODY' 청크 앞에 와야 한다. 'BODY' 뒤의 청크는 '추가' 청크로 간주되어, 많은 프로그램에서 읽지 않는다.[4]
ILBM에는 다음과 같은 청크가 정의되어 있다:
- BMHD ('''B'''it'''M'''ap'''H'''ea'''D'''er)
- CMAP ('''C'''olor'''MAP''') - 컬러 팔레트
- GRAB ('''GRAB''' 위치)
- CAMG ('''C'''ommodore '''AM'''i'''G'''a 컴퓨터)
- BODY - 비트 플레인과 마스크
Deluxe Paint는 DPAN ('''Dpa'''i'''n'''t) 청크를 사용한다.
애니메이션을 지원하는 ANIM 형식은 ILBM에서 파생되었으며, ANHD ('''AN'''imation '''H'''ea'''D'''er)와 DLTA ('''DeLTA''') 청크를 추가로 사용한다.[4]
2. 1. BMHD: Bitmap Header
'''BMHD''' (비트맵 헤더) 청크는 이미지 표시 방법을 지정하며, 보통 '''FORM''' 내부의 첫 번째 청크이다. 이미지의 높이와 너비를 정의할 뿐만 아니라 화면에 어디에 그릴지, 다양한 화면 해상도에서 어떻게 표시할지, 이미지가 압축되었는지 여부도 정의한다.[4]유형 | 이름 | 설명 |
---|---|---|
UINT16BE | width | 이미지 너비 (픽셀) |
UINT16BE | height | 이미지 높이 (픽셀) |
INT16BE | xOrigin | 화면에서 이미지의 왼쪽 위 모서리가 있는 위치 (픽셀). 이미지가 더 큰 이미지의 일부이거나 전체 화면이 아닌 경우 값은 보통 0, 0이다. |
INT16BE | yOrigin | |
UINT8 | numPlanes | 비트맵의 평면 수. 단색은 1, 16색은 4, 256색은 8, 색상표만 있고 이미지 데이터가 없는 경우 0이다. (즉, 이 파일은 단순히 색상표이다.) |
UINT8 | mask | 1 = 마스크, 2 = 투명 색상, 3 = 올가미 (MacPaint용). 마스크 데이터는 비트 평면으로 간주되지 않는다. |
UINT8 | compression | 0이면 압축되지 않음. 1이면 이미지 데이터가 RLE로 압축됨. 2는 Atari ST용 Deluxe Paint의 "수직 RLE"이다. 다른 값은 이론적으로 다른 압축 방법을 나타낼 수 있다. |
UINT8 | pad1 | 읽을 때는 무시하고, 이후 호환성을 위해 쓸 때는 0으로 설정 |
UINT16BE | transClr | 투명 색상. mask >= 2인 경우에만 유용함 |
UINT8 | xAspect | 픽셀 종횡비 (너비:높이의 비율). 320x200 5:6 또는 10:11과 같은 다양한 화면 해상도에서 이미지를 표시하는 데 사용됨 |
UINT8 | yAspect | |
INT16BE | pageWidth | 이미지를 표시할 화면 크기 (픽셀). 보통 320×200 |
INT16BE | pageHeight |
2. 2. BODY: Image Data
'''BODY''' 청크는 일반적으로 파일의 마지막 청크이며,[4] 가장 크다.ILBM 파일에서 '''BODY''' 청크는 실제 이미지 데이터를 행별로 인터리브된 비트 플레인(선택적 마스크 포함)으로 저장한다. 비트 플레인은 1부터 n까지 먼저 나타나고, 그 다음 마스크 플레인이 나타난다. 이미지가 압축되지 않은 경우 각 라인은 `(너비 + 15) / 16`개의 16비트 값으로 구성된다(예: 픽셀당 1비트, 16비트의 가장 가까운 배수로 반올림).[4] PBM 파일에서 '''BODY''' 청크는 압축되지 않은 상태에서 이미지 데이터를 포함하는 연속적인 바이트 스트림이므로 더 간단하다.
2. 2. 1. 압축
ILBM 파일에서 '''BODY''' 청크는 실제 이미지 데이터를 행별로 인터리브된 비트 플레인(선택적 마스크 포함)으로 저장한다. 압축된 경우 각 라인은 개별적으로 압축되며, 압축 시 항상 16비트의 배수이다.[4]이미지가 압축된 경우, 각 데이터 행(각 비트 플레인은 아님)은 마스크 데이터가 있는 경우 이를 포함하여 개별적으로 압축된다. 압축은 플래그를 사용하는 다양한 RLE 압축 방식이다. 압축 해제 방법은 다음과 같다.[4]
- 이미지 크기에서 계산된 최종 길이의 바이트 데이터가 될 때까지 반복한다.
- 압축 해제된 데이터 길이가 최종 길이보다 작은 동안:
- # 바이트 [값]을 읽는다.
- # [값] > 128인 경우:
- #* 다음 바이트를 읽고 (257 - [값])번 출력한다.
- #* 2바이트 앞으로 이동하여 위 단계를 반복한다.
- # [값] < 128인 경우:
- #* 다음 [값 + 1] 바이트를 읽고 출력한다.
- #* [값 + 2] 바이트 앞으로 이동하여 위 단계를 반복한다.
- # [값] = 128이면 압축 해제를 중지한다.
압축 루틴의 경우, 2바이트 반복 실행은 앞뒤로 리터럴 실행이 있는 경우를 제외하고는 복제 실행으로 인코딩하는 것이 가장 좋다. 이 경우 세 개를 하나의 리터럴 실행으로 병합하는 것이 가장 좋다. 항상 3바이트를 초과하는 반복은 복제 실행으로 인코딩해야 한다.[4]
2. 3. CAMG: Amiga Mode
'''CAMG''' 청크는 코모도어 아미가 컴퓨터에서 사용되는 뷰포트 모드를 저장한다. "듀얼 플레이필드" 및 "홀드 앤 모디파이"와 같은 아미가 디스플레이 모드를 지정하는 데 사용된다.[4] 아미가 게임 외에서는 드물게 사용된다.유형 | 이름 | 설명 |
---|---|---|
UINT32BE | 뷰포트 모드 | 비트 플래그; 아미가 하드웨어에서 직접 해석됨 |
2. 4. CMAP: Palette
CMAP 청크는 이미지에 사용된 팔레트를 담고 있으며, 각 색상에 대한 3바이트 RGB 값(빨강, 초록, 파랑)으로 구성된다. 각 바이트는 0에서 255 사이의 값을 가진다.[4]CMAP 청크의 길이는 (3 × 색상 수) 바이트이다. 팔레트의 색상 수는 (2 ^ 비트 평면 수)가 된다. 이 청크는 선택 사항이며, 없을 경우 기본 팔레트가 사용된다. 예상보다 적은 수의 항목을 가질 수 있다(예: 4 평면 '16색' 비트맵의 경우 7색). IFF 사양에 따라 색상 수가 홀수이면 청크 길이를 짝수 바이트로 만들기 위해 1바이트가 추가되지만, 이 추가 바이트는 청크의 길이 필드에 포함되지 않는다.[4]
ILBM 파일은 이미지 데이터 없이 색상 맵만 포함하기도 하는데, 이는 이미지에 별도로 적용할 수 있는 색상 팔레트를 저장하는 데 자주 사용된다.[4]
2. 5. GRAB: Hotspot
GRAB 청크는 이미지의 핫스팟(hotspot) 위치를 지정한다. 핫스팟은 이미지 내에서 특정한 동작을 유발하는 지점을 의미하며, 주로 마우스 클릭과 같은 사용자 상호작용에 사용된다.2. 6. SPRT: Z-order
주어진 원본 소스에는 ILBM 파일 형식에서 스프라이트의 Z-order (우선 순위)를 지정하는 청크에 대한 정보가 없다. 따라서 이 섹션에는 해당 내용을 작성할 수 없다.2. 7. TINY: Thumbnail
ILBM은 미리보기 이미지를 저장하는 TINY 청크를 지원하지 않는다. 원본 소스에는 TINY 청크에 대한 언급이 없으며, ILBM 파일 형식의 구성 요소와 청크 유형에 대한 설명만 제공된다.3. 아미가와의 관계
ILBM은 아미가 컴퓨터의 그래픽 기능을 활용하기 위해 설계되었다. 특히, 'CAMG' 청크는 코모도어 아미가 컴퓨터용으로 사용되며, "듀얼 플레이필드" 및 "홀드 앤 모디파이"와 같은 아미가 디스플레이 모드를 지정하는 LONG "뷰포트 모드"를 저장할 수 있다.
CAMG 청크의 구조는 다음과 같다.
유형 | 이름 | 설명 |
---|---|---|
UINT32BE | 뷰포트 모드 | 비트 플래그; 아미가 하드웨어에서 직접 해석됨 |
아미가의 OCS 및 ECS 칩셋은 최대 6개의 비트 플레인을 지원하여, 일반적으로 64색 표시가 가능하다. 그러나 팔레트 레지스터는 32개뿐이므로, 5개의 비트 플레인은 팔레트 레지스터 번호에 직접 대응한다. 6개의 비트 플레인은 픽셀의 휘도를 조절하거나 HAM 모드를 통해 색상 표현을 확장하는 데 사용된다. AGA 칩셋은 8개의 비트 플레인을 지원하고 256색 팔레트 레지스터를 갖추어, 64색, 128색, 256색 모드와 HAM8 모드를 지원한다.
3. 1. Extra Half-Brite (EHB)
Extra Half-Brite|엑스트라 하프 브라이트영어 (EHB)는 아미가 칩셋의 특수 그래픽 모드 중 하나이다. ILBM 파일에 CAMG 청크(16진수로 0x80)가 포함되어 있고, 비트 7이 설정되어 있으면 EHB 모드를 사용한다.[4]EHB 모드에서는 32개 이하의 항목을 가진 컬러 맵을 사용하지만, 이미지는 6개의 비트 플레인을 갖는다. 가장 중요한 비트 플레인은 플래그 역할을 한다. 이 플래그가 설정되지 않으면 하위 5비트를 컬러 맵의 인덱스로 사용하여 일반적인 32색 이미지를 표시한다. 플래그가 설정되면 하위 5비트를 컬러 맵의 인덱스로 사용하되, 해당 색상의 RGB 구성 요소를 오른쪽으로 한 비트 이동하여 밝기를 절반으로 줄인 색상을 사용한다. 즉, 32색 팔레트에 추가로 32개의 반 밝기 색상을 사용할 수 있게 되어, 총 64색을 표현할 수 있다.[4]
64개의 항목을 가진 컬러 맵을 만들고, 하위 32개 항목을 상위 절반에 복사하여 반 밝기로 변환한 다음, 6개의 모든 비트 플레인을 색상 인덱스로 사용할 수도 있다.[4]
OCS (Original Chip Set) 및 ECS (Enhanced Chip Set)는 최대 6개의 비트 플레인을 지원하여 EHB 모드를 통해 64색 표시가 가능하다.
3. 2. Hold-And-Modify (HAM)
ILBM 파일에 비트 11이 설정된 CAMG 청크(예: 16진수 0x800)가 포함된 경우, 해당 파일은 아미가 칩셋의 HAM(Hold-And-Modify, 홀드 앤 모디파이) 모드를 사용한다. HAM6 형식에서 컬러 맵은 최대 16개의 항목을 가지지만, 이미지는 6개(또는 5개)의 비트 플레인을 갖는다. HAM8 형식에서 컬러 맵은 최대 64개의 항목을 가지지만, 이미지는 8개(또는 7개)의 비트 플레인을 갖는다.[4]마지막 두 비트 플레인(홀수 개의 비트 플레인이 있는 경우 항상 0인 추가 비트 플레인으로 간주)은 처음 4개(또는 6개)의 비트 플레인을 사용하는 방법을 나타내는 제어 플래그이다.[4]
제어 플래그 | 설명 |
---|---|
00 | 비트 플레인 0-3(또는 0-5)을 일반적인 컬러 맵 인덱스로 사용 |
10 | 이전 픽셀의 색상을 사용하되, 파란색 구성 요소를 비트 플레인 0-3(또는 0-5)의 비트로 대체 |
01 | 이전 픽셀의 색상을 사용하되, 빨간색 구성 요소를 비트 플레인 0-3(또는 0-5)의 비트로 대체 |
11 | 이전 픽셀의 색상을 사용하되, 녹색 구성 요소를 비트 플레인 0-3(또는 0-5)의 비트로 대체 |
스캔 라인의 첫 번째 픽셀이 수정 픽셀인 경우, 이미지 테두리 색상을 수정하여 사용한다.[4]
색상 구성 요소를 수정하는 데 4비트를 사용하는 경우, 해당 구성 요소의 상위 4비트와 하위 4비트 모두에서 4비트를 사용해야 한다(전반적인 색상 영역 감소를 방지하기 위해). 6비트를 사용하는 경우 이 점이 덜 중요하지만, 수정 비트의 최상위 2비트를 색상 구성 요소의 최하위 2비트에 넣을 수도 있다.[4]
OCS (Original Chip Set) 및 ECS (Enhanced Chip Set)는 최대 6개의 비트 플레인을 지원하며, 일반적으로 64색 표시가 가능하다. 그러나 팔레트 레지스터는 32개밖에 없다. 5개의 비트 플레인은 팔레트 레지스터 번호에 직접 대응한다. 6개의 비트 플레인의 용도는 두 가지가 있는데, 하나는 픽셀의 휘도(밝음/어두움)를 지정하여 64색을 표시하는 모드이고, 다른 하나는 HAM (Hold And Modify) 모드라고 불리며, 팔레트에서는 16색만 사용하지만 제한적으로 4096색을 표시하는 모드이다.
AGA (Advanced Graphics Architecture) 칩셋에서는 8개의 비트 플레인을 사용할 수 있으며, 256색의 팔레트 레지스터가 있다. 이 때문에 64색, 128색, 256색의 모드가 있다. 또한 HAM8 모드에서 64색의 팔레트를 사용하여 최대 262,144색을 표시한다.
4. 유틸리티
ILBM 파일을 처리하는 대부분의 유틸리티는 매킨토시 페인트나 디럭스 페인트와 같이 다소 오래되었다. 이르판뷰는 파일을 볼 수 있으며, 비상업적 용도로 무료이고 리눅스에서도 작동한다. 넷PBM은 ILBM 이미지를 자체 PPM 형식으로 변환할 수 있으며[5] 다시 변환할 수 있다.[6] 디럭스 페인트에서 영감을 얻은 GrafX2 픽셀 아트 그래픽 편집기는 ILBM 파일을 로드하고 저장할 수 있지만 최대 256색으로 제한되므로 HAM 또는 24비트 ILBM 이미지는 모든 색상을 표시하지 않는다. ImageMagick 및 GraphicsMagick 또한 넷PBM의 ''ilbmtoppm'' 및 ''ppmtoilbm'' 유틸리티가 설치되어 있으면 ILBM 이미지를 표시하고 변환할 수 있다.
5. 기타 チャンク (일본어 문서에서 추가)
ILBM 파일은 작성자, 버전, 저작권 등 표준 IFF 청크를 포함할 수 있다. 디럭스 페인트에서 생성된 파일에는 DPAN(디럭스 페인트 설정 저장) 청크도 포함된다.
ANIM 형식은 ILBM에서 파생된 애니메이션 지원 형식이며, ANHD(애니메이션 헤더) 및 DLTA(프레임 간 차이 저장, 다양한 압축 방법 지원) 청크가 추가로 정의된다.
참조
[1]
웹사이트
EA IFF 85: Standard for Interchange Format Files
http://www.martinred[...]
Electronic Arts
1985-01-14
[2]
웹사이트
"ILBM" IFF Interleaved Bitmap
http://home.comcast.[...]
Electronic Arts
1986-01-17
[3]
서적
Encyclopedia of Graphics File Formats, Second Edition
https://archive.org/[...]
O'Reilly Media
2014-02-27
[4]
웹사이트
ILBM IFF Interleaved Bitmap
http://wiki.amigaos.[...]
2018-07-30
[5]
웹사이트
ilbmtoppm
http://netpbm.source[...]
2019-06-13
[6]
웹사이트
ppmtoilbm
http://netpbm.source[...]
2019-06-13
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com