JFIF
JPEG 파일 교환 형식(JPEG File Interchange Format, JFIF)는 ITU-T 권고 T.871 및 ISO/IEC 10918-5로 게시된 이미지 파일 형식 표준이다. 이는 JPEG 알고리즘으로 인코딩된 이미지 데이터를 포함하는 컨테이너 형식에 대한 추가 사양을 정의한다. JPEG 컨테이너 형식에 대한 기본 사양은 JPEG 교환 형식(JPEG Interchange Format, JIF)으로 알려진 JPEG 표준의 부속서 B(Annex B)에 정의되어 있다. JFIF는 불필요한 복잡성, 성분 샘플 등록, 해상도, 가로세로비 및 색 공간을 포함한 JIF의 몇 가지 제한 사항을 해결하기 위해 JIF를 기반으로 구축되었다. JFIF가 원래의 JPG 표준은 아니기 때문에 다른 MIME 유형을 기대할 수도 있지만, 여전히 "image/jpeg"(수정된 정보보다는 주요 데이터 형식을 나타냄)로 등록되어 있다. JFIF는 더 새로운 교환 이미지 파일 형식(Exif)과 상호 호환되지 않는다.
JPEG 파일 교환 형식(JPEG File Interchange Format, JFIF)는 ITU-T 권고 T.871 및 ISO/IEC 10918-5로 게시된 이미지 파일 형식 표준이다. 이는 JPEG 알고리즘으로 인코딩된 이미지 데이터를 포함하는 컨테이너 형식에 대한 추가 사양을 정의한다. JPEG 컨테이너 형식에 대한 기본 사양은 JPEG 교환 형식(JPEG Interchange Format, JIF)으로 알려진 JPEG 표준의 부속서 B(Annex B)에 정의되어 있다. JFIF는 불필요한 복잡성, 성분 샘플 등록, 해상도, 가로세로비 및 색 공간을 포함한 JIF의 몇 가지 제한 사항을 해결하기 위해 JIF를 기반으로 구축되었다. JFIF가 원래의 JPG 표준은 아니기 때문에 다른 MIME 유형을 기대할 수도 있지만, 여전히 "image/jpeg"(수정된 정보보다는 주요 데이터 형식을 나타냄)로 등록되어 있다.
JFIF는 더 새로운 교환 이미지 파일 형식(Exif)과 상호 호환되지 않는다.
목적
[편집]JFIF는 JPEG 파트 1 표준(ISO/IEC 10918-1, ITU-T 권고 T.81)에서 지정되지 않은 상태로 남아 있는 여러 세부 사항을 정의한다.[1]
성분 샘플 등록
[편집]JPEG는 여러 성분(예: Y, Cb, Cr)이 서로 다른 해상도를 가질 수 있도록 허용하지만, 이러한 서로 다른 샘플 배열(비트맵을 렌더링함)이 어떻게 정렬되어야 하는지는 정의하지 않는다. 이 픽셀 생성 정보는 픽셀 데이터 자체이거나 흔하지 않은 '첫 번째 모서리 및 채우기' 방식이라기보다는, 사각형의 무게 중심으로 사각형을 나타낼 것을 기대하며 렌더링된다.
해상도 및 가로세로비
[편집]JPEG 표준에는 이미지의 해상도나 가로세로비를 코딩하는 방법이 포함되어 있지 않다. JFIF는 JPEG에 대한 애플리케이션 세그먼트 확장을 사용하여 해상도 또는 가로세로비 정보를 제공한다. 이는 애플리케이션 세그먼트 #0을 사용하며, ASCII로 "JFIF"라고 적힌 널 종단 문자열과 그 뒤의 0인 바이트로 구성된 세그먼트 헤더를 가진다. 또한 이것이 파일의 첫 번째 세그먼트여야 한다고 명시함으로써 JFIF 파일을 쉽게 인식할 수 있게 한다. 디지털 카메라로 기록된 Exif 이미지는 일반적으로 이 세그먼트를 포함하지 않지만, 다른 모든 측면에서는 대개 JFIF 표준을 준수한다.
색 공간
[편집]JFIF 파일의 압축 코딩에 사용되는 JPEG 표준은 이미지에 어떤 색 인코딩을 사용할지 정의하지 않는다. JFIF는 사용될 색 모델을 정의한다. 즉, 그레이스케일을 위한 Y, 또는 CCIR 601(현재는 ITU-R BT.601로 알려짐)에 정의된 RGB 기본색에서 파생된 YCbCr을 사용하되, Y, Cb, Cr 성분에 대해 다른 "전체 범위(full range)" 스케일링을 적용한다. 검은색은 Y=16, 흰색은 Y=235로 표현되고 이 범위를 벗어나는 값은 신호 처리의 "헤드룸(headroom)"과 "풋룸(footroom)"으로 사용되는 CCIR 601의 "스튜디오 범위(studio range)"와 달리, JFIF는 8비트 표현의 256개 레벨을 모두 사용하여 검은색은 Y=0, 최대 흰색은 Y=255가 된다. CCIR 601을 통해 JFIF에 정의된 RGB 기본색도 최신 애플리케이션에서 일반적인 관행이 된 것과는 다소 다르다(예: SRGB에 정의된 색 기본색과 약간 다르다). 게다가 CCIR 601(2007년 이전)은 RGB 기본색에 대한 정밀한 정의를 제공하지 않았으며, 대신 텔레비전 산업의 기본 관행에 의존했다.
JFIF 이미지의 색상 해석은 ICC 프로필, 색 공간 메타데이터 또는 SRGB 태그를 삽입하고 이 정보를 해석하는 애플리케이션을 사용함으로써 개선될 수 있다.
파일 형식 구조
[편집]JFIF 파일은 일련의 마커 또는 마커 세그먼트로 구성된다(세부 사항은 JPEG, 구문 및 구조 참조). 마커는 JPEG 표준의 파트 1에 정의되어 있다.[1] 각 마커는 두 바이트로 구성된다: FF 바이트와 그 뒤에 오는 00 또는 FF가 아닌 바이트로 마커의 유형을 지정한다. 일부 마커는 단독으로 존재하지만, 대부분은 다음 패턴에 따라 데이터 바이트를 포함하는 마커 세그먼트의 시작을 나타낸다.
FF xx s1 s2 [데이터 바이트]
바이트 s1과 s2는 함께 연산되어 다음 "데이터 바이트"의 길이와 길이를 표현하는 데 사용된 2바이트를 더한 값을 지정하는 빅 엔디언 16비트 정수를 나타낸다. 즉, s1과 s2는 이어지는 데이터 바이트의 수를 로 지정한다.
JPEG 표준 파트 1에 따르면, 애플리케이션은 APP 마커 세그먼트를 사용하여 데이터의 애플리케이션별 의미를 정의할 수 있다. JFIF 표준에서는 다음과 같은 APP 마커 세그먼트가 정의된다.
- JFIF APP0 마커 세그먼트(줄여서 JFIF 세그먼트) (필수)
- JFIF 확장 APP0 마커 세그먼트(줄여서 JFXX 세그먼트) (선택)
이들은 아래에 설명되어 있다.
JFIF 표준은 JFIF APP0 마커 세그먼트가 SOI 마커 바로 다음에 올 것을 요구한다. JFIF 확장 APP0 마커 세그먼트가 사용되는 경우, 이는 반드시 JFIF APP0 마커 세그먼트 바로 다음에 와야 한다.[2] 따라서 JFIF 파일은 다음과 같은 구조를 갖는다.
| JFIF 파일 구조 | ||
|---|---|---|
| 세그먼트 | 코드 | 설명 |
| SOI | FF D8 |
이미지 시작(Start of Image) |
| JFIF-APP0 | FF E0 s1 s2 4A 46 49 46 00 ... |
아래 참조 |
| JFXX-APP0 | FF E0 s1 s2 4A 46 58 58 00 ... |
선택 사항, 아래 참조 |
| … 추가 마커 세그먼트 (예: SOF, DHT, COM) | ||
| SOS | FF DA |
스캔 시작(Start of Scan) |
| 압축된 이미지 데이터 | ||
| EOI | FF D9 |
이미지 끝(End of Image) |
JFIF APP0 마커 세그먼트
[편집]필수인 JFIF APP0 마커 세그먼트에서는 이미지의 매개변수가 지정된다. 선택적으로 비압축 썸네일을 삽입할 수 있다.
| JFIF APP0 마커 세그먼트 | ||
|---|---|---|
| 필드 | 크기 (바이트) | 설명 |
| APP0 마커 | 2 | FF E0
|
| 길이 | 2 | APP0 마커를 제외한 세그먼트의 길이 |
| 식별자 | 5 | 4A 46 49 46 00 = ASCII로 "JFIF", 널 바이트로 종료됨
|
| JFIF 버전 | 2 | 첫 번째 바이트는 주 버전, 두 번째 바이트는 부 버전 (1.02의 경우 01 02)
|
| 밀도 단위 | 1 | 이어지는 픽셀 밀도 필드에 대한 단위
|
| X밀도 | 2 | 수평 픽셀 밀도. 0이 아니어야 함 |
| Y밀도 | 2 | 수직 픽셀 밀도. 0이 아니어야 함 |
| X썸네일 | 1 | 이어지는 삽입된 RGB 썸네일의 수평 픽셀 수. 0일 수 있음 |
| Y썸네일 | 1 | 이어지는 삽입된 RGB 썸네일의 수직 픽셀 수. 0일 수 있음 |
| 썸네일 데이터 | 3 × n | R0, G0, B0, ... Rn-1, Gn-1, Bn-1 순서의 비압축 24비트 RGB(색상 채널당 8비트) 래스터 썸네일 데이터; n = X썸네일 × Y썸네일 |
JFIF 확장 APP0 마커 세그먼트
[편집]JFIF APP0 마커 세그먼트 바로 뒤에 JFIF 확장 APP0 마커 세그먼트가 올 수 있다. 이 세그먼트는 JFIF 버전 1.02 이상에서만 존재할 수 있다. 이를 통해 3가지 다른 형식으로 썸네일 이미지를 삽입할 수 있다.
| JFIF 확장 APP0 마커 세그먼트 | ||
|---|---|---|
| 필드 | 크기 (바이트) | 설명 |
| APP0 마커 | 2 | FF E0
|
| 길이 | 2 | APP0 마커를 제외한 세그먼트의 길이 |
| 식별자 | 5 | 4A 46 58 58 00 = ASCII로 "JFXX", 널 바이트로 종료됨
|
| 썸네일 형식 | 1 | 삽입된 썸네일에 어떤 데이터 형식이 사용되는지 지정:
|
| 썸네일 데이터 | 가변 | 썸네일 형식에 따라 다름, 아래 참조 |
썸네일 데이터는 다음과 같이 썸네일 형식에 따라 달라진다.
| JPEG 인코딩을 사용하여 저장된 썸네일 | ||
|---|---|---|
| 필드 | 크기 (바이트) | 설명 |
| SOI | 2 | FF D8
|
| 가변 | YCbCr 또는 Y만을 사용하는 JIF 형식이어야 하며, JFIF 또는 JFXX 세그먼트를 포함해서는 안 됨 | |
| EOI | 2 | FF D9
|
| 픽셀당 1바이트를 사용하여 저장된 썸네일 | ||
|---|---|---|
| 필드 | 크기 (바이트) | 설명 |
| X썸네일 | 1 | 삽입된 썸네일의 수평 픽셀 수. 0이 아니어야 함 |
| Y썸네일 | 1 | 삽입된 썸네일의 수직 픽셀 수. 0이 아니어야 함 |
| 썸네일 팔레트 | 768 | 각각 24비트 RGB 색상 값을 포함하는 256개의 팔레트 항목 |
| 썸네일 데이터 | n | 팔레트 내 색상의 인덱스를 포함하는 픽셀당 1바이트, n = X썸네일 × Y썸네일 |
| 픽셀당 3바이트를 사용하여 저장된 썸네일 | ||
|---|---|---|
| 필드 | 크기 (바이트) | 설명 |
| X썸네일 | 1 | 삽입된 썸네일의 수평 픽셀 수. 0이 아니어야 함 |
| Y썸네일 | 1 | 삽입된 썸네일의 수직 픽셀 수. 0이 아니어야 함 |
| 썸네일 데이터 | 3 × n | R0, G0, B0, ... Rn-1, Gn-1, Bn-1 순서의 비압축 24비트 RGB(색상 채널당 8비트) 래스터 썸네일 데이터; n = X썸네일 × Y썸네일 |
호환성
[편집]더 새로운 교환 이미지 파일 형식(Exif)은 JFIF와 비교할 만하지만, 두 표준은 상호 호환되지 않는다. 이는 두 표준 모두 특정 애플리케이션 세그먼트(JFIF의 경우 APP0, Exif의 경우 APP1)가 SOI 마커 바로 다음에 와야 한다고 명시하기 때문이다. 실제로는 많은 프로그램과 디지털 카메라가 두 애플리케이션 세그먼트가 모두 포함된 파일을 생성한다. 이는 대부분의 디코더에서 이미지 디코딩에 영향을 미치지 않지만, 제대로 설계되지 않은 JFIF 또는 Exif 파서는 파일을 제대로 인식하지 못할 수 있다.
JFIF는 어도비 포토샵의 JPEG "정보 리소스 블록" 확장 및 IPTC 정보 교환 모델 메타데이터와 호환되는데, 이는 JFIF가 다른 애플리케이션 세그먼트를 배제하지 않으며 포토샵 확장이 파일의 첫 번째일 필요가 없기 때문이다. 그러나 포토샵은 일반적으로 CMYK 버퍼를 JFIF를 준수하지 않는 4성분 "Adobe JPEG"로 저장한다. 이러한 파일은 YCbCr 색 공간이 아니기 때문에 일반적으로 웹 브라우저 및 기타 인터넷 소프트웨어에서 디코딩할 수 없다.
역사
[편집]JFIF 문서의 개발은 C-Cube 마이크로시스템즈의 에릭 해밀턴이 주도했으며, 1991년 말 C-Cube에서 열린 다양한 컴퓨터, 통신 및 이미징 회사의 대표 약 40명이 참석한 회의에서 첫 번째 버전에 대한 합의가 이루어졌다. 그 직후 소규모 개정판인 JFIF 1.01이 발표되었다.[3] 거의 20년 동안 사용 가능한 최신 버전은 1992년 9월 1일에 발표된 v1.02였다.[2]
1996년, RFC 2046은 인터넷을 통해 JPEG 이미지를 전송하는 데 사용되는 이미지 형식이 JFIF여야 한다고 명시했다. "image/jpeg"의 MIME 유형은 JFIF로 인코딩되어야 한다. 그러나 실제로는 거의 모든 인터넷 소프트웨어가 JFIF 준수 여부와 관계없이 Y 또는 YCbCr 성분을 사용하는 모든 기본 JIF 이미지를 디코딩할 수 있다.
시간이 흐르면서 C-Cube는 구조 조정되었고(결국 하모닉, LSI 로직, 매그넘 세미컨덕터, 아바고 테크놀로지스, 브로드컴, GigOptix, GigPeak 등으로 분할 및 승계됨), 문서에 대한 관심을 잃었다. 이 사양은 2009년경 Ecma 인터내셔널과 ITU-T/ISO/IEC Joint Photographic Experts Group이 역사의 뒤안길로 사라지는 것을 방지하고 표준 간행물에서 공식적으로 인용할 수 있는 방법을 제공하며 편집 품질을 개선하기 위해 이를 가져가기 전까지 공식적인 발행자가 없었다. 이는 역사적 기록의 유실을 방지하기 위해 2009년 ECMA에서 기술 보고서(Technical Report) 번호 98로 발표되었으며,[3] 2011년 ITU-T에 의해 권고 T.871로,[4] 그리고 2013년 ISO/IEC에 의해 ISO/IEC 10918-5로 공식 표준화되었다.[5] 새로운 간행물에는 편집상의 개선 사항이 포함되었으나 실질적인 기술적 변경 사항은 없었다.
같이 보기
[편집]각주
[편집]- ↑ 가 나 “Recommendation ITU-T T.81: Information technology – Digital compression and coding of continuous-tone still images – Requirements and guidelines” (PDF). 《ITU-T (formerly CCITT)》. 1992년 2월 18일. 2015년 6월 15일에 확인함.
- ↑ 가 나 Hamilton, Eric (1992년 9월 12일). “JPEG File Interchange Format, Version 1.02” (pdf, 0.02 MB). 2015년 6월 15일에 확인함.
- ↑ 가 나 “JPEG File Interchange Format (JFIF)”. 《ecma-international.org》. 2009. 2015년 6월 15일에 확인함.
- ↑ “Recommendation ITU-T T.871: Information technology – Digital compression and coding of continuous-tone still images: JPEG File Interchange Format (JFIF)” (PDF). ITU-T. 2011년 5월 14일. 2015년 6월 15일에 확인함.
- ↑ “ISO/IEC 10918-5:2013: Information technology – Digital compression and coding of continuous-tone still images: JPEG File Interchange Format (JFIF).”. ISO/International Electrotechnical Commission. 2013년 5월 1일. 2015년 6월 15일에 확인함.
더 읽어보기
[편집]도서
[편집]- Miano, John M, "Compressed Image File Formats"; 1999, Addison-Wesley ISBN 978-0-201-60443-6
- Pennebaker, William B. and 조안 L. 미첼: JPEG still image data compression standard; 3rd edition, 1993, Springer ISBN 978-0-442-01272-4
표준
[편집]- Hamilton, Eric: JPEG File Interchange Format, Version 1.02 (PDF, 0.02 MB) 1 September 1992
- Recommendation ITU-T T.871: Information technology – Digital compression and coding of continuous-tone still images: JPEG File Interchange Format (JFIF) (PDF and Microsoft Word, 0.2 MB) Approved 14 May 2011; posted 11 September 2012
- Recommendation ITU-T T.81: Information technology – Digital compression and coding of continuous-tone still images – Requirements and guidelines (PDF and Microsoft Word, 1.5 MB) Approved 18 September 1992; posted 14 April 2004