JPEG
チェック済み
ページは変更保留のため保護されています

JPEG
圧縮率とそれに伴う損失が左から右に減少するヨーロッパヤマネコの写真
ファイル名拡張子
.jpg、、、、、.jpeg​.jpe.jif​.jfif​.jfi
インターネットメディアの種類
画像/jpeg
タイプコードJPEG
統一型識別子（UTI）パブリック.jpeg
魔法の数字ff d8 ff
開発者共同写真専門家グループ、IBM、三菱電機、AT&T、キヤノン株式会社[ 1 ]
初回リリース1992年9月18日 （1992年9月18日）
フォーマットの種類非可逆画像圧縮形式
圧縮ID
延長JPEG 2000
標準ISO/IEC 10918、ITU-T T.81、ITU-T T.83、ITU-T T.84、ITU-T T.86
Webサイトjpeg .org /jpeg /Wikidataで編集する
腹部CTスキャンの連続的に変化するJPEG圧縮（Q=100からQ=1の間）

JPEG（/ ˈ dʒ eɪ p ɛ ɡ / JAY -peg、Joint Photographic Experts Groupの略で、過去に遡ってJPEG 1と呼ばれることもある）[ 2 ] [ 3 ]は、デジタル画像、特にデジタル写真で作成された画像によく使用される非可逆圧縮方式です。圧縮度合いは調整可能で、ストレージサイズと画質の間で選択的なトレードオフが可能です。JPEG は通常、顕著ではあるものの、広く受け入れられている知覚可能な画質の損失を伴う 10:1 の圧縮を実現します。[ 4 ] JPEG は 1992 年の導入以来、世界で最も広く使用されている画像圧縮規格であり[ 5 ] [ 6 ]、最も広く使用されているデジタル画像形式で、2015 年現在、毎日数十億枚の JPEG 画像が作成されています。[ 7 ]

Joint Photographic Experts Group は1992 年に、離散コサイン変換(DCT) アルゴリズムに基づいて標準を作成しました。 [ 8 ] [ 9 ] [ 10 ] JPEG は、インターネット、そして後にソーシャルメディアにおけるデジタル画像とデジタル写真の普及に大きく貢献しました。[ 11 ] JPEG 圧縮は多くの画像ファイル形式で使用されています。JPEG/ Exif は、デジタルカメラやその他の写真画像キャプチャデバイスで使用される最も一般的な画像形式です。JPEG/ JFIFとともに、ワールドワイドウェブ上で写真画像を保存および転送するための最も一般的な形式です。[ 12 ]これらの形式のバリエーションは区別されないことが多く、単に JPEG と呼ばれます。

JPEGのMIMEメディアタイプは「image/jpeg」です。ただし、古いバージョンのInternet Explorerでは、JPEG画像をアップロードする際に「image/pjpeg」というMIMEタイプが提供されます。[ 13 ] JPEGファイルは通常、 「jpg」または「jpeg」というファイル名拡張子を持ちます。JPEG/JFIFは最大65,535×65,535ピクセルの画像サイズをサポートしており、[ 14 ]アスペクト比1:1の場合、最大4ギガピクセルまで対応します。2000年、JPEGグループは後継となるJPEG 2000というフォーマットを発表しましたが、JPEGに取って代わる主流の画像規格にはなりませんでした。[ 15 ]

歴史

背景

1992年に公開されたオリジナルのJPEG仕様は、CCITT（現在のITU-T ）とJoint Photographic Experts Groupによって引用された様々な初期の研究論文や特許のプロセスを実装しています。[ 1 ]

JPEGの非可逆圧縮アルゴリズムの基礎は離散コサイン変換（DCT）[ 9 ] [ 10 ]であり、これは1972年にナシル・アーメドによって画像圧縮技術として初めて提案されました[ 16 ] [ 10 ]。アーメドは1974年の論文[ 17 ]でT.ナタラジャンとKRラオと共同でDCTアルゴリズムを発表し、 JPEG仕様書にも引用されています[ 9 ] 。

JPEG仕様は複数の企業の特許を引用しています。以下の特許が算術符号化アルゴリズムの基礎となっています。[ 1 ]

  • IBM
  • 三菱電機
    • JP H02202267  ( 1021672 ) – 1989 年 1 月 21 日 – 木村敏弘、木野重典、小野文隆、吉田正幸 – コーディングシステム
    • JP H03247123  ( 2-46275 ) – 1990 年 2 月 26 日 – 木村知宏、木野重典、小野文隆、吉田正幸 – 符号化装置および符号化方法

JPEG仕様は、IBMの他の3つの特許も引用している。特許保有者として挙げられている他の企業には、AT&T（2件）とキヤノン株式会社がある。 [ 1 ]このリストには、 Compression LabsのWen-Hsiung ChenとDaniel J. Klenkeが1986年10月に出願した米国特許4,698,672号が含まれていない。この特許はDCTベースの画像圧縮アルゴリズムを規定しており、後に2002年に論争を巻き起こした（下記の特許論争を参照）。[ 18 ]しかし、JPEG仕様は、Wen-Hsiung Chenが1977年と1984年に発表した2つの先行研究論文を引用している。[ 1 ]

JPEG規格

「JPEG」はJoint Photographic Experts Group（合同写真専門家グループ）の略称で、JPEG規格およびその他の静止画像符号化規格を策定した委員会の名称です。「Joint」はISO TC97 WG8とCCITT SGVIIIの略称です。1986年に設立されたこのグループは、1980年代後半にJPEG規格を開発しました。同グループは1992年にJPEG規格を公開しました。[ 5 ]

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）の2つのサブグループの1つであり、静止画像の符号化と題されている。[ 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は以下の部分で構成されています。

連続階調静止画像のデジタル圧縮符号化 - 部品[ 20 ] [ 22 ] [ 25 ]
一部 ISO/IEC規格 ITU-T勧告 最初の公開日 最新の改正 タイトル 説明
パート1 ISO/IEC 10918-1:1994T.81 (09/92)1992年9月18日要件とガイドライン
パート2 ISO/IEC 10918-2:1995T.83 (11/94)1994年11月11日コンプライアンステスト ソフトウェア適合に関するルールとチェック (パート 1 に準拠)。
パート3 ISO/IEC 10918-3:1997T.84 (07/96)1996年7月3日1999年4月1日拡張機能 静止画像交換ファイル形式（SPIFF）を含む、パート1を改善するための拡張機能のセット。 [ 26 ]
パート4 ISO/IEC 10918-4:2024T.86 (06/98)1998年6月18日Appnマーカー JPEGを拡張するために使用されるパラメータの一部を登録する方法
パート5 ISO/IEC 10918-5:2013T.871 (05/11)2011年5月14日JPEG ファイル交換フォーマット (JFIF) JPEG規格でエンコードされた画像のファイル形式として事実上の標準となっている、広く普及したフォーマットです。2009年、JPEG委員会はJFIFをJPEG Part 5として標準化するためのアドホックグループを正式に設立しました。[ 27 ]
パート6 ISO/IEC 10918-6:2013T.872 (06/12)2012年6月印刷システムへの応用 印刷用に ISO/IEC 10918-1 に従ってエンコードされた画像を交換するための機能とアプリケーション ツールのサブセットを指定します。
パート7 ISO/IEC 10918-7:2023T.873 (06/21)2019年5月 2023年11月 リファレンスソフトウェア JPEGコアコーディングシステムのリファレンス実装を提供します

Ecma International TR /98はJPEGファイル交換フォーマット（JFIF）を規定しており、初版は2009年6月に発行されました。[ 28 ]

特許論争

2002年、フォージェント・ネットワークスは、1986年10月27日に出願され1987年10月6日に認可された特許（Compression Labsのウェン・ヒュン・チェンとダニエル・J・クレンケによる米国特許4,698,672 ）に起因するJPEG技術の特許権を所有しており、それを行使すると主張した。 [ 18 ] [ 29 ]当時フォージェントはCompression Labsを所有していなかったが、チェンは後にシスコで働く前にCompression Labsをフォージェントに売却した。これによりフォージェントが特許の所有権を取得した。[ 18 ]フォージェントの2002年の発表は、ユニシスがGIF画像圧縮規格に対する権利を主張しようとした時を 彷彿とさせる騒動を巻き起こした。

JPEG委員会は2002年に特許請求の範囲を調査し、先行技術によって無効であるとの見解を示しました。[ 30 ]この見解は様々な専門家によって共有されています。[ 18 ] [ 31 ]

2002年から2004年の間に、フォージェントは約30社に特許をライセンス供与することで約1億500万ドルの収益を得た。2004年4月、フォージェントはさらなるライセンス料の支払いを求めて31社を提訴した。同年7月、大手コンピュータ企業21社の連合が特許の無効化を目的とした反訴を起こした。さらに、マイクロソフトも2005年4月にフォージェントに対して別の訴訟を起こした。[ 32 ] 2006年2月、米国特許商標庁はパブリック・パテント・ファウンデーションの要請を受け、フォージェントのJPEG特許の再審査に同意した。[ 33 ] 2006年5月26日、USPTOは先行技術に基づき特許を無効と判断した。USPTOはまた、フォージェントが先行技術を認識していたにもかかわらず、特許庁への報告を意図的に避けていたと判断した。このため、特許の回復を求めるいかなる訴えも認められる可能性は極めて低かった。[ 34 ]

フォージェント社は1994年に欧州特許庁から同様の特許を取得しているが、その執行力がどの程度かは不明である。[ 35 ]

2006年10月27日現在、米国特許の20年の有効期間は満了したと見られ、2006年11月にフォージェントはJPEG標準の使用に対する特許請求の執行を放棄することに同意した。[ 36 ]

JPEG 委員会は、その標準規格 (特にベースライン方式) がライセンス料を支払うことなく実装可能であることを明確な目標の 1 つとしており、 20 を超える大規模な組織からJPEG 2000標準規格に対する適切なライセンス権を確保しています。

2007年8月初旬、別の会社であるGlobal Patent Holdings, LLCは、1993年に発行された特許（米国特許5,253,341）が、ウェブサイトまたは電子メールを介したJPEG画像のダウンロードによって侵害されていると主張しました。無効とされなければ、この特許はJPEG画像を表示するあらゆるウェブサイトに適用される可能性があります。この特許は、2000年から2007年まで米国特許商標庁によって再審査されていました。2007年7月、特許庁は特許の元のクレームをすべて取り消しましたが、Global Patent Holdingsが提案した追加のクレーム（クレーム17）は有効であると判断しました。[ 37 ] Global Patent Holdingsはその後、特許のクレーム17に基づいて数件の訴訟を起こしました。

再審査後の最初の2件の訴訟はいずれもイリノイ州シカゴで起こされ、Global Patent Holdingsは、 Green Bay Packers、CDW、Motorola、Apple、Orbitz、Officemax、Caterpillar、Kraft、Peapodを被告として訴えた。3件目の訴訟は2007年12月5日に南フロリダでADT Security Services、AutoNation、Florida Crystals Corp.、HearUSA、MovieTickets.com、Ocwen Financial Corp.、Tire Kingdomを相手取って起こされ、4件目の訴訟は2008年1月8日に南フロリダでBoca Raton Resort & Clubを相手取って起こされた。5件目の訴訟はGlobal Patent Holdingsを相手取ってネバダ州で起こされた。この訴訟はGlobal Patent Holdingsから脅迫を受けたとされるZappos.com , Inc.が起こしたもので、'341特許は無効であり侵害されていないという司法宣言を求めた。

グローバル・パテント・ホールディングスは、グレゴリー・アハロニアン[ 38 ]や「パテント・トロール・トラッカー」として知られるウェブサイトブログの匿名運営者[ 39 ]など、広範なソフトウェア特許に対する批判者を訴えたり脅迫したりするために、'341特許を利用していた。 2007年12月21日、シカゴの特許弁護士ヴァーノン・フランシセンは、米国特許商標庁に対し、新たな先行技術に基づいて、'341特許の唯一の残存請求項を再審査するよう要請した。[ 40 ]

2008年3月5日、米国特許商標庁は、新たな先行技術が特許の有効性に関して重大な新たな疑問を提起していると判断し、'341特許の再審査に同意した。[ 41 ]再審査の結果を受けて、係属中の5件の訴訟のうち4件の侵害被疑者は、米国特許商標庁による'341特許の審査が完了するまで訴訟を一時停止（停止）する申立てを行った。2008年4月23日、イリノイ州シカゴで2件の訴訟を担当する判事は、これらの申立てを認めた。[ 42 ] 2008年7月22日、特許庁は2回目の再審査における最初の「オフィスアクション」を発行し、19の個別の根拠に基づき、当該クレームは無効であると判定した。[ 43 ] 2009年11月24日、すべてのクレームを取り消す再審査証明書が発行された。

2011年から2013年初頭にかけて、テキサス州東部に拠点を置くプリンストン・デジタル・イメージ・コーポレーション[ 44 ]は、米国特許4,813,056号を侵害したとして多数の企業を提訴し始めた。プリンストンは、JPEG画像圧縮規格が特許4,813,056号を侵害していると主張し、多数のウェブサイト、小売業者、カメラおよび機器メーカー、再販業者を提訴している。この特許は元々ゼネラル・エレクトリック社が所有し、譲渡していた。この特許は2007年12月に失効したが、プリンストンはこの特許の「過去の侵害」を理由に多数の企業を提訴している。 （米国特許法では、特許権者は訴訟提起の6年前まで「過去の侵害」を理由に訴訟を起こすことができるため、プリンストンは理論上、2013年12月まで企業を訴え続けることができた。）2013年3月時点で、プリンストンはニューヨーク州とデラウェア州で55社以上の企業を相手取った訴訟を係属中であった。ゼネラル・エレクトリックがこの訴訟に関与していたかどうかは不明であるが、裁判記録によると、同社は2009年にプリンストンに特許を譲渡し、特許に関する一定の権利を保持している。[ 45 ]

典型的な用途

JPEG圧縮アルゴリズムは、滑らかな色調の変化を持つ写実的な風景の写真や絵画に最適です。レスポンシブなプレゼンテーションを実現するために画像データ量の削減が重要なWeb用途では、JPEGの圧縮率の高さからJPEGが広く使用されています。JPEG/ Exifは、デジタルカメラで保存される最も一般的な形式でもあります。

しかし、JPEGは線画やその他のテキストやアイコンのグラフィックには適していません。隣接するピクセル間の強いコントラストが目立つアーティファクトを引き起こす可能性があるためです。[ 46 ]このような画像は、 TIFF、GIF、PNG、またはRAW画像形式などのロスレスグラフィック形式で保存する方が適切です。JPEG規格にはロスレスコーディングモードが含まれていますが、ほとんどの製品ではサポートされていません。

JPEGは一般的に非可逆圧縮方式であり、画像の忠実度が低下するため、画像データの正確な再現（一部の科学・医療用画像処理アプリケーションや特定の技術画像処理作業など）には適していません。[ 46 ]

JPEGは、画像が再圧縮されるたびに画質が多少低下するため、複数回の編集が行われるファイルには適していません。特に、画像が切り取られたり、シフトされたり、エンコードパラメータが変更されたりすると、画質が低下します（詳細はデジタル生成ロスを参照）。連続編集や繰り返し編集による画像情報の損失を防ぐには、最初の編集をロスレス形式で保存し、その後もロスレス形式で編集を行い、最終的にJPEG形式で公開して配布するという方法があります。

JPEG圧縮

JPEG は、離散コサイン変換 (DCT)に基づく非可逆圧縮形式を使用します。この数学的演算により、ビデオ ソースの各フレーム/フィールドが空間 (2D) 領域から周波数領域 (別名、変換領域) に変換されます。これは、人間の心理視覚システムが高周波数情報 (つまり、明度と色相の急激な変化) をどのように破棄するかに大まかに基づいた知覚モデルです。変換領域では、情報を削減するプロセスは量子化と呼ばれます。簡単に言えば、量子化とは、大きな数値スケール (各数値の出現頻度が異なる) をより小さなスケールに最適に削減する方法であり、変換領域は画像を表現するのに便利です。これは、他の係数よりも画像全体への寄与が少ない高周波数係数が、圧縮率の高い小さな値であるという特性があるためです。量子化された係数は、その後、順序付けされ、出力ビットストリームに可逆的にパックされます。JPEG のほぼすべてのソフトウェア実装では、ユーザーが圧縮率 (およびその他のオプション パラメーター) を制御できるため、画質を犠牲にしてファイル サイズを小さくすることができます。組み込みアプリケーション (同様の DCT 圧縮方式を使用する miniDV など) では、パラメータはアプリケーションに対して事前に選択され、固定されます。

圧縮方式は通常、非可逆圧縮です。つまり、元の画像情報の一部が失われ、復元できないため、画質に影響する可能性があります。JPEG規格では、オプションとしてロスレスモードが定義されています。ただし、このモードは多くの製品でサポートされていません。

インターレース・プログレッシブJPEG形式も存在します。この形式では、データは複数のパスで段階的に高精細化され、圧縮されます。これは、低速回線でダウンロードしながら表示する大きな画像に最適で、データの一部のみを受信した場合でも、十分なプレビューが可能です。ただし、プログレッシブJPEG形式は広くサポートされているわけではありません。プログレッシブJPEG形式をサポートしていないプログラム（Windows 7より前のバージョンのInternet Explorerなど）[ 47 ]でプログレッシブJPEG形式を受信すると、ソフトウェアは画像が完全にダウンロードされた後にのみ表示します。

医療画像、交通情報、カメラなどのアプリケーションの中には、12ビットJPEG画像（グレースケールとカラーの両方）を作成・処理するものもあります。12ビットJPEG形式は、JPEG仕様の拡張部分に含まれています。libjpegコーデックは12ビットJPEGをサポートしており、高性能版も存在します。[ 48 ]

ロスレス編集

画像サイズが1MCUブロック（最小符号化単位）の倍数（通常、4:2:0クロマサブサンプリングでは両方向とも16ピクセル）である限り、JPEG画像へのいくつかの変更はロスレス（つまり、再圧縮やそれに伴う画質の低下なし）で実行できます。これを実装するユーティリティには、以下が含まれます。

  • jpegtranとその GUI、Jpegcrop。
  • IrfanView は「JPG Lossless Crop (PlugIn)」と「JPG Lossless Rotation (PlugIn)」を使用します。これには JPG_TRANSFORM プラグインのインストールが必要です。
  • 「ロスレス クロップ トゥ ファイル」と「JPEG ロスレス 回転」を使用するFastStone 画像ビューア。
  • 「JPEG ロスレス変換」を使用するXnViewMP 。
  • ACDSee は、「ロスレス JPEG 操作を強制」オプションを使用してロスレス回転 (ロスレス クロッピングはサポートしません) をサポートします。

ブロックは90度単位で回転したり、水平、垂直、対角軸で反転したり、画像内で移動したりできます。元の画像のすべてのブロックを修正後の画像で使用する必要はありません。

JPEG画像の上端と左端は8×8ピクセル（MCUサイズが大きい場合は16×16ピクセル）のブロック境界上になければなりませんが、下端と右端は必ずしもそうである必要はありません。これにより、ロスレスクロップ処理の可能性が制限され、下端または右端が全チャンネルのブロック境界上にない画像の反転や回転が防止されます（ブロック境界が必須である上端または左端にエッジが重なるためです）。

画像が8または16の倍数（彩度サブサンプリングの度合いによって異なる）でない場合の回転はロスレスではありません。このような画像を回転すると、ブロックが再計算され、画質が低下します。[ 49 ]

ロスレスクロッピングを使用する場合、クロップ領域の下部または右側がブロック境界上にない場合、部分的に使用されたブロックの残りのデータはクロップされたファイルに残り、復元できます。また、ベースライン形式とプログレッシブ形式の間では、係数がファイル内に配置される順序のみが異なるため、品質を損なうことなく変換できます。

さらに、複数の JPEG 画像は、同じ品質で保存され、エッジがブロック境界と一致している限り、ロスレスで結合できます。

JPEGファイル

「JPEG交換フォーマット」（JIF）として知られるファイル形式は、この規格の附属文書Bで規定されています。しかし、この「純粋な」ファイル形式は、主に規格のあらゆる側面を完全に実装したエンコーダとデコーダのプログラミングの難しさ、そして規格自体にいくつかの欠点があることから、ほとんど使用されていません。

  • 色空間の定義
  • コンポーネントサブサンプリング登録
  • ピクセルアスペクト比の定義。

これらの問題に対処するため、いくつかの追加規格が開発されました。最初の規格は1992年にリリースされたJPEGファイル交換フォーマット（JFIF）で、近年ではExif（ Exchangeable image file format）とICCカラープロファイルがそれに続きました。これらのフォーマットはどちらも、異なるマーカーで構成されるJIFバイトレイアウトを使用していますが、さらにJIF規格の拡張ポイントの1つであるアプリケーションマーカーも採用しています。JFIFはAPP0を使用し、ExifはAPP1を使用します。JIF規格で将来使用するために残され、JIF規格では読み込まれないファイルセグメント内に、これらの規格は特定のメタデータを追加します。

したがって、JFIFは、特定の制約（例えば、すべての異なるエンコードモードを許可しないなど）を規定している点で、ある意味ではJIF標準の簡略版である一方、メタデータが追加されているため、別の意味ではJIFの拡張版であると言える。オリジナルのJFIF標準のドキュメントには、次のように記載されている。[ 50 ]

JPEGファイル交換フォーマットは、JPEGビットストリームを様々なプラットフォームやアプリケーション間で交換するための最小限のファイルフォーマットです。この最小限のフォーマットには、TIFF JPEG仕様やアプリケーション固有のファイルフォーマットに見られるような高度な機能は含まれていません。また、この簡素化されたフォーマットの唯一の目的はJPEG圧縮画像の交換を可能にすることであるため、これらの機能は含まれるべきではありません。

JPEG圧縮方式を採用した画像ファイルは一般に「JPEGファイル」と呼ばれ、JIF画像形式のバリエーションで保存されます。JPEGを出力する画像キャプチャデバイス（デジタルカメラなど）のほとんどは、実際にはカメラ業界がメタデータ交換のために標準化したExif形式でファイルを作成しています。一方、Exif規格ではカラープロファイルが許可されていないため、ほとんどの画像編集ソフトウェアはJPEGをJFIF形式で保存し、ExifファイルのAPP1セグメントをほぼ準拠した方法でメタデータとして取り込みます。JFIF規格はある程度柔軟に解釈されます。[ 51 ]

厳密に言えば、JFIF規格とExif規格は互換性がありません。なぜなら、それぞれの規格では、マーカーセグメント（それぞれAPP0またはAPP1）が最初に出現するように規定されているからです。実際には、ほとんどのJPEGファイルには、Exifヘッダーの前にJFIFマーカーセグメントが含まれています。これにより、古い形式のリーダーは古い形式のJFIFセグメントを正しく処理できますが、新しいリーダーは、先頭に出現することの要件をそれほど厳しくせずに、後続のExifセグメントもデコードします。

JPEGファイル名拡張子

JPEG圧縮を使用するファイルの最も一般的なファイル名拡張子はと.jpgですが.jpeg、、も使用されます。[ 52 ] JPEGデータは他のファイルタイプに埋め込むことも可能です。TIFFで.jpeエンコードされたファイルには、メイン画像のサムネイルとしてJPEG画像が埋め込まれることが多く、 MP3ファイルにはID3v2タグにカバーアートのJPEGを含めることができます。 .jfif.jif

カラープロファイル

多くのJPEGファイルにはICCカラープロファイル（カラースペース）が埋め込まれています。一般的に使用されるカラープロファイルには、 sRGBやAdobe RGBなどがあります。これらのカラースペースは非線形変換を使用するため、8ビットJPEGファイルのダイナミックレンジは約11ストップです。ガンマカーブを参照してください。

画像にカラープロファイル情報が指定されていない場合（タグなし）、ウェブページに表示するためにカラースペースはsRGBであるとみなされます。[ 53 ] [ 54 ]

構文と構造

JPEG画像は、一連のセグメントで構成されます。各セグメントはマーカーで始まり、各マーカーは0xFFバイトで始まり、その後にマーカーの種類を示すバイトが続きます。マーカーの中には、この2バイトのみで構成されるものもあれば、2バイト（上位バイト、下位バイト）が続くものもあります。この2バイトは、マーカー固有のペイロードデータの長さを示します。（長さには、長さを表す2バイトが含まれますが、マーカーを表す2バイトは含まれません。）一部のマーカーの後にはエントロピー符号化データが続きますが、そのようなマーカーの長さにはエントロピー符号化データは含まれません。連続する0xFFバイトはパディング用のフィルバイトとして使用されますが、このフィルバイトによるパディングは、エントロピー符号化スキャンデータの直後に続くマーカーに対してのみ行われるべきです（詳細はJPEG仕様のセクションB.1.1.2およびE.1.2を参照してください。特に「圧縮データの後にマーカーが追加されるすべてのケースにおいて、オプションの0xFFフィルバイトがマーカーの前にあっても構いません」）。

エントロピー符号化データ内では、0xFFバイトの後に、次のバイトの前にエンコーダによって0x00バイトが挿入されます。これにより、本来マーカーがない場所にマーカーがあるようには見えなくなり、フレーミングエラーを防止できます。デコーダはこの0x00バイトをスキップする必要があります。バイトスタッフィングと呼ばれるこの手法（JPEG仕様セクションF.1.2.3を参照）は、エントロピー符号化データにのみ適用され、マーカーペイロードデータには適用されません。ただし、エントロピー符号化データには独自のマーカーがいくつかあることに注意してください。具体的には、リセットマーカー（0xD0～0xD7）は、エントロピー符号化データの独立したチャンクを分離して並列デコードを可能にするために使用されます。エンコーダはこれらのリセットマーカーを一定の間隔で自由に挿入できます（ただし、すべてのエンコーダがこれを実行するわけではありません）。

一般的なJPEGマーカー[ 55 ]
短縮名 バイト ペイロード 名前 コメント
ソイ 0xFF、0xD8なし画像の開始
ソフ0 0xFF、0xC0可変サイズフレームの開始（ベースラインDCT） これはベースライン DCT ベースの JPEG であることを示し、幅、高さ、コンポーネントの数、およびコンポーネントのサブサンプリング (例: 4:2:0) を指定します。
SOF2 0xFF、0xC2可変サイズフレームの開始（プログレッシブ DCT） これはプログレッシブ DCT ベースの JPEG であることを示し、幅、高さ、コンポーネントの数、およびコンポーネントのサブサンプリング (例: 4:2:0) を指定します。
DHT 0xFF、0xC4可変サイズハフマンテーブルを定義する 1 つ以上のハフマン テーブルを指定します。
DQT 0xFF、0xDB可変サイズ量子化テーブルを定義する 1 つ以上の量子化テーブルを指定します。
ドライ 0xFF、0xDD4バイト再起動間隔を定義する RST nマーカー間の間隔を最小符号化単位（MCU）で指定します。このマーカーの後には、固定サイズを示す2バイトが続くため、他の可変サイズセグメントと同様に扱うことができます。
SOS 0xFF、0xDA可変サイズスキャン開始 画像の上から下へのスキャンを開始します。ベースラインDCT JPEG画像では通常、スキャンは1回のみです。プログレッシブDCT JPEG画像では通常、複数のスキャンが含まれます。このマーカーは、どのデータスライスが含まれるかを指定し、その直後にエントロピー符号化されたデータが続きます。
RST n0xFF、0xD n ( n =0..7)なし再起動 rマクロブロックごとに挿入されます。ここでrはDRIマーカーによって設定された再開間隔です。DRIマーカーがない場合には使用されません。マーカーコードの下位3ビットは0から7までの値を循環します。
アプリn0xFF、0xE n可変サイズアプリケーション固有 たとえば、Exif JPEG ファイルは、 TIFFに基づいた構造でレイアウトされたメタデータを保存するために APP1 マーカーを使用します。
コム 0xFF、0xFE可変サイズコメント テキストコメントが含まれます。
EOI 0xFF、0xD9なし画像の終わり

他の種類の JPEG エンコーディングを導入する 他のStart Of Frameマーカーもあります。

複数のベンダーが同じ APP nマーカー タイプを使用する可能性があるため、アプリケーション固有のマーカーは、標準名またはベンダー名 (「Exif」や「Adobe」など) またはその他の識別文字列で始まることがよくあります。

リスタートマーカーでは、ブロック間の予測変数がリセットされ、ビットストリームはバイト境界に同期されます。リスタートマーカーは、信頼性の低いネットワークを介した伝送やファイル破損などのビットストリームエラーからの回復手段を提供します。リスタートマーカー間のマクロブロックの連続は独立してデコードできるため、これらの連続は並列にデコードできます。

JPEGコーデックの例

JPEGファイルは様々な方法でエンコードできますが、最も一般的なのはJFIFエンコードです。エンコードプロセスはいくつかのステップで構成されます。

  1. 画像の色表現はRGBからY′C B C Rに変換されます。Y′C B C Rは、明るさを表す1つの輝度成分（Y′）と、色を表す2つの彩度成分（C BとC R）で構成されます。このステップは省略される場合もあります。
  2. 彩度データの解像度は、通常 2 分の 1 または 3 分の 1 に低減されます。これは、目が明るさの細部よりも色の細部に対して敏感ではないという事実を反映しています。
  3. 画像は8×8ピクセルのブロックに分割され、各ブロックのY、C、 B 、C 、 Rの各データに対して離散コサイン変換（DCT）が行われます。DCTは、一種の空間周波数スペクトルを生成するという点でフーリエ変換に似ています。
  4. 周波数成分の振幅は量子化される。人間の視覚は、高周波の輝度変化の強さよりも、広い領域における色や輝度の小さな変化にはるかに敏感である。そのため、高周波成分の振幅は低周波成分よりも低い精度で保存される。エンコーダの品質設定（例えば、Independent JPEG Groupのライブラリ[ 56 ]では0～100のスケールで50や95など）は、各周波数成分の解像度がどの程度低下するかに影響する。極端に低い品質設定が使用されると、高周波成分は完全に破棄される。
  5. すべての 8×8 ブロックの結果データは、ハフマン符号化の変形であるロスレス アルゴリズムを使用してさらに圧縮されます。

デコード処理では、量子化は不可逆であるため、これらの手順を逆に実行します。このセクションの残りの部分では、エンコードとデコードの処理についてより詳しく説明します。

エンコーディング

JPEG規格のオプションの多くは一般的には使用されていません。前述の通り、ほとんどの画像ソフトウェアはJPEGファイルを作成する際に、よりシンプルなJFIF形式を使用しています。この形式では、エンコード方式などが規定されています。ここでは、1ピクセルあたり24ビット（赤、緑、青それぞれ8ビット）の入力データに適用する場合の、より一般的なエンコード方式の1つについて簡単に説明します。このオプションは非可逆圧縮方式です。これらのオプションは、以下のマトリックスで表されます。

色空間変換

まず、画像をRGB（デフォルトではsRGB [ 53 ] [ 54 ]だが、他の色空間も可能）からY′C B C R（または、非公式にはYCbCr）と呼ばれる異なる色空間に変換する必要があります。この色空間には、Y'、C B、およびC Rの3つの要素があります。Y'要素はピクセルの明るさを表し、C BおよびC R要素は彩度（青と赤の要素に分割）を表します。これは基本的に、デジタルカラーテレビやビデオDVDなどのデジタルビデオで使用されている色空間と同じです。Y′C B C R色空間変換により、知覚的な画質に大きな影響を与えることなく、より高い圧縮率を実現できます（または、同じ圧縮率でより高い知覚的な画質を実現できます）。最終的な画像の知覚的な品質にとってより重要な明るさの情報が1つのチャネルに限定されるため、圧縮効率が向上します。これは、人間の視覚システムにおける色の知覚に近いものです。また、色変換により、統計的な相関除去によって圧縮率も向上します。

JFIF規格では、Y′C B C Rへの特別な変換が規定されており、JPEGファイルの互換性を最大限に高めるためには、この変換を行う必要があります。しかし、「最高品質」モードの一部のJPEG実装では、この変換処理を適用せず、代わりにRGBカラーモデルで色情報を保持します。この場合、画像は赤、緑、青の輝度成分ごとに別々のチャネルに格納されます。これにより圧縮効率が低下し、ファイルサイズが特に重要な場合には使用されない可能性があります。

ダウンサンプリング

人間の目には色と明るさに敏感な受容体が密集しているため、人間は画像の色相と彩度（Cb成分とCr成分）よりも、画像の明るさ（Y'成分）においてはるかに細かいディテールを認識することができます。この知識を活用することで、より効率的に画像を圧縮するエンコーダを設計することができます。

Y′C B C Rカラーモデルへの変換により、次に行われる通常のステップ、つまり Cb および Cr 成分の空間解像度を下げる処理（「ダウンサンプリング」または「クロマサブサンプリング」と呼ばれる）が可能になります。JPEG 画像で通常行われるダウンサンプリングの比率は、4:4:4（ダウンサンプリングなし）、4:2:2（水平方向に 2 分の 1 に縮小）、または（最も一般的には）4:2:0（水平方向と垂直方向の両方で 2 分の 1 に縮小）です。圧縮プロセスの残りの部分では、Y′、Cb、および Cr はそれぞれ非常によく似た方法で個別に処理されます。

ブロック分割

サブサンプリング後、各チャンネルは8×8のブロックに分割されます。クロマサブサンプリングの方式に応じて、8×8（4:4:4 - サブサンプリングなし）、16×8（4:2:2）、または最も一般的には16×16（4:2:0）の最小符号化単位（MCU）ブロックが生成されます。ビデオ圧縮では、MCUはマクロブロックと呼ばれます。

チャンネルのデータが整数個のブロックを表さない場合、エンコーダーは不完全なブロックの残りの領域を何らかのダミーデータで埋める必要があります。エッジを固定色（例えば黒）で塗りつぶすと、境界の可視部分にリンギングアーティファクトが発生する可能性があります。エッジピクセルを繰り返すことは、このようなアーティファクトを軽減する（必ずしも完全に除去できるわけではありません）一般的な手法であり、より高度な境界塗りつぶし手法を適用することもできます。

離散コサイン変換

8ビットグレースケールで表示された8×8のサブイメージ

次に、各成分（Y、Cb、Cr）の8×8ブロックそれぞれが、正規化された2次元タイプII離散コサイン変換（DCT）を用いて周波数領域表現に変換されます。離散コサイン変換については、引用文献1を参照してください。DCTは、離散コサイン変換などの変換群の文脈では「タイプII DCT」と呼ばれることもあり、対応する逆変換（IDCT）は「タイプIII DCT」と呼ばれます。

たとえば、8×8 8ビットのサブイメージは次のようになります。

[52556166706164736359559010985697262596811314410466736358711221541067069676168104126886870796560707768587585716459556165838779696865767894]。{\displaystyle \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を計算する前に、その値は正の範囲からゼロを中心とした範囲にシフトされます。8ビット画像の場合、元のブロックの各エントリは範囲 に含まれます。範囲の中点（この場合は値128）が各エントリから差し引かれ、ゼロを中心としたデータ範囲が生成されます。これにより、修正された範囲は になります。このステップにより、後続のDCT処理段階でのダイナミックレンジ要件が削減されます。 [0、255]{\displaystyle [0,255]}[−128、127]{\displaystyle [-128,127]}

このステップの結果、次の値が生成されます。

グラム＝×⟶[−76−73−67−62−58−67−64−55−65−69−73−38−19−43−59−56−66−69−60−1516−24−62−55−65−70−57−626−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]↓y。{\displaystyle 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\\-6 1&-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基底関数と呼ばれ、出力値は変換係数と呼ばれます。水平インデックスは、垂直インデックスは です。あなた{\displaystyle u}v{\displaystyle v}

次のステップは、次のように表される 2 次元 DCT を実行することです。

 Gu,v=14α(u)α(v)∑x=07∑y=07gx,ycos⁡[(2x+1)uπ16]cos⁡[(2y+1)vπ16]{\displaystyle \ 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{\displaystyle \ u}は水平空間周波数で、整数です。 0≤u<8{\displaystyle \ 0\leq u<8}
  •  v{\displaystyle \ v}は垂直空間周波数で、整数です。 0≤v<8{\displaystyle \ 0\leq v<8}
  • α(u){\displaystyle \alpha (u)}そして、変換を直交させるためにスケール係数を正規化している。α(v){\displaystyle \alpha (v)}α(i)={12,if i=01,otherwise{\displaystyle \alpha (i)={\begin{cases}{\frac {1}{\sqrt {2}}},&{\mbox{if }}i=0\\1,&{\mbox{otherwise}}\end{cases}}}
  •  gx,y{\displaystyle \ g_{x,y}}座標のピクセル値です (x,y){\displaystyle \ (x,y)}
  •  Gu,v{\displaystyle \ G_{u,v}}座標におけるDCT係数である (u,v).{\displaystyle \ (u,v).}

上記の行列にこの変換を実行すると、次のようになります (小数点以下 2 桁に丸められます)。

G=u⟶[−415.38−30.19−61.2027.2456.12−20.10−2.390.464.47−21.86−60.7610.2513.15−7.09−8.544.88−46.837.3777.13−24.56−28.919.935.42−5.65−48.5312.0734.10−14.76−10.246.301.831.9512.12−6.55−13.20−3.95−1.871.75−2.793.14−7.732.912.38−5.94−2.380.944.301.85−1.030.180.42−2.42−0.88−3.024.12−0.66−0.170.14−1.07−4.19−1.17−0.100.501.68]↓v.{\displaystyle 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係数（交流成分とも呼ばれます）です。[ 57 ] DCTの利点は、上記のように、信号の大部分を結果の片隅に集約する傾向があることです。続く量子化ステップでは、この効果が強調されると同時に、DCT係数の全体的なサイズが縮小され、エントロピー段階で効率的に圧縮しやすい信号が生成されます。

DCTは、8ビット/コンポーネント画像のDCT係数の保存に最大11ビット以上（DCT計算の忠実度によって異なります）を要するため、データのビット深度を一時的に増加させます。これにより、コーデックはこれらの係数を保持するために一時的に16ビットの数値を使用する必要があり、この時点で画像表現のサイズが2倍になります。これらの値は通常、量子化ステップによって8ビット値に戻されます。この段階での一時的なサイズの増加は、ほとんどのJPEG実装ではパフォーマンス上の問題にはなりません。これは、通常、画像のエンコードまたはデコード処理中、完全なDCT形式で保存されるのは画像のごく一部だけであるためです。

量子化

人間の目は、比較的広い範囲における小さな明るさの違いを見分けるのは得意ですが、高周波数の明るさの変化の強さを正確に見分けるのは得意ではありません。そのため、高周波成分の情報量を大幅に削減することができます。これは、周波数領域の各成分をその成分の定数で単純に割り、最も近い整数に丸めるだけで実現できます。DCT計算が十分に高い精度で実行されている場合、この丸め操作は、処理全体の中で（クロマサブサンプリングを除く）唯一のロスのある操作です。この結果、通常、高周波成分の多くはゼロに丸められ、残りの多くは小さな正または負の数となり、表現に必要なビット数が大幅に少なくなります。

量子化マトリックスの要素は圧縮率を制御し、値が大きいほど圧縮率も高くなります。典型的な量子化マトリックス（元のJPEG規格で規定されている品質50%の場合）は以下のとおりです。

Q=[1611101624405161121214192658605514131624405769561417222951878062182237566810910377243555648110411392496478871031211201017292959811210010399].{\displaystyle 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係数は次のように計算される。

Bj,k=round(Gj,kQj,k) for j=0,1,2,…,7;k=0,1,2,…,7{\displaystyle 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}

ここで、 は量子化されていない DCT 係数、は上記の量子化行列、 は量子化された DCT 係数です。 G{\displaystyle G}Q{\displaystyle Q}B{\displaystyle B}

この量子化行列を上記の DCT 係数行列と併用すると、次のようになります。

左：一連の基底関数から最終的な画像が構築されます。右：画像を構成する各DCT基底関数と、対応する重み係数。中央：係数を乗じた基底関数。この要素が最終画像に追加されます。この例では、見やすくするために、8×8マクロブロックを双線形補間によって10倍に拡大しています。
B=[−26−3−622−1000−2−411000−315−1−1000−312−1000010000000000000000000000000000000].{\displaystyle 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係数）を使用し、最も近い整数に丸めると、

round(−415.3716)=round(−25.96)=−26.{\displaystyle \mathrm {round} \left({\frac {-415.37}{16}}\right)=\mathrm {round} \left(-25.96\right)=-26.}

サブブロックの高周波要素のほとんど (つまり、xまたはy空間周波数が 4 を超える要素) はゼロ値に量子化されていることに注意してください。

エントロピー符号化

JPEG画像コンポーネントのジグザグ順序

エントロピー符号化は、ロスレスデータ圧縮の特殊な形式です。画像成分を「ジグザグ」に並べ、類似周波数をグループ化するランレングス符号化（RLE）アルゴリズムを用いて、長さ符号化のゼロを挿入し、残った成分に ハフマン符号化を適用します。

JPEG規格では、デコーダが算術符号化をサポートすることも許可されていますが、必須ではありません。算術符号化は数学的にはハフマン符号化よりも優れています。しかし、この機能は歴史的にロイヤリティ負担を伴うライセンスを必要とする特許で保護されており、またハフマン符号化に比べてエンコードとデコードが遅いため、ほとんど使用されていません。算術符号化は通常、ファイルサイズを約5～7%小さくします。[ 58 ]

前回の量子化DC係数は、現在の量子化DC係数を予測するために使用されます。実際の値ではなく、両者の差が符号化されます。63個の量子化AC係数の符号化では、このような予測差分は使用されません。

上記の量子化係数のジグザグシーケンスを以下に示します。（示されている形式は、理解と表示を容易にするためのものです。）

−26
−30
−3−2−6
2−41−3
11512
−11−1200
000−1−100
00000000
0000000
000000
00000
0000
000
00
0

i番目のブロックが で表され、各ブロック内の位置が で表され（および）、DCT 画像内の任意の係数は で表すことができます。したがって、上記の方式では、 （ i番目のブロックの ）ピクセルのエンコード順序は、...Bi{\displaystyle B_{i}}(p,q){\displaystyle (p,q)}p=0,1,...,7{\displaystyle p=0,1,...,7}q=0,1,...,7{\displaystyle q=0,1,...,7}Bi(p,q){\displaystyle B_{i}(p,q)}Bi(0,0){\displaystyle B_{i}(0,0)}Bi(0,1){\displaystyle B_{i}(0,1)}Bi(1,0){\displaystyle B_{i}(1,0)}Bi(2,0){\displaystyle B_{i}(2,0)}Bi(1,1){\displaystyle B_{i}(1,1)}Bi(0,2){\displaystyle B_{i}(0,2)}Bi(0,3){\displaystyle B_{i}(0,3)}Bi(1,2){\displaystyle B_{i}(1,2)}

ベースラインのシーケンシャルJPEGエンコードおよびデコードプロセス

このエンコード モードは、ベースラインシーケンシャルエンコードと呼ばれます。ベースライン JPEG は、プログレッシブエンコードもサポートしています。シーケンシャル エンコードでは 1 度に 1 つのブロックの係数を (ジグザグに) エンコードしますが、プログレッシブ エンコードでは、すべてのブロックの係数の同様の位置にあるバッチ (スキャン と呼ばれる)を 1 回でエンコードし、その後にすべてのブロックの次の係数のバッチをエンコードする、というように繰り返します。たとえば、画像が N 個の 8×8 ブロック に分割されている場合、3 スキャン プログレッシブ エンコードでは、最初のスキャンですべてのブロックの DC 成分、つまりすべての についてをエンコードします。その後に 2 番目のスキャンが続き、そこではさらにいくつかの成分 (さらに 4 つの成分があると仮定すると、それらはから まで、依然としてジグザグに) の係数をすべてのブロック (したがって、シーケンスは) の係数をエンコードし、最後のスキャンですべてのブロックの残りの係数をすべてエンコードします。 B0,B1,B2,...,Bn−1{\displaystyle B_{0},B_{1},B_{2},...,B_{n-1}}Bi(0,0){\displaystyle B_{i}(0,0)}i=0,1,2,...,N−1{\displaystyle i=0,1,2,...,N-1}Bi(0,1){\displaystyle B_{i}(0,1)}Bi(1,1){\displaystyle B_{i}(1,1)}B0(0,1),B0(1,0),B0(2,0),B0(1,1),B1(0,1),B1(1,0),...,BN(2,0),BN(1,1){\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はゼロ以外の量子化された AC 係数です。
  • RUNLENGTHは、このゼロ以外の AC 係数の前にあるゼロの数です。
  • SIZEはxを表すために必要なビット数です。
  • AMPLITUDEはxのビット表現です。

ランレングス符号化は、各非ゼロAC係数xを調べ、前のAC係数の前にゼロがいくつあったかを判断することで機能します。この情報に基づいて、2つのシンボルが生成されます。

シンボル1シンボル2
（ランレングス、サイズ）（振幅）

RUNLENGTHとSIZEは同じバイトに格納されるため、それぞれ4ビットの情報しか含まれません。上位ビットはゼロの数を表し、下位ビットはxの値をエンコードするために必要なビット数を表します。

これは、シンボル1が非ゼロAC係数の前の最初の15個のゼロに関する情報しか格納できないという直接的な意味合いを持ちます。しかし、JPEGは2つの特別なハフマン符号語を定義しています。1つは、残りの係数がゼロの場合にシーケンスを途中で終了させるためのもの（「End-of-Block」または「EOB」と呼ばれます）で、もう1つは、非ゼロAC係数に達する前にゼロの連続が15を超える場合に使用されます。このように、ある非ゼロAC係数の前に16個のゼロが出現する場合、シンボル1は「特別に」(15, 0)(0) としてエンコードされます。

全体的なプロセスは、(0, 0) で表される「EOB」に到達するまで継続されます。

これを念頭に置くと、先ほどのシーケンスは次のようになります。

(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 係数であり、同じ方法でエンコードされません。上記を参照してください。)

ここから、係数の出現頻度に基づいて頻度計算が行われます。この例のブロックでは、量子化された係数のほとんどは、直前にゼロ係数が存在しない小さな数値です。このような頻度の高いケースは、より短いコードワードで表されます。

圧縮率とアーティファクト

この画像は、非圧縮画像と、品質設定50でJPEG圧縮された同じ画像との間のピクセルの違いを示しています。暗い色ほど、差が大きいことを意味します。特に、鋭いエッジ付近やブロック状の形状で変化が生じていることに注目してください。
元の画像
圧縮された 8×8 の正方形は、非可逆圧縮によるその他の視覚的アーティファクトとともに、拡大された画像に表示されます。

結果として得られる圧縮率は、量子化フェーズで使用する除数の強さを調整することで、必要に応じて調整できます。10:1の圧縮率では、通常、元の画像と目で見分けがつかない画像になります。100:1の圧縮率も通常は可能ですが、元の画像と比べて明らかにアーティファクトが目立ちます。適切な圧縮レベルは、画像の使用目的によって異なります。

外観画像
画像アイコンエッジの忙しさの図解[ 59 ]

ワールドワイドウェブを利用する人なら、JPEG画像に現れる圧縮アーティファクトと呼ばれる不規則性に馴染みがあるかもしれません。これは、コントラストの強いエッジ（特に曲線や角）の周囲にノイズとして現れたり、画像が「ブロック状」になったりすることがあります。これはJPEGアルゴリズムの量子化ステップに起因します。特に、コントラストの強い色の間の鋭角な角の周囲では顕著です（このような角が多数含まれるテキストが良い例です）。MPEGビデオにおける同様のアーティファクトは、モスキートノイズと呼ばれます。これは、結果として生じる「エッジの混雑」と、時間の経過とともに変化する不自然な点が、物体の周りに群がる蚊のように見えるためです。[ 59 ] [ 60 ]

これらのアーティファクトは、圧縮レベルを低くすることで軽減できます。ロスレスファイル形式で画像を保存すれば、これらのアーティファクトを完全に回避できますが、ファイルサイズは大きくなります。レイトレーシングプログラムで作成された画像では、地形にブロック状の形状が目立ちます。低強度圧縮によるアーティファクトの中には、画像を見るだけであれば許容できるものもありますが、その後画像を処理すると強調され、通常は許容できない品質になってしまいます。以下の例は、エッジ検出処理におけるロスレス圧縮の影響を示しています。

画像ロスレス圧縮非可逆圧縮
オリジナル
Cannyエッジ検出器で処理

一部のプログラムでは、個々のブロックの圧縮率を調整できます。アーティファクトの少ない画像領域には、より強い圧縮が適用されます。これにより、画質の低下を抑えながら、JPEGファイルのサイズを手動で縮小することが可能です。

量子化段階では常に情報が失われるため、JPEG規格は常に非可逆圧縮コーデックです。（浮動小数点数の量子化と丸めの両方で情報が失われます。）量子化行列が1の行列であっても、丸めの段階では情報が失われます。

デコード

画像を表示するためのデコードは、上記のすべてを逆に実行することで構成されます。

DCT係数行列を取得する（DC係数の差を戻した後）

[−26−3−622−1000−2−411000−315−1−1000−312−1000010000000000000000000000000000000]{\displaystyle \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]}

そして、上記の量子化行列と エントリごとの積をとると、次のようになる。

[−416−33−603248−40000−24−561926000−421380−24−40000−421744−290000180000000000000000000000000000000]{\displaystyle \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) を実行することです。

fx,y=14∑u=07∑v=07α(u)α(v)Fu,vcos⁡[(2x+1)uπ16]cos⁡[(2y+1)vπ16]{\displaystyle 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{\displaystyle \ x}はピクセル行で、整数です。 0≤x<8{\displaystyle \ 0\leq x<8}
  •  y{\displaystyle \ y}はピクセル列で、整数です。 0≤y<8{\displaystyle \ 0\leq y<8}
  •  α(u){\displaystyle \ \alpha (u)}は、整数に対して先ほど定義した正規化スケール係数です。 0≤u<8{\displaystyle \ 0\leq u<8}
  •  Fu,v{\displaystyle \ F_{u,v}}は座標における近似DCT係数である (u,v).{\displaystyle \ (u,v).}
  •  fx,y{\displaystyle \ f_{x,y}}座標における再構成されたピクセル値である (x,y){\displaystyle \ (x,y)}

出力を整数値に丸めると（元の値は整数値だったため）、値を持つ画像が生成されます（それでも128だけ下方にシフトされています）。

元の画像 (上) と解凍された画像 (下) の間にはわずかな違いが目立ちます。違いは左下隅で最もよくわかります。
[−66−63−71−68−56−65−68−46−71−73−72−46−20−41−66−57−70−78−68−1720−14−61−63−63−73−62−827−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]{\displaystyle \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を加算する

[62655760726360825755568210887627158506011114811467656555661201551146870706367101122886078717164708062568175826754636566838194755468818187].{\displaystyle \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]{\displaystyle [0,255]}

圧縮解除されたサブイメージを元のサブイメージと比較すると (右側の画像も参照)、差 (元のサブイメージ - 圧縮されていないサブイメージ) は次のエラー値になります。

[−10−1046−2−24−964−181−2714982−4−10−18−2352−1−82−1−3−213408−88−6−4−0−362−610−11−35−8−4−1−06−15−614−3−5−37]{\displaystyle \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 値 (つまり、) です。 164∑x=07∑y=07|e(x,y)|=4.8750{\displaystyle {\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 と逆 DCT の最大許容誤差によって、JPEG コーデックのエンコード プロセスとデコード プロセスの両方に必要な実装精度を定義しています。たとえば、デコーダ実装の出力は、上記の標準の一部として提供される参照テスト コードストリームに適用された場合、DCT 領域で 1 量子化単位の誤差を超えてはなりません。他の多くのより現代的な標準とは異なり、ITU.T T.83 | ISO/IEC 10918-2 では画像領域での誤差境界は策定されていません。

JPEG圧縮の効果

JPEG 圧縮アーティファクトは、細かく不均一なテクスチャを持つ写真によく溶け込み、高い圧縮率を実現します。高い圧縮率が、まず画像の左上隅にある高周波テクスチャに影響を与え、コントラストの強い線がぼやけていく様子に注目してください。非常に高い圧縮率は画像の品質に深刻な影響を与えますが、全体的な色と画像の形状は依然として認識可能です。ただし、色の精度は (人間の目にとって) 輪郭の精度 (輝度に基づく) ほど低下しません。このことから、輝度面の精度をより多くの情報ビットで維持するために、まず輝度と色情報を分離するカラー モデルで画像を変換し、その後で色平面をサブサンプリングする (この場合も低品質の量子化が使用される可能性があります) 必要があることがわかります。

サンプル写真

Photoshop で 4480 x 4480 ピクセルの画像を 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)に記載されている。 [ 61 ]

注意: 上記の画像は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画像に含まれるデータを、表現された画像を変更することなくさらに圧縮する方法に関する新たな研究が発表されました。[ 62 ] [ 63 ] [ 64 ] [ 65 ]これは、元の画像がJPEG形式でしか入手できず、アーカイブや伝送のためにサイズを縮小する必要があるシナリオに応用できます。標準的な汎用圧縮ツールでは、JPEGファイルを大幅に圧縮することはできません。

通常、このような方式は、DCT 係数をコーディングするための単純な方式の改良を利用しますが、次の点が考慮されていません。

  • 同じブロック内の隣接する係数の大きさ間の相関。
  • 隣接するブロック内の同じ係数の大きさ間の相関。
  • 異なるチャネル内の同じ係数/ブロックの大きさ間の相関。
  • DC係数を合わせると、元の画像にスケーリング係数を乗じた縮小版のような画像になります。連続階調画像のロスレス符号化によく知られている方式を適用することで、 JPEGで使用されるハフマン符号化DPCMよりもいくらか優れた圧縮率を実現できます。

JPEG には、DCT 係数の符号化効率を向上させるための標準的ではあるがあまり使用されていないオプションがいくつか既に存在している。算術符号化オプションとプログレッシブ符号化オプション (各係数の値が独立して符号化され、各係数の分布が大きく異なるため、ビットレートが低くなる) である。現代の手法では、係数を並べ替えて大きな値の係数をグループ化する、[ 62 ]隣接する係数とブロックを使用して新しい係数値を予測する、[ 64 ]ブロックまたは係数を、その統計と隣接する値に基づいて少数の独立して符号化されたモデルに分割する、[ 63 ] [ 64 ]そして最近では、ブロックをデコードし、空間領域で後続のブロックを予測し、それらをエンコードして DCT 係数の予測を生成する[ 65 ]などの改良が行われている。

通常、このような方法では既存のJPEGファイルを15～25％圧縮することができ、低品質設定で圧縮されたJPEGの場合は最大65％の改善が得られます。[ 64 ] [ 65 ]

packJPGと呼ばれる無料で入手可能なツールは、2007年の論文「JPEGファイルの冗長性削減の改善」に基づいています。2016年のバージョン2.5kでは、トランスコーディングによって平均20%の削減が報告されています。[ 66 ] 2018年のJPEG XL（ISO/IEC 18181）でも、トランスコーディングによって同様の削減が報告されています。

立体3Dの派生フォーマット

JPEG 立体視

立体視の.JPSファイルの例

JPSは、2D画像から3D効果を作成するために使用される立体JPEG画像です。2つの静止画像（左目用と右目用）が含まれ、1つのJPEGファイルに2つの横並びの画像としてエンコードされています。JPEGステレオスコピック（JPS、拡張子.jps）は、立体画像用のJPEGベースの形式です。[ 67 ] [ 68 ] JPEG APP3マーカーフィールドにさまざまな構成が格納されていますが、通常は2倍幅の画像が1つ含まれており、交差した（つまり、画像の右半分に左フレーム、またはその逆）横並びの配置で同じサイズの2つの画像を表します。このファイル形式は、特別なソフトウェアなしでJPEGとして表示することも、他のモードでレンダリング用に処理することもできます。

JPEG マルチピクチャーフォーマット

JPEG マルチピクチャ
ファイル名拡張子
.mpo
統一型識別子（UTI）パブリック.mpo-image [ 69 ]

JPEGマルチピクチャーフォーマット（MPO、拡張子.mpo）は、複数の画像を1つのファイルに保存するためのJPEGベースのフォーマットです。2つ以上のJPEGファイルが連結されています。[ 70 ] [ 71 ]また、画像記述用のJPEG APP2マーカーセグメントも定義しています。富士フイルム FinePix Real 3D W1、HTC Evo 3D、JVC GY-HMZ1U AVCHD/MVC拡張カムコーダー、ニンテンドー3DS、パナソニック ルミックス DMC-TZ20、DMC-TZ30、DMC - TZ60、DMC-TS4（FT4）、ソニーDSC-HX7Vなど、さまざまなデバイスが3D画像を保存するために使用しています。他のデバイスでは、テレビに表示できる「プレビュー画像」を保存するために使用されています。

ここ数年、立体画像の利用が増えたことにより、科学界は立体画像圧縮アルゴリズムの開発に多大な努力を費やしてきました。[ 72 ] [ 73 ]

実装

JPEGコーデックの非常に重要な実装として、Independent JPEG Groupのフリープログラミングライブラリlibjpegがあります。これは1991年に初めて公開され、標準規格の成功の鍵となりました。このライブラリは数え切れないほどのアプリケーションで使用されました。 [ 3 ]開発は1998年に停止しましたが、2009年のバージョン7でlibjpegが再登場した際に、以前のバージョンとのABI互換性が失われました。2010年のバージョン8では非標準の拡張機能が導入され、これはIJGの元リーダーであるトム・レーン氏から批判されました。[ 74 ]

libjpeg-turboは1998年のlibjpeg 6bからフォークされ、SIMD最適化によってlibjpegを改良しています。当初はlibjpegのメンテナンスされたフォークとして見られていましたが、2009年の互換性のない変更以降、より人気が高まりました。[ 75 ] [ 76 ] 2019年には、ISO/IEC 10918-7およびITU-T T.873としてITU|ISO/IECの参照実装となりました。[ 77 ]

ISO/IEC Joint Photographic Experts Groupは、JPEG XTという名称のもう一つの参照ソフトウェア実装を管理しています。この実装は、ベースJPEG（ISO/IEC 10918-1および18477-1）とJPEG XT拡張（ISO/IEC 18477 Parts 2および6-9）、そしてJPEG-LS（ISO/IEC 14495）の両方をエンコードできます。[ 78 ] 2016年には、「強化版JPEG」がISO JPEG XT参照実装のオプションとして導入されました。[ 79 ]

JPEGを非伝統的な方法でエンコードし、与えられたファイルサイズで画質を最大化することには、根強い関心があります。2014年、Mozillaはlibjpeg-turboからMozJPEGを作成しました。これは、ウェブ画像向けの低速ですが高品質のエンコーダです。[ 80 ] 2017年3月、GoogleはオープンソースプロジェクトGuetzliをリリースしました。これは、エンコード時間を大幅に短縮する代わりに、ファイルサイズを小さくするものです（これは、 PNGやその他のロスレスデータ形式におけるZopfliの機能に似ています）。[ 81 ]

2024年4月、Googleは新しいJPEGコーディングライブラリであるJpegliを導入しました。これは、強化された機能と高品質圧縮設定での圧縮率35％向上を提供し、コーディング速度はMozJPEGに匹敵します。[ 82 ]

後継者

Joint Photographic Experts Group は、元の JPEG 形式の機能を補完または置き換えることを目的としたいくつかの新しい標準を開発しました。

JPEG LS

1993年にISO-14495-1/ITU-T.87として策定されたJPEG LSは、JPEGのオリジナルのロスレス実装よりも効率的な、複雑さの少ないロスレスファイル形式を提供します。また、ロスレスに近いロッシーモードも備えています。機能は主にこのモードに限定されており、その他の点ではオリジナルのJPEGとほぼ同じ制限事項を共有しています。

JPEG 2000

JPEG 2000は、2000年12月にISO/IEC 15444として公開されました。離散ウェーブレット変換（DWT）をベースとし、オリジナルのJPEG規格を完全に置き換え、あらゆる点でそれを凌駕することを目指して設計されました。JPEGは、色チャンネルあたり最大38ビット、他のどのフォーマットよりも多くの16384チャンネル、そして多様な色空間とハイダイナミックレンジ（HDR）をサポートします。さらに、アルファ透過符号化、他のどのフォーマットよりも多くの数十億ピクセルの画像、そしてロスレス圧縮をサポートします。ロスレス圧縮率が大幅に向上し、高圧縮レベルにおける目に見えるアーティファクトが大幅に減少しています。[ 83 ]

JPEG XT

JPEG XT（ISO/IEC 18477）は2015年6月に公開され、JPEGベースのフォーマットを拡張し、より高い整数ビット深度（最大16ビット）、高ダイナミックレンジ画像と浮動小数点符号化、ロスレス符号化、アルファチャンネル符号化をサポートしています。拡張は、JPEGベースのファイルフォーマットであるJFIFおよび8ビット非可逆圧縮画像と下位互換性があります。JPEG XTは、JFIFに基づく拡張可能なファイルフォーマットを使用します。拡張レイヤーは、JPEGの8ビットベースレイヤーを変更し、高解像度画像を復元するために使用されます。既存のソフトウェアは上位互換性があり、JPEG XTバイナリストリームを読み取ることができますが、デコードできるのはベース8ビットレイヤーのみです。[ 84 ]

JPEG XL

JPEG XL（ISO/IEC 18181）は2021年から2022年にかけて公開されました。JPEG形式を新しいDCTベースのロイヤリティフリー形式に置き換え、従来のJPEG画像の保存オプションとして効率的なトランスコードを可能にします。[ 85 ]この新しい形式は、 HEIF HM、Daala、WebPが示す静止画像圧縮性能を上回るように設計されています。数十億ピクセルの画像、適切な伝達関数（PQおよびHLG ）による最大32ビット/コンポーネントのハイダイナミックレンジ、ビットマップフォントやグラデーションなどの合成画像のパッチエンコーディング、アニメーション画像、アルファチャンネルコーディング、RGB/YCbCr/ I2CtCpカラーエンコーディングの選択をサポートします。 [ 86 ] [ 87 ] [ 88 ] [ 89 ]

参照

参考文献

  1. ^ a b c d e「T.81 – 連続階調静止画像のデジタル圧縮および符号化 – 要件およびガイドライン」(PDF)。CCITT 。 1992年9月。2019年12月30日時点のオリジナルよりアーカイブ(PDF) 。 2019年7月12日閲覧。
  2. ^ 「JPEG」の定義. Collins English Dictionary . 2013年9月21日時点のオリジナルよりアーカイブ。 2013年5月23日閲覧。
  3. ^ a b「JPEG 1の概要」。Joint Photographic Experts Group。2025年1月30日時点のオリジナルよりアーカイブ。2025年2月5日閲覧。
  4. ^ Haines, Richard F.; Chuang, Sherry L. (1992年7月1日).生命科学実験モニタリングにおける画像の許容度に対するビデオ圧縮の影響（技術報告書）. NASA . NASA-TP-3239, A-92040, NAS 1.60:3239 . 2016年3月13日閲覧. JPEG静止画圧縮レベルは、本研究で5:1から120:1という広い範囲で検討されたにもかかわらず、同様に高い許容度を示した。
  5. ^ a b Hudson, Graham; Léger, Alain; Niss, Birger; Sebestyén, István; Vaaben, Jørgen (2018年8月31日). 「JPEG-1規格25周年：成功の理由、現在、そして未来」 . Journal of Electronic Imaging . 27 (4): 1. doi : 10.1117/1.JEI.27.4.040901 . S2CID 52164892 . 
  6. ^ Svetlik, Joe (2018年5月31日). 「JPEG画像フォーマットの説明」 . BT.com . BTグループ. 2019年8月5日時点のオリジナルよりアーカイブ。2019年8月5日閲覧。
  7. ^ Baraniuk, Chris (2015年10月15日). 「JPEGにコピープロテクションが導入される可能性」 . BBCニュース. BBC . 2019年10月9日時点のオリジナルよりアーカイブ。 2019年9月13日閲覧。
  8. ^アンドレア、トリンクヴァルダー (2016 年 10 月 7 日)。「JPEG: 25 Jahre und kein bisschen alt」 [JPEG: 25 年 (古い) で、少しも古くありません]。de:Heise オンライン(ドイツ語)。2019年9月5日のオリジナルからアーカイブ。2019 年9 月 5 日に取得。
  9. ^ a b c「T.81 – 連続階調静止画像のデジタル圧縮および符号化 – 要件およびガイドライン」(PDF) . CCITT . 1992年9月. 2019年7月12日閲覧。
  10. ^ a b c "JPEG: 25 Jahre und kein bisschen alt" . Heise オンライン(ドイツ語)。 2016 年 10 月。2019 年9 月 5 日に取得。
  11. ^ Caplan, Paul (2013年9月24日). 「JPEGとは何か？ 毎日目にする目に見えない物体」 .アトランティック誌. 2019年10月9日時点のオリジナルよりアーカイブ。 2019年9月13日閲覧。
  12. ^ 「HTTP Archive – 興味深い統計」httparchive.org . 2016年4月6日閲覧。
  13. ^ 「Internet ExplorerでのMIMEタイプの検出」。Microsoft。2016年7月13日。2022年10月30日時点のオリジナルよりアーカイブ。 2022年11月2日閲覧。
  14. ^ 「JPEG File Interchange Format」（PDF） . 2014年9月3日. 2014年9月3日時点のオリジナルよりアーカイブ。 2017年10月16日閲覧。{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  15. ^ 「JPEG 2000が普及しなかった理由」アメリカ規格協会（ANSI）2018年7月10日。2018年12月16日時点のオリジナルよりアーカイブ。 2019年9月13日閲覧。
  16. ^ Ahmed, Nasir (1991年1月). 「離散コサイン変換の考案経緯」 .デジタル信号処理. 1 (1): 4– 5. Bibcode : 1991DSP.....1....4A . doi : 10.1016/1051-2004(91)90086-Z .
  17. ^ Ahmed, Nasir ; Natarajan, T.; Rao, KR (1974年1月)、「離散コサイン変換」、IEEE Transactions on Computers、C-23 (1): 90– 93、Bibcode : 1974ITCmp.100...90A、doi : 10.1109/TC.1974.223784、S2CID 149806273 
  18. ^ a b c d Lemos, Robert (2002年7月23日). 「JPEGクレームにおける特許の真実を探る」 . CNET . 2019年7月13日時点のオリジナルよりアーカイブ。2019年7月13日閲覧。
  19. ^ ISO/IEC JTC 1/SC 29 (2009年5月7日). 「ISO/IEC JTC 1/SC 29/WG 1 – 静止画像の符号化（SC 29/WG 1の構造）」 . 2013年12月31日時点のオリジナルよりアーカイブ。 2009年11月11日閲覧。{{cite web}}: CS1 maint: numeric names: authors list (link)
  20. ^ a b ISO/IEC JTC 1/SC 29. 「作業計画（SC 29/WG 1に割り当て）」。2013年12月31日時点のオリジナルよりアーカイブ。2009年11月7日閲覧。{{cite web}}: CS1 maint: numeric names: authors list (link)
  21. ^ ISO. 「JTC 1/SC 29 – 音声、画像、マルチメディア及びハイパーメディア情報の符号化」。2010年7月3日時点のオリジナルよりアーカイブ。2009年11月11日閲覧。
  22. ^ a b JPEG. 「Joint Photographic Experts Group, JPEG Homepage」 . 2009年9月27日時点のオリジナルよりアーカイブ。2009年11月8日閲覧。
  23. ^ 「T.81: 情報技術 - 連続階調静止画像のデジタル圧縮および符号化 - 要件とガイドライン」Itu.int。2012年11月6日時点のオリジナルよりアーカイブ。2009年11月7日閲覧。
  24. ^ William B. Pennebaker、Joan L. Mitchell (1993). JPEG静止画像データ圧縮規格（第3版）. Springer. p. 291. ISBN 978-0-442-01272-4。
  25. ^ ISO. 「JTC 1/SC 29 – 音声、画像、マルチメディア及びハイパーメディア情報の符号化」。2010年7月3日時点のオリジナルよりアーカイブ。2009年11月7日閲覧。
  26. ^ 「SPIFF、静止画像交換ファイルフォーマット」アメリカ議会図書館。2012年1月30日。2018年7月31日時点のオリジナルよりアーカイブ。 2018年7月31日閲覧。
  27. ^ Louis Sharpe (2009年4月24日). 「JPEG XRがFDISステータスに移行 JPEGファイル交換フォーマット（JFIF）がJPEG Part 5として標準化へ」 （プレスリリース）. 2009年10月8日時点のオリジナルよりアーカイブ。 2009年11月9日閲覧。
  28. ^ 「JPEG File Interchange Format (JFIF)」 ECMA TR/98 第1版Ecma International 2009年。2021年1月14日時点のオリジナルよりアーカイブ。 2011年8月1日閲覧。
  29. ^ 「ForgentのJPEG特許」SourceForge、2002年。2019年5月13日時点のオリジナルよりアーカイブ。 2019年7月13日閲覧。
  30. ^ 「最近の特許請求について」 Jpeg.org 、 2002年7月19日。 2007年7月14日時点のオリジナルよりアーカイブ。2011年5月29日閲覧。
  31. ^ 「JPEGとJPEG2000 – 特許争いと技術革新の間」。2004年8月17日時点のオリジナルよりアーカイブ。2017年4月16日閲覧。{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  32. ^ Kawamoto, Dawn (2005年4月22日). 「グラフィックス特許訴訟、Microsoftに反撃」 . CNET News . 2023年1月20日時点のオリジナルよりアーカイブ。2023年1月20日閲覧。
  33. ^ 「商標局、Forgent JPEG特許を再審査」Publish.com 、2006年2月3日。2016年5月15日時点のオリジナルよりアーカイブ。 2009年1月28日閲覧。
  34. ^ 「USPTO：フォージェントがJPEG標準は無効と断言」 Groklaw.net 2006年5月26日。2019年5月16日時点のオリジナルよりアーカイブ。 2007年7月21日閲覧。
  35. ^ 「冗長性を削減するためのコーディングシステム」 Gauss.ffii.org . 2011年6月12日時点のオリジナルよりアーカイブ。 2011年5月29日閲覧。
  36. ^ 「JPEG特許請求権放棄」 Public Patent Foundation、2006年11月2日。2007年1月2日時点のオリジナルよりアーカイブ。 2006年11月3日閲覧。
  37. ^ 「米国特許番号5,253,341のEx Parte Reexamination Certificate」 。2008年6月2日時点のオリジナルよりアーカイブ。
  38. ^ワークグループ. 「Rozmanith：ソフトウェア特許を利用して批判を黙らせる」 . Eupat.ffii.org . 2011年7月16日時点のオリジナルよりアーカイブ。2011年5月29日閲覧。
  39. ^ 「トロール追跡者の氏名に5,000ドルの懸賞金：レイ・ニーロは誰が自分について悪質なことを言っているのか知りたい」 Law.com 。 2010年11月21日時点のオリジナルよりアーカイブ。 2011年5月29日閲覧。
  40. ^ Reimer, Jeremy (2008年2月5日). 「Hunting trolls: USPTO asked to reexamine broad image patent」 . Arstechnica.com . 2008年12月8日時点のオリジナルよりアーカイブ。2011年5月29日閲覧。
  41. ^米国特許庁 – 5,253,341 C1の再審査を承認
  42. ^ 「裁判官、JPEG特許を凍結」 Techdirt.com 、 2008年4月30日。2011年11月14日時点のオリジナルよりアーカイブ。2011年5月29日閲覧。
  43. ^ 「JPEG特許の単一クレームが却下（そして念のため却下）」 Techdirt.com 2008年8月1日. 2019年11月28日時点のオリジナルよりアーカイブ。2011年5月29日閲覧。
  44. ^ワークグループ. 「Princeton Digital Image Corporation ホームページ」 . 2013年4月11日時点のオリジナルよりアーカイブ。 2013年5月1日閲覧。
  45. ^ワークグループ (2013年4月3日). 「GEライセンス契約に関するプリンストン裁判所の判決に関する記事」 . 2016年3月9日時点のオリジナルよりアーカイブ。2013年5月1日閲覧。
  46. ^ a b Kaur, Rajandeep (2016年5月). 「画像圧縮技術のレビュー」 . International Journal of Computer Applications . 142 (1): 8– 11. doi : 10.5120/ijca2016909658 .
  47. ^ 「プログレッシブデコードの概要」。Microsoft Developer Network。Microsoft。2012年11月19日時点のオリジナルよりアーカイブ。2012年3月23日閲覧。
  48. ^ Fastvideo (2019年5月). 「GPU上の12ビットJPEGエンコーダ」 . 2019年5月6日時点のオリジナルよりアーカイブ。 2019年5月6日閲覧。
  49. ^ 「JPEG写真をロスレスで回転させる理由」 Petapixel.com 、 2012年8月14日。2017年10月17日時点のオリジナルよりアーカイブ。 2017年10月16日閲覧。
  50. ^ 「JFIFファイルフォーマット（PDF）」（PDF）。2021年1月13日時点のオリジナルよりアーカイブ（PDF） 。 2006年6月19日閲覧。
  51. ^ Tom Lane (1999年3月29日). 「JPEG画像圧縮に関するFAQ」 . 2010年11月10日時点のオリジナルよりアーカイブ。2007年9月11日閲覧。(質問 14: 「ファイル形式についてなぜ議論が起こっているのですか?」)
  52. ^ 「JPEGファイルについて知っておくべきことすべて | Adob​​e」www.adobe.com . 2023年8月18日閲覧。
  53. ^ a b「インターネットの標準デフォルトカラースペース - sRGB」。www.w3.org。2022年2月18日時点のオリジナルよりアーカイブ。2022年2月18日閲覧。
  54. ^ a b “IEC 61966-2-1:1999/AMD1:2003 | IEC Webstore” . webstore.iec.ch . 2022年2月18日時点のオリジナルよりアーカイブ。 2022年2月18日閲覧。
  55. ^ “ISO/IEC 10918-1: 1993(E) p.36” . 2011年8月1日時点のオリジナルよりアーカイブ。2007年11月30日閲覧。
  56. ^ Thomas G. Lane. 「高度な機能：圧縮パラメータの選択」 . IJG JPEGライブラリの使用. 2001年11月26日時点のオリジナルよりアーカイブ。 2008年10月8日閲覧。
  57. ^ 「DC / AC周波数に関する質問 - Doom9のフォーラム」forum.doom9.org . 2017年10月17日時点のオリジナルよりアーカイブ。 2017年10月16日閲覧。
  58. ^ Maini, Raman; Mehra, Suruchi (2010年12月). 「JPEG2000画像圧縮のレビュー」 . International Journal of Computer Applications . 11 (9): 43– 47. doi : 10.5120/1607-2159 – CiteSeerX経由.
  59. ^ a b Phuc-Tue Le DinhとJacques Patry.ビデオ圧縮アーティファクトとMPEGノイズ低減Archived 2006-03-14 at the Wayback Machine . Video Imaging DesignLine. 2006年2月24日. 2009年5月28日閲覧。
  60. ^「 3.9 モスキートノイズ：エッジの混雑による歪みの一種で、動きに伴って発生することがあり、物体に重なる動くアーティファクトや斑点状のノイズパターン（人の頭や肩の周りを飛び回る蚊に似ている）を特徴とする。」 ITU-T勧告P.930 (08/96) 映像用基準障害システムの原理 2010年2月16日アーカイブWayback Machine
  61. ^ Julià Minguillón, Jaume Pujol (2001年4月). 「JPEG標準の一様量子化誤差モデリングとシーケンシャルおよびプログレッシブ動作モードへの応用」(PDF) . Electronic Imaging . 10 (2): 475– 485. Bibcode : 2001JEI....10..475M . doi : 10.1117/1.1344592 . hdl : 10609/6263 . S2CID 16629522. 2020年8月3日時点のオリジナルよりアーカイブ(PDF) . 2019年9月23日閲覧。 
  62. ^ a b I. Bauermann、E. Steinbacj. JPEG画像のさらなるロスレス圧縮. Picture Coding Symposium (PCS 2004)論文集、サンフランシスコ、米国、2004年12月15～17日。
  63. ^ a b N. ポノマレンコ、K. エギアザリアン、V. ルーキン、J. アストラ。 JPEG 画像の追加のロスレス圧縮、Proc.第4国際空港の画像および信号処理および解析に関するシンポジウム (ISPA 2005)、ザグレブ、クロアチア、117 ～ 120 ページ、2005 年 9 月 15 ～ 17 日。
  64. ^ a b c d M. StirnerとG. Seelmann. JPEGファイルの冗長性削減の改善. 画像符号化シンポジウム(PCS 2007)論文集, ポルトガル, リスボン, 2007年11月7日～9日
  65. ^ a b c松田一郎、野本幸雄、若林啓、伊藤進. ブロック適応型イントラ予測を用いたJPEG画像のロスレス再エンコード. 第16回ヨーロッパ信号処理会議 (EUSIPCO 2008) 議事録.
  66. ^ Stirner, Matthias (2023年2月19日). 「packjpg/packJPG」 . GitHub . 2023年3月2日時点のオリジナルよりアーカイブ。2023年3月2日閲覧。
  67. ^ J. Siragusa; DC Swift (1997). 「汎用立体データ記述子」(PDF) . VRex, Inc., Elmsford, New York, US . 2011年10月30日時点のオリジナル(PDF)からアーカイブ。
  68. ^ Tim Kemp, JPSファイル 2009年1月18日アーカイブWayback Machine
  69. ^ "CGImageSource.SupportedTypes" . Claris FileMaker MBSプラグイン. MonkeyBread Software. 2020年12月30日時点のオリジナルよりアーカイブ。 2023年5月21日閲覧。
  70. ^ 「Multi-Picture Format」（PDF） 2009年。 2016年4月5日時点のオリジナル（PDF）からアーカイブ。2015年12月30日閲覧。
  71. ^ 「MPO2Stereo: Fujifilm MPOファイルをJPEGステレオペアに変換する」、Mtbs3d.com、2010年5月31日時点のオリジナルよりアーカイブ、 2010年1月12日閲覧。
  72. ^ Alessandro Ortis; Sebastiano Battiato (2015), Sitnik, Robert; Puech, William (eds.), "A new fast matching method for adaptive compression of stereoscopic images" , Three-Dimensional Image Processing , Three-Dimensional Image Processing, Measurement (3DIPM), and Applications 2015, 9393 , SPIE - Three-Dimensional Image Processing, Measurement (3DIPM), and Applications 2015: 93930K, Bibcode : 2015SPIE.9393E..0KO , doi : 10.1117/12.2086372 , S2CID 18879942 , 2016年3月3日時点のオリジナルよりアーカイブ、2015年4月30日閲覧。 
  73. ^ Alessandro Ortis; Francesco Rundo; Giuseppe Di Giore; Sebastiano Battiato, Adaptive Compression of Stereoscopic Images , International Conference on Image Analysis and Processing (ICIAP) 2013, archived from the original on 3 March 2016 , retrieved 30 April 2015
  74. ^ Tom Lane、2013年1月16日: jpeg-9、API/ABI互換性、そしてこのプロジェクトの将来的な役割Archived 2018-12-04 at the Wayback Machine
  75. ^ libjpeg-turbo を使用または提供するソフトウェアArchived 2017-03-18 at the Wayback Machine . 2012年2月9日.
  76. ^問題 48789 – chromium – libjpeg の代わりに libjpeg-turbo を使用するArchived 2015-08-01 at the Wayback Machine . 2011年4月14日.
  77. ^ 「ISO/IEC 10918-7: 2023 情報技術 - 連続階調静止画像のデジタル圧縮および符号化 - パート7：参照ソフトウェア」ISO . 2025年6月24日閲覧。「T.873 (05/19): 情報技術 - 連続階調静止画像のデジタル圧縮および符号化：参照ソフトウェア」www.itu.int。2022年6月2日時点のオリジナルよりアーカイブ。2023年3月1日閲覧。
  78. ^ “JPEG - JPEG XT” . jpeg.org . 2018年3月4日時点のオリジナルよりアーカイブ。2018年3月3日閲覧。
  79. ^ Richter, Thomas (2016年9月). 「JPEG on STEROIDS: JPEG画像圧縮における共通最適化手法」. 2016 IEEE International Conference on Image Processing (ICIP) . pp.  61– 65. doi : 10.1109/ICIP.2016.7532319 . ISBN 978-1-4673-9961-6. S2CID  14922251 .
  80. ^ 「'mozjpeg' プロジェクトの紹介」 Mozilla Research、2014年3月5日。2023年3月1日時点のオリジナルよりアーカイブ。 2023年3月1日閲覧。
  81. ^ 「Announcement Guetzli: A New Open Source JPEG Encoder」 Research.googleblog.com 2017年3月16日。2017年10月6日時点のオリジナルよりアーカイブ。 2017年10月16日閲覧。
  82. ^ 「Jpegliの紹介：新しいJPEGコーディングライブラリ」。Googleオープンソースブログ。2024年4月3日。2024年4月3日時点のオリジナルよりアーカイブ。2024年4月4日閲覧。
  83. ^ Sneyers, Jon (2021年2月22日). 「JPEGを次世代画像コーデックに置き換える時が来た」 . Cloudinary . 2023年11月14日閲覧。
  84. ^ “JPEG - JPEG XT” . jpeg.org . 2018年3月4日時点のオリジナルよりアーカイブ。2018年3月3日閲覧。
  85. ^アラクイジャラ、ジルキ;ファン・アッセルドンク、ルード。サミ州ブーコート。ブルース、マーティン。コムシャ、ユリア＝マリア。ファーシング、モーリッツ。フィッシュバッハー、トーマス。クリッチニコフ、エフゲニー。ゴメス、セバスチャン。ロバート・オブリク。ポテンパ、クシシュトフ。ラトゥシュニャク、アレクサンダー。スニーズ、ジョン。ザバトカ、ゾルタン。ロード、ヴァンダーヴェンヌ。ヴェルサリ、ルカ。ワッセンベルク、1月（2019年9月6日）。「JPEG XL 次世代画像圧縮アーキテクチャとコーディング ツール」。テッシャーでは、アンドリュー G。エブラヒミ、トゥーラジ (編)。デジタル画像処理の応用 XLII． Vol. 11137.p. 20.書誌コード: 2019SPIE11137E..0KA . doi : 10.1117/12.2529237 . ISBN 978-1-5106-2967-7. S2CID  202785129 . 2021年12月26日時点のオリジナルよりアーカイブ。2021年12月26日閲覧。
  86. ^ラトゥーシュニャック、アレクサンダー;ワッセンベルク、ジャン。スニーズ、ジョン。アラクイジャラ、ジルキ。ヴァンデベンヌ、ロード。ヴェルサリ、ルカ。ロバート・オブリク。ザバトカ、ゾルタン。クリッチニコフ、エフゲニー。コムサ、ユリア・マリア。ポテンパ、クシシュトフ。ブルース、マーティン。ファーシング、モーリッツ。カサノバ、レナタ。ルート・ファン・アッセルドンク。サミ州ブーコート。ゴメス、セバスチャン。フィッシュバッハー、トーマス (2019)。 「JPEG XL画像符号化方式委員会草案」。arXiv : 1908.03565 [ eess.IV ]。
  87. ^ 「N79010 次世代画像符号化規格（JPEG XL）の最終提案募集」（PDF） . ISO/IEC JTC 1/SC 29/WG 1（ITU-T SG16） . 2022年10月31日時点のオリジナルよりアーカイブ（PDF） . 2018年5月29日閲覧。
  88. ^ ISO/IEC 18181-1:2022 情報技術 - JPEG XL 画像符号化システム - パート1：コア符号化システム。
  89. ^ ISO/IEC 18181-2:2021 情報技術 - JPEG XL 画像符号化システム - パート2：ファイル形式。
ウィキメディア コモンズには、 JPEG 圧縮に関連するメディアがあります。
「 https://en.wikipedia.org/w/index.php?title=JPEG&oldid=1328915161」から取得