Loading article…
JPEGファイル交換フォーマット（JFIF）は、ITU-T勧告T.871およびISO/IEC 10918-5として公開されている画像ファイルフォーマット規格です。JPEGアルゴリズムでエンコードされた画像データを含むコンテナフォーマットの補足仕様を定義します。JPEGコンテナフォーマットの基本仕様は、JPEG交換フォーマット（JIF）として知られるJPEG規格の附属書Bで定義されています。JFIFはJIFをベースに、不要な複雑さ、コンポーネントサンプルのレジストレーション、解像度、アスペクト比、カラースペースなど、JIFのいくつかの制限を解決します。JFIFはオリジナルのJPG規格ではないため、別のMIMEタイプを期待するかもしれませんが、実際には「image/jpeg」（修正された情報ではなく、その主要なデータフォーマットを示す）として登録されています。
JFIFは、より新しい交換可能な画像ファイル形式（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 になります。JFIF で CCIR 601 を介して定義されている RGB 原色も、新しいアプリケーションで一般的になっているものとは多少異なります (たとえば、 sRGBで定義されている原色とはわずかに異なります)。さらに、CCIR 601（2007年以前）はRGBカラーの原色について明確な定義を与えておらず、テレビ業界の慣習に依拠していた。
JFIF画像の色の解釈は、ICCプロファイル、カラースペースメタデータ、またはsRGBタグを埋め込み、これらの情報を解釈するアプリケーションを使用することで改善される可能性があります。
JFIF ファイルは、マーカーまたはマーカー セグメントのシーケンスで構成されます (詳細はJPEG、構文と構造を参照)。マーカーはJPEG標準のパート 1 で定義されています。[ 1 ]各マーカーは 2 バイトで構成されます。1 バイトの後に、またはFFと等しくない 1 バイトが続き、マーカーのタイプを指定します。一部のマーカーは単独で存在しますが、ほとんどのマーカーは、次のパターンに従ってデータ バイトを含むマーカー セグメントの開始を示します。00FF
FF xxs1s2[data bytes]
バイトs1とs2は、ビッグエンディアンの16ビット整数として扱われ、後続の「データバイト」の長さと、その長さを表すために使用される2バイトの長さを指定します。言い換えれば、s1とs2は、後続のデータバイトの数を指定します。。
JPEG規格のパート1によれば、アプリケーションはAPPマーカーセグメントを使用して、データのアプリケーション固有の意味を定義できます。JFIF規格では、以下のAPPマーカーセグメントが定義されています。
それらについては以下に説明します。
JFIF規格では、JFIF APP0マーカーセグメントはSOIマーカーの直後に続く必要があります。JFIF拡張APP0マーカーセグメントを使用する場合は、JFIF APP0マーカーセグメントの直後に続く必要があります。[ 2 ]したがって、JFIFファイルは次の構造になります。
必須のJFIF APP0マーカーセグメントには、画像のパラメータが指定されます。オプションで、非圧縮のサムネイルを埋め込むこともできます。
JFIF APP0マーカーセグメントの直後には、JFIF拡張APP0マーカーセグメントが続く場合があります。このセグメントは、JFIFバージョン1.02以降でのみ使用可能です。これにより、3種類の異なる形式でサムネイル画像を埋め込むことができます。
サムネイルデータは、サムネイルのフォーマットによって以下のように異なります。
新しいExchangeable Image File Format（Exif）はJFIFに似ていますが、両規格は互換性がありません。これは、両規格とも、それぞれのアプリケーションセグメント（JFIFの場合はAPP0、Exifの場合はAPP1）がSOIマーカーの直後に続く必要があると規定しているためです。実際には、多くのプログラムやデジタルカメラは、両方のアプリケーションセグメントを含むファイルを生成します。これはほとんどのデコーダーの画像デコードには影響しませんが、設計の不十分なJFIFまたはExifパーサーではファイルが正しく認識されない可能性があります。
JFIFは、Adobe PhotoshopのJPEG「情報リソースブロック」拡張機能およびIPTC情報交換モデルのメタデータと互換性があります。これは、JFIFが他のアプリケーションセグメントを排除するものではなく、Photoshop拡張機能がファイル内で最初に記述される必要がないためです。ただし、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合同写真専門家グループによって取り上げられるまで、公式の発行者はいなかった。歴史的記録の喪失を防ぐため、2009年にECMAによって技術レポート番号98として発行され[ 3 ] 、2011年にITU-Tによって勧告T.871として 正式に標準化され[ 4 ] 、2013年にISO/IECによってISO/IEC 10918-5として標準化された[ 5 ]。新しい出版物には編集上の改善が含まれていたが、実質的な技術的変更はなかった。
