JPEGファイル交換形式( JFIF ) は、ITU-T勧告 T.871 およびISO/IEC 10918-5として公開されている画像ファイル形式の標準です。JPEG アルゴリズムでエンコードされた画像データを含むコンテナ形式の補足仕様を定義します。JPEG コンテナ形式の基本仕様は、JPEG 標準の付録 B で定義され、JPEG 交換形式 (JIF) として知られています。JFIFは、JIF を基に構築され、不要な複雑さ、コンポーネント サンプルの登録、解像度、アスペクト比、色空間など、JIF の制限の一部を解決しています。JFIF は元の JPG 標準ではないため、別のMIMEタイプが期待されるかもしれません。ただし、これは依然として「image/jpeg」として登録されています (修正された情報ではなく、プライマリ データ形式を示します)。
JFIF は、新しいExchangeable image file format (Exif) と相互に互換性がありません。
目的
JFIFはJPEGパート1規格(ISO / IEC 10918-1、ITU-T勧告T.81)で規定されていない多くの詳細を定義しています。 [1]
コンポーネントサンプル登録
JPEG では、複数のコンポーネント ( Y、Cb、Crなど) が異なる解像度を持つことが許可されていますが、ビットマップをレンダリングする異なるサンプル配列をどのように配置するかは定義されていません。このピクセル生成情報は、直接ピクセル データであったり、「最初のコーナーとフラッド」などであったりするのではなく、重心によって長方形を示すことを想定してレンダリングされますが、これは一般的ではありません。
解像度とアスペクト比
JPEG 標準には、画像の解像度やアスペクト比をコード化する方法は含まれていません。JFIF は、JPEG のアプリケーション セグメント拡張を使用して解像度やアスペクト比の情報を提供します。JFIF は、ASCIIで「JFIF」と綴られたヌル終端文字列とそれに続く 0 に等しいバイトで構成されるセグメント ヘッダーを持つアプリケーション セグメント #0 を使用し、これがファイルの最初のセグメントでなければならないことを指定します。これにより、JFIF ファイルを簡単に認識できます。デジタル カメラで記録されたExif画像には通常、このセグメントは含まれませんが、他のすべての点では JFIF 標準に準拠しています。
色空間
JFIF ファイルの圧縮コーディングに使用される JPEG 標準では、画像に使用するカラー エンコーディングは定義されていません。JFIF は、使用するカラー モデルを定義します。グレースケールの場合はY 、CCIR 601 (現在は Rec. ITU-R BT.601 として知られています)で定義されているRGB カラー プライマリから派生したYCbCrのいずれかですが、Y、Cb、Cr コンポーネントの「フル レンジ」スケーリングが異なります。CCIR 601 で定義されている「スタジオ レンジ」では、黒は Y=16、白は Y=235 で表され、この範囲外の値は信号処理の「ヘッドルーム」と「フットルーム」に使用できますが、JFIF では 8 ビット表現の 256 レベルすべてを使用するため、黒の場合は Y=0、ピーク白の場合は Y=255 になります。 CCIR 601 を介して JFIF で定義された RGB 原色も、新しいアプリケーションで一般的に使用されているものとは多少異なります (たとえば、sRGBで定義された原色とは若干異なります)。さらに、CCIR 601 (2007 年以前) では、RGB 原色の正確な定義は提供されておらず、テレビ業界の基本的な慣行に依存していました。
JFIF イメージの色の解釈は、ICCプロファイル、カラースペース メタデータ、またはsRGBタグを埋め込み、この情報を解釈するアプリケーションを使用することで改善される可能性があります。
ファイル形式の構造
JFIF ファイルは、一連のマーカーまたはマーカー セグメントで構成されています (詳細については、JPEG の構文と構造を参照してください)。マーカーは、 JPEG標準のパート 1 で定義されています。[1]各マーカーは 2 つのバイトで構成されます。1 つのバイトの後に、マーカーの種類を指定するか、またはFFに等しくないバイトが続きます。一部のマーカーは独立していますが、ほとんどは次のパターンに従ってデータ バイトを含むマーカー セグメントの開始を示します。
00FF
FF xx s1 s2 [data bytes]
バイトs1とs2 は、次の「データ バイト」の長さと、長さを表すために使用される 2 バイトを指定するビッグ エンディアンの16 ビット整数を表すために一緒に使用されます。つまり、s1とs2 は、次のデータ バイトの数をとして指定します。
JPEG 標準のパート 1 によれば、アプリケーションは APP マーカー セグメントを使用して、データのアプリケーション固有の意味を定義できます。JFIF 標準では、次の APP マーカー セグメントが定義されています。
- JFIF APP0 マーカー セグメント (略して JFIF セグメント) (必須)
- JFIF 拡張 APP0 マーカー セグメント (略して JFXX セグメント) (オプション)
以下にそれらについて説明します。
JFIF規格では、JFIF APP0マーカーセグメントがSOIマーカーの直後に続くことが要求されています。JFIF拡張APP0マーカーセグメントを使用する場合は、JFIF APP0マーカーセグメントの直後に続く必要があります。[2]したがって、JFIFファイルの構造は次のようになります。
JFIF APP0 マーカーセグメント
必須の JFIF APP0 マーカー セグメントでは、画像のパラメータが指定されます。オプションで、圧縮されていないサムネイルを埋め込むことができます。
JFIF拡張APP0マーカーセグメント
JFIF APP0 マーカー セグメントの直後に JFIF 拡張 APP0 マーカー セグメントが続く場合があります。このセグメントは、JFIF バージョン 1.02 以降にのみ存在します。これにより、3 つの異なる形式でサムネイル画像を埋め込むことができます。
サムネイル データは、サムネイル形式によって次のように異なります。
互換性
新しいExchangeable image file format (Exif) は JFIF に匹敵しますが、この 2 つの標準は相互に互換性がありません。これは、両方の標準で、特定のアプリケーション セグメント (JFIF の場合は APP0、Exif の場合は APP1) が SOI マーカーの直後に続く必要があると規定されているためです。実際には、多くのプログラムやデジタル カメラは、両方のアプリケーション セグメントを含むファイルを生成します。これは、ほとんどのデコーダーでイメージのデコードには影響しませんが、設計が不十分な JFIF または Exif パーサーはファイルを正しく認識しない可能性があります。
JFIF は他のアプリケーション セグメントを排除せず、Photoshop の拡張子がファイルの先頭にある必要がないため、Adobe Photoshopの JPEG「情報リソース ブロック」拡張子およびIPTC 情報交換モデルメタデータと互換性があります。ただし、Photoshop は通常、CMYK バッファを JFIF に準拠していない 4 コンポーネントの「Adobe JPEG」として保存します。これらのファイルは YCbCr カラー スペースではないため、通常は Web ブラウザやその他のインターネット ソフトウェアでデコードできません。
歴史
JFIF文書の開発はC-Cube MicrosystemsのEric Hamiltonが主導し、1991年後半にC-Cubeで開催された会議で、さまざまなコンピュータ、通信、画像処理会社の代表者約40名が参加して、最初のバージョンに関する合意が成立しました。その後まもなく、マイナーリビジョンであるJFIF 1.01が公開されました。[3]ほぼ20年間、最新バージョンは1992年9月1日に公開されたv1.02でした。[2]
1996 年、RFC 2046 では、インターネット経由で JPEG 画像を送信するときに使用する画像形式は JFIF にする必要があると規定されました。MIMEタイプ「image/jpeg」は JFIF としてエンコードする必要があります。ただし、実際には、JFIF に準拠しているかどうかに関係なく、Y または YCbCr コンポーネントを使用するベースラインJIF画像をほぼすべてのインターネット ソフトウェアでデコードできます。
時が経つにつれ、C-Cubeは再編され(最終的にはHarmonic、LSI Logic、Magnum Semiconductor、Avago Technologies、Broadcom、GigOptix、GigPeakなどに分割された)、この文書に対する関心を失い、仕様書には公式の発行元がなかったが、 2009年頃にEcma InternationalとITU-T/ISO/IEC Joint Photographic Experts Groupが、仕様書が歴史に埋もれるのを避け、標準的な出版物で正式に引用して編集の質を向上させる手段を提供するために、仕様書を取り上げました。歴史的記録の損失を避けるために、2009年にECMAによって技術レポート番号98として発行され、[3] 2011年にITU-Tによって勧告T.871 [4]として 正式に標準化され 、2013年にISO/IECによってISO/IEC 10918-5 [5]として正式に標準化されました。新しい出版物には編集上の改善が含まれていましたが、大幅な技術的変更はありませんでした。
参照
参考文献
- ^ ab 「勧告ITU-T T.81:情報技術 - 連続階調静止画像のデジタル圧縮および符号化 - 要件とガイドライン」(PDF)。ITU -T (旧CCITT)。1992年2月18日。 2015年6月15日閲覧。
- ^ ab Hamilton, Eric (1992年9月12日). 「JPEG ファイル交換フォーマット、バージョン1.02」(pdf、0.02 MB) 。 2015年6月15日閲覧。
- ^ ab 「JPEG ファイル交換フォーマット (JFIF)」。ecma-international.org。2009年。 2015年6月15日閲覧。
- ^ 「勧告ITU-T T.871: 情報技術 - 連続階調静止画像のデジタル圧縮および符号化: JPEG ファイル交換フォーマット (JFIF)」(PDF)。ITU-T。2011年5月14日。 2015年6月15日閲覧。
- ^ 「ISO/IEC 10918-5:2013: 情報技術 - 連続階調静止画像のデジタル圧縮および符号化: JPEG ファイル交換形式 (JFIF)」。ISO/国際電気標準会議。2013 年 5 月 1 日。2015 年6 月 15 日閲覧。
さらに読む
書籍
- Miano, John M、「圧縮画像ファイル形式」、1999 年、Addison-Wesley ISBN 978-0-201-60443-6
- ペネベーカー、ウィリアム B. およびジョアン L. ミッチェル:JPEG 静止画像データ圧縮規格、第 3 版、1993 年、Springer ISBN 978-0-442-01272-4
標準
- ハミルトン、エリック: JPEG ファイル交換フォーマット、バージョン 1.02 (PDF、0.02 MB) 1992 年 9 月 1 日
- ITU-T T.871 勧告: 情報技術 - 連続階調静止画像のデジタル圧縮および符号化: JPEG ファイル交換形式 (JFIF) (PDF および Microsoft Word、0.2 MB) 2011 年 5 月 14 日承認、2012 年 9 月 11 日掲載
- ITU-T T.81 勧告: 情報技術 - 連続階調静止画像のデジタル圧縮および符号化 - 要件とガイドライン (PDF および Microsoft Word、1.5 MB) 1992 年 9 月 18 日承認、2004 年 4 月 14 日掲載
