JPEG

JPEG

圧縮率とそれに伴う損失が左から右に減少しているヨーロッパヤマネコの写真
ファイル名拡張子	.jpg、、、、、.jpeg​.jpe .jif​.jfif​.jfi
インターネットメディアの種類	画像/jpeg
タイプコード	JPEG
統一型識別子 (UTI)	パブリック.jpeg
魔法の数字	ff d8 ff
開発者	合同写真専門家グループ、IBM、三菱電機、AT&T、キヤノン株式会社[1]
初回リリース	1992年9月18日; 32年前 ( 1992-09-18 )
フォーマットの種類	非可逆 画像圧縮 形式
延長	JPEG2000
標準	ISO/IEC 10918、ITU-T T.81、ITU-T T.83、ITU-T T.84、ITU-T T.86
Webサイト	jpeg.org/jpeg/

JPEG（/ ˈ dʒ eɪ p ɛ ɡ / JAY -peg、Joint Photographic Experts Groupの略）^[2]は、デジタル画像、特にデジタル写真で作成された画像に一般的に使用される非可逆圧縮方式です。圧縮の程度は調整可能で、ストレージサイズと画質の間で選択的なトレードオフが可能です。JPEGは通常、画質の知覚できる低下をほとんど伴わずに10:1の圧縮を実現します。^[3] 1992年の導入以来、JPEGは世界で最も広く使用されている画像圧縮規格であり、 ^{[4] [5]}最も広く使用されているデジタル画像フォーマットであり、2015年現在、毎日数十億枚のJPEG画像が作成されています。^[6]

Joint Photographic Experts Group は1992 年にこの標準を作成しました。^[7] JPEG は、インターネット、そして後にソーシャル メディアでのデジタル画像とデジタル写真の普及に大きく貢献しました。^{[8] [循環参照]} JPEG 圧縮は、多くの画像ファイル形式で使用されます。JPEG/ Exifは、デジタル カメラやその他の写真画像キャプチャ デバイスで使用される最も一般的な画像形式です。JPEG/ JFIFとともに、 World Wide Web上で写真画像を保存および送信するための最も一般的な形式です。^[9]これらの形式のバリエーションは区別されないことが多く、単に JPEG と呼ばれます。

JPEG のMIMEメディア タイプは「image/jpeg」ですが、古いバージョンのInternet Explorerでは、JPEG 画像をアップロードするときに「image/pjpeg」という MIME タイプが提供されます。^{[10] JPEG ファイルの}ファイル名拡張子は通常「jpg」または「jpeg」です。JPEG/JFIF は最大 65,535×65,535 ピクセルの画像サイズをサポートしており、^[11]アスペクト比1:1 の場合は最大 4 ギガピクセルです。2000 年に、JPEG グループは後継となる形式としてJPEG 2000を導入しましたが、元の JPEG を置き換えることはできませんでした。^[12]

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

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

• IBM
  • 米国特許 4,652,856 – 1986 年 2 月 4 日 – Kottappuram MA Mohiuddin およびJorma J. Rissanen – 乗算のない複数アルファベットの算術コード
  • 米国特許 4,905,297 – 1990 年 2 月 27 日 – G. Langdon、JL Mitchell、WB Pennebaker、Jorma J. Rissanen – 算術符号化エンコーダおよびデコーダ システム
  • 米国特許 4,935,882 – 1990 年 6 月 19 日 – WB Pennebaker および JL Mitchell – 算術符号化器の確率適応
• 三菱電機
  • 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 年に論争の的となりました (下記の特許論争を参照)。^[13]ただし、JPEG 仕様では、1977 年と 1984 年に発表された Wen-Hsiung Chen による 2 つの以前の研究論文が引用されています。 ^[1]

「JPEG」はJoint Photographic Experts Groupの略で、JPEG規格やその他の静止画像符号化規格を作成した委員会の名前です。「Joint」はISO TC97 WG8とCCITT SGVIIIの略です。1986年に設立されたこのグループは、1980年代後半にJPEG規格を開発しました。このグループは1992年にJPEG規格を公開しました。^[4]

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つであり、静止画像の符号化と呼ばれている。^{[14] [15] [16]} ITU-T側では、ITU-T SG16がそれぞれの組織である。元々のJPEGグループは1986年に組織され、^{[17] 1992年に最初のJPEG標準を発行し、1992年9月に}ITU-T勧告T.81 ^[18]として承認され、1994年にはISO / IEC 10918-1として承認された。

JPEG規格では、画像をバイトストリームに圧縮し、画像に解凍する方法を定義するコーデックが指定されていますが、そのストリームを格納するために使用されるファイル形式は指定されていません。^[19] Exif 規格とJFIF規格は、JPEG圧縮画像の交換に一般的に使用されるファイル形式を定義しています。

JPEG 規格は正式には「情報技術 - 連続階調静止画像のデジタル圧縮および符号化」と呼ばれます。ISO/IEC 10918 は次の部分で構成されています。

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

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

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

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

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

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

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）は有効であると判定した。^[32] 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特許は無効であり侵害されていないという司法宣言を求めた。

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

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

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

JPEG 圧縮アルゴリズムは、滑らかなトーンと色の変化を持つ写実的なシーンの写真や絵画に最適です。レスポンシブなプレゼンテーションのために画像に使用するデータ量を減らすことが重要となる Web での使用では、JPEG の圧縮の利点により JPEG が人気です。JPEG/ Exif は、デジタル カメラで保存される最も一般的な形式でもあります。

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

JPEG の典型的な使用法は、画像の忠実度を低下させる非可逆圧縮方式であるため、画像データの正確な再現には適していません (一部の科学的および医療用画像処理アプリケーションや特定の技術的な画像処理作業など)。

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

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

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

インターレース プログレッシブJPEG形式もあり、これはデータが段階的に詳細度を増す複数のパスで圧縮される。これは、低速接続でダウンロード中に表示される大きな画像に最適で、データの一部のみを受信した後でも適切なプレビューが可能になる。ただし、プログレッシブJPEGのサポートは普遍的ではない。プログレッシブJPEGをサポートしていないプログラム（Windows 7より前のバージョンのInternet Explorerなど）^[41]でプログレッシブJPEGを受信すると、ソフトウェアは画像が完全にダウンロードされた後にのみ画像を表示する。

グレースケールとカラーの両方で12ビットJPEG画像を作成および処理する医療用画像、交通、カメラアプリケーションも多数あります。12ビットJPEG形式は、JPEG仕様の拡張部分に含まれています。libjpegコーデックは12ビットJPEGをサポートしており、高性能バージョンも存在します。^[42]

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

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

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

JPEG 画像の上端と左端は 8 × 8 ピクセルのブロック境界 (または、より大きな MCU サイズの場合は 16 × 16 ピクセル) 上にある必要がありますが、下端と右端はそうである必要はありません。これにより、ロスレス クロップ操作の可能性が制限され、すべてのチャネルで下端または右端がブロック境界上にない画像の反転や回転が防止されます (エッジが上端または左端に配置されるため、前述のようにブロック境界は必須です)。

画像が8または16の倍数ではない場合の回転は、その値はクロマサブサンプリングに依存し、ロスレスではありません。そのような画像を回転すると、ブロックが再計算され、品質が低下します。^[43]

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

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

「JPEG 交換形式」(JIF) として知られるファイル形式は、標準の付録 B で指定されています。ただし、この「純粋な」ファイル形式は、主に標準のすべての側面を完全に実装するエンコーダとデコーダをプログラミングするのが難しいことと、標準に次のような欠点があることから、ほとんど使用されていません。

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

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

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

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

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

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

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

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

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

JPEG 画像は、一連のセグメントで構成され、各セグメントはマーカーで始まります。マーカーはそれぞれ 0xFF バイトで始まり、その後にマーカーの種類を示すバイトが続きます。マーカーの中には、この 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 エンコーディングを導入する 他のStart Of Frameマーカーもあります。

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

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

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

1. 画像内の色の表現はRGBから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のライブラリ^[50]の0〜100のスケールで50または95 ）は、各周波数成分の解像度がどの程度低下するかに影響します。過度に低い品質設定が使用されると、高周波成分はすべて破棄されます。
5. すべての 8×8 ブロックの結果データは、ハフマン符号化の変形であるロスレス アルゴリズムを使用してさらに圧縮されます。

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

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

まず、画像をRGB（デフォルトではsRGB、^{[47] [48]}だが、他の色空間も可能）から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カラーモデルで色情報を保持するものもあります。 ^[51]この場合、画像は赤、緑、青の明るさのコンポーネントごとに別々のチャネルに保存されます。これにより、圧縮効率が低下し、ファイルサイズが特に重要な場合には使用されない可能性があります。

人間の目には色と明るさに敏感な受容体の密度があるため、人間は画像の色相と彩度 (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 はマクロブロックと呼ばれます。

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

次に、各コンポーネント (Y、Cb、Cr) の 8×8 ブロックはそれぞれ、正規化された 2 次元タイプ II 離散コサイン変換 (DCT) を使用して周波数領域表現に変換されます (離散コサイン変換の引用 1 を参照)。離散コサイン変換のような変換ファミリーのコンテキストでは、DCT は「タイプ II DCT 」と呼ばれることもあり、対応する逆変換 (IDCT) は「タイプ III DCT」と呼ばれます。

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

${\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 処理段階でのダイナミック レンジ要件が削減されます。 ${\displaystyle [0,255]}$${\displaystyle [-128,127]}$

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

${\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\\-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.}$

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

${\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]}$

どこ

• ${\displaystyle \ u}$は水平空間周波数で、整数です。${\displaystyle \ 0\leq u<8}$
• ${\displaystyle \ v}$は垂直空間周波数で、整数です。${\displaystyle \ 0\leq v<8}$
• ${\displaystyle \alpha (u)={\begin{cases}{\frac {1}{\sqrt {2}}},&{\mbox{if }}u=0\\1,&{\mbox{otherwise}}\end{cases}}}$は変換を正規直交にするための正規化スケール係数である
• ${\displaystyle \ g_{x,y}}$座標のピクセル値です${\displaystyle \ (x,y)}$
• ${\displaystyle \ G_{u,v}}$座標におけるDCT係数である${\displaystyle \ (u,v).}$

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

${\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 係数 (交互成分とも呼ばれます) です。^[52] DCT の利点は、上記のように、結果の 1 つのコーナーにほとんどの信号が集約される傾向があることです。その後の量子化ステップでは、この効果を強調すると同時に DCT 係数の全体的なサイズを縮小し、エントロピー段階で効率的に圧縮しやすい信号を生成します。

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

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

量子化マトリックスの要素は圧縮率を制御し、値が大きいほど圧縮率も高くなります。一般的な量子化マトリックス (元の JPEG 標準で指定されている 50% の品質の場合) は次のとおりです。

${\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係数は次のように計算される。

${\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 係数です。 ${\displaystyle G}$${\displaystyle Q}$${\displaystyle B}$

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

${\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係数）を使用し、最も近い整数に丸めると、

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

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

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

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

前の量子化 DC 係数は、現在の量子化 DC 係数を予測するために使用されます。実際の値ではなく、2 つの係数の差がエンコードされます。63 個の量子化 AC 係数のエンコードでは、このような予測の差は使用されません。

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

i番目のブロックが で表され、各ブロック内の位置がおよびで表されている場合、DCT 画像内の任意の係数は として表すことができます。したがって、上記の方式では、ピクセルをエンコードする順序 ( i 番目のブロックの場合)は、、、、、、、、、などと なります。${\displaystyle B_{i}}$${\displaystyle (p,q)}$${\displaystyle p=0,1,...,7}$${\displaystyle q=0,1,...,7}$${\displaystyle B_{i}(p,q)}$${\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)}$

このエンコード モードは、ベースラインシーケンシャルエンコードと呼ばれます。ベースライン JPEG は、プログレッシブエンコードもサポートしています。シーケンシャル エンコードでは、一度に 1 つのブロックの係数を (ジグザグに) エンコードしますが、プログレッシブ エンコードでは、すべてのブロックの係数の同様の位置にあるバッチを 1 回でエンコードし (スキャン と呼びます)、その後にすべてのブロックの次のバッチの係数をエンコードする、というように繰り返します。たとえば、画像が N 個の 8×8 ブロック に分割されている場合、3 スキャン プログレッシブ エンコードでは、最初のスキャンですべてのブロック、つまりすべての のDC成分をエンコードします。その後に 2 番目のスキャンが続き、すべてのブロックの係数をさらにいくつか (さらに 4 つの成分があると仮定すると、それらはからで、やはりジグザグに) エンコードし (したがって、シーケンスは です)、最後のスキャンですべてのブロックの残りの係数をすべてエンコードします。 ${\displaystyle B_{0},B_{1},B_{2},...,B_{n-1}}$${\displaystyle B_{i}(0,0)}$${\displaystyle i=0,1,2,...,N-1}$${\displaystyle B_{i}(0,1)}$${\displaystyle B_{i}(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 つのシンボルが作成されます。

RUNLENGTHとSIZE はどちらも同じバイト上にあり、それぞれ 4 ビットの情報のみが含まれています。上位ビットはゼロの数を扱い、下位ビットはxの値をエンコードするために必要なビット数を示します。

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

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

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

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

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

結果の圧縮率は、量子化フェーズで使用される除数を多かれ少なかれ積極的にすることで、必要に応じて変えることができます。10 対 1 の圧縮では、通常、目で見て元の画像と区別がつかない画像になります。通常、100 対 1 の圧縮率は可能ですが、元の画像と比較すると明らかにアーティファクトが目立ちます。適切な圧縮レベルは、画像の使用目的によって異なります。

外観イメージ
エッジの忙しさの図解[53]

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

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

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

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

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

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

${\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]}$

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

${\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) を実行することです。これは次のように表されます。

${\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]}$

どこ

• ${\displaystyle \ x}$はピクセル行で、整数です。${\displaystyle \ 0\leq x<8}$
• ${\displaystyle \ y}$は整数のピクセル列です。${\displaystyle \ 0\leq y<8}$
• ${\displaystyle \ \alpha (u)}$は、整数に対して以前に定義した正規化スケール係数です。${\displaystyle \ 0\leq u<8}$
• ${\displaystyle \ F_{u,v}}$は座標における近似DCT係数である${\displaystyle \ (u,v).}$
• ${\displaystyle \ f_{x,y}}$座標における再構成されたピクセル値である${\displaystyle \ (x,y)}$

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

${\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を加算する

${\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].}$

これは解凍されたサブイメージです。一般に、解凍プロセスでは、元の入力範囲外の値が生成されることがあります。このような場合、デコーダーは、元のビット深度で解凍されたイメージを保存するときにオーバーフローが発生しないように、出力値をその範囲内に収めるようにクリップする必要があります。 ${\displaystyle [0,255]}$

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

${\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 値 (つまり、) です。 ${\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 の最大許容誤差によって、JPEG コーデックのエンコードおよびデコード プロセスに必要な実装精度の両方を定義しています。たとえば、デコーダ実装の出力は、上記の標準の一部として提供される参照テスト コードストリームに適用された場合、DCT ドメインで 1 つの量子化単位の誤差を超えてはなりません。他の多くの最新の標準とは異なり、ITU.T T.83 | ISO/IEC 10918-2 は、画像ドメインでの誤差境界を策定していません。

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)に記載されています。 ^[55]

中品質の写真は、非圧縮画像に必要なストレージ スペースの 4.3% しか使用しませんが、目立ったディテールの損失や目に見えるアーティファクトはほとんどありません。ただし、圧縮の特定のしきい値を超えると、圧縮された画像に目に見える欠陥がますます現れます。このしきい値効果の数学的説明については、レート歪み理論に関する記事を参照してください。この点で JPEG に特有の制限は、重複しない 8×8 ブロック変換構造です。JPEG 2000やJPEG XRなどのより新しい設計では、より低い周波数係数に対してより大きな空間範囲の変換を使用し、重複する変換基底関数を使用することで、ビット使用量が減少するにつれて、より緩やかな品質の低下が見られます。

2004年から2008年にかけて、JPEG画像に含まれるデータを、表現された画像を変更せずにさらに圧縮する方法に関する新しい研究が登場しました。^{[56] [57] [58] [59]}これは、元の画像がJPEG形式でしか利用できず、アーカイブや転送のためにサイズを縮小する必要があるシナリオに適用されます。標準的な汎用圧縮ツールでは、JPEGファイルを大幅に圧縮することはできません。

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

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

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

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

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

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

JPEG マルチピクチャ

ファイル名拡張子	.mpo
統一型識別子 (UTI)	パブリック.mpo-イメージ[63]

JPEG マルチピクチャーフォーマット (MPO、拡張子 .mpo) は、複数の画像を 1 つのファイルに保存するための JPEG ベースのフォーマットです。2 つ以上の JPEG ファイルが連結されています。^{[64] [65]}また、画像の説明用に JPEG APP2 マーカーセグメントも定義されています。Fujifilm FinePix Real 3D W1、HTC Evo 3D、JVC GY-HMZ1U AVCHD/MVC 拡張カムコーダー、Nintendo 3DS、Panasonic Lumix DMC-TZ20、DMC-TZ30 、 DMC-TZ60、DMC-TS4 (FT4)、Sony DSC-HX7V など、さまざまなデバイスが 3D 画像の保存に使用しています。他のデバイスでは、テレビに表示できる「プレビュー画像」の保存に使用されています。

ここ数年、立体画像の利用が増えたことにより、科学界では立体画像圧縮アルゴリズムの開発に多大な努力が払われてきた。^{[66] [67]}

JPEG コーデックの非常に重要な実装は、Independent JPEG Group のフリープログラミングライブラリlibjpeg^{です。これは 1991 年に初めて公開され、標準の成功の鍵となりました。このライブラリは数え切れないほどのアプリケーションで使用されました。 [68]}開発は 1998 年に静かになりました。libjpeg が 2009 バージョン 7 で再登場したとき、以前のバージョンとのABI 互換性が失われました。2010 年のバージョン 8 では非標準の拡張機能が導入されましたが、この決定は IJG の元リーダーである Tom Lane によって批判されました。^[69]

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

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

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

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

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

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

JPEG 2000 は、2000 年 12 月に ISO/IEC 15444 として公開されました。これは離散ウェーブレット変換(DWT) に基づいており、元の JPEG 標準を完全に置き換え、あらゆる点でそれを上回るように設計されました。色チャネルあたり最大 38 ビット、他のどの形式よりも多くの 16384 チャネル、多数の色空間、およびハイダイナミックレンジ (HDR) が可能です。さらに、アルファ透過コーディング、他のどの形式よりも多くの数十億ピクセルの画像、およびロスレス圧縮をサポートしています。ロスレス圧縮率が大幅に向上し、強力な圧縮レベルで目に見えるアーティファクトが大幅に減少しました。^[78]

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

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

• AVIF
• Better Portable Graphics、HEVCのフレーム内エンコーディングに基づくフォーマット
• C-Cube は、チップ形式で JPEG を早期に実装した企業です。
• グラフィックファイル形式の比較
• デブロッキングフィルタ（ビデオ）、同様のデブロッキング手法をJPEGに適用できる。
• カメラファイルシステムの設計ルール(DCF)
• ロスレス画像コーデックFELICS
• ファイル拡張子
• グラフィック編集プログラム
• 高効率画像ファイル形式、 HEVCおよびその他の画像コーディング形式用の画像コンテナ形式
• Lenna（テスト画像）は、画像処理アルゴリズムをテストするために使われる従来の標準画像です。
• モーションJPEG
• ウェブP

• 公式サイト
• W3.org の JPEG 標準 (JPEG ISO/IEC 10918-1 ITU-T 勧告 T.81)
• W3.org の JFIF ファイル形式
• visengi.com の 1 から 100 までの量子化レベル全体にわたるサンプル画像
• JPEG デコーダー オープンソースコード、著作権 (C) 1995–1997、Thomas G. Lane