JPEG

http://www.jpeg.org/jpeg/ CT 스캔에 대한 연속적인 JPEG 압축 (Q=100과 Q=1 사이)]] **제이펙**([ˈdʒeɪpɛɡ], 합동사진전문가단체북한자료센터: 남북한 IT용어 비교url=http://unibook.unikorea.go.kr/?cate=1⊂_num=50&pageNo;=53)url-status=liveurl-status=live은 디지털 이미지, 특히 디지털 사진으로 생성된 이미지에 일반적으로 사용되는 손실 압축 방식이다. 압축 정도를 조절할 수 있어 저장 크기와 화질 간의 균형을 선택할 수 있다. JPEG는 일반적으로 이미지 품질에서 눈에 띄지만 널리 용인되는 손실과 함께 10:1 압축을 달성한다.quote=The JPEG still-image-compression levels, even with the large range of 5:1 to 120:1 in this study, yielded equally high levels of acceptability 1992년 도입된 이래 JPEG는 세계에서 가장 널리 사용되는 이미지 압축 표준이자last=Svetlik 가장 널리 사용되는 디지털 이미지 파일 형식으로, 2015년 기준 매일 수십억 개의 JPEG 이미지가 생성된다.url-status=live 공동 사진 전문가 그룹은 1992년 이산 코사인 변환(DCT) 알고리즘을 기반으로 표준을 만들었다.trans-title=JPEG: 25 years (old) and not a bit oldpublisher=CCITTlanguage=de JPEG는 인터넷과 이후 소셜 미디어 전반에 걸쳐 디지털 이미지와 디지털 사진의 확산에 크게 기여했다.url-access=limited JPEG 압축은 여러 이미지 파일 형식에서 사용된다. JPEG/Exif는 디지털 카메라 및 기타 사진 이미지 캡처 장치에서 사용하는 가장 일반적인 이미지 형식이다. JPEG/JFIF와 함께 월드 와이드 웹에서 사진 이미지를 저장하고 전송하는 가장 일반적인 형식이다.access-date=2016-04-06 이러한 형식 변형은 종종 구별되지 않고 단순히 JPEG라고 불린다. JPEG의 MIME 미디어 타입은 "image/jpeg"이지만, 이전 인터넷 익스플로러 버전에서는 JPEG 이미지를 업로드할 때 "image/pjpeg" MIME 타입을 제공했다.url-status=live JPEG 파일은 일반적으로 "jpg" 또는 "jpeg" 파일 확장자를 가진다. JPEG/JFIF는 최대 65,535×65,535픽셀의 이미지 크기를 지원하며,archive-date=3 September 2014 따라서 가로세로비가 1:1일 때 최대 4기가픽셀까지 지원한다. 2000년, JPEG 그룹은 후속으로 의도된 JPEG 2000 형식을 도입했지만, 원본 JPEG를 지배적인 이미지 표준으로 대체할 수 없었다.url-status=live
# 역사

## 배경
1992년에 발행된 원본 JPEG 규격은 CCITT (현 ITU-T) 및 공동 사진 전문가 그룹에서 인용한 다양한 이전 학술 논문과 특허의 프로세스를 구현한다.url-status=live JPEG의 손실 압축 알고리즘의 기초는 이산 코사인 변환(DCT)이다. 이는 나시르 아메드가 1972년에 이미지 압축 기술로 처음 제안했다.bibcode=1991DSP.....1....4A 아메드는 T. 나타라잔, K. R. 라오와 함께 1974년 논문에서 DCT 알고리즘을 발표했고, 이는 JPEG 규격에 인용되었다. JPEG 규격은 여러 회사의 특허를 인용하고 있다. 다음 특허들은 산술 부호화 알고리즘의 기초를 제공했다. * IBM ** 4652856 – 1986년 2월 4일 – Kottappuram M. A. Mohiuddin 및 요르마 리사넨 – Multiplication-free multi-alphabet arithmetic code ** 4905297 – 1990년 2월 27일 – G. Langdon, 조안 L. 미첼, W. B. Pennebaker 및 Jorma J. Rissanen – Arithmetic coding encoder and decoder system ** 4935882 – 1990년 6월 19일 – W. B. Pennebaker 및 J. L. Mitchell – Probability adaptation for arithmetic coders * 미쓰비시 전기 ** H02202267 (1021672) – 1989년 1월 21일 – Toshihiro Kimura, Shigenori Kino, Fumitaka Ono, Masayuki Yoshida – 코딩 시스템 ** H03247123 (2-46275) – 1990년 2월 26일 – Tomohiro Kimura, Shigenori Kino, Fumitaka Ono, 및 Masayuki Yoshida – 코딩 장치 및 코딩 방법 JPEG 규격은 IBM의 다른 세 가지 특허도 인용하고 있다. 특허 보유자로 인용된 다른 회사로는 AT&T; (두 가지 특허) 및 캐논이 있다. 목록에는 Compression Labs의 웬시웅 첸과 대니얼 J. 클렌케가 1986년 10월에 출원한 4698672가 빠져 있다. 이 특허는 DCT 기반 이미지 압축 알고리즘을 설명하며, 나중에 2002년에 논란의 원인이 되었다 (특허 논쟁 참조).url-status=live 그러나 JPEG 규격은 웬시웅 첸의 1977년 및 1984년의 두 가지 이전 연구 논문을 인용했다.
## JPEG 표준
"JPEG"는 JPEG 표준 및 기타 정지 영상 코딩 표준을 만든 위원회 이름인 공동 사진 전문가 그룹의 약자이다. "Joint"는 ISO TC97 WG8 및 CCITT SGVIII을 의미했다. 1986년에 설립된 이 그룹은 1980년대 후반에 JPEG 표준을 개발했다. 이 그룹은 1992년에 JPEG 표준을 발표했다.doi-access=free 1987년, ISO TC 97은 ISO/IEC JTC 1이 되었고, 1992년, CCITT는 ITU-T가 되었다. 현재 JTC1 측에서는 JPEG가 ISO/IEC 공동 기술 위원회 1, 분과 위원회 29, 실무 그룹 1 (ISO/IEC JTC 1/SC 29/WG 1)의 두 하위 그룹 중 하나이며, 정지 영상 코딩을 담당한다.archive-date=2013-12-31archive-date=2013-12-31url-status=live ITU-T 측에서는 ITU-T SG16이 해당 기관이다. 원본 JPEG 그룹은 1986년에 조직되었으며,url-status=live 1992년에 첫 JPEG 표준을 발표했고, 1992년 9월에는 **ITU-T 권고 T.81**url-status=live로 승인되었으며, 1994년에는 **ISO/IEC 10918-1**로 승인되었다. JPEG 표준은 이미지가 바이트 스트림으로 압축되고 다시 이미지로 해제되는 방법을 정의하는 코덱을 지정하지만, 해당 스트림을 포함하는 데 사용되는 파일 형식은 지정하지 않는다. url = https://books.google.com/books?id=AepB_PZ_WMkC&dq;=JPEG+%22did+not+specify+a+file+format%22&pg;=PA291 Exif 및 JFIF 표준은 JPEG 압축 이미지를 교환하는 데 일반적으로 사용되는 파일 형식을 정의한다. JPEG 표준은 공식적으로 정보 기술 – 연속 톤 정지 이미지의 디지털 압축 및 코딩으로 명명되었다. ISO/IEC 10918은 다음 부분들로 구성된다. {| class="wikitable sortable" |+연속 톤 정지 이미지의 디지털 압축 및 코딩 – 부분url-status=live |- ! | 부분 ! | ISO/IEC 표준 ! | ITU-T 권고. ! | 첫 공개 날짜 ! | 최신 개정 ! | 제목 ! 설명 |- | Part 1 | ISO/IEC 10918-1:1994 | T.81 (09/92) | 1992-09-18 | | 요구사항 및 지침 | |- | Part 2 | ISO/IEC 10918-2:1995 | T.83 (11/94) | 1994-11-11 | | 규정 준수 테스트 | 소프트웨어 적합성(파트 1)에 대한 규칙 및 검사. |- | Part 3 | ISO/IEC 10918-3:1997 | T.84 (07/96) | 1996-07-03 | 1999-04-01 | 확장 | **정지 이미지 교환 파일 형식** (SPIFF)을 포함하여 파트 1을 개선하기 위한 확장 집합.url-status=live |- | Part 4 | ISO/IEC 10918-4:2024 | T.86 (06/98) | 1998-06-18 | | 앱 마커 | JPEG를 확장하는 데 사용되는 일부 매개변수를 등록하는 방법 |- | Part 5 | ISO/IEC 10918-5:2013 | T.871 (05/11) | 2011-05-14 | | JPEG 파일 교환 형식 (JFIF) | JPEG 표준으로 인코딩된 이미지의 사실상의 파일 형식이었던 인기 있는 형식. 2009년 JPEG 위원회는 JFIF를 JPEG Part 5로 표준화하기 위한 임시 그룹을 공식적으로 설립했다.archive-date=2009-10-08 |- | Part 6 | ISO/IEC 10918-6:2013 | T.872 (06/12) | 2012-06 | | 인쇄 시스템에 적용 | 인쇄를 위해 ISO/IEC 10918-1에 따라 인코딩된 이미지 교환을 위한 기능 및 응용 도구의 하위 집합을 지정한다. |- |Part 7 |ISO/IEC 10918-7:2023 |T.873 (06/21) |2019년 5월 |2023년 11월 |참조 소프트웨어 |JPEG 코어 코딩 시스템의 참조 구현을 제공한다. |} Ecma 인터내셔널 TR/98은 JPEG 파일 교환 형식(JFIF)을 지정하며, 첫 번째 판은 2009년 6월에 발행되었다.url-status=live
## 특허 논쟁
2002년, Forgent Networks는 1986년 10월 27일에 출원되어 1987년 10월 6일에 부여된 Compression Labs의 웬시웅 첸과 대니얼 J. 클렌케의 특허 4698672에서 비롯된 JPEG 기술에 대한 특허권을 소유하고 있으며 이를 집행할 것이라고 주장했다.url-status=live 당시 Forgent는 Compression Labs를 소유하고 있지 않았지만, 첸이 Cisco로 이직하기 전에 Compression Labs를 Forgent에 매각했다. 이로 인해 Forgent는 해당 특허권을 획득하게 되었다. Forgent의 2002년 발표는 유니시스가 GIF 이미지 압축 표준에 대한 권리를 주장하려 했던 시도를 연상시키는 소동을 일으켰다. JPEG 위원회는 2002년에 특허 주장을 조사했고, 그들은 선행 기술에 의해 무효화되었다고 판단했으며,archive-date=2007-07-14 이는 다양한 전문가들의 견해와 일치했다.archive-date=August 17, 2004 2002년부터 2004년까지 Forgent는 약 30개 회사에 특허를 라이선스하여 약 1억 5백만 달러를 벌어들였다. 2004년 4월, Forgent는 추가 라이선스 비용을 강제하기 위해 다른 31개 회사를 고소했다. 같은 해 7월, 21개 대형 컴퓨터 회사 컨소시엄은 특허 무효화를 목표로 반소를 제기했다. 또한 Microsoft는 2005년 4월 Forgent에 대해 별도의 소송을 제기했다.url-status=live 2006년 2월, 미국특허청은 Public Patent Foundation의 요청에 따라 Forgent의 JPEG 특허를 재심사하는 데 동의했다.archive-url=http://arquivo.pt/wayback/20160515113624/http://www.publish.com/c/a/Graphics-Tools/Trademark-Office-Reexamines-Forgent-JPEG-Patent/ 2006년 5월 26일, USPTO는 선행 기술을 근거로 특허가 무효임을 확인했다. USPTO는 또한 Forgent가 선행 기술에 대해 알고 있었음에도 불구하고 의도적으로 특허청에 알리지 않았다는 것을 확인했다. 이로 인해 특허를 되살리기 위한 어떤 항소도 성공할 가능성이 매우 낮아졌다.url-status=live Forgent는 1994년 유럽 특허청으로부터 유사한 특허를 받았지만, 그 집행 가능성은 불확실하다.archive-url=https://web.archive.org/web/20110612114555/http://gauss.ffii.org/PatentView/EP266049 2006년 10월 27일부로 미국 특허의 20년 유효 기간이 만료되었으며, 2006년 11월 Forgent는 JPEG 표준 사용에 대한 특허 청구권 주장을 포기하는 데 동의했다.url-status=live JPEG 위원회는 표준(특히 기본 방법)이 라이선스 비용 지불 없이 구현될 수 있도록 하는 것을 명시적인 목표 중 하나로 삼고 있으며, JPEG 2000 표준에 대한 적절한 라이선스 권리를 20개 이상의 대규모 조직으로부터 확보했다. 2007년 8월부터 Global Patent Holdings, LLC는 1993년에 발급된 자사의 특허(5,253,341)가 웹사이트 또는 이메일을 통한 JPEG 이미지 다운로드에 의해 침해되었다고 주장했다. 이 특허가 무효화되지 않으면, 이 특허는 JPEG 이미지를 표시하는 모든 웹사이트에 적용될 수 있다. 이 특허는 2000년부터 2007년까지 미국특허청의 재심사 대상이었고, 2007년 7월 특허청은 특허의 모든 원본 청구권을 취소했지만, Global Patent Holdings가 제안한 추가 청구권(청구권 17)은 유효하다고 판단했다.archive-date=June 2, 2008 Global Patent Holdings는 그 후 특허의 청구권 17을 기반으로 여러 소송을 제기했다. 재심사 후 처음 두 건의 소송은 모두 일리노이주 시카고에서 제기되었으며, Global Patent Holdings는 그린베이 패커스, CDW, 모토로라, 애플, Orbitz, Officemax, 캐터필러, 크래프트, Peapod를 피고로 고소했다. 세 번째 소송은 2007년 12월 5일 남부 플로리다에서 ADT Security Services, AutoNation, Florida Crystals Corp., HearUSA, MovieTickets.com, Ocwen Financial Corp. 및 Tire Kingdom을 상대로 제기되었고, 네 번째 소송은 2008년 1월 8일 남부 플로리다에서 Boca Raton Resort & Club을 상대로 제기되었다. 다섯 번째 소송은 네바다에서 Global Patent Holdings를 상대로 제기되었다. 이 소송은 Global Patent Holdings로부터 위협을 받았다고 주장하는 Zappos.com, Inc.에 의해 제기되었으며, '341 특허가 무효이며 침해되지 않았다는 사법적 선언을 구했다. Global Patent Holdings는 또한 '341 특허를 사용하여 광범위한 소프트웨어 특허에 대한 노골적인 비판자들을 고소하거나 위협하기도 했는데, 그중에는 Gregory Aharonianarchive-date=2011-07-16과 "Patent Troll Tracker"로 알려진 웹사이트 블로그의 익명 운영자가 포함된다.url-status=live 2007년 12월 21일, 시카고의 특허 변호사 Vernon Francissen은 새로운 선행 기술을 근거로 '341 특허의 유일하게 남은 청구권을 재심사해달라고 미국특허청에 요청했다.url-status=live 2008년 3월 5일, 미국특허청은 '341 특허를 재심사하는 데 동의했으며, 새로운 선행 기술이 특허의 유효성에 대해 상당한 새로운 의문을 제기한다고 판단했다.미국특허청 – 5,253,341 C1 재심사 승인 재심사에 비추어 볼 때, 보류 중인 다섯 건의 소송 중 네 건의 피고측은 미국특허청의 '341 특허 심사가 완료될 때까지 사건을 일시 중단(정지)해 달라는 신청을 제기했다. 2008년 4월 23일, 일리노이주 시카고에서 두 건의 소송을 담당하던 판사는 해당 사건들의 신청을 승인했다.url-status=live 2008년 7월 22일, 특허청은 두 번째 재심사의 첫 번째 "Office Action"을 발행하여, 19가지 다른 근거를 바탕으로 해당 청구권이 무효임을 확인했다.url-status=live 2009년 11월 24일, 모든 청구권을 취소하는 재심사 증명서가 발급되었다. 2011년부터 2013년 초까지 동부 텍사스에 기반을 둔 Princeton Digital Image Corporationarchive-url=https://archive.today/20130411084058/http://www.princetondigitalimage.com/이라는 단체가 4813056의 침해 혐의로 수많은 회사를 고소하기 시작했다. 프린스턴은 JPEG 이미지 압축 표준이 '056 특허를 침해한다고 주장하며 수많은 웹사이트, 소매업체, 카메라 및 장치 제조업체, 리셀러를 고소했다. 이 특허는 원래 제너럴 일렉트릭이 소유하고 양도했다. 이 특허는 2007년 12월에 만료되었지만, 프린스턴은 "과거 침해"를 이유로 수많은 회사를 고소했다. (미국 특허법에 따르면, 특허 소유자는 소송 제기 전 최대 6년까지 "과거 침해"를 이유로 소송을 제기할 수 있으므로, 프린스턴은 이론적으로 2013년 12월까지 계속해서 회사를 고소할 수 있었다.) 2013년 3월 현재, 프린스턴은 뉴욕과 델라웨어에서 55개 이상의 회사를 상대로 소송을 진행 중이다. 제너럴 일렉트릭의 소송 개입 여부는 불분명하지만, 법원 기록에 따르면 2009년에 특허를 프린스턴에 양도했으며 특허에 대한 특정 권리를 보유하고 있다.access-date=2013-05-01
# 일반적인 용도
JPEG 압축 알고리즘은 부드러운 톤과 색상 변화를 가진 사실적인 장면의 사진 및 그림에 가장 잘 작동한다. 웹 사용에서는 이미지에 사용되는 데이터 양을 줄이는 것이 반응형 프레젠테이션에 중요하므로, JPEG의 압축 이점이 JPEG를 인기 있게 만든다. JPEG/Exif는 디지털 카메라에서 저장하는 가장 일반적인 형식이다. 그러나 JPEG는 선화 및 기타 텍스트 또는 아이콘 그래픽에는 적합하지 않다. 이러한 그래픽에서는 인접 픽셀 간의 날카로운 대비가 눈에 띄는 압축 가공물을 유발할 수 있기 때문이다.doi=10.5120/ijca2016909658 이러한 이미지는 무손실 그래픽 형식인 TIFF, GIF, PNG 또는 Raw 이미지 포맷으로 저장하는 것이 더 좋다. JPEG 표준에는 무손실 코딩 모드가 포함되어 있지만, 이 모드는 대부분의 제품에서 지원되지 않는다. JPEG의 일반적인 사용은 이미지 충실도를 감소시키는 손실 압축 방식이므로, 이미지 데이터의 정확한 재현(일부 과학 및 의료 영상 응용 프로그램 및 특정 기술 영상 처리 작업과 같은)에는 부적절하다. JPEG는 또한 여러 번 편집될 파일에도 적합하지 않다. 이미지가 다시 압축될 때마다 일부 화질이 손실되기 때문이며, 특히 이미지가 잘리거나 이동되거나 인코딩 매개변수가 변경되면 더욱 그렇다. 자세한 내용은 디지털 세대 손실을 참조하라. 순차적이고 반복적인 편집 중 이미지 정보 손실을 방지하려면 첫 번째 편집을 무손실 형식으로 저장하고, 해당 형식으로 후속 편집을 수행한 다음, 최종적으로 배포용으로 JPEG로 게시할 수 있다.
# JPEG 압축
JPEG는 이산 코사인 변환(DCT)에 기반한 손실 형태의 압축을 사용한다. 이 수학적 연산은 비디오 소스의 각 프레임/필드를 공간(2D) 도메인에서 주파수 도메인(변환 도메인이라고도 함)으로 변환한다. 인간의 시각 심리 시스템이 고주파 정보, 즉 강도와 색상 색조의 급격한 전환을 버리는 방식에 느슨하게 기반한 지각 모델. 변환 도메인에서 정보 감소 과정은 양자화라고 한다. 더 간단히 말하면, 양자화는 많은 수의 스케일(각 숫자의 다른 발생 빈도 포함)을 더 작은 스케일로 최적으로 줄이는 방법이며, 변환 도메인은 이미지의 편리한 표현 방식이다. 왜냐하면 다른 계수보다 전체 그림에 덜 기여하는 고주파 계수는 특성상 압축률이 높은 작은 값이기 때문이다. 양자화된 계수는 그 다음으로 순서가 지정되고 무손실 방식으로 출력 비트스트림으로 압축된다. JPEG의 거의 모든 소프트웨어 구현은 사용자가 압축률(및 기타 선택적 매개변수)을 제어할 수 있도록 하여, 사용자가 화질과 더 작은 파일 크기 사이에서 절충할 수 있게 한다. 임베디드 애플리케이션(예: 유사한 DCT 압축 스키마를 사용하는 miniDV)에서는 매개변수가 애플리케이션에 대해 미리 선택되고 고정된다. 압축 방식은 일반적으로 손실 방식이다. 즉, 원본 이미지 정보의 일부가 손실되어 복원할 수 없으며, 이는 이미지 품질에 영향을 미칠 수 있다. JPEG 표준에는 선택적 무손실 모드가 정의되어 있다. 그러나 이 모드는 제품에서 널리 지원되지 않는다. 또한 인터레이스된 프로그레시브 JPEG 형식이 있는데, 이 형식에서는 데이터가 점진적으로 더 높은 디테일의 여러 패스로 압축된다. 이는 느린 연결을 통해 다운로드되는 동안 표시될 큰 이미지에 이상적이며, 데이터의 일부만 수신한 후에도 합리적인 미리 보기를 허용한다. 그러나 프로그레시브 JPEG에 대한 지원은 보편적이지 않다. 프로그레시브 JPEG가 이를 지원하지 않는 프로그램(예: 윈도우 7 이전의 인터넷 익스플로러 버전)url-status = live에 의해 수신되면, 소프트웨어는 이미지가 완전히 다운로드된 후에만 이미지를 표시한다. 12비트 JPEG 이미지를 그레이스케일 및 컬러로 생성하고 처리하는 많은 의료 영상, 교통 및 카메라 응용 프로그램도 있다. 12비트 JPEG 형식은 JPEG 사양의 확장 부분에 포함되어 있다. Libjpeg 코덱은 12비트 JPEG를 지원하며 고성능 버전도 존재한다.url-status = live
## 무손실 편집
JPEG 이미지에 대한 여러 변경은 이미지 크기가 1 MCU 블록(최소 인코딩 단위)의 배수(일반적으로 4:2:0 크로마 서브샘플링의 경우 양방향으로 16픽셀)인 한 무손실로(즉, 재압축 및 관련 품질 손실 없이) 수행할 수 있다. 이를 구현하는 유틸리티는 다음과 같다. * jpegtran 및 GUI, Jpegcrop. * IrfanView는 "JPG Lossless Crop (PlugIn)" 및 "JPG Lossless Rotation (PlugIn)"을 사용하며, JPG_TRANSFORM 플러그인을 설치해야 한다. * 패스트스톤 이미지 뷰어는 "Lossless Crop to File" 및 "JPEG Lossless Rotate"를 사용한다. * XnViewMP는 "JPEG lossless transformations"를 사용한다. * ACDSee는 "Force lossless JPEG operations" 옵션을 사용하여 무손실 회전(무손실 자르기는 아님)을 지원한다. 블록은 90도 간격으로 회전하거나, 수평, 수직, 대각선 축으로 뒤집거나, 이미지 내에서 이동할 수 있다. 원본 이미지의 모든 블록이 수정된 이미지에서 사용될 필요는 없다. JPEG 이미지의 상단 및 왼쪽 가장자리는 8x8 픽셀 블록 경계(또는 더 큰 MCU 크기의 경우 16x16 픽셀)에 있어야 하지만, 하단 및 오른쪽 가장자리는 그럴 필요가 없다. 이로 인해 가능한 **무손실 자르기** 작업이 제한되며, 모든 채널에 대해 하단 또는 오른쪽 가장자리가 블록 경계에 있지 않은 이미지의 뒤집기 및 회전이 방지된다(가장자리가 위쪽 또는 왼쪽으로 이동하게 되는데, 위에서 언급했듯이 블록 경계가 필수적이기 때문이다). 크로마 서브샘플링에 따라 8 또는 16의 배수가 아닌 이미지를 회전하는 것은 무손실이 아니다. 이러한 이미지를 회전하면 블록이 다시 계산되어 화질이 손실된다.url-status=live 무손실 자르기를 사용할 때, 자르기 영역의 하단 또는 오른쪽이 블록 경계에 있지 않으면, 부분적으로 사용된 블록의 나머지 데이터가 잘린 파일에 여전히 존재하며 복구될 수 있다. 또한 품질 손실 없이 베이스라인 형식과 프로그레시브 형식 간에 변환하는 것도 가능하다. 이는 파일에 계수가 배치되는 순서만 다르기 때문이다. 또한 여러 JPEG 이미지를 무손실로 결합할 수 있다. 단, 동일한 품질로 저장되었고 가장자리가 블록 경계와 일치해야 한다.
# JPEG 파일
"JPEG 교환 형식"(JIF)으로 알려진 파일 형식은 표준의 부록 B에 명시되어 있다. 그러나 이 "순수한" 파일 형식은 거의 사용되지 않는다. 주로 인코더 및 디코더가 표준의 모든 측면을 완전히 구현하도록 프로그래밍하기 어렵기 때문이며, 표준의 특정 단점 때문이다. * 색 공간 정의 * 구성 요소 서브샘플링 등록 * 픽셀 가로세로비 정의. 이러한 문제를 해결하기 위해 여러 추가 표준이 발전해 왔다. 이 중 첫 번째는 1992년에 출시된 JPEG File Interchange Format (JFIF)이었고, 최근에는 Exchangeable image file format (Exif) 및 ICC 색상 프로파일이 뒤따랐다. 이 두 형식은 마커로 구성된 실제 JIF 바이트 레이아웃을 사용하지만, 추가적으로 JIF 표준의 확장 지점 중 하나인 응용 프로그램 마커를 사용한다: JFIF는 APP0을 사용하고 Exif는 APP1을 사용한다. JIF 표준에서 향후 사용을 위해 남겨두었고 JIF가 읽지 않는 파일의 이 세그먼트 내에서 이러한 표준은 특정 메타데이터를 추가한다. 따라서 JFIF는 어떤 면에서는 JIF 표준의 축소 버전이다. 특정 제약(예: 모든 다른 인코딩 모드를 허용하지 않음)을 지정하기 때문이며, 다른 면에서는 추가된 메타데이터로 인해 JIF의 확장이다. 원본 JFIF 표준 문서는 다음과 같이 명시한다.url-status = live JPEG 파일 교환 형식은 JPEG 비트스트림이 다양한 플랫폼과 응용 프로그램 간에 교환될 수 있도록 하는 최소한의 파일 형식이다. 이 최소 형식은 TIFF JPEG 사양이나 특정 응용 프로그램 파일 형식에서 찾을 수 있는 고급 기능을 포함하지 않는다. 또한 이 단순화된 형식의 유일한 목적은 JPEG 압축 이미지를 교환할 수 있도록 하는 것이므로 그렇게 해서는 안 된다. JPEG 압축을 사용하는 이미지 파일은 일반적으로 "JPEG 파일"이라고 불리며, JIF 이미지 형식의 변형으로 저장된다. JPEG를 출력하는 대부분의 이미지 캡처 장치(디지털 카메라 등)는 실제로 Exif 형식으로 파일을 생성하는데, 이는 카메라 산업에서 메타데이터 교환을 위해 표준화된 형식이다. 반면에 Exif 표준은 색상 프로필을 허용하지 않으므로, 대부분의 이미지 편집 소프트웨어는 JPEG를 JFIF 형식으로 저장하고, 거의 준수하는 방식으로 메타데이터를 포함하기 위해 Exif 파일의 APP1 세그먼트를 포함한다. JFIF 표준은 다소 유연하게 해석된다.url-status=live (q. 14: "Why all the argument about file formats?") 엄밀히 말하면, JFIF와 Exif 표준은 호환되지 않는다. 각각의 마커 세그먼트(각각 APP0 또는 APP1)가 먼저 나타나야 한다고 지정하기 때문이다. 실제로 대부분의 JPEG 파일은 Exif 헤더 앞에 JFIF 마커 세그먼트를 포함한다. 이를 통해 이전 판독기는 이전 형식의 JFIF 세그먼트를 올바르게 처리할 수 있으며, 최신 판독기는 Exif 세그먼트가 먼저 나타나야 한다는 요구 사항에 덜 엄격하여 다음 Exif 세그먼트도 디코딩한다.
## JPEG 파일 확장자
JPEG 압축을 사용하는 파일의 가장 일반적인 파일 확장자는 **`.jpg`** 및 **`.jpeg`** 이지만, `.jpe`, `.jfif` 및 `.jif`도 사용된다.language=en-US JPEG 데이터는 다른 파일 형식에 내장될 수도 있다. 예를 들어, TIFF로 인코딩된 파일은 종종 JPEG 이미지를 메인 이미지의 섬네일로 내장하며, MP3 파일은 ID3v2 태그에 커버 아트의 JPEG를 포함할 수 있다.
## 색상 프로필
많은 JPEG 파일은 ICC 색상 프로필(색 공간)을 내장한다. 일반적으로 사용되는 색상 프로필에는 sRGB 및 Adobe RGB가 있다. 이러한 색 공간은 비선형 변환을 사용하므로 8비트 JPEG 파일의 동적 범위는 약 11 스톱이다. 감마 곡선을 참조하라. 이미지가 색상 프로필 정보(태그 없음)를 지정하지 않으면 웹페이지 표시 목적으로 sRGB 색 공간으로 가정된다.url-status=liveurl-status=live
# 구문 및 구조
JPEG 이미지는 일련의 세그먼트로 구성되며, 각 세그먼트는 마커로 시작하고, 각 마커는 0xFF 바이트로 시작한 다음 어떤 종류의 마커인지를 나타내는 바이트가 이어진다. 일부 마커는 이 두 바이트만으로 구성되며, 다른 마커는 그 뒤에 두 바이트(높은 바이트, 낮은 바이트 순)가 이어져서 마커별 페이로드 데이터의 길이를 나타낸다. (길이에는 길이에 대한 두 바이트는 포함되지만 마커에 대한 두 바이트는 포함되지 않는다.) 일부 마커는 엔트로피 부호화된 데이터가 뒤따르며, 그러한 마커의 길이는 엔트로피 부호화된 데이터를 포함하지 않는다. 연속된 0xFF 바이트는 패딩 목적으로 채움 바이트로 사용되지만, 이 채움 바이트 패딩은 엔트로피 부호화된 스캔 데이터 바로 뒤에 오는 마커에 대해서만 발생해야 한다(자세한 내용은 JPEG 사양 섹션 B.1.1.2 및 E.1.2 참조; 특히 "압축된 데이터 뒤에 마커가 추가되는 모든 경우에 선택적 0xFF 채움 바이트가 마커 앞에 올 수 있다"). 엔트로피 부호화된 데이터 내에서, 0xFF 바이트 뒤에는 인코더가 다음 바이트 앞에 0x00 바이트를 삽입하여, 의도하지 않은 마커가 나타나지 않도록 하여 프레이밍 오류를 방지한다. 디코더는 이 0x00 바이트를 건너뛰어야 한다. 바이트 스터핑이라고 불리는 이 기술(JPEG 사양 섹션 F.1.2.3 참조)은 마커 페이로드 데이터가 아닌 엔트로피 부호화된 데이터에만 적용된다. 그러나 엔트로피 부호화된 데이터 자체에도 몇 가지 마커가 있다. 특히 리셋 마커(0xD0부터 0xD7까지)는 독립적인 엔트로피 부호화된 데이터 청크를 분리하여 병렬 디코딩을 허용하는 데 사용되며, 인코더는 이러한 리셋 마커를 일정한 간격으로 삽입할 수 있다(모든 인코더가 그렇게 하는 것은 아니다). {| class="wikitable" |+ 일반적인 JPEG 마커url-status = live ! 짧은 이름 ! 바이트 ! 페이로드 ! 이름 ! 주석 |- ! SOI | 0xFF, 0xD8 || 없음 || 이미지 시작 | |- ! SOF0 | 0xFF, 0xC0 || 가변 크기 || 프레임 시작 (베이스라인 DCT) | 이것이 베이스라인 DCT 기반 JPEG임을 나타내며, 너비, 높이, 구성 요소 수 및 구성 요소 서브샘플링(예: 4:2:0)을 지정한다. |- ! SOF2 | 0xFF, 0xC2 || 가변 크기 || 프레임 시작 (프로그레시브 DCT) | 이것이 프로그레시브 DCT 기반 JPEG임을 나타내며, 너비, 높이, 구성 요소 수 및 구성 요소 서브샘플링(예: 4:2:0)을 지정한다. |- ! DHT | 0xFF, 0xC4 || 가변 크기 || 허프먼 테이블 정의 | 하나 이상의 허프먼 테이블을 지정한다. |- ! DQT | 0xFF, 0xDB || 가변 크기 || 양자화 테이블 정의 | 하나 이상의 양자화 테이블을 지정한다. |- ! DRI | 0xFF, 0xDD || 4 바이트 || 재시작 간격 정의 | RSTn 마커 사이의 간격을 최소 코딩 단위(MCU)로 지정한다. DRI 마커가 없으면 사용되지 않는다. 마커 코드의 하위 3비트는 값 0에서 7까지 순환한다. |- ! SOS | 0xFF, 0xDA || 가변 크기 || 스캔 시작 | 이미지의 위에서 아래로 스캔을 시작한다. 베이스라인 DCT JPEG 이미지에는 일반적으로 단일 스캔이 있다. 프로그레시브 DCT JPEG 이미지에는 일반적으로 여러 스캔이 포함된다. 이 마커는 포함할 데이터의 슬라이스를 지정하며, 그 뒤에 엔트로피 코딩된 데이터가 즉시 이어진다. |- ! RSTn | 0xFF, 0xDn (n=0..7) || 없음 || 재시작 | r 매크로블록마다 삽입되며, r은 DRI 마커에 의해 설정된 재시작 간격이다. DRI 마커가 없으면 사용되지 않는다. 마커 코드의 하위 세 비트는 0에서 7까지 순환한다. |- ! APPn | 0xFF, 0xEn || 가변 크기 || 응용 프로그램별 | 예를 들어, Exif JPEG 파일은 TIFF에 기반한 구조로 메타데이터를 저장하기 위해 APP1 마커를 사용한다. |- ! COM | 0xFF, 0xFE || 가변 크기 || 주석 | 텍스트 주석을 포함한다. |- ! EOI | 0xFF, 0xD9 || 없음 || 이미지 끝 | |} 다른 종류의 JPEG 인코딩을 도입하는 다른 프레임 시작 마커도 있다. 여러 공급업체가 동일한 APPn 마커 유형을 사용할 수 있으므로, 응용 프로그램별 마커는 종종 표준 또는 공급업체 이름(예: "Exif" 또는 "Adobe") 또는 다른 식별 문자열로 시작한다. 재시작 마커에서, 블록 대 블록 예측 변수는 재설정되고, 비트스트림은 바이트 경계에 동기화된다. 재시작 마커는 신뢰할 수 없는 네트워크를 통한 전송 또는 파일 손상과 같은 비트스트림 오류 후 복구 수단을 제공한다. 재시작 마커 사이의 매크로블록 실행은 독립적으로 디코딩될 수 있으므로, 이러한 실행은 병렬로 디코딩될 수 있다.
# JPEG 코덱 예시
JPEG 파일은 다양한 방식으로 인코딩될 수 있지만, 가장 일반적으로는 JFIF 인코딩을 사용하여 수행된다. 인코딩 프로세스는 여러 단계로 구성된다. # 이미지의 색상 표현은 RGB에서 YCbCr로 변환된다. 이는 밝기를 나타내는 하나의 루마 구성 요소(Y')와 색상을 나타내는 두 개의 크로마 구성 요소(CB 및 CR)로 구성된다. 이 단계는 때때로 건너뛴다. # 크로마 데이터의 해상도는 일반적으로 2 또는 3배 감소된다. 이는 인간의 눈이 미세한 밝기 세부 사항보다 미세한 색상 세부 사항에 덜 민감하다는 사실을 반영한다. # 이미지는 8×8 픽셀 블록으로 분할되고, 각 블록에 대해 Y, CB, CR 데이터 각각이 이산 코사인 변환(DCT)을 거친다. DCT는 공간 주파수 스펙트럼을 생성한다는 점에서 푸리에 변환과 유사하다. # 주파수 구성 요소의 진폭은 양자화된다. 인간의 시각은 넓은 영역에 걸친 색상 또는 밝기의 작은 변화에는 매우 민감하지만, 고주파 밝기 변화의 정확한 강도를 구별하는 데는 그다지 능숙하지 않다. 따라서 고주파 구성 요소의 진폭은 저주파 구성 요소보다 낮은 정확도로 저장된다. 인코더의 품질 설정(예: 독립 JPEG 그룹 라이브러리에서 0-100 스케일의 50 또는 95url-status = live)은 각 주파수 구성 요소의 해상도가 어느 정도로 감소되는지에 영향을 미친다. 지나치게 낮은 품질 설정을 사용하면 고주파 구성 요소는 완전히 버려진다. # 모든 8×8 블록에 대한 결과 데이터는 무손실 알고리즘인 허프먼 부호화의 변형으로 추가 압축된다. 디코딩 프로세스는 양자화가 되돌릴 수 없기 때문에 이러한 단계를 역순으로 수행한다. 이 섹션의 나머지 부분에서는 인코딩 및 디코딩 프로세스가 더 자세히 설명된다.
## 인코딩
JPEG 표준의 많은 옵션은 일반적으로 사용되지 않으며, 위에서 언급했듯이 대부분의 이미지 소프트웨어는 JPEG 파일을 만들 때 더 간단한 JFIF 형식을 사용하며, 이는 다른 것들 중에서도 인코딩 방법을 지정한다. 여기에는 픽셀당 비트가 24비트(각각 빨강, 초록, 파랑 8비트)인 입력에 적용될 때 가장 일반적인 인코딩 방법 중 하나에 대한 간략한 설명이 있다. 이 특정 옵션은 손실 데이터 압축 방법이다. 이들은 아래 행렬로 표시된다.
### 색 공간 변환
먼저, 이미지는 RGB(기본적으로 sRGB, 그러나 다른 색 공간도 가능)에서 YCbCr (또는 비공식적으로 YCbCr)이라는 다른 색 공간으로 변환되어야 한다. 여기에는 Y', CB, CR의 세 가지 구성 요소가 있다. Y' 구성 요소는 픽셀의 밝기를 나타내고, CB 및 CR 구성 요소는 색차 (파란색 및 빨간색 구성 요소로 분할)를 나타낸다. 이는 기본적으로 디지털 텔레비전 및 비디오 DVD를 포함한 디지털 비디오에서 사용되는 것과 동일한 색 공간이다. YCbCr 색 공간 변환은 인지적 이미지 품질에 큰 영향을 미치지 않으면서 더 큰 압축률을 허용한다(또는 동일한 압축률에서 더 큰 인지적 이미지 품질). 압축은 이미지의 최종 인지적 품질에 더 중요한 밝기 정보가 단일 채널에만 국한되기 때문에 더 효율적이다. 이는 인간 시각 시스템의 색상 인식과 더 밀접하게 일치한다. 색상 변환은 또한 통계적 탈상관화를 통해 압축을 향상시킨다. YCbCr로의 특정 변환은 JFIF 표준에 명시되어 있으며, 결과 JPEG 파일이 최대 호환성을 가지도록 수행되어야 한다. 그러나 "최고 품질" 모드의 일부 JPEG 구현은 이 단계를 적용하지 않고 대신 색상 정보를 RGB 색 모델에 유지한다.language=en 여기서 이미지는 빨강, 초록, 파랑 밝기 구성 요소에 대한 별도의 채널에 저장된다. 이로 인해 압축 효율이 떨어지므로, 파일 크기가 특히 중요할 때는 사용되지 않을 가능성이 높다.
### 다운샘플링
인간 눈의 색상 및 밝기 감지 수용체 밀도로 인해 인간은 이미지의 밝기(Y' 구성 요소)에서는 이미지의 색조 및 색상 채도(Cb 및 Cr 구성 요소)에서보다 훨씬 더 미세한 세부 사항을 볼 수 있다. 이 지식을 활용하여 인코더는 이미지를 더 효율적으로 압축하도록 설계될 수 있다. YCbCr 색상 모델로의 변환은 다음 일반적인 단계인 Cb 및 Cr 구성 요소의 공간 해상도를 줄이는 것("다운샘플링" 또는 "크로마 서브샘플링"이라고 함)을 가능하게 한다. JPEG 이미지에 대해 일반적으로 다운샘플링이 수행되는 비율은 4:4:4(다운샘플링 없음), 4:2:2(수평 방향으로 2배 감소), 또는 (가장 일반적으로) 4:2:0(수평 및 수직 방향으로 모두 2배 감소)이다. 나머지 압축 프로세스 동안 Y', Cb 및 Cr은 별도로 그리고 매우 유사한 방식으로 처리된다.
### 블록 분할
크로마 서브샘플링 후 각 채널은 8x8 블록으로 분할되어야 한다. 크로마 서브샘플링에 따라 이는 8x8(4:4:4 – 서브샘플링 없음), 16x8(4:2:2), 또는 가장 일반적으로 16x16(4:2:0) 크기의 최소 코딩 단위(MCU) 블록을 생성한다. 영상 압축에서 MCU는 매크로블록이라고 불린다. 채널에 대한 데이터가 정수 개의 블록을 나타내지 않으면 인코더는 불완전한 블록의 나머지 영역을 어떤 형태의 더미 데이터로 채워야 한다. 가장자리를 고정된 색상(예: 검정색)으로 채우면 테두리의 가시적인 부분에 따라 링잉 현상이 발생할 수 있다. 가장자리 픽셀을 반복하는 것은 이러한 아티팩트를 줄이는(반드시 제거하지는 않음) 일반적인 기술이며, 더 정교한 테두리 채우기 기술도 적용할 수 있다.
### 이산 코사인 변환
8비트 그레이스케일로 표시된 8×8 서브 이미지 다음으로, 각 구성 요소(Y, Cb, Cr)의 각 8×8 블록은 정규화된 2차원 유형-II 이산 코사인 변환(DCT)을 사용하여 주파수 영역 표현으로 변환된다. 이산 코사인 변환의 참조 1을 참조하라. DCT는 이산 코사인 변환과 같은 변환군에서 "유형-II DCT"라고 불리기도 하며, 해당 역변환(IDCT)은 "유형-III DCT"로 표시된다. 예를 들어, 이러한 8x8 8비트 서브 이미지는 다음과 같을 수 있다. : \left[ \begin{array}{rrrrrrrr} 52 & 55 & 61 & 66 & 70 & 61 & 64 & 73 \\\ 63 & 59 & 55 & 90 & 109 & 85 & 69 & 72 \\\ 62 & 59 & 68 & 113 & 144 & 104 & 66 & 73 \\\ 63 & 58 & 71 & 122 & 154 & 106 & 70 & 69 \\\ 67 & 61 & 68 & 104 & 126 & 88 & 68 & 70 \\\ 79 & 65 & 60 & 70 & 77 & 68 & 58 & 75 \\\ 85 & 71 & 64 & 59 & 55 & 61 & 65 & 83 \\\ 87 & 79 & 69 & 68 & 65 & 76 & 78 & 94 \end{array} \right]. 8×8 블록의 DCT를 계산하기 전에, 그 값들은 양의 범위에서 0을 중심으로 하는 범위로 이동된다. 8비트 이미지의 경우, 원본 블록의 각 항목은 [0, 255] 범위에 속한다. 범위의 중간점(이 경우 값 128)은 각 항목에서 빼져서 0을 중심으로 하는 데이터 범위를 생성하며, 따라서 수정된 범위는 [-128, 127]이다. 이 단계는 이어지는 DCT 처리 단계에서 동적 범위 요구 사항을 줄인다. 이 단계의 결과는 다음과 같다. :g= \begin{array}{c} x \\\ \longrightarrow \\\ \left[ \begin{array}{rrrrrrrr} -76 & -73 & -67 & -62 & -58 & -67 & -64 & -55 \\\ -65 & -69 & -73 & -38 & -19 & -43 & -59 & -56 \\\ -66 & -69 & -60 & -15 & 16 & -24 & -62 & -55 \\\ -65 & -70 & -57 & -6 & 26 & -22 & -58 & -59 \\\ -61 & -67 & -60 & -24 & -2 & -40 & -60 & -58 \\\ -49 & -63 & -68 & -58 & -51 & -60 & -70 & -53 \\\ -43 & -57 & -64 & -69 & -73 & -67 & -63 & -45 \\\ -41 & -49 & -59 & -60 & -63 & -52 & -50 & -34 \end{array} \right] \end{array} \Bigg\downarrow y. DCT는 8×8 입력 값 블록을 64개의 패턴의 선형 결합으로 변환한다. 이 패턴들은 2차원 DCT 기저 함수라고 불리며, 출력 값은 변환 계수라고 불린다. 수평 인덱스는 u이고 수직 인덱스는 v이다. 다음 단계는 다음과 같이 주어지는 2차원 DCT를 취하는 것이다. :\ G_{u,v} = \frac{1}{4} \alpha(u) \alpha(v) \sum_{x=0}^7 \sum_{y=0}^7 g_{x,y} \cos \left[\frac{(2x+1)u\pi}{16} \right] \cos \left[\frac{(2y+1)v\pi}{16} \right] 여기서 * \ u는 수평 공간 주파수이며, 정수 \ 0 \leq u < 8에 해당한다. * \ v는 수직 공간 주파수이며, 정수 \ 0 \leq v < 8에 해당한다. * \alpha(u) 및 \alpha(v)는 변환을 정규직교로 만들기 위한 정규화 스케일 팩터이다. \alpha(i) = \begin{cases} \frac{1}{\sqrt{2, & \mbox{if }i=0 \\\ 1, & \mbox{otherwise} \end{cases} * \ g_{x,y}는 좌표 \ (x,y)에서의 픽셀 값이다. * \ G_{u,v}는 좌표 \ (u,v)에서의 DCT 계수이다. 위의 행렬에 이 변환을 수행하면 다음(소수점 이하 두 자리로 반올림)을 얻는다. :G= \begin{array}{c} u \\\ \longrightarrow \\\ \left[ \begin{array}{rrrrrrrr} -415.38 & -30.19 & -61.20 & 27.24 & 56.12 & -20.10 & -2.39 & 0.46 \\\ 4.47 & -21.86 & -60.76 & 10.25 & 13.15 & -7.09 & -8.54 & 4.88 \\\ -46.83 & 7.37 & 77.13 & -24.56 & -28.91 & 9.93 & 5.42 & -5.65 \\\ -48.53 & 12.07 & 34.10 & -14.76 & -10.24 & 6.30 & 1.83 & 1.95 \\\ 12.12 & -6.55 & -13.20 & -3.95 & -1.87 & 1.75 & -2.79 & 3.14 \\\ -7.73 & 2.91 & 2.38 & -5.94 & -2.38 & 0.94 & 4.30 & 1.85 \\\ -1.03 & 0.18 & 0.42 & -2.42 & -0.88 & -3.02 & 4.12 & -0.66 \\\ -0.17 & 0.14 & -1.07 & -4.19 & -1.17 & -0.10 & 0.50 & 1.68 \end{array} \right] \end{array} \Bigg\downarrow v. 크기가 상당히 큰 왼쪽 상단 모서리 항목에 주목한다. 이것은 DC 계수(상수 구성 요소라고도 함)로, 전체 블록의 기본 색조를 정의한다. 나머지 63개 계수는 AC 계수(교류 구성 요소라고도 함)이다.url-status=live DCT의 장점은 위에서 볼 수 있듯이 대부분의 신호를 결과의 한 모서리에 집계하는 경향이 있다는 것이다. 다음 양자화 단계는 이 효과를 강조하는 동시에 DCT 계수의 전체 크기를 줄여 엔트로피 단계에서 효율적으로 압축하기 쉬운 신호를 생성한다. DCT는 데이터의 비트 깊이를 일시적으로 증가시킨다. 8비트/구성 요소 이미지의 DCT 계수는 저장에 11비트 이상(DCT 계산의 충실도에 따라 다름)을 차지하기 때문이다. 이로 인해 코덱은 이러한 계수를 저장하기 위해 일시적으로 16비트 숫자를 사용해야 할 수 있으며, 이 시점에서 이미지 표현 크기가 두 배로 늘어난다. 이러한 값은 일반적으로 양자화 단계를 통해 다시 8비트 값으로 줄어든다. 이 단계에서의 일시적인 크기 증가는 대부분의 JPEG 구현에서 성능 문제가 되지 않는다. 이미지 인코딩 또는 디코딩 프로세스 중 일반적으로 이미지의 매우 작은 부분만 특정 시점에 완전한 DCT 형태로 저장되기 때문이다.
### 양자화
인간의 눈은 비교적 넓은 영역에서 밝기의 작은 차이를 잘 보지만, 고주파 밝기 변화의 정확한 강도를 구별하는 데는 그다지 능숙하지 않다. 이를 통해 고주파 구성 요소의 정보 양을 크게 줄일 수 있다. 이는 주파수 영역의 각 구성 요소를 해당 구성 요소에 대한 상수로 나눈 다음 가장 가까운 정수로 반올림하여 수행된다. 이 반올림 작업은 DCT 계산이 충분히 높은 정밀도로 수행되는 경우 전체 프로세스에서 유일한 손실 작업이다(크로마 서브샘플링 제외). 이 결과로, 일반적으로 많은 고주파 구성 요소가 0으로 반올림되고, 나머지 많은 부분은 작은 양수 또는 음수가 되어 훨씬 더 적은 비트를 사용하여 표현된다. 양자화 행렬의 요소는 압축률을 제어하며, 값이 클수록 압축률이 높아진다. 일반적인 양자화 행렬(원본 JPEG 표준에 명시된 50% 품질의 경우)은 다음과 같다. :Q= \begin{bmatrix} 16 & 11 & 10 & 16 & 24 & 40 & 51 & 61 \\\ 12 & 12 & 14 & 19 & 26 & 58 & 60 & 55 \\\ 14 & 13 & 16 & 24 & 40 & 57 & 69 & 56 \\\ 14 & 17 & 22 & 29 & 51 & 87 & 80 & 62 \\\ 18 & 22 & 37 & 56 & 68 & 109 & 103 & 77 \\\ 24 & 35 & 55 & 64 & 81 & 104 & 113 & 92 \\\ 49 & 64 & 78 & 87 & 103 & 121 & 120 & 101 \\\ 72 & 92 & 95 & 98 & 112 & 100 & 103 & 99 \end{bmatrix}. 양자화된 DCT 계수는 다음과 같이 계산된다. :B_{j,k} = \mathrm{round} \left( \frac{G_{j,k{Q_{j,k \right) \mbox{ for } j=0,1,2,\ldots,7; k=0,1,2,\ldots,7 여기서 G는 양자화되지 않은 DCT 계수이고, Q는 위의 양자화 행렬이며, B는 양자화된 DCT 계수이다. 위의 양자화 행렬을 위의 DCT 계수 행렬과 함께 사용하면 다음과 같은 결과가 나온다. 왼쪽: 일련의 기저 함수로부터 최종 이미지가 구성된다. 오른쪽: 이미지를 구성하는 DCT 기저 함수의 각 부분과 해당 가중 계수. 중간: 계수가 곱해진 후의 기저 함수: 이 구성 요소는 최종 이미지에 추가된다. 명확성을 위해 이 예제의 8×8 매크로블록은 이선형 보간법을 사용하여 10배 확대되었다. :B= \left[ \begin{array}{rrrrrrrr} -26 & -3 & -6 & 2 & 2 & -1 & 0 & 0 \\\ 0 & -2 & -4 & 1 & 1 & 0 & 0 & 0 \\\ -3 & 1 & 5 & -1 & -1 & 0 & 0 & 0 \\\ -3 & 1 & 2 & -1 & 0 & 0 & 0 & 0 \\\ 1 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\\ 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\\ 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\\ 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \end{array} \right]. 예를 들어, -415(DC 계수)를 사용하여 가장 가까운 정수로 반올림하면 : \mathrm{round} \left( \frac{-415.37}{16} \right) = \mathrm{round} \left( -25.96 \right) = -26. 서브블록의 대부분의 고주파 요소(즉, x 또는 y 공간 주파수가 4보다 큰 요소)가 0 값으로 양자화됨을 주목하라.
### 엔트로피 부호화
엔트로피 부호화 JPEG 이미지 구성 요소의 지그재그 순서 엔트로피 부호화는 비손실 데이터 압축의 특별한 형태이다. 이는 유사한 주파수를 함께 그룹화하고 길이를 코딩하는 0을 삽입한 다음 남은 부분에 허프먼 부호화를 사용하여 이미지 구성 요소를 "지그재그" 순서로 배열하는 것을 포함한다. JPEG 표준은 디코더가 산술 부호화 사용을 지원하는 것을 허용하지만 요구하지는 않는다. 산술 부호화는 수학적으로 허프먼 부호화보다 우수하다. 그러나 이 기능은 역사적으로 로열티가 필요한 특허에 의해 보호되었고, 허프먼 부호화보다 인코딩 및 디코딩 속도가 느리기 때문에 거의 사용되지 않았다. 산술 부호화는 일반적으로 파일을 약 5-7% 더 작게 만든다.via=CiteSeerX 이전 양자화된 DC 계수는 현재 양자화된 DC 계수를 예측하는 데 사용된다. 실제 값 대신 두 값의 차이가 인코딩된다. 63개의 양자화된 AC 계수 인코딩은 이러한 예측 차분을 사용하지 않는다. 위의 양자화된 계수에 대한 지그재그 순서는 아래에 나와 있다. (표시된 형식은 이해/보기 편의를 위한 것이다.) :{| |- || −26 || | || | || | || | || | || | || | |- | −3 || 0 |- | −3 || −2 || −6 |- | 2 || −4 || 1 || −3 |- | 1 || 1 || 5 || 1 || 2 |- | −1 || 1 || −1 || 2 || 0 || 0 |- | 0 || 0 || 0 || −1 || −1 || 0 || 0 |- | 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0 |- | 0 || 0 || 0 || 0 || 0 || 0 |- | 0 || 0 || 0 || 0 || 0 |- | 0 || 0 || 0 || 0 |- | 0 || 0 || 0 |- | 0 || 0 |- | 0 |} i번째 블록이 B_i로 표현되고, 각 블록 내의 위치가 (p,q)로 표현될 때(p = 0, 1, ..., 7, q = 0, 1, ..., 7), DCT 이미지의 모든 계수는 B_i (p,q)로 표현될 수 있다. 따라서 위 방식에서 픽셀 인코딩 순서(i번째 블록의 경우)는 B_i (0,0), B_i (0,1), B_i (1,0), B_i (2,0), B_i (1,1), B_i (0,2), B_i (0,3), B_i (1,2) 등이다. 베이스라인 순차 JPEG 인코딩 및 디코딩 프로세스 이 인코딩 모드를 베이스라인 순차 인코딩이라고 한다. 베이스라인 JPEG는 프로그레시브 인코딩도 지원한다. 순차 인코딩은 한 번에 단일 블록의 계수를 인코딩하는 반면(지그재그 방식), 프로그레시브 인코딩은 모든 블록의 유사한 위치의 계수 묶음을 한 번에 인코딩하고(스캔이라고 함), 다음 묶음의 계수를 모든 블록에 대해 인코딩하는 식으로 계속된다. 예를 들어, 이미지가 N개의 8x8 블록 B_0,B_1,B_2,...,B_{n-1}로 나뉘어 있다면, 3스캔 프로그레시브 인코딩은 첫 번째 스캔에서 모든 블록에 대한 DC 구성 요소 B_i (0,0)를 인코딩한다. 즉, 모든 i = 0, 1, 2, ..., N-1에 대해 인코딩한다. 다음으로, 두 번째 스캔은 몇 가지 더 많은 구성 요소(네 개의 구성 요소가 더 있다고 가정하면, B_i (0,1)부터 B_i (1,1)까지, 여전히 지그재그 방식으로)를 모든 블록에 대해 인코딩한다(따라서 순서는: 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 계수이다. * RUNLENGTH는 이 0이 아닌 AC 계수 이전에 나온 0의 개수이다. * SIZE는 x를 나타내는 데 필요한 비트 수이다. * AMPLITUDE는 x의 비트 표현이다. 런-렝스 인코딩은 각 0이 아닌 AC 계수 x를 검사하여 이전 AC 계수 이전에 몇 개의 0이 왔는지 결정하는 방식으로 작동한다. 이 정보를 사용하여 두 개의 기호가 생성된다. :{| |- ! 기호 1 || 기호 2 |- | (RUNLENGTH, SIZE) || (AMPLITUDE) |} RUNLENGTH와 SIZE는 모두 동일한 바이트에 위치하며, 이는 각각 4비트의 정보만 포함함을 의미한다. 상위 비트는 0의 개수를 다루는 반면, 하위 비트는 x의 값을 인코딩하는 데 필요한 비트 수를 나타낸다. 이는 기호 1이 0이 아닌 AC 계수 앞에 오는 첫 15개의 0에 대한 정보만 저장할 수 있다는 즉각적인 함의를 가진다. 그러나 JPEG는 두 가지 특별한 허프먼 코드워드를 정의한다. 하나는 나머지 계수가 0일 때 시퀀스를 조기에 종료하는 것(EOB 또는 "End-of-Block"이라고 함)이고, 다른 하나는 0이 아닌 AC 계수에 도달하기 전에 0의 실행이 15를 초과하는 경우이다. 0이 아닌 AC 계수 앞에 16개의 0이 발견되는 경우, 기호 1은 "(15, 0)(0)"으로 "특별히" 인코딩된다. 전체 프로세스는 "(0, 0)"으로 표시되는 "EOB"Snd에 도달할 때까지 계속된다. 이를 염두에 두고, 앞서의 시퀀스는 다음과 같이 된다. :(0, 2)(-3);(1, 2)(-3);(0, 2)(-2);(0, 3)(-6);(0, 2)(2);(0, 3)(-4);(0, 1)(1);(0, 2)(-3);(0, 1)(1);(0, 1)(1); :(0, 3)(5);(0, 1)(1);(0, 2)(2);(0, 1)(-1);(0, 1)(1);(0, 1)(-1);(0, 2)(2);(5, 1)(-1);(0, 1)(-1);(0, 0); (행렬의 첫 번째 값인 −26은 DC 계수이다. 동일한 방식으로 인코딩되지 않는다. 위를 참조하라.) 여기서부터 계수의 발생 빈도를 기반으로 주파수 계산이 이루어진다. 예제 블록에서는 양자화된 계수 중 대부분이 작은 숫자이며, 바로 앞에 0 계수가 오지 않는다. 이러한 빈번한 경우는 더 짧은 코드워드로 표현된다.
## 압축률 및 아티팩트
이 이미지는 비압축 이미지와 품질 설정 50으로 JPEG 압축된 동일한 이미지 간의 차이 나는 픽셀을 보여준다. 어두울수록 더 큰 차이를 의미한다. 특히 날카로운 모서리 근처에서 발생하고 블록과 같은 모양을 가지는 변화에 주목하라. 원본 이미지 확대된 그림에서 압축된 8×8 정사각형이 보이며, 손실 압축의 다른 시각적 아티팩트도 함께 나타난다. 결과 압축률은 양자화 단계에서 사용되는 제수(divisor)를 덜 공격적으로 또는 더 공격적으로 사용하여 필요에 따라 조절할 수 있다. 10:1 압축은 일반적으로 원본과 눈으로 구별할 수 없는 이미지를 생성한다. 100:1 압축률도 일반적으로 가능하지만, 원본과 비교할 때 뚜렷한 아티팩트가 나타난다. 적절한 압축 수준은 이미지가 사용될 목적에 따라 달라진다. image1=가장자리 번잡함의 그림 월드 와이드 웹을 사용하는 사람들은 JPEG 이미지에서 나타나는 압축 가공물로 알려진 불규칙성에 익숙할 것이다. 이는 대비되는 가장자리(특히 곡선과 모서리) 주변의 노이즈 또는 "블록형" 이미지 형태로 나타날 수 있다. 이는 JPEG 알고리즘의 양자화 단계 때문이다. 이는 대비되는 색상 간의 날카로운 모서리 주변에서 특히 두드러진다(텍스트는 그러한 모서리가 많기 때문에 좋은 예이다). MPEG 비디오의 유사한 아티팩트는 모기 노이즈라고 불린다. 그 결과 "가장자리 번잡함"과 시간이 지남에 따라 변하는 가짜 점들이 마치 모기가 물체 주위에 떼 지어 날아다니는 것처럼 보이기 때문이다.Phuc-Tue Le Dinh and Jacques Patry. 비디오 압축 아티팩트 및 MPEG 노이즈 감소 date=2006-03-14. Video Imaging DesignLine. 2006년 2월 24일. 2009년 5월 28일 검색됨."**3.9 모기 노이즈:** 움직임과 관련되기도 하는 가장자리 번잡함 왜곡의 한 형태로서, 이동하는 아티팩트 및 얼룩덜룩한 노이즈 패턴이 물체 위에 중첩되어 나타나는 특징이 있으며(사람의 머리와 어깨 주위를 날아다니는 모기를 닮음)." ITU-T Rec. P.930 (08/96) 비디오 참조 손상 시스템 원리 date=2010-02-16 이러한 아티팩트는 압축 수준을 낮추어 줄일 수 있다. 무손실 파일 형식을 사용하여 이미지를 저장하면 완전히 피할 수 있지만, 파일 크기가 더 커진다. 광선 추적 프로그램으로 생성된 이미지에는 지형에 눈에 띄는 블록형 모양이 나타난다. 특정 낮은 강도의 압축 아티팩트는 단순히 이미지를 볼 때는 허용될 수 있지만, 이미지가 나중에 처리되면 강조되어 허용할 수 없는 품질로 이어질 수 있다. 윤곽선 검출 처리 단계에 대한 손실 압축의 효과를 보여주는 아래 예시를 참조하라. {| class="wikitable" |- ! 이미지 !! 무손실 압축 !! 손실 압축 |- ! 원본 | || |- ! 캐니 윤곽선 검출기로 처리 | || |} 일부 프로그램은 사용자가 개별 블록이 압축되는 정도를 변경할 수 있도록 허용한다. 이미지의 아티팩트가 적게 나타나는 영역에는 더 강력한 압축이 적용된다. 이러한 방식으로 JPEG 파일 크기를 수동으로 줄이면서 품질 손실을 줄일 수 있다. 양자화 단계는 항상 정보 손실을 초래하므로, JPEG 표준은 항상 손실 압축 코덱이다. (부동 소수점 숫자를 양자화하고 반올림하는 과정에서 모두 정보가 손실된다.) 양자화 행렬이 단위 행렬이라 할지라도, 반올림 단계에서 정보는 여전히 손실될 것이다. -
## 디코딩
이미지를 표시하기 위한 디코딩은 위에서 설명한 모든 작업을 역순으로 수행하는 것으로 구성된다. DCT 계수 행렬(DC 계수의 차이를 다시 추가한 후)을 가져오면 : \left[ \begin{array}{rrrrrrrr} -26 & -3 & -6 & 2 & 2 & -1 & 0 & 0 \\\ 0 & -2 & -4 & 1 & 1 & 0 & 0 & 0 \\\ -3 & 1 & 5 & -1 & -1 & 0 & 0 & 0 \\\ -3 & 1 & 2 & -1 & 0 & 0 & 0 & 0 \\\ 1 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\\ 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\\ 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\\ 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \end{array} \right] 그리고 위의 양자화 행렬과 요소별 곱셈을 하면 다음과 같이 된다. : \left[ \begin{array}{rrrrrrrr} -416 & -33 & -60 & 32 & 48 & -40 & 0 & 0 \\\ 0 & -24 & -56 & 19 & 26 & 0 & 0 & 0 \\\ -42 & 13 & 80 & -24 & -40 & 0 & 0 & 0 \\\ -42 & 17 & 44 & -29 & 0 & 0 & 0 & 0 \\\ 18 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\\ 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\\ 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\\ 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \end{array} \right] 이는 왼쪽 상단 부분의 원본 DCT 계수 행렬과 매우 유사하다. 다음 단계는 다음과 같이 주어지는 2차원 역 DCT(2D 유형-III DCT)를 취하는 것이다. f_{x,y} = \frac{1}{4} \sum_{u=0}^7 \sum_{v=0}^7 \alpha(u) \alpha(v) F_{u,v} \cos \left[\frac{(2x+1)u\pi}{16} \right] \cos \left[\frac{(2y+1)v\pi}{16} \right] 여기서 * \ x는 픽셀 행이며, 정수 \ 0 \leq x < 8에 해당한다. * \ y는 픽셀 열이며, 정수 \ 0 \leq y < 8에 해당한다. * \ \alpha(u)는 이전에 정의된 정규화 스케일 팩터이며, 정수 \ 0 \leq u < 8에 해당한다. * \ F_{u,v}는 좌표 \ (u,v)에서의 근사 DCT 계수이다. * \ f_{x,y}는 좌표 \ (x,y)에서의 재구성된 픽셀 값이다. 출력을 정수 값으로 반올림하면 (원본은 정수 값을 가졌으므로) (여전히 128만큼 낮아진) 값을 가진 이미지가 생성된다. footer=원본(상단)과 압축 해제된 이미지(하단) 사이에는 약간의 차이가 눈에 띄는데, 이는 왼쪽 하단 모서리에서 가장 쉽게 확인할 수 있다. : \left[ \begin{array}{rrrrrrrr} -66 & -63 & -71 & -68 & -56 & -65 & -68 & -46 \\\ -71 & -73 & -72 & -46 & -20 & -41 & -66 & -57 \\\ -70 & -78 & -68 & -17 & 20 & -14 & -61 & -63 \\\ -63 & -73 & -62 & -8 & 27 & -14 & -60 & -58 \\\ -58 & -65 & -61 & -27 & -6 & -40 & -68 & -50 \\\ -57 & -57 & -64 & -58 & -48 & -66 & -72 & -47 \\\ -53 & -46 & -61 & -74 & -65 & -63 & -62 & -45 \\\ -47 & -34 & -53 & -74 & -60 & -47 & -47 & -41 \end{array} \right] 각 항목에 128을 더하면 : \left[ \begin{array}{rrrrrrrr} 62 & 65 & 57 & 60 & 72 & 63 & 60 & 82 \\\ 57 & 55 & 56 & 82 & 108 & 87 & 62 & 71 \\\ 58 & 50 & 60 & 111 & 148 & 114 & 67 & 65 \\\ 65 & 55 & 66 & 120 & 155 & 114 & 68 & 70 \\\ 70 & 63 & 67 & 101 & 122 & 88 & 60 & 78 \\\ 71 & 71 & 64 & 70 & 80 & 62 & 56 & 81 \\\ 75 & 82 & 67 & 54 & 63 & 65 & 66 & 83 \\\ 81 & 94 & 75 & 54 & 68 & 81 & 81 & 87 \end{array} \right]. 이것이 압축 해제된 서브 이미지이다. 일반적으로 압축 해제 프로세스는 원본 입력 범위인 [0, 255]를 벗어나는 값을 생성할 수 있다. 이 경우 디코더는 원본 비트 깊이로 압축 해제된 이미지를 저장할 때 오버플로를 방지하기 위해 출력 값을 해당 범위 내로 유지하도록 클리핑해야 한다. 압축 해제된 서브 이미지를 원본 서브 이미지(오른쪽 이미지도 참조)와 비교하여 차이(원본 - 압축 해제)를 구하면 다음 오차 값이 나온다. : \left[ \begin{array}{rrrrrrrr} -10 & -10 & 4 & 6 & -2 & -2 & 4 & -9 \\\ 6 & 4 & -1 & 8 & 1 & -2 & 7 & 1 \\\ 4 & 9 & 8 & 2 & -4 & -10 & -1 & 8 \\\ -2 & 3 & 5 & 2 & -1 & -8 & 2 & -1 \\\ -3 & -2 & 1 & 3 & 4 & 0 & 8 & -8 \\\ 8 & -6 & -4 & -0 & -3 & 6 & 2 & -6 \\\ 10 & -11 & -3 & 5 & -8 & -4 & -1 & -0 \\\ 6 & -15 & -6 & 14 & -3 & -5 & -3 & 7 \end{array} \right] 픽셀당 평균 절대 오차는 약 5값이다 (즉, \frac{1}{64} \sum_{x=0}^7 \sum_{y=0}^7 |e(x,y)| = 4.8750). 오차는 왼쪽 하단 모서리에서 가장 눈에 띄며, 왼쪽 하단 픽셀이 바로 오른쪽 픽셀보다 어두워진다.
## 필요 정밀도
JPEG 코덱의 구현에 필요한 정밀도는 JPEG 표준 준수를 위해 수립된 요구사항을 통해 암묵적으로 정의된다. 이러한 요구사항은 ITU.T 권고 T.83 | ISO/IEC 10918-2에 명시되어 있다. MPEG 표준 및 많은 후기 JPEG 표준과 달리, 위 문서는 참조 테스트 스트림에 의해 결정된 DCT 도메인에서 순방향 및 역방향 DCT의 최대 허용 오차를 통해 JPEG 코덱의 인코딩 및 디코딩 프로세스 모두에 필요한 구현 정밀도를 정의한다. 예를 들어, 디코더 구현의 출력은 위 표준의 일부로 제공되는 참조 테스트 코드스트림에 적용될 때 DCT 도메인에서 하나의 양자화 단위 오차를 초과해서는 안 된다. 특이하게도, 다른 많은 현대 표준과 달리 ITU.T T.83 | ISO/IEC 10918-2는 이미지 도메인에서 오차 한계를 공식화하지 않는다.
# JPEG 압축의 효과
JPEG 압축 아티팩트는 세부적이고 불균일한 텍스처를 가진 사진에 잘 어울려 더 높은 압축률을 허용한다. 높은 압축률이 이미지의 왼쪽 상단 모서리에 있는 고주파 텍스처에 먼저 어떻게 영향을 미치는지, 그리고 대비되는 선들이 어떻게 더 흐릿해지는지 주목하라. 매우 높은 압축률은 이미지 품질에 심각한 영향을 미치지만, 전체적인 색상과 이미지 형태는 여전히 인식할 수 있다. 그러나 색상의 정밀도는 윤곽선(휘도 기반)의 정밀도보다 덜 손실된다(인간의 눈에는). 이는 휘도 평면의 정밀도를 더 많은 정보 비트로 보존하기 위해, 색상 평면을 서브샘플링하기 전에(더 낮은 품질의 양자화를 사용할 수도 있음) 휘도와 색상 정보를 분리하는 색상 모델로 이미지를 먼저 변환해야 한다는 사실을 정당화한다.
## 샘플 사진
4480x4480 픽셀 사진에 대한 어도비 포토샵의 JPEG 압축 시각적 영향 참고로, 아래의 비압축 24비트 RGB 비트맵 이미지(73,242 픽셀)는 219,726바이트(모든 다른 정보 헤더 제외)를 필요로 한다. 아래 표시된 파일 크기에는 내부 JPEG 정보 헤더 및 일부 메타데이터가 포함된다. 최고 품질 이미지(Q=100)의 경우 픽셀당 약 8.25비트가 필요하다. 그레이스케일 이미지의 경우 픽셀당 최소 6.5비트면 충분하다(유사한 Q=100 품질 색상 정보는 약 25% 더 많은 인코딩 비트를 필요로 한다). 아래 최고 품질 이미지(Q=100)는 픽셀당 9비트로 인코딩되었고, 중간 품질 이미지(Q=25)는 픽셀당 1비트를 사용한다. 대부분의 응용 프로그램에서는 품질 계수가 픽셀당 0.75비트(Q=12.5) 미만으로 내려가지 않아야 한다. 낮은 품질 이미지에서 볼 수 있듯이, 최저 품질 이미지는 픽셀당 0.13비트만 사용하며 매우 낮은 색상을 보여준다. 이는 이미지가 상당히 축소된 크기로 표시될 때 유용하다. Q 계수 대신 PSNR을 사용하여 주어진 이미지 품질에 대한 더 나은 양자화 행렬을 생성하는 방법은 Minguillón & Pujol (2001)에 설명되어 있다.url-status=live ::{| class="wikitable" |+ align="bottom"| 참고: 위의 이미지는 IEEE / CCIR / EBU 시험 이미지가 아니며, 인코더 설정이 지정되거나 제공되지 않는다. |- ! 이미지 !! 품질 !! 크기 (바이트) !! 압축률 !! 주석 |- | | 최고 품질 (Q = 100) | 81,447 | 2.7:1 | 극히 미미한 아티팩트 |- | | 고품질 (Q = 50) | 14,679 | 15:1 | 서브 이미지 아티팩트의 초기 징후 |- | | 중간 품질 (Q = 25) | 9,407 | 23:1 | 더 강한 아티팩트; 고주파 정보 손실 |- | | 낮은 품질 (Q = 10) | 4,787 | 46:1 | 심각한 고주파 손실로 인해 서브 이미지 경계에 뚜렷한 아티팩트("매크로블록킹") 발생 |- | | 최저 품질 (Q = 1) | 1,523 | 144:1 | 색상과 세부 정보의 극심한 손실; 잎사귀가 거의 인식 불가능하다. |} 중간 품질 사진은 비압축 이미지에 필요한 저장 공간의 4.3%만 사용하지만, 세부 정보 손실이나 눈에 띄는 아티팩트가 거의 없다. 그러나 특정 압축 임계값을 넘어서면 압축된 이미지는 점점 더 눈에 띄는 결함을 보인다. 이 임계값 효과에 대한 수학적 설명은 부호율-변형 이론 문서를 참조하라. 이러한 면에서 JPEG의 특정 한계는 비중첩 8×8 블록 변환 구조이다. JPEG 2000 및 JPEG XR과 같은 더 현대적인 디자인은 낮은 주파수 계수에 더 큰 공간적 범위를 갖는 변환을 사용하고 중첩 변환 기저 함수를 사용하여 비트 사용량이 감소함에 따라 품질 저하가 더욱 부드럽게 나타난다.
# 무손실 추가 압축
2004년부터 2008년까지, 표현된 이미지를 수정하지 않고 JPEG 이미지에 포함된 데이터를 추가로 압축하는 방법에 대한 새로운 연구가 나타났다.I. Bauermann and E. Steinbacj. Further Lossless Compression of JPEG Images. Proc. of Picture Coding Symposium (PCS 2004), San Francisco, US, December 15–17, 2004.N. Ponomarenko, K. Egiazarian, V. Lukin and J. Astola. Additional Lossless Compression of JPEG Images, Proc. of the 4th Intl. Symposium on Image and Signal Processing and Analysis (ISPA 2005), Zagreb, Croatia, pp. 117–120, September 15–17, 2005.M. Stirner and G. Seelmann. Improved Redundancy Reduction for JPEG Files. Proc. of Picture Coding Symposium (PCS 2007), Lisbon, Portugal, November 7–9, 2007Ichiro Matsuda, Yukio Nomoto, Kei Wakabayashi and Susumu Itoh. Lossless Re-encoding of JPEG images using block-adaptive intra prediction. Proceedings of the 16th European Signal Processing Conference (EUSIPCO 2008). 이는 원본 이미지가 JPEG 형식으로만 제공되고, 보관 또는 전송을 위해 크기를 줄여야 하는 시나리오에 적용된다. 표준 범용 압축 도구는 JPEG 파일을 크게 압축할 수 없다. 일반적으로 이러한 방식은 DCT 계수를 코딩하는 단순한 방식의 개선 사항을 활용하는데, 이 방식은 다음 사항을 고려하지 못한다. * 동일한 블록 내 인접 계수 간의 크기 상관관계; * 인접 블록 내 동일 계수 간의 크기 상관관계; * 다른 채널 내 동일 계수/블록 간의 크기 상관관계; * DC 계수를 함께 취하면 원본 이미지의 축소된 버전에 스케일링 인자가 곱해진 것과 유사하다. 연속 톤 이미지의 무손실 코딩을 위한 잘 알려진 방식이 적용될 수 있으며, JPEG에서 사용되는 허프먼 부호화된 DPCM보다 다소 더 나은 압축률을 달성한다. JPEG에는 DCT 계수 코딩 효율을 향상시키기 위한 표준이지만 거의 사용되지 않는 옵션이 이미 존재한다: 산술 코딩 옵션과 프로그레시브 코딩 옵션(각 계수에 대한 값이 독립적으로 코딩되고, 각 계수가 상당히 다른 분포를 가지므로 더 낮은 비트율을 생성한다). 현대적인 방법은 계수를 재정렬하여 더 큰 크기의 계수를 함께 그룹화하고; 인접 계수와 블록을 사용하여 새로운 계수 값을 예측하고; 블록 또는 계수를 통계 및 인접 값에 따라 소수의 독립적으로 코딩된 모델로 분할하고; 가장 최근에는 블록을 디코딩하고, 공간 영역에서 후속 블록을 예측한 다음, 이를 인코딩하여 DCT 계수에 대한 예측을 생성함으로써 이러한 기술을 개선했다. 일반적으로 이러한 방법은 기존 JPEG 파일을 15~25% 압축할 수 있으며, 저품질 설정으로 압축된 JPEG의 경우 최대 65%까지 개선할 수 있다. 팩JPG(packJPG)라는 무료 도구는 2007년 논문 "Improved Redundancy Reduction for JPEG Files"를 기반으로 한다. 2016년 버전 2.5k 기준으로, 트랜스코딩을 통해 일반적으로 20% 감소한다고 보고한다.url-status=live JPEG XL (ISO/IEC 18181)은 2018년에 유사한 트랜스코딩 감소를 보고한다.
# 스테레오스코픽 3D를 위한 파생 형식

## JPEG 스테레오스코픽
스테레오스코픽 .JPS 파일의 예시 JPS는 2D 이미지에서 3D 효과를 생성하는 데 사용되는 스테레오스코픽 JPEG 이미지이다. 이는 왼쪽 눈과 오른쪽 눈을 위한 두 개의 정적 이미지를 단일 JPG 파일에 나란히 인코딩한 것을 포함한다. JPEG 스테레오스코픽(JPS, 확장자 .jps)은 스테레오스코픽 이미지를 위한 JPEG 기반 형식이다.archive-date=2011-10-30Tim Kemp, JPS 파일 date=2009-01-18 JPEG APP3 마커 필드에 저장된 다양한 구성을 가지고 있지만, 일반적으로 교차 눈 방식(즉, 이미지의 오른쪽 절반에 왼쪽 프레임이 있고 그 반대도 마찬가지)으로 동일한 크기의 두 이미지를 나타내는 이중 너비 이미지를 포함한다. 이 파일 형식은 특수 소프트웨어 없이 JPEG로 볼 수 있으며, 다른 모드에서 렌더링하기 위해 처리될 수도 있다.
## JPEG 다중 사진 형식
url-status=live JPEG 멀티픽처 형식(MPO, 확장자 .mpo)은 단일 파일에 여러 이미지를 저장하기 위한 JPEG 기반 형식이다. 두 개 이상의 JPEG 파일을 연결하여 구성된다.archive-url=https://web.archive.org/web/20160405200235/http://cipa.jp/std/documents/e/DC-007_E.pdf 또한 이미지 설명을 위한 JPEG APP2 마커 세그먼트를 정의한다. 다양한 장치에서 3D 이미지를 저장하는 데 사용되며, 예를 들어 후지필름 파인픽스 리얼 3D W1, HTC 에보 3D, JVC GY-HMZ1U AVCHD/MVC 확장 캠코더, 닌텐도 3DS, 파나소닉 루믹스 DMC-TZ20, DMC-TZ30, DMC-TZ60, DMC-TS4 (FT4), 소니 DSC-HX7V 등이 있다. 다른 장치에서는 TV에 표시할 수 있는 "미리 보기 이미지"를 저장하는 데 사용된다. 최근 몇 년 동안 스테레오스코픽 이미지의 사용이 증가함에 따라, 과학계에서는 스테레오스코픽 이미지 압축을 위한 알고리즘을 개발하기 위해 많은 노력을 기울였다.
# 구현
JPEG 코덱의 매우 중요한 구현은 Independent JPEG Group의 자유 프로그래밍 라이브러리 **Libjpeg**이다. 1991년에 처음 발표되었으며 표준 성공의 핵심이었다. 이 라이브러리는 수많은 애플리케이션에서 사용되었다. 개발은 1998년에 조용해졌고, 2009년 버전 7로 Libjpeg이 다시 등장했을 때, 이전 버전과의 ABI 호환성이 깨졌다. 2010년 버전 8은 비표준 확장을 도입했는데, 이는 원본 IJG 리더인 Tom Lane에 의해 비판받았다.Tom Lane, 2013년 1월 16일: jpeg-9, API/ABI 호환성 및 이 프로젝트의 미래 역할 date=2018-12-04 **libjpeg-turbo**는 1998년 Libjpeg 6b에서 포크되었으며, SIMD 최적화를 통해 Libjpeg을 개선한다. 원래 Libjpeg의 유지 보수 포크로 여겨졌으나, 2009년 호환되지 않는 변경 이후 더욱 인기를 얻었다.libjpeg-turbo를 사용하거나 제공하는 소프트웨어 date=2017-03-18. 2012년 2월 9일.Issue 48789 – 크로뮴 – Libjpeg 대신 libjpeg-turbo 사용 date=2015-08-01. 2011년 4월 14일. 2019년에 ISO/IEC 10918-7 및 ITU-T T.873으로 ITU|ISO/IEC 참조 구현이 되었다.language=enwebsite=www.itu.int ISO/IEC 공동 사진 전문가 그룹은 JPEG XT 헤딩 아래에 다른 참조 소프트웨어 구현을 유지하고 있다. 이는 기본 JPEG(ISO/IEC 10918-1 및 18477-1)와 JPEG XT 확장(ISO/IEC 18477 Part 2 및 6-9), 그리고 JPEG-LS (ISO/IEC 14495)를 모두 인코딩할 수 있다.url-status=live 2016년, "JPEG on steroids"는 ISO JPEG XT 참조 구현의 옵션으로 도입되었다.s2cid=14922251 주어진 파일 크기에서 이미지 품질을 최대화하는 비전통적인 방식으로 JPEG를 인코딩하는 것에 대한 지속적인 관심이 있다. 2014년에 모질라는 웹 이미지를 위한 느리지만 고품질 인코더인 libjpeg-turbo에서 **MozJPEG**를 만들었다.url-status=live 2017년 3월, 구글은 Zopfli가 PNG 및 기타 무손실 데이터 형식에 대해 수행하는 것과 유사하게, 파일 크기를 줄이기 위해 인코딩 시간을 훨씬 더 오래 소요하는 오픈 소스 프로젝트 Guetzli를 출시했다.url-status=live 2024년 4월, Google은 새로운 JPEG 코딩 라이브러리인 **Jpegli**를 선보였으며, 이는 고품질 압축 설정에서 35%의 압축률 향상과 함께 향상된 기능을 제공하며, 코딩 속도는 MozJPEG와 비슷하다.date=3 April 2024
# 후속 형식
공동 사진 전문가 그룹은 원본 JPEG 형식의 기능을 보완하거나 대체하기 위한 몇 가지 새로운 표준을 개발했다.
## JPEG LS
JPEG LS 1993년에 시작되어 ISO-14495-1/ITU-T.87로 발행된 JPEG LS는 JPEG의 원본 무손실 구현보다 효율적인 저복잡도 무손실 파일 형식을 제공한다. 또한 무손실에 가까운 손실 모드도 특징이다. 그 기능은 주로 여기에 국한되며, 다른 측면에서는 원본 JPEG와 동일한 한계를 공유한다.
## JPEG 2000
JPEG 2000 JPEG 2000은 2000년 12월 ISO/IEC 15444로 발행되었다. 이는 이산 웨이블릿 변환(DWT)을 기반으로 하며, 원본 JPEG 표준을 완전히 대체하고 모든 면에서 능가하도록 설계되었다. 38비트/색상 채널 및 16384채널까지 허용하며, 다른 어떤 형식보다도 많고, 다양한 색상 공간을 지원하여 높은 동적 범위(HDR)를 제공한다. 또한, 알파 투명도 코딩, 수십억 픽셀 이미지(다른 어떤 형식보다도 많음) 및 무손실 압축을 지원한다. 강력한 압축 수준에서도 눈에 띄는 아티팩트가 훨씬 적고 손실 압축률이 크게 향상되었다.access-date=14 November 2023
## JPEG XT
JPEG XT JPEG XT (ISO/IEC 18477)는 2015년 6월에 발표되었으며, 기본 JPEG 형식에 더 높은 정수 비트 깊이(최대 16비트), 높은 동적 범위 이미지 및 부동 소수점 코딩, 무손실 코딩, 알파 채널 코딩에 대한 지원을 확장한다. 확장은 기본 JPEG/JFIF 파일 형식 및 8비트 손실 압축 이미지와 하위 호환된다. JPEG XT는 JFIF를 기반으로 하는 확장 가능한 파일 형식을 사용한다. 확장 계층은 JPEG 8비트 기본 계층을 수정하고 고해상도 이미지를 복원하는 데 사용된다. 기존 소프트웨어는 하위 호환되며 JPEG XT 이진 스트림을 읽을 수 있지만, 기본 8비트 계층만 디코딩한다.url-status=live
## JPEG XL
JPEG XL JPEG XL (ISO/IEC 18181)은 2021년에서 2022년 사이에 발표되었다. 이는 JPEG 형식을 새로운 DCT 기반의 로열티 프리 형식으로 대체하며, 전통적인 JPEG 이미지의 저장 옵션으로 효율적인 트랜스코딩을 허용한다.url-status=live 새로운 형식은 HEIF HM, Daala 및 WebP에서 보여주는 정지 이미지 압축 성능을 능가하도록 설계되었다. 수십억 픽셀 이미지, 픽셀당 최대 32비트의 높은 동적 범위를 적절한 전송 함수(PQ 및 HLG)로 지원하며, 비트맵 글꼴 및 그라디언트와 같은 합성 이미지의 패치 인코딩, 애니메이션 이미지, 알파 채널 코딩, 그리고 RGB/YCbCr/ICtCp 색상 인코딩 선택을 지원한다.year = 2019url-status=livecsnumber=77977csnumber=80617