JPEG

JPEG 또는 JPG(/ˈdʒeɪpɛ/JAY-peg)^[2]는 디지털 이미지, 특히 디지털 사진에서 생성된 이미지들에 대해 일반적으로 사용되는 손실 압축 방법이다. 압축 정도를 조정할 수 있어 스토리지 크기와 이미지 품질 사이에서 선택할 수 있다. JPEG는 일반적으로 영상 화질에서 감지할 수 있는 손실이 거의 없는 10:1 압축을 달성한다.^[3] JPEG는 1992년 도입 이후 세계에서 가장 널리 사용되는 이미지 압축 표준이자 가장 ^[4][5][6]널리 사용되는 디지털 이미지 포맷으로 2015년 현재 매일 수십억 장의 JPEG 이미지가 생산되고 있다.^[7]

'JPEG'라는 용어는 1992년 이 표준을 만든 '공동사진전문가그룹'의 이니셜리즘/어법이다. JPEG의 기본은 1972년 나시르 아흐메드가 처음 제안한 손실 이미지 압축 기술인 ^[1]이산 코사인 변환(DCT)이다.^[8] JPEG는 인터넷과 소셜 미디어에 디지털 이미지와 디지털 사진의 확산에 크게 기여했다.^[9]

JPEG 압축은 많은 이미지 파일 형식에서 사용된다. JPEG/Exif는 디지털 카메라 및 기타 사진 이미지 캡처 장치가 사용하는 가장 일반적인 이미지 형식이며, JPEG/JFIF와 함께 World Wide Web에서 사진 이미지를 저장하고 전송하는 가장 일반적인 형식이다.^[10] 이러한 형식 변화는 종종 구별되지 않으며, 간단히 JPEG라고 불린다.

JPEG의 MIME 미디어 유형은 JPEG 이미지를 업로드할 때 MIME 유형의 이미지/pjpeg를 제공하는 이전 Internet Explorer 버전을 제외하고 image/jpeg이다.^[11] JPEG 파일에는 일반적으로 파일 이름 확장자가 .jpg 또는 .jpeg. JPEG/JFIF는 최대 영상 크기가 65,535×65,535 픽셀이므로 최대 4기가픽셀까지 지원한다.^[12] 2000년에 JPEG 그룹은 후속 모델인 JPEG 2000을 목표로 하는 형식을 도입했지만, 기존의 JPEG를 지배적인 이미지 표준으로 대체할 수는 없었다.^[13]

역사

배경

1992년에 발행된 JPEG 원본 규격은 CCITT(현재의 ITU-T, ITU-T Study Group 16을 통한 ITU-T)와 공동 사진 전문가 그룹이 인용한 다양한 초기 연구 논문 및 특허의 과정을 구현한다.^[1] JPEG의 손실 압축 알고리즘의 주요 근거는 1972년 나시르 아흐메드가 이미지 압축 기법으로 처음 제안한 이산 코사인 변환(DCT)이다.^{[1][14][8][14]} 아흐메드는 1973년 캔자스 주립대학의 T. 나타라얀, 알링턴에 있는 텍사스 대학의 K. R. 라오 등과 함께 실용적인 DCT 알고리즘을 개발했다.^[8] 그들의 1974년 논문은^[15] JPEG 규격에 인용되어 있으며, 1977년 Wen-Hsiung Chen, C.H. Smith, S.C.의 논문을 포함하여 DCT에 대해 더 많은 연구를 수행한 몇 개의 후기 연구 논문도 포함되어 있다. N.J. Narasinha와 S.C.의 1978년 논문뿐만 아니라 ^[1][16]빠른 DCT 알고리즘을 설명한 프랄릭. 프랄릭, 그리고 1984년 B.G. 리가 쓴 논문.^[1] 명세서는 또한 양자화 알고리즘에 대한 영향으로서 W.K.Pratt와 W.Hsiung Chen의 1984년 논문을 인용하고 있으며,^[1][17] David A도 인용하고 있다. 허프먼의 1952년 논문 허프먼 코딩 알고리즘.^[1]

JPEG 규격은 여러 회사의 특허를 인용하고 있다. 다음의 특허는 산술 코딩 알고리즘의 기초를 제공했다.^[1]

• IBM
  • 미국 특허 4,652,856 – 1986년 2월 4일 – Kotappuram M. A. Mohiuddin 및 Jorma J. Rissanen – 곱셈 없는 다중 알파벳 산술 코드
  • 미국 특허 4,905,297 – 1990년 2월 27일 – G. 랭던, J.L. 미첼, W.B. 펜네베이커, 조마 J. 리사넨 – 산술 코딩 인코더 및 디코더 시스템
  • 미국 특허 4,935,882 – 1990년 6월 19일 – W.B. 펜네베이커 및 J.L. 미첼 – 산술 코더의 확률 적응
• 미쓰비시 전기
  • JP H02202267 (1021672) – 1989년 1월 21일 – 기무라 도시히로, 키노 시게노리, 오노 후미타카, 요시다 마사유키 – 코딩 시스템
  • JP H03247123(2-46275) – 1990년 2월 26일 – 오노 후미타카, 기무라 도모히로, 요시다 마사유키, 키노 시게노리 – 코딩 기구 및 코딩 방법

JPEG 규격에는 IBM의 다른 특허 3건도 인용되어 있다. 특허권자로 거론되는 다른 기업으로는 AT&T(특허 2건)와 캐논이 있다.^[1] 1986년 10월 압축연구소의 원 흐엉 첸과 다니엘 J. 클렌케가 출원한 미국 특허권 469만8672건은 이 목록에 없다. 이 특허는 DCT 기반 이미지 압축 알고리즘을 기술하며, 이후 2002년에 논란의 원인이 될 것이다(아래 특허 논란 참조).^[18] 그러나 JPEG 명세서는 1977년과 1984년에 발표된 천원웅 연구 논문의 두 개의 초기 논문을 인용했다.^[1]

JPEG 표준

"JPEG"는 JPEG 표준을 만든 위원회의 이름인 "Joint Photography Experts Group"과 다른 스틸 사진 코딩 표준을 의미한다. "조인트"는 ISO TC97 WG8 및 CCITT SGVIII를 나타낸다. 1986년에 설립된 이 단체는 1980년대 후반에 JPEG 표준을 개발했다. 그들이 조사한 몇 가지 변환 코사인 변환 기법 중에서, 그들은 이산 코사인 변환(DCT)을 선택했는데, 그것은 지금까지 가장 효율적인 실제 압축 기법이었기 때문이다. 이 단체는 1992년에 JPEG 표준을 발표했다.^[5]

In 1987, ISO TC 97 became ISO/IEC JTC1 and, in 1992, CCITT became ITU-T. Currently on the JTC1 side, JPEG is one of two sub-groups of ISO/IEC Joint Technical Committee 1, Subcommittee 29, Working Group 1 (ISO/IEC JTC 1/SC 29/WG 1) – titled as Coding of still pictures.^[19][20][21] ITU-T측에서는 ITU-T SG16이 각각의 주체다. 원래의 JPEG 그룹은 1986년에 ^[22]조직되어 1992년에 최초의 JPEG 표준을 발행하였으며, 1992년 9월에는 ITU-T 권장 T.81로^[23], 1994년에는 ISO/IEC 10918-1로 승인되었다.

JPEG 표준은 코덱을 지정하는데, 코덱은 이미지를 바이트 스트림으로 압축한 후 다시 압축하여 이미지로 압축하는 방법을 정의하지만, 해당 스트림을 포함하는 데 사용되는 파일 형식은 정의하지 않는다.^[24] Exif와 JFIF 표준은 JPEG 압축된 이미지의 교환을 위해 일반적으로 사용되는 파일 형식을 정의한다.

JPEG 표준은 공식적으로 정보 기술 – 연속 톤 스틸 이미지의 디지털 압축 및 코딩으로 명명된다. ISO/IEC 10918은 다음과 같은 부분으로 구성된다.

Ecma International /98은 JPEG File Interchange Format(JFIF)을 지정하며, 2009년 6월에 초판이 발행되었다.^[28]

특허논란

2002년에, Eudent Networks는 JPEG 기술에 대한 특허권을 소유했고, 1986년 10월 27일에 출원되어 1987년 10월 6일에 특허권을 부여받은 특허로부터 비롯되었다: 압축 연구소의 Wen-Hsiung Chen과 Daniel J. Klenke에 의한 미국 특허 4,698,672.^[18][29] 당시 Guardent가 Compression Labs를 소유하지 않았지만, Chen은 Cisco에서 일하기 전에 나중에 Guardent에 Compression Labs를 판매했다. 이는 유던트가 특허에 대한 소유권을 획득하는 결과로 이어졌다.^[18] 2002년 포던트의 발표는 유니시스가 GIF 이미지 압축 표준에 대한 권리를 주장하려는 시도를 연상시키는 분노를 일으켰다.

JPEG 위원회는 2002년 특허청구를 조사하여 선행기술에 의해 무효화되었다는 의견을 제시하였는데,^[30] 이는 여러 전문가들의 공통된 견해였다.^[18][31] 특허는 나시르 아흐메드, T. 나타라얀, K. R. 라오의 1974년 논문에서 유래한 손실 이미지 압축 기술인 ^[18]이산 코사인 변환(DCT)을 기반으로 한 이미지 압축 알고리즘을 기술하고 있다.^[1][14][15] Wen-Hsiung Chen은 C.H. Smith와 S.C.와 함께 1977년 논문에서 빠른 DCT 알고리즘을 설명하면서 DCT 기법을 더욱 발전시켰다. 프랄릭^[16][18] 1992년 JPEG 규격은 DCT 알고리즘에 대한 1974년 아흐메드 논문과 1977년 첸 논문, 정량화 알고리즘에 대한 첸과 W.K. 프라트의 1984년 논문을 모두 인용하였다.^[1][17] 압축연구소는 첸이 설립한 회사로 DCT 기술을 최초로 상용화한 기업이다.^[32] 첸이 1986년 클렌케에 DCT 기반 이미지 압축 알고리즘에 대한 특허를 출원했을 때, 후에 JPEG 표준이 될 대부분의 것들은 이미 이전 문헌에서 공식화되었다.^[18] JPEG 대표 리처드 클라크도 첸 자신이 JPEG 위원회 중 한 곳에 앉았다고 주장했지만, 용서ent는 이 주장을 부인했다.^[18]

2002년과 2004년 사이에, Fordent는 30여 개 회사에 그들의 특허를 허가함으로써 약 1억 500만 달러를 획득할 수 있었다. 2004년 4월, Gudent는 추가 라이센스 지불을 강제하기 위해 다른 31개 회사를 고소했다. 같은 해 7월 21개 대형 컴퓨터 업체 컨소시엄이 특허 무효화를 목표로 맞소송을 제기했다. 또 마이크로소프트는 2005년 4월 유던트를 상대로 별도의 소송을 시작했다.^[33] 2006년 2월 미국 특허상표국은 공공특허재단의 요청에 따라 Fordent의 JPEG 특허를 재검토하기로 합의했다.^[34] 2006년 5월 26일, USPTO는 선행기술에 근거한 특허가 무효라고 판단했다. USPTO는 또한 Fordent가 선행기술에 대해 알고 있었지만 의도적으로 특허청에 알리지 않았다는 것을 발견했다. 이것은 특허권 복원에 대한 어떤 호소도 성공할 가능성이 매우 낮다.^[35]

Forident 또한 1994년에 유럽특허청에서 부여한 유사한 특허를 가지고 있지만, 그것이 얼마나 집행 가능한지는 확실하지 않다.^[36]

2006년 10월 27일 현재, 미국 특허의 20년 임기는 만료된 것으로 보이며, 2006년 11월, Forident는 JPEG 표준의 사용에 대한 특허 청구권의 집행을 포기하기로 합의하였다.^[37]

JPEG 위원회는 자사의 표준(특히 기준 방법)을 라이센스 수수료 지불 없이 구현할 수 있다는 명백한 목표의 하나로 20개 이상의 대형 조직으로부터 JPEG 2000 표준에 대한 적절한 라이센스 권한을 확보했다.^{[citation needed]}

2007년 8월부터, 또 다른 회사인 글로벌 특허 홀딩스, LLC는 1993년에 발행된 특허(미국 특허 5,253,341)가 JPEG 이미지를 웹사이트나 이메일로 다운로드함으로써 침해된다고 주장했다. 무효화되지 않으면 이 특허는 JPEG 영상을 표시하는 모든 웹사이트에 적용될 수 있다. 이 특허는 2000년부터 2007년까지 미국 특허청(United Office)에서 재심사를 받았으며, 2007년 7월 특허청은 이 특허의 원래 주장을 모두 취소했지만 글로벌 특허홀딩스(Global Extent Holdings)가 제안한 추가 청구(청구 17)가 유효하다는 사실을 밝혀냈다.^[38] 이어 글로벌특허홀딩스는 자사 특허 17건을 청구해 다수의 소송을 제기했다.

미국 일리노이주 시카고에서 열린 글로벌 특허홀딩스(Global Extremit Holdings)의 재심사에 이은 첫 2건의 소송에서 둘 다 그린베이 패커스(Green Bay Packers), CDW(CDW), 모토로라(Motorola), 애플(Approtz), 오피스테맥스(ORitz), 오스테맥스(Offeremax), 캐터필러), 캐터필러(Catter), 크래터), 크라프트(Craftraftraf 2007년 12월 5일, 사우스 플로리다에서는 ADT 보안 서비스, 오토네이션, 플로리다 크리스털 주식회사, HearUSA, MovieTickets.com, Ocwen Financial Corporation, 타이어 킹덤을 상대로 한 세 번째 소송이 제기되었고, 2008년 1월 8일에는 사우스 플로리다에서 보카 라톤 리조트 & 클럽을 상대로 한 네 번째 소송이 제기되었다. 네바다의 글로벌 특허 홀딩스를 상대로 다섯 번째 소송이 제기되었다. 이 소송은 글로벌 특허홀딩스로부터 위협을 받은 것으로 알려진 주식회사 아마존닷컴이 제기한 것으로, '341 특허는 무효하며 침해되지 않는다'는 사법적 선언을 청구했다.

글로벌 특허 홀딩스는 또한 그레고리 아하로니안과^[39] "특허 트롤 추적기"로 알려진 웹사이트의 익명 운영자를 포함한 광범위한 소프트웨어 특허에 대한 비판자들을 고소하거나 위협하기 위해 341 특허권을 사용했다.^[40] 2007년 12월 21일, 시카고의 특허 변호사 버논 프랜시센은 미국 특허청에 '341 특허'의 유일한 잔여 주장을 새로운 선행기술에 기초하여 재검토해 줄 것을 요청했다.^[41]

2008년 3월 5일, 미국 특허청은 '341 특허'를 재검토하기로 합의하여, 새로운 선행기술이 특허의 유효성과 관련하여 상당한 새로운 문제를 제기한다는 것을 발견했다.^[42] 재심의를 고려해 미 특허청(특허청)의 '341호 특허 심사'가 끝날 때까지 소송 보류(스테이)를 청구한 소송 5건 중 4건이다. 2008년 4월 23일, 일리노이주 시카고에서 두 건의 소송을 주재하는 한 판사가 이 사건들의 소송을 허가했다.^[43] 2008년 7월 22일 특허청은 19개의 별도 근거에 근거하여 청구가 무효라고 판단하여 2차 재심의 「사무처 조치」를 제1호 발행하였다.^[44] 2009년 11월 24일, 모든 청구를 취소하는 재심사 증명서가 발급되었다.

2011년부터 2013년 초까지 동부 텍사스에 ^[45]본사를 둔 프린스턴 디지털 이미지 코퍼레이션으로 알려진 한 회사는 미국 특허 4,813,056건을 침해한 혐의로 많은 회사를 고소하기 시작했다. 프린스턴은 JPEG 이미지 압축 표준이 '056년' 특허를 침해하고 다수의 웹사이트, 소매업체, 카메라 및 장치 제조업체, 리셀러를 고소했다고 주장한다. 이 특허는 원래 제너럴 일렉트릭에 소유되어 할당되었다. 특허는 2007년 12월에 만료되었지만 프린스턴은 이 특허에 대한 "과거 침해"로 많은 기업을 고소했다. (미국 특허법에 따르면, 특허 소유자는 소송 제기 6년 전까지 "과거 침해"로 소송을 제기할 수 있으므로, 프린스턴은 이론적으로 2013년 12월까지 회사를 계속 고소할 수 있다. 프린스턴은 2013년 3월 현재 55개 이상의 회사를 상대로 뉴욕과 델라웨어에 소송이 계류 중이다. 법원 기록에 따르면 2009년 프린스턴에 특허를 배당하고 특허에 대한 일정한 권리를 보유하고 있다고 나와 있지만 제너럴 일렉트릭의 소송 개입 여부는 알려지지 않았다.^[46]

일반적인 사용법

JPEG 압축 알고리즘은 톤과 색상의 매끄러운 변형을 가진 사진과 그림에서 최상으로 작동한다. 컬러 및 그레이스케일 스틸 이미지에는 가장 잘 사용되지만 바이너리 이미지에는 사용되지 않는다. 응답성 프리젠테이션을 위해 이미지에 사용되는 데이터 양을 줄이는 것이 중요한 웹 사용의 경우, JPEG의 압축 이점은 JPEG를 인기 있게 만든다.^[47] JPEG/Exif는 디지털 카메라가 저장하는 가장 일반적인 형식이기도 하다.^[48]

그러나 JPEG는 선 도면과 인접한 픽셀 간의 날카로운 대비가 눈에 띄는 아티팩트를 유발할 수 있는 기타 텍스트 그래픽 또는 상징 그래픽에는 적합하지 않다. 이러한 이미지는 TIFF,^[48] GIF, PNG와 같은 무손실 그래픽 포맷으로 더 잘 저장되며, JPEG 표준은 무손실 코딩 모드를 포함하지만, 다른 무손실 포맷에 비해 압축 방식의 열등감 때문에 많은 제품에서 지원되지 않는다. ISO는 그러한 목적을 위해 JPEG-LS라는 자체적인 파일 형식을 개발했다.^[47]

JPEG는 영상 충실도를 떨어뜨리는 손실 압축 방식이기 때문에 영상 데이터의 정확한 복제(일부 과학 및 의료 영상 애플리케이션, 특정 기술 영상 처리 작업 등)에 적합하지 않다. 또한 JPEG 파일은 이미지를 다시 압축할 때마다 일부 이미지 품질이 손실되므로 여러 편집 작업을 수행하기에 적합하지 않다. 자세한 내용은 디지털 생성 손실 참조. 순차적이고 반복적인 편집 중에 이미지 정보 손실을 방지하기 위해 첫 번째 편집은 무손실 형식으로 저장한 후 그 형식으로 편집한 후 최종적으로 배포를 위해 JPEG로 게시할 수 있다.^[48]

JPEG 압축

JPEG는 이산 코사인 변환(DCT)에 기초한 손실 형태의 압축을 사용한다. 이 수학적 연산은 공간(2D) 영역에서 비디오 소스의 각 프레임/필드를 주파수 영역(예: 변환 도메인)으로 변환한다. 인간의 정신운동적 시스템에 느슨하게 기반을 둔 지각 모델은 고주파 정보, 즉 강도의 급격한 전환과 색조를 무시한다. 변환 도메인에서, 정보를 줄이는 과정을 정량화라고 한다. 간단히 말해서, 정량화는 큰 수 척도(각 숫자의 발생이 서로 다른)를 더 작은 수 척도로 최적으로 줄이는 방법이며, 변환 영역은 다른 계수보다 전체적인 그림에 덜 기여하는 고주파 계수가 특징이기 때문에 이미지를 편리하게 표현하는 방법이다.소형 트럭을 높은 압착성으로 연결하다 그런 다음 정량화된 계수를 시퀀싱하고 출력 비트스트림에 무손실 포장한다. JPEG의 거의 모든 소프트웨어 구현은 사용자가 압축 비율에 대한 사용자 제어(다른 선택적 매개 변수뿐만 아니라)를 허용하므로 사용자는 화질을 작은 파일 크기로 교환할 수 있다. 임베디드 애플리케이션(예: 유사한 DCT-압축 체계를 사용하는 miniDV)에서는 파라미터가 애플리케이션에 대해 미리 선택되고 고정된다.

압축 방법은 일반적으로 손실되므로 원본 영상 정보가 손실되어 복원할 수 없으므로 이미지 품질에 영향을 줄 수 있다. JPEG 표준에 정의된 옵션 무손실 모드가 있다. 그러나 이 모드는 제품에서는 널리 지원되지 않는다.^[47]

또한 데이터가 점진적으로 높은 세부사항의 다중 통과로 압축되는 인터레이스 프로그레시브 JPEG 형식도 있다. 이는 느린 연결을 통해 다운로드하는 동안 표시되는 대형 이미지에 이상적이며, 데이터의 일부만 수신한 후 합리적인 미리보기가 가능하다. 그러나, 진보적인 JPEG에 대한 지원은 보편적이지 않다. 윈도우 7 이전의 Internet Explorer 버전과 같이 이를 지원하지 않는 프로그램에서 프로그레시브 JPEG를 수신하면 소프트웨어는 이미지를 완전히 다운로드한 후에만 표시한다.^[49]

무손실 편집

영상 크기가 1MCU 블록(최소 코드화된 단위)의 배수(보통 양방향 16픽셀, 4:2:0 크로마 서브샘플링의 경우)인 한 JPEG 영상에 대한 많은 변경을 손실 없이 수행할 수 있다. 이를 구현하는 유틸리티는 다음과 같다.

• Jpegtran과 그 GUI인 Jpegcrop.
• IrfanView는 JPG_TRANSFORM 플러그인을 설치해야 하는 "JPG 무손실 크롭(PlugIn)"과 "JPG 무손실 회전(PlugIn)"을 사용한다.
• "Rossless Crop to File" 및 "JPEG Rossless Rotate"를 사용하는 FastStone 이미지 뷰어.
• "JPEG 무손실 변환"을 사용한 XnViewMP.
• ACDSee는 "Force Rossless JPEG operation" 옵션으로 무손실 회전(무손실 JPEG operation)을 지원한다.

블록은 90도 단위로 회전할 수 있으며 수평, 수직, 대각선 축에서 플립할 수 있으며 영상에서 이리저리 이동할 수 있다. 원본 이미지의 모든 블록을 수정된 블록에 사용할 필요는 없다.

JPEG 영상의 상단 및 왼쪽 가장자리는 8 × 8 픽셀 블록 경계 위에 놓여야 하지만 하단 및 오른쪽 가장자리는 그럴 필요가 없다. 이는 가능한 무손실 작물 작업을 제한하며, 하단 또는 오른쪽 가장자리가 모든 채널의 블록 경계 위에 있지 않은 이미지의 플립과 회전을 방지한다(가장자리가 위에서 언급한 바와 같이 블록 경계는 필수 사항이기 때문이다).

(크롬 하위 샘플링에 따라) 영상 너비와 높이가 8 또는 16의 배수가 아닌 회전은 무손실이 아니다. 이러한 이미지를 회전하면 블록이 다시 계산되어 품질이 저하된다.^[50]

무손실 자르기 사용 시, 자르기 영역의 하단 또는 우측이 블록 경계 위에 있지 않을 경우 부분적으로 사용된 블록의 나머지 데이터는 자르기된 파일에 남아 복구될 수 있다. 파일에 계수가 배치되는 순서가 차이뿐이기 때문에 품질 손실 없이 기준선 형식과 프로그레시브 형식 간 변환도 가능하다.

또한, 동일한 품질로 저장되고 가장자리가 블록 경계와 일치한다면, 몇 개의 JPEG 영상은 손실 없이 결합될 수 있다.

JPEG 파일

"JPEG Interchange Format"(JIF)으로 알려진 파일 형식은 이 표준의 부속서 B에 명시되어 있다. 그러나 이러한 "순수" 파일 형식은 주로 표준의 모든 측면을 완전히 구현하는 프로그래밍 인코더와 디코더의 어려움 및 표준의 특정 단점 때문에 거의 사용되지 않는다.

• 색 공간 정의
• 구성 요소 하위 샘플링 등록
• 픽셀 가로 세로 비율 정의.

이러한 문제를 해결하기 위해 몇 가지 추가 표준이 진화되었다. 1992년에 출시된 이 중 첫 번째 것은 JPEG 파일 교환 포맷(또는 JFIF)이었고, 최근에는 Exchangeable 이미지 파일 포맷(Exif)과 ICC 색상 프로필이 그 뒤를 이었다. 이 두 형식 모두 다른 마커로 구성된 실제 JIF 바이트 레이아웃을 사용하지만, 또한 JIF 표준의 확장 지점 중 하나인 응용 프로그램 마커: JFIF는 APP0을 사용하는 반면, Exif는 APP1을 사용한다. JIF 표준에서 향후 사용을 위해 남겨 두었으며, JIF 표준에 의해 읽히지 않은 파일의 이러한 세그먼트 내에서, 이 표준들은 특정 메타데이터를 추가한다.

따라서 JIFF는 어떤 면에서는 일정한 제약조건(모든 다른 인코딩 모드를 허용하지 않는 등)을 명시한다는 점에서 JIF 표준의 축소판인 반면, 어떤 면에서는 추가된 메타데이터로 인한 JIF의 확장판이다. 원본 JFIF 표준에 대한 문서에는 다음과 같이 명시되어 있다.^[51]

JPEG 파일 교환 형식은 JPEG 비트스트림을 다양한 플랫폼과 애플리케이션 간에 교환할 수 있는 최소 파일 형식이다. 이 최소 형식에는 TIFF JPEG 규격에서 찾을 수 있는 고급 기능이나 애플리케이션별 파일 형식이 포함되지 않는다. 또한, 이러한 단순화된 형식의 유일한 목적은 JPEG 압축 영상을 교환하는 것이다.

JPEG 압축을 사용하는 이미지 파일은 일반적으로 "JPEG 파일"이라고 하며, JIF 이미지 형식의 변형으로 저장된다. JPEG를 출력하는 대부분의 이미지 캡처 장치(디지털 카메라 등)는 실제로 카메라 업계가 메타데이터 교환을 위해 표준화한 포맷인 엑시프 포맷으로 파일을 만들고 있다. 한편, Exif 표준은 컬러 프로필을 허용하지 않기 때문에 대부분의 이미지 편집 소프트웨어는 JPEG를 JFIF 형식으로 저장하고, 또한 거의 호환되는 방식으로 메타데이터를 포함시키기 위해 Exif 파일에서 APP1 세그먼트를 포함하고 있다. JFIF 표준은 다소 유연하게 해석된다.^[52]

엄밀히 말하면, 각각 마커 세그먼트(APP0 또는 APP1)를 먼저 표시하도록 지정하기 때문에 JFIF와 Exif 표준은 양립할 수 없다. 실제로 대부분의 JPEG 파일에는 Exif 헤더 앞에 있는 JFIF 마커 세그먼트가 포함되어 있다. 이것은 나이든 독자들이 이전의 형식인 JFIF 세그먼트를 올바르게 다룰 수 있게 하는 반면, 새로운 독자들은 또한 다음 Exif 세그먼트를 디코딩하여, 먼저 나타나도록 요구하는 것에 대해 덜 엄격하다.

JPEG 파일 이름 확장명

JPEG 압축을 사용하는 파일의 가장 일반적인 파일 이름 확장자는 및 , 그러나 .jpe, .jfif 그리고 .jif 또한 사용된다. 또한 JPEG 데이터가 다른 파일 형식에 내장될 수도 있다. TIFF 인코딩된 파일들은 종종 주 이미지의 축소판 그림으로 JPEG 이미지를 포함하고 MP3 파일은 ID3v2 태그에 커버 아트의 JPEG를 포함할 수 있다.

색 프로필

많은 JPEG 파일에는 ICC 색상 프로파일(색상 공간)이 포함되어 있다. 일반적으로 사용되는 색 프로필에는 sRGB와 Adobe RGB가 포함된다. 이러한 색상 공간은 비선형 변환을 사용하기 때문에, 8비트 JPEG 파일의 동적 범위는 약 11 정지다. 감마선을 참조한다.

구문 및 구조

JPEG 영상은 각 마커로 시작하는 일련의 세그먼트로 구성되며, 각 마커는 0xFF 바이트로 시작하고, 그 다음 마커의 종류를 나타내는 바이트로 구성된다. 어떤 마커는 단지 2바이트로 구성되며, 다른 마커는 2바이트(높음에서 낮음)가 뒤따르며, 이는 마커 특유의 페이로드 데이터의 길이를 나타낸다. (길이에는 길이에 대한 2바이트가 포함되지만 마커에 대한 2바이트는 포함되지 않는다.) 일부 마커는 엔트로피 코드 데이터가 뒤따른다. 이러한 마커의 길이는 엔트로피 코드 데이터를 포함하지 않는다. 연속 0xFF 바이트는 패딩을 위한 채우기 바이트로 사용되지만 이 채우기 바이트 패딩은 엔트로피 코드 스캔 데이터 직후 마커에 대해서만 수행되어야 한다(자세한 내용은 JPEG 사양 섹션 B.1.1.2 및 E.1.2 참조). 특히 "압축된 데이터 뒤에 마커가 추가되는 모든 경우 옵션 0xFF 채우기 바이트가 마커 앞에 있을 수 있음").

엔트로피 코드 데이터 내에서는 0xFF 바이트 이후 다음 바이트 이전에 인코더에 의해 0x00 바이트를 삽입하여, 0x00 바이트가 없는 곳에 마커가 나타나지 않도록 하여 프레임 오류를 방지한다. 디코더는 이 0x00 바이트를 건너뛰어야 한다. 바이트 스터핑(JPEG 규격 섹션 F.1.2.3 참조)이라고 하는 이 기법은 페이로드 데이터를 표시하지 않고 엔트로피 코드 데이터에만 적용된다. 그러나 엔트로피 코드화된 데이터에는 고유의 몇 가지 마커가 있다는 점에 유의하십시오. 특히, 병렬 디코딩을 허용하기 위해 엔트로피 코드 데이터의 독립적인 청크를 분리하는 데 사용되는 재설정 마커(0xD0 ~ 0xD7)와 인코더는 이러한 재설정 마커를 정기적으로 삽입할 수 있다(모든 인코더가 이렇게 하는 것은 아님).

다른 종류의 JPEG 인코딩을 도입하는 Start Of Frame 마커도 있다.

여러 벤더가 동일한 APPN 마커 유형을 사용할 수 있으므로 애플리케이션별 마커는 표준 또는 벤더 이름(예: "Exif" 또는 "Adobe") 또는 기타 식별 문자열로 시작하는 경우가 많다.

재시작 마커에서는 블록 대 블록 예측 변수가 재설정되고 비트스트림이 바이트 경계로 동기화된다. 재시작 마커는 신뢰할 수 없는 네트워크를 통한 전송이나 파일 손상과 같은 비트스트림 오류 후 복구 수단을 제공한다. 재시작 마커 사이의 매크로 블록 실행은 독립적으로 디코딩될 수 있으므로, 이러한 실행은 병렬로 디코딩될 수 있다.

JPEG 코덱 예제

JPEG 파일은 다양한 방법으로 인코딩할 수 있지만, 가장 일반적으로 JFIF 인코딩으로 이루어진다. 인코딩 프로세스는 다음과 같은 몇 단계로 구성된다.

1. 영상의 색채 표현은 밝기를 나타내는 1개의 루마 성분(Y')과 색을 나타내는 2개의 크로마 성분(C와_B C_R)으로 구성된 Y′CC로_BR 변환된다. 이 단계는 때때로 건너뛰기도 한다.
2. 크로마 데이터의 분해능은 보통 2 또는 3의 인수로 감소한다. 이는 미세한 밝기 디테일에 비해 미세한 색 디테일에 눈이 덜 민감하다는 점을 반영한 것이다.
3. 영상은 8×8픽셀의 블록으로 분할되며, 각 블록에 대해 Y, C_B, C 데이터는_R 각각 이산 코사인 변환(DCT)을 거친다. DCT는 일종의 공간 주파수 스펙트럼을 생성한다는 점에서 푸리에 변환과 유사하다.
4. 주파수 성분의 진폭을 정량화한다. 인간의 시력은 고주파 밝기 변동의 강도보다 넓은 영역에 대한 색상이나 밝기의 작은 변화에 훨씬 더 민감하다. 따라서 고주파 성분의 크기는 저주파 성분보다 낮은 정확도로 저장된다. 인코더의 품질 설정(예: 독립형 JPEG 그룹의 라이브러리에서^[54] 0–100 척도의 50 또는 95)은 각 주파수 성분의 분해능이 어느 정도 감소하는지에 영향을 미친다. 지나치게 낮은 품질 설정을 사용할 경우 고주파 구성 요소는 모두 폐기된다.
5. 모든 8×8 블록에 대한 결과 데이터는 허프만 인코딩의 변형인 무손실 알고리즘으로 더욱 압축된다.

해독 과정은 되돌릴 수 없기 때문에 정량화를 제외하고 이러한 단계를 역전시킨다. 이 절의 나머지 부분에서는 인코딩 및 디코딩 프로세스가 더 자세히 설명되어 있다.

인코딩

JPEG 표준의 많은 옵션은 일반적으로 사용되지 않으며, 위에서 언급한 바와 같이 대부분의 이미지 소프트웨어는 JPEG 파일을 생성할 때 보다 간단한 JFIF 형식을 사용하며, 무엇보다도 인코딩 방법을 지정한다. 다음은 픽셀당 24비트(빨간색, 녹색, 파란색 각각 8개)의 입력에 적용할 때 보다 일반적인 인코딩 방법 중 하나에 대한 간략한 설명이다. 이 특정 옵션은 손실 데이터 압축 방법이다.

색 공간 변환

첫째, 이미지는 RGB에서 Y′CC_BR(또는 비공식적으로 YCbCr)라고 하는 다른 색 공간으로 변환되어야 한다. Y, C_B, C 세_R 가지 성분을 가지고 있다: Y' 성분은 픽셀의 밝기를 나타내고, C와_B C_R 성분은 색도(파란색 및 적색 성분의 분할)를 나타낸다. 이는 기본적으로 비디오 DVD를 포함한 디지털 비디오뿐만 아니라 디지털 컬러 텔레비전에서 사용되는 색 공간과 동일하며, 아날로그 PAL 비디오와 MAC에서 색상이 표현되는 방식과 유사하다(그러나 YQ 색 공간을 사용하는 아날로그 NTSC에서는 그렇지 않다). Y′CC_BR 색 공간 변환은 지각 영상 화질(또는 동일한 압축에 대한 더 큰 지각 영상 화질)에 큰 영향을 미치지 않고 더 큰 압축을 가능하게 한다. 영상의 궁극적인 지각 품질에 더 중요한 밝기 정보가 단일 채널에 국한되기 때문에 압축이 더 효율적이다. 이것은 인간의 시각 체계에서 색의 지각에 더욱 밀접하게 대응된다. 색 변환은 또한 통계적 장식에 의해 압축을 개선한다.

Y′CC로의_BR 특정 변환은 JFIF 표준에 명시되어 있으며, 결과 JPEG 파일이 최대 호환성을 갖도록 수행되어야 한다. 그러나 "최고 품질" 모드의 일부 JPEG 구현은 이 단계를 적용하지 않고 RGB 색상 모델에 색상 정보를 유지하며,^[55] RGB 색상은 적색, 녹색 및 청색 밝기 구성요소를 위해 별도의 채널에 저장된다. 따라서 압축 효율성이 떨어지고 파일 크기가 특히 중요한 경우에는 사용되지 않을 수 있다.

다운샘플링

인간의 눈에 있는 색과 밝기에 민감한 수용체의 밀도 때문에 인간은 이미지의 색과 색 포화(Cb와 Cr 성분)보다 이미지의 밝기(Y' 성분)에서 상당히 미세한 디테일을 볼 수 있다. 이 지식을 이용하여 인코더는 이미지를 더 효율적으로 압축하도록 설계될 수 있다.

Y′CC_BR 컬러 모델로의 변환은 Cb와 Cr 컴포넌트의 공간 분해능("다운샘플링" 또는 "크롬아 서브샘플링"이라 함)을 감소시키는 다음 통상적인 단계를 가능하게 한다. 일반적으로 JPEG 영상에 대해 다운샘플링이 수행되는 비율은 4:4:4(다운샘플링이 없음), 4:2:2:2(수평방향에서 2배 감소), 또는 (가장 일반적으로) 4:2:0(수평방향과 수직방향 모두에서 2배 감소)이다. 나머지 압축 공정의 경우 Y', Cb, Cr은 매우 유사한 방식으로 별도로 처리된다.

블록 분할

서브샘플링 후 각 채널은 8×8 블록으로 분할해야 한다. 이는 크로마 서브샘플링에 따라 크기가 8×8(4:4:4 – 서브샘플링 없음), 16×8(4:2:2) 또는 가장 일반적으로 16×16(4:2:0)인 최소코드단위(MCU) 블록을 산출한다. 비디오 압축에서 MCU는 매크로블록이라고 불린다.

채널 데이터가 블록의 정수 수를 나타내지 않는 경우 인코더는 불완전한 블록의 나머지 영역을 어떤 형태의 더미 데이터로 채워야 한다. 가장자리를 고정된 색상(예: 검은색)으로 채우면 테두리의 가시적인 부분을 따라 울리는 아티팩트가 생성될 수 있으며, 가장자리 픽셀을 반복하는 것은 그러한 아티팩트를 줄인(그러나 반드시 제거할 필요는 없음) 일반적인 기법이며, 보다 정교한 테두리 채우기 기법도 적용할 수 있다.

이산 코사인 변환

다음으로, 각 구성요소(Y, Cb, Cr)의 8×8 블록은 표준화된 2차원 타입 II 이산 코사인 변환(DCT)을 사용하여 주파수 영역 표현으로 변환된다. 이산 코사인 변환의 인용 1을 참조한다. DCT는 이산 코사인 변환에서와 같이 변환 계열의 맥락에서 "타입-II DCT"라고 부르기도 하며, 해당 역(IDCT)은 "타입-III DCT"로 표시된다.

예를 들어 이러한 8×8 8비트 하위 이미지 중 하나는 다음과 같을 수 있다.

8×8 블록의 DCT를 계산하기 전에 그 값은 양의 범위에서 0을 중심으로 한 값으로 이동한다. 8비트 이미지의 경우 원본 블록의 각 항목은${\displaystyle }$[ ${\displaystyle 0,}$ ${\displaystyle 255}$ ${\displaystyle ]}$ ${\displaystyle [0,255]}$ 범위에 속한다$.$ 범위의 중간점(이 경우, 값 128)을 각 항목에서 빼서 0을 중심으로 하는 데이터 범위를 생성하므로 수정된 범위는${\displaystyle }[{\displaystyle }$ - ${\displaystyle 128,}$ ${\displaystyle 127}$ ${\displaystyle ]}$ ${\displaystyle$[-$128,127]}$이다$.$ 이 단계는 다음과 같은 DCT 처리 단계의 동적 범위 요구사항을 감소시킨다.

이 단계에서는 다음과 같은 값이 발생한다.

다음 단계는 다음과 같은 2차원 DCT를 취하는 것이다.

어디에

• ${\displaystyle u}$ ${\displaystyle$\$u}$은(는) 0 < 8 $[\displaystyle$\$0\leq u <8}$에 대한 수평 공간 주파수 입니다
• ${\displaystyle v}$ ${\displaystyle$\$v}$은(는) 0 v< $[\displaystyle$\ 0$\leq v<8}$에 대한 수직 공간 주파수 입니다
• )={ = 0 이면$displaystyle$\$\(u)={\precent{case}{\frac$ {1}{\sqrt{$2}}},&\mbox{}}}}}$는 변환을 정형화하는 정규화된 척도 계수다$.$
• ${\displaystyle g_{}}$ ${\displaystyle x_{}}$, ${\displaystyle y_{}}$ ${\$\$g_{x,y}$는 ${\displaystyle \mathrm{좌표}}$(x , ${\displaystyle y}$) $displaystyle$\$(x,y)}$의 픽셀 값이다${\displaystyle .}$
• ${\displaystyle G_{}}$ ${\displaystyle u_{}}$, ${\displaystyle v_{}}$ ${\$\$G_{u,v}}$은(u${\displaystyle }$,${\displaystyle v}$ ) 좌표에서의 DCT 계수다. ${\displaystyle \ (u,v).$$}$

위의 행렬에서 이 변환을 수행하면 다음과 같은 결과가 나온다(소수점 이상으로 가장 가까운 두 자리까지 반올림).

좌측 상단 모서리에 약간 큰 크기의 항목을 기록해 두십시오. 이것은 전체 블록에 대한 기본 색조를 정의하는 DC 계수(상수 성분이라고도 함)이다. 나머지 63개의 계수는 교류 계수(교대 성분이라고도 함)^[56]이다. DCT의 장점은 위에서 볼 수 있는 것처럼 결과의 한쪽 구석에 대부분의 신호를 집계하는 경향이다. 뒤따르는 정량화 단계는 DCT 계수의 전체 크기를 줄이는 동시에 이러한 효과를 강조하여 엔트로피 단계에서 효율적으로 압축하기 쉬운 신호를 발생시킨다.

DCT는 8비트/구성 요소 이미지의 DCT 계수가 (DCT 계산의 충실도에 따라) 저장하기 위해 최대 11비트 이상을 차지하기 때문에 데이터의 비트 깊이를 일시적으로 증가시킨다. 이로 인해 코덱이 일시적으로 16비트 숫자를 사용하여 이러한 계수를 보유하게 되어 이 시점에서 이미지 표현 크기가 두 배가 될 수 있다. 이러한 값은 일반적으로 정량화 단계에 의해 다시 8비트 값으로 축소된다. 일반적으로 이미지 인코딩 또는 디코딩 프로세스 중 주어진 시간에 영상의 매우 작은 부분만 전체 DCT 형태로 저장되기 때문에 이 단계에서 일시적으로 크기가 증가하는 것은 대부분의 JPEG 구현의 성능 문제가 아니다.

수량화

사람의 눈은 비교적 넓은 부위에 비해 밝기의 차이가 작은 것은 잘 보이나 고주파 밝기 변동의 정확한 강도를 구분하는 데는 그다지 능숙하지 않다. 이를 통해 고주파 구성 요소의 정보량을 크게 줄일 수 있다. 이것은 주파수 영역의 각 구성요소를 해당 구성요소에 대한 상수로 나눈 다음 가장 가까운 정수로 반올림하는 것만으로 이루어진다. 이 반올림 연산은 DCT 연산이 충분히 높은 정밀도로 수행될 경우 전체 공정에서 유일한 손실 연산이 된다(크롬 서브샘플링 제외). 그 결과, 일반적으로 고주파 성분의 다수가 0으로 반올림되고, 나머지는 작은 양수나 음수가 되어, 나타내기 위해 많은 비트가 적게 든다.

정량화 매트릭스의 요소는 압축비를 제어하며, 값이 클수록 압축이 커진다. 일반적인 정량화 매트릭스(원래 JPEG 표준에 명시된 50% 품질의 경우)는 다음과 같다.

계량화된 DCT 계수는 다음을 통해 계산된다.

여기서 $G{\displaystyle }$ ${\displaystyle G}$은(는) 미정량 DCT 계수, Q ${\displaystyle Q}$은(는) 위의 정량화 행렬, B ${\displaystyle B}$은(는) 정량화된 DCT 계수다.

위의 DCT 계수 행렬과 함께 이 정량화 행렬을 사용하면 다음과 같은 결과를 얻을 수 있다.

예를 들어 -415(DC 계수) 사용 및 가장 가까운 정수로 반올림

하위 블록의 고주파 원소(즉, 공간 주파수가 4보다 큰 x 또는 y)는 대부분 0 값으로 정량화된다.

엔트로피 부호화

엔트로피 코딩은 무손실 데이터 압축의 특별한 형태다. 유사한 주파수를 함께 묶는 RLE(Run-Length Encryption) 알고리즘을 채택한 '지그재그' 순서로 영상 구성요소를 배열하고, 길이 코딩 0을 삽입한 뒤 남은 부분에 허프먼 코딩을 사용하는 것이 포함된다.

JPEG 표준은 또한 디코더가 허프만 코딩보다 수학적으로 우위에 있는 산술 코딩의 사용을 지원할 수 있도록 허용하지만 필요하지 않다. 그러나 역사적으로 로열티 부담 라이선스가 필요한 특허에 가려져 있었고, 허프만 코딩에 비해 인코딩과 디코딩이 느리기 때문에 이 기능은 거의 사용되지 않았다. 산술 코딩은 일반적으로 파일을 약 5~7% 작게 만든다.

이전의 정량화된 DC 계수는 현재 정량화된 DC 계수를 예측하는 데 사용된다. 둘의 차이는 실제 값보다 인코딩되어 있다. 63 정량화된 AC 계수의 인코딩은 그러한 예측 차이점을 사용하지 않는다.

위의 정량화된 계수에 대한 지그재그 시퀀스는 아래와 같다. (표시된 형식은 이해/보기의 용이성을 위한 형식일 뿐이다.)

If the i-th block is represented by ${\displaystyle B_{i}}$ and positions within each block are represented by ${\displaystyle (p,q)}$, where ${\displaystyle p=0,1,...,7}$ and ${\displaystyle q=0,1,...,7}$, then any coefficient in the DCT image can be represented as ${\displaystyle B_{i}(p,q)}$. Thus, in the above scheme, the order of encoding pixels (for the i-th block) is ${\displaystyle B_{i}(0,0)}$, ${\displaystyle B_{i}(0,1)}$, ${\displaystyle B_{i}(1,0)}$, ${\displaystyle B_{i}(2,0)}$$$, ${\displaystyle B_{i}(1,1)}$, ${\displaystyle B_{i}(0,2)}$, ${\displaystyle B_{i}(0,3)}$, ${\displaystyle B_{i}(1,2)}$ and so on.

이 인코딩 모드를 기준선 순차 인코딩이라고 한다. 기준선 JPEG는 진행 인코딩도 지원한다. 순차 인코딩은 한 번에 한 블록의 계수를 인코딩하는 반면(지그재그 방식으로), 프로그레시브 인코딩은 한 번에 모든 블록의 유사한 위치의 계수 배치를 인코딩하고(스캔이라고 함), 그 다음에 모든 블록의 계수 등의 다음 배치를 인코딩한다. For example, if the image is divided into N 8×8 blocks ${\displaystyle B_{0},B_{1},B_{2},...,B_{n-1}}$, then a 3-scan progressive encoding encodes DC component ${\displaystyle B_{i}(0,0)}$ for all blocks (i.e., for all ${\displaystyle$$i=0,1,2,...,N-1},$ 첫 번째 검색$).$ 이후 2차 스캔이 진행되는데, $Bi{\displaystyle {}_{}}$ (${\displaystyle 0}$, ${\displaystyle 1}$ ) B i (1${\displaystyle }$)$${\$displaystyle B_{i$} ($0,1)}$에서 ${\displaystyle \mathrm{Bi}{}_{}}$(1,${\displaystyle 1}$) ${\displaystyle B_{i}$ (1$,1)}$까지 여전히$$ 지그재그 방식으로 인코딩된다$.$ At this point, the coefficient sequence is: ${\displaystyle B_{0}(0,1),$$B_{0}(1,0),B_{0}(2,0),B_{0}(1,1),B_{1}(0,1),$$B_{1$}(1$,0), ...,B_{N}(2,0),B_{N}(1,1}),$ $$그 다음에 마지막 스캔에서 모든 블록의 나머지 계수가 나타난다.

모든 유사 위치 계수가 인코딩되면 인코딩되는 다음 위치는 위 그림에 표시된 지그재그 횡방향에서 다음에 발생하는 위치다. 차이가 너무 크지는 않지만, 각 "스캔" 또는 "통과"(비슷한 위치 계수를 포함)에서 서로 다른 주파수에 맞게 조정된 서로 다른 허프만 테이블(아래 참조)을 사용할 수 있기 때문에 기준선 순차 JPEG에 비해 베이스라인 JPEG 인코딩이 더 나은 압축을 제공하는 것으로 밝혀졌다.

글의 나머지 부분에서는 생성된 계수 패턴이 순차적 모드에 기인한다고 가정한다.

위에서 생성된 계수 패턴을 인코딩하기 위해 JPEG는 허프먼 인코딩을 사용한다. 인코더가 인코딩되는 이미지에서 실제 주파수 분포에 최적화된 허프만 테이블을 동적으로 생성하도록 선택할 수도 있지만, JPEG 표준은 범용 허프만 테이블을 제공한다.

지그재그로 정량화된 데이터를 인코딩하는 프로세스는 런 길이 인코딩으로 시작한다. 여기서:

• x는 0이 아닌 정량화된 AC 계수다.
• RUNLENTH는 이 0이 아닌 AC 계수 이전에 발생한 0의 수입니다.
• SIZE는 x를 나타내는 데 필요한 비트 수입니다.
• 진폭은 x의 비트 표현이다.

런 길이 인코딩은 0이 아닌 각 AC 계수 x를 검사하고 이전 AC 계수 이전에 0이 얼마나 왔는지 결정함으로써 작동한다. 이 정보를 사용하여 다음과 같은 두 가지 기호가 생성된다.

RUNLENT와 SIZE는 모두 동일한 바이트에 위치하며, 각각은 4비트의 정보만을 포함하고 있다는 것을 의미한다. 높은 비트는 0의 수를 다루는 반면, 낮은 비트는 x의 값을 인코딩하는 데 필요한 비트 수를 나타낸다.

이는 기호 1이 0이 아닌 AC 계수 앞에 있는 처음 15개의 0에 관한 정보만 저장할 수 있다는 것을 즉시 시사한다. 그러나 JPEG는 두 개의 특별한 허프만 코드 단어를 정의한다. 하나는 나머지 계수가 0일 때("차단 끝" 또는 "EOB"라고 함) 시퀀스를 조기 종료하는 것이고, 다른 하나는 0이 아닌 AC 계수에 도달하기 전에 0의 런이 15를 초과할 때 입니다. 주어진 0이 아닌 AC 계수 이전에 16개의 0이 발생하는 경우 기호 1은 (15, 0)(0)으로 인코딩된다.

전체 프로세스는 (0, 0)으로 표시된 "EOB"에 도달할 때까지 계속된다.

이를 염두에 두고 아까의 순서는 다음과 같이 된다.

• (0, 2)(-3);(1, 2)(-3);(0, 1)(-2);(0, 2)(-6);(0, 1)(2);(0, 1)(-4);(0, 1)(1);(0, 2)(-3);(0, 1)(1);(0, 1)(1);
• (0, 2)(5);(0, 1)(1);(0, 1)(2);(0, 1)(-1);(0, 1)(1);(0, 1)(-1);(0, 1)(2);(5, 1)(-1);(0, 1)(-1);(0, 0);

(행렬의 첫 번째 값인 -26은 DC 계수로서, 같은 방법으로 인코딩되지 않는다. 위 참조)

여기서부터 계수의 발생을 기준으로 주파수 계산이 이루어진다. 이 예제 블록에서 정량화된 계수의 대부분은 0 계수가 바로 앞에 있지 않은 작은 숫자들이다. 이런 빈도가 높은 경우는 짧은 암호 단어로 표현될 것이다.

압축비 및 아티팩트

그 결과 압축 비율은 정량화 단계에서 사용되는 칸막이에서 어느 정도 공격적이면 필요에 따라 변화할 수 있다. 10 대 1의 압축은 대개 원본과 눈으로 구분할 수 없는 이미지를 낳는다. 압축비 100:1은 보통 가능하지만 원본에 비해 뚜렷하게 인공적으로 보일 것이다. 적절한 압축 수준은 이미지를 배치할 용도에 따라 달라진다.

월드 와이드 웹을 사용하는 사람들은 JPEG 영상에 나타나는 압축 아티팩트로 알려진 불규칙성에 익숙할 수 있으며, 이는 대조되는 가장자리(특히 곡선과 코너), 또는 "막힘" 영상에 대한 노이즈의 형태를 취할 수 있다. 이는 JPEG 알고리즘의 정량화 단계 때문이다. 그것들은 특히 대조적인 색들 사이의 날카로운 모서리를 중심으로 눈에 띈다. (텍스트는 그러한 모서리를 많이 포함하고 있기 때문에 좋은 예다.) MPEG 영상에 있는 유사한 공예품들은 모기 소음이라고 일컬어지는데, 그 결과 "가장자리 분주함"과 시간이 지남에 따라 변하는 가짜 점들이 물체 주위로 몰려드는 모기를 닮았기 때문이다.^[57][58]

이러한 아티팩트는 더 낮은 수준의 압축을 선택하여 줄일 수 있으며, 파일 크기가 더 커지더라도 무손실 파일 형식을 사용하여 이미지를 저장함으로써 완전히 피할 수 있다. 레이트레이싱 프로그램으로 만들어진 이미지들은 지형에 눈에 띄게 막힌 모양을 하고 있다. 특정 저강도 압축 아티팩트는 단순히 영상을 볼 때 허용될 수 있지만 영상이 후속적으로 처리될 경우 강조될 수 있으며, 일반적으로 허용 불가능한 품질을 초래한다. 아래 예를 들어, 가장자리 감지 처리 단계에 대한 압축 손실 효과를 입증하십시오.

일부 프로그램에서는 사용자가 개별 블록을 압축하는 양을 변경할 수 있다. 아티팩트가 더 적은 이미지 영역에 더 강력한 압축이 적용된다. 이러한 방식으로 JPEG 파일 크기를 수동으로 줄일 수 있으며 품질 손실은 줄일 수 있다.

정량화 단계는 항상 정보의 손실을 초래하기 때문에 JPEG 표준은 항상 손실 압축 코덱이다. (정량화와 반올림에서 정보는 모두 손실된다.) 정량화 매트릭스가 하나의 매트릭스라고 해도 라운딩 단계에서 정보는 여전히 손실된다.

디코딩

영상을 표시하기 위해 디코딩하는 것은 위의 모든 것을 역순으로 하는 것으로 구성된다.

DCT 계수 행렬 가져오기(DC 계수의 차이를 다시 추가한 후)

위로부터 정량화 매트릭스와 함께 엔트리 제품(inter-for-inter)을 획득한 결과

왼쪽 상단 부분의 원래 DCT 계수 행렬과 매우 유사하다.

다음 단계는 다음과 같은 2차원 역 DCT(2D 유형-III DCT)를 취하는 것이다.

어디에

• ${\displaystyle x}$ ${\displaystyle$\$x}$은(는) 정수 < ${\displaystyle$\$0\leq$ x$<8}$에 대한 픽셀 행입니다
• ${\displaystyle y}$ ${\displaystyle$\$y}$은(는) 정수 < $[\displaystyle$\$0\leq$ y$<8}$에 대한 픽셀 열입니다
• ${\displaystyle \alpha }$ (${\displaystyle u}$ )$${\$displaystyle \alpha$ ($u)}$은(는) 정수 < ${\displaystyle$\ 0$\leq$u$<8$에 대해 위와 같이 정의된다$$.
• ${\displaystyle F_u}$ , ${\displaystyle v_{}}$ ${\$\$F_{u,v}}$은(${\displaystyle u}$, ${\displaystyle v}$) 좌표에서 재구성된 근사 계수다${\displaystyle$\$(u,v).$$}$
• ${\displaystyle f_{}}$ ${\displaystyle x_{}}$, ${\displaystyle y_{}}$ ${\$\$f_{x,y}$는 ${\displaystyle \mathrm{좌표}}$(x ,${\displaystyle }$y${\displaystyle }$) ${\displaystyle$ \ (x$,y)}$에서 재구성된 픽셀 값이다$$.

출력을 정수 값으로 반올림하면(원본에 정수 값이 있기 때문에) 값이 있는 이미지가 생성됨(128만큼 아래로 이동됨)

각 항목에 128개 추가

이것은 압축이 풀린 아비상이다. 일반적으로 감압 공정은 원래 입력 범위인${\displaystyle }$[ ${\displaystyle 0,}$ ${\displaystyle 255}$] ${\displaystyle [0,255]$을 벗어나 값을 생성할 수 있다$.$ 이렇게 되면 디코더는 원래 비트 깊이와 함께 감압된 영상을 저장할 때 오버플로를 방지하기 위해 출력 값을 해당 범위 내에 유지할 수 있도록 잘라내야 한다.

압축 해제된 하위 이미지는 다음과 같은 오류 값으로 차이(원본 - 압축되지 않은) 결과를 취함으로써 원본 하위 이미지와 비교할 수 있다(오른쪽에 있는 영상도 참조).

픽셀당 평균 약 5개의 절대 오차(예: 1 ${\displaystyle \frac{64}{}}$ ${\displaystyle \sum \underset{}{\overset{}{}}}$ ${\displaystyle \underset{}{\overset{}{x}}}$= 0 ${\displaystyle \underset{}{\overset{}{\mathrm{}}}}$ ${\displaystyle \underset{}{\overset{}{}}\underset{}{\overset{}{}}}$ y${\displaystyle \underset{}{\overset{}{}}}$= ${\displaystyle \underset{}{\overset{}{0}}}$ ${\displaystyle \underset{}{\overset{}{\mathrm{}}}}$ ${\displaystyle e\underset{}{\overset{}{}}}$( ${\displaystyle x}$, y${\displaystyle }$)${\displaystyle }$= 4${\displaystyle .8750}$ ${\frac$ 스타일 ${\\frac {1}{64}}\sum$_{$x=0}^{7}\sum$_{$y=0}^{7} e(x,y) =4.8750}).$

이 오류는 바로 오른쪽에 있는 픽셀보다 하단 왼쪽 픽셀이 어두워지는 하단 왼쪽 모서리에서 가장 눈에 띈다.

필수정밀도

인코딩 및 디코딩 적합성, 따라서 정밀도 요건은 ISO/IEC 10918-2, 즉 JPEG 규격의 파트 2에 명시되어 있다. 예를 들어, 이 규격은 시험 대상 JPEG 구현의 영상에서 형성된 (위방향 변환) DCT 계수에 기준 계수와 비교하여 하나의 정량화 버킷 정밀도 내에 있는 오류가 있어야 한다. 이를 위해 ISO/IEC 10918-2는 코드스트림이 디코딩해야 하는 DCT 계수뿐만 아니라 테스트 스트림을 제공한다.

마찬가지로 ISO/IEC 10918-2는 인코더 정밀도를 DCT 도메인에서 최대 허용 오차 관점에서 정의한다. 이것은 많은 다른 표준들이 디코더 적합성만 정의하고 인코더에게 구문론적으로 올바른 코드스트림을 생성하도록 요구할 때까지만 요구하기 때문에 매우 이례적이다.

ISO/IEC 10918-2에서 발견된 테스트 영상은 (pseudo-) 무작위 패턴으로 최악의 경우를 확인한다. ISO/IEC 10918-1은 컬러스페이스를 정의하지 않으며, JFIF(현재의 ISO/IEC 10918-5)의 YCbCr to RGB 변환도 포함하지 않기 때문에 후자 변환의 정밀도는 ISO/IEC 10918-2로 테스트할 수 없다.

픽셀 구성요소 출력당 8비트 정밀도를 지원하기 위해, 디퀀티화와 역 DCT 변환은 일반적으로 최적화된 디코더에서 최소 14비트 정밀도로 구현된다.

JPEG 압축 효과

JPEG 압축 아티팩트는 세부적인 균일하지 않은 질감이 있는 사진과 잘 어우러져 높은 압축 비율을 허용한다. 높은 압축 비율이 영상의 왼쪽 상단 모서리에 있는 고주파 질감에 먼저 어떤 영향을 미치는지, 대조되는 선이 어떻게 더 흐릿해지는지 주목하십시오. 비록 전체적인 색상과 이미지 형태가 여전히 알아볼 수 있지만, 매우 높은 압축 비율은 이미지의 품질에 심각한 영향을 미친다. 그러나 색의 정밀도는 등고선의 정밀도(휘도 기준)보다 (인간의 눈에는) 덜 고생한다. 이것은 더 많은 정보 비트로 휘도 평면의 정밀도를 보존하기 위해 색도 평면을 서브샘플링하기 전에, 먼저 영상이 색도 정보로부터 휘도를 분리하는 색상 모델에서 변환되어야 한다는 사실을 정당화한다.

샘플 사진

정보의 경우, 압축되지 않은 24비트 RGB 비트맵 이미지(73,242픽셀)는 219,726바이트(다른 모든 정보 헤더 제외)가 필요하다. 아래에 표시된 파일화에는 내부 JPEG 정보 헤더와 일부 메타데이터가 포함된다. 최고 화질 영상(Q=100)의 경우 컬러 픽셀당 약 8.25비트가 필요하다.^{[citation needed]} 그레이스케일 영상의 경우 픽셀당 최소 6.5비트로 충분하다(비슷한 Q=100 퀄리티 컬러 정보에 인코딩된 비트가 약 25% 더 필요하다). 아래의 최고 화질 영상(Q=100)은 컬러 픽셀당 9비트로 인코딩되며, 중 화질 영상(Q=25)은 컬러 픽셀당 1비트를 사용한다. 대부분의 어플리케이션의 경우, 화질 계수가 낮은 화질 영상에서 입증된 것처럼 화소당 0.75비트(Q=12.5) 이하로 내려가서는 안 된다. 화질이 낮은 이미지는 픽셀당 0.13비트만 사용하고, 색상은 매우 불량하다. 이것은 영상이 상당히 축소된 크기로 표시될 때 유용하다. Q 인자 대신 PSNR을 사용하여 주어진 영상 화질에 대해 더 나은 정량화 매트릭스를 만드는 방법은 Minguillon & Pujol(2001)에 설명되어 있다.^[59]

중급 화질 사진은 압축되지 않은 이미지에 필요한 저장 공간의 4.3%만 사용하지만 디테일이나 가시적인 아티팩트가 눈에 띄게 손실되는 경우는 거의 없다. 그러나 압축의 특정 임계값이 통과되면 압축된 이미지는 점점 더 가시적인 결함을 보여준다. 이 임계값 효과에 대한 수학적 설명은 비율-분산 이론에 대한 기사를 참조하십시오. 이와 관련하여 JPEG의 특별한 한계는 오버랩되지 않은 8×8 블록 변환 구조다. JPEG 2000 및 JPEG XR과 같은 보다 현대적인 디자인은 비트 사용량이 감소함에 따라 더욱 우아한 품질 저하를 보인다 – 낮은 주파수 계수에 대해 공간 범위가 더 큰 변환을 사용하고 중복된 변환 기준 함수를 사용함으로써.

무손실 추가 압축

2004년부터 2008년까지 JPEG 영상에 포함된 데이터를 표시된 영상을 수정하지 않고 추가로 압축하는 방법에 대한 새로운 연구가 등장했다.^{[60][61][62][63]} 이것은 JPEG 형식으로만 원본 영상을 사용할 수 있는 시나리오의 어플리케이션을 가지고 있으며, 보관이나 전송을 위해 그 크기를 줄여야 한다. 표준 범용 압축 도구는 JPEG 파일을 크게 압축할 수 없다.

일반적으로 그러한 계획은 DCT 계수를 코딩하기 위한 순진한 계획의 개선을 이용하는데, 이는 다음과 같은 점을 고려하지 못한다.

• 동일한 블럭에서 인접한 계수의 크기 간의 상관 관계
• 인접한 블럭에서 동일한 계수의 크기 간의 상관 관계
• 서로 다른 채널에서 동일한 계수/블록의 크기 간의 상관 관계
• 함께 찍은 DC 계수는 원래 영상에 스케일링 계수를 곱한 다운스케일 버전과 유사하다. 연속 톤 영상의 무손실 코딩을 위한 잘 알려진 체계를 적용할 수 있으며, JPEG에서 사용되는 허프만 코딩 DPCM보다 다소 나은 압축을 달성할 수 있다.

일부 표준이지만 거의 사용되지 않는 옵션은 이미 JPEG에 존재하여 DCT 계수의 코딩 효율을 향상시키고 있다: 산술 코딩 옵션과 프로그레시브 코딩 옵션(각 계수의 값이 독립적으로 코딩되고 각 계수의 분포가 유의하게 다르기 때문에 비트 전송률이 낮아진다). 근대적 제어 학교 수법. 이러한 기술에 더 큰 규모의 그룹 계수에 계수가 저장되어 있는 순서에 의해;[60] 새로운 계수 값을 예측하기 위해 인접한 계수 및 블록을 이용하여, 독립적으로 코딩되어 모델들은 그들의 통계와 인접한 값을 바탕으로 한 작은 숫자였을 것이다;[61][62]중[62] 나누는 장애나 계수를 향상시켰습니다.그리고 가장 일어나tly, 블록을 디코딩하고, 공간 영역의 후속 블록을 예측한 다음, 인코딩하여 DCT 계수에 대한 예측을 생성한다.^[63]

일반적으로 그러한 방법은 기존 JPEG 파일을 15~25% 압축할 수 있으며, 저품질 설정으로 압축된 JPEG의 경우 최대 65%^[62][63]의 개선 효과를 낼 수 있다.

packJ라는 자유롭게 사용할 수 있는 도구PG는 2007년 논문 "JPEG 파일의 중복성 감소 개선"^[64]을 기반으로 한다. ISO libjpeg를 사용한 "JPEG on 스테로이드"라는 제목의 2016년 논문은 손실 여부와 상관없이 현재의 기법이 JPEG XR만큼 JPEG를 효율적으로 만들 수 있다는 것을 보여준다.; mozjpeg는 유사한 기법을 사용한다.^[65] JPEG XL은 JPEG로의 효율적인 백 변환으로 JPEG를 무손실 재인코딩할 수 있는 새로운 파일 형식이다.

파생 형식

입체 3D용

JPEG 입체영상

JPEG Stereoscopic(JPS, 확장자 .jps)은 JPEG 기반의 입체 영상 형식이다.^[66][67] JPEG APP3 마커 필드에 저장되는 구성 범위를 가지지만 대개 이중 너비의 이미지 하나를 포함하고 있으며, 이는 동일한 크기의 두 이미지를 십자형(이미지 오른쪽 절반의 왼쪽 프레임과 그 반대쪽)으로 나란히 배열한 것이다. 이 파일 형식은 특별한 소프트웨어 없이 JPEG로 볼 수도 있고, 다른 모드에서 렌더링을 위해 처리할 수도 있다.

JPEG 다중 사진 형식

JPEG Multi-Picture Format(MPO, 확장명 .mpo)은 여러 개의 영상을 하나의 파일에 저장하는 JPEG 기반 형식이다. 여기에는 두 개 이상의 JPEG 파일이 함께 연결되어 있다.^[68][69] 또한 영상 설명을 위해 JPEG APP2 마커 세그먼트를 정의한다. Various devices use it to store 3D images, such as Fujifilm FinePix Real 3D W1, HTC Evo 3D, JVC GY-HMZ1U AVCHD/MVC extension camcorder, Nintendo 3DS, Sony PlayStation 3,^[70] Sony PlayStation Vita,^[71] Panasonic Lumix DMC-TZ20, DMC-TZ30, DMC-TZ60, DMC-TS4 (FT4), and Sony DSC-HX7V. TV에 표시할 수 있는 "이미지 미리보기"를 저장하는 데 사용하는 장치도 있다.

최근 몇 년간 입체영상의 사용이 증가함에 따라 과학계는 입체영상 압축 알고리즘 개발에 많은 노력을 기울였다.^[72][73]

JPEG XT

JPEG XT(ISO/IEC 18477)는 2015년 6월에 발행되었으며, 더 높은 정수 비트 깊이(최대 16비트), 고다이나믹 레인지 영상 및 부동 소수점 코딩, 무손실 코딩, 알파 채널 코딩 등을 지원하여 기본 JPEG 포맷을 확장하였다. 확장자는 기본 JPEG/JFIF 파일 형식 및 8비트 손실 압축 이미지와 역호환된다. JPEG XT는 JFIF를 기반으로 확장 가능한 파일 형식을 사용한다. 확장 계층은 JPEG 8비트 기본 계층을 수정하고 고해상도 이미지를 복원하는 데 사용된다. 기존 소프트웨어는 기본 8비트 계층만 디코딩할 수 있지만, 정방향 호환성이 있고 JPEG XT 이진 스트림을 읽을 수 있다.^[74]

호환되지 않는 JPEG 표준

공동사진 전문가 그룹은 또한 JPEG 2000, JPEG XR, JPEG XS를 포함하여 JPEG 이름을 포함한 일부 다른 형식을 담당한다.

JPEG XL

JPEG XL은 JPEG에 비해 압축 효율성이 우수하고 현대적인 기능을 갖춘 또 다른 포맷이다.^[75] HEVC HM, Dala 및 WebP가 보여준 스틸 이미지 압축 성능을 초과하도록 설계되었으며, JPEG를 대체하려는 이전의 노력과는 달리 기존 JPEG 이미지에 대해 보다 효율적인 압축 전송 및 스토리지 옵션을 제공하고자 하였다. 형식은 JPEG 디코더와 직접 호환되지 않는다. 기존 JPEG 비트스트림을 복원하려면 트랜스코딩 단계를 수행해야 한다.^[76][77][78]

구현

JPEG 코덱의 매우 중요한 구현은 독립형 JPEG 그룹의 무료 프로그래밍 라이브러리 libjpeg이었다. 1991년에 처음 출판되어 표준의 성공을 위한 열쇠가 되었다.^[79] 최근 버전은 이전 버전과의 ABI 호환성을 깬 독점적 확장을 도입한다. 많은 저명한 소프트웨어 프로젝트에서 libjpeg는 더 높은 성능, SIMD 호환성 및 원래의 libjpeg 버전과의 역호환성을 제공하는 libjpeg-turbo로 대체되었다.^[80]

구글은 2017년 3월 더 긴 인코딩 시간을 작은 파일 크기(PNG 및 기타 무손실 데이터 형식에 대해 Zopfli가 하는 것과 유사)로 맞바꾸는 오픈소스 프로젝트 Guetzli를 출시했다.^[81]

ISO/IEC 공동사진 전문가 그룹은 기본 JPEG(ISO/IEC 10918-1 및 18477–1)와 JPEG XT 확장(ISO/IEC 18477 Part 2 및 6–9)과 JPEG-LS(ISO/IEC 14495)를 모두 인코딩할 수 있는 참조 소프트웨어 구현을 유지하고 있다.^[82]

참고 항목

• 에이비프
• 더 나은 휴대용 그래픽, HEVC의 프레임 내부 인코딩을 기반으로 하는 형식
• 칩 형태로 JPEG를 초기 구현한 C-Cube
• 그래픽 파일 형식 비교
• 레이아웃 엔진 비교(그래픽)
• Deblocking 필터(비디오), 유사한 Deblocking 방법을 JPEG에 적용할 수 있음
• 카메라 파일 시스템(DCF)의 설계 규칙
• 파일 확장명
• 그래픽 편집 프로그램
• 고효율 이미지 파일 형식, HEVC용 이미지 컨테이너 형식 및 기타 이미지 코딩 형식
• JPEG 파일 교환 형식
• 이미지 처리 알고리즘을 테스트하는 데 사용되는 기존의 표준 이미지인 Lenna(테스트 이미지)
• 무손실 이미지 코덱 FELICS
• 모션 JPEG

참조

외부 링크

• JPEG Standard(JPEG ISO/IEC 10918-1 ITU-T 권장 T.81) W3.org
• 공식 공동 사진 전문가 그룹(JPEG) 사이트
• JFIF 파일 형식(W3.org
• Python 코드를 이해하기 쉬운 250줄의 JPEG 뷰어
• 단일 C++ 소스 파일의 공용 도메인 JPEG 압축기와 code.google.com에서 일치하는 압축 해제기
• JPEG 디코더 오픈 소스 코드, 저작권 (C) 1995–1997, Thomas G. Lane