Tiffの話
TIFFとは
画像フォーマットの一種である。歴史は古くインターネット普及以前の代物である。基本的にはオフラインで使うために設計されたフォーマットでオンラインには向いていない。これはTIFFの仕様上ファイルシークが大量に発生するため、ストリーミングには向いていないのである。この部分はJPEGとは対象的である。JPEGはファイルシークが発生しないのとある程度のエラーリカバリーが可能なのでストリーミング向きである。
TIFFフォーマットの仕様
TIFFの制限
TIFFの制限は、offset情報が4byte固定になっている点から来ている。つまり4GBを越えるデータを扱えない。それを扱える様に拡張したのがBig TIFFと呼ばれるものであるが、ここでは扱わない。4GBを越える画像がほぼ無いから。超高解像度の印刷用データを無圧縮で扱う時に出てきそうではある。
ヘッダの仕様
+0000 +----------+
| II or MM |
+0002 +----------+
| 42 |
+0004 +----------+
|IFD offset|---> IFD
| |
| |
+0008 +----------+
- HEADER ヘッダは、'II'もしくは'MM'で始まる。IIはリトルエンディアン、MMはビッグエンディアンでデータが格納されていることをしめしている。
- ヘッダに続く2byteはバージョン情報が入っている。バージョン情報と言ってもほぼ固定で42(0x2A)である。ところがTIFFはバイ・エンディアンを採用していることから、最初の2byteがIIで始まる場合は[0x2A,0x00]であり、MMで始まる場合は[0x00,0x2A]になる。
- 続く4byteにIFDのOffsetが格納されているIFD(Image File Directoy)は、イメージのタグ化されたデータが格納されているフィールドである。Offsetを指定していると言うことは、ヘッダの直後にIFDが存在するとは限らず、ファイルの最後に格納されている可能性もあると言うことである。このデータもヘッダで格納順序が変わる。以下のデータもすべて変わる。
Image File Directory
IFD は以下の構造になっている。
最初の2byteにDirectory Entries(タグ)の数が格納されている。そこからタグの数だけEnrtyが格納されており、最後に次のIFDのOffsetが格納されている。IFDは複数に分割する事が可能である。ただし、一番最後のIFDは0で終わる必要がある。このIFDにはTagのIDの小さい方からソートされて格納されている。もし次のIDが前のIDより小さいなら、それは複数のイメージが格納されており、次のイメージデータを差している可能性が高い。その場合、NewSubfileTypeとSubfileTYpeをチェックし、サムネイルや付加データでないことを確認する必要がある。要するに解析がしんどい。
IFD
+0000 +----------+
| n | タグの数 2byte
+0002 +----------+
| | 1つめのタグ(Directry Entry) 12byte
+0014 +----------+
| | 2つめのタグ
+0026 +----------+
| |
......
+----------+
| | 次のIFD Offset 4byte
+xxxx +----------+
Directory Entry
Directory Entryはタグのデータが埋め込まれているところである。サイズは12byteである、しかし値を格納できるサイズが4byteのなので、4byteを越える場合はデータが埋め込まれている値そのものではなく値を格納されているoffsetが格納されている。
これが割と面倒な部分。Data TypeがUint8なら4つまで、UShort16なら2つまで、ULong32なら1つまでならOffsetではなく値が格納されている訳である。これ以外のData Typeもあり、Count=1でも8Byteを越えるケースがあり、その場合は必ずOffsetを示している。
IFD
+0000 +----------+
| | Tag ID 2byte
+0002 +----------+
| | Data Type 2byte
+0004 +----------+
| |
| | Count 4byte
| |
+0008 +----------+
| |
| | values or data offset
| |
+0012 +----------+
Tag IDは0-65535(0x0000-0xffff)までの値を取りうるが、0x8000以上がプライベートTagIDになる。Exifはこのプライベート領域のタグIDを使って居るが、GPSは独自のタグIDを振っている。
Data Type
Tiff6.0で採用されているデータ型は以下の通り
| # | byte | Type | 注釈 |
|---|---|---|---|
| 1 | 1 | BYTE | UInt8(符号無し8bit整数) |
| 2 | 1 | ASCII | 7bitのASCIIコード。最後必ず0x00(NULL)で終わる |
| 3 | 2 | SHORT | Uint16(符号無し16bit整数) |
| 4 | 4 | LONG | Uint32(符号無し32bit整数) |
| 5 | 8 | RATIONAL | 分数 Uint32の分子とUint32の分母 |
| 6 | 1 | SBYTE | SInt8(符号付き8bit) |
| 7 | 1 | UNDEFINED | Tagが解釈する。countにはbyte数が入る |
| 8 | 2 | SSHORT | SInt16(符号付き16bit整数) |
| 9 | 4 | SLONG | SInt32(符号付き32bit整数) |
| 10 | 8 | SRATIONAL | 分数 SInt32の分子とUInt32の分母 |
| 11 | 4 | FLOAT | 浮動小数点（IEEE 単精度浮動小数点) |
| 12 | 8 | DOUBLE | 浮動小数点（IEEE 倍精度浮動小数点) |
タグの格納方法
小さい番号のタグから順番に格納することになっている。かりに、大きい番号のタグの後に小さい番号のタグが出てきた場合は、マルチメージTiffであることを示唆している。
Tiffのタグの情報
ほぼ網羅しているサイトは以下だけではないだろうか？
Tiffの自由度の高さ
TIFFはフォーマットの自由度が低く。あり得ない実装が可能である。逆に言えば全てを実装できないのである。実際に全て実装しているTIFFデコーダは存在せず、間違った実装も多いのである。しかもプライベートのタグが多く、その部分はブラックボックスになっている訳である。
言い替えると多少の不具合を許容するように書かないとデコーダが動かない……。
基本的なイメージ
2値画像
2値画像で必須とされているタグは以下の通り
| Tag | 名称 | Count | Data Type | 説明 |
|---|---|---|---|---|
| 0x0100 | ImageWidth | 1 | SHORT/LONG | 画像の横の長さ |
| 0x0101 | ImageLength | 1 | SHORT/LONG | 画像の縦の長さ(height) |
| 0x0103 | Compression | 1 | SHORT | 1=なし、2= CCITT Group 3 32773= PackBits |
| 0x0106 | PhotometricInterpretation | 1 | SHORT | 0 白が0 1 黒が0 |
| 0x0111 | StripOffsets | n | SHORT/LONG | 画像格納領域のOffset n=ImageLength/RowsPerStrip を切り上げ |
| 0x0116 | RowsPerStrip | 1 | SHORT/LONG | 一つの画像格納領域に格納されている画像の縦の長さ |
| 0x0117 | StripOffsets | n | SHORT/LONG | 画像格納領域のサイズ(byte) n=ImageLength/RowsPerStrip を切り上げ |
| 0x011A | XResolution | 1 | RATIONAL | 画像の解像度(横方向) |
| 0x011B | YResolution | 1 | RATIONAL | 画像の解像度(縦方向) |
| 0x0128 | ResolutionUnit | 1 | SHORT | 解像度の単位 1=なし 2=インチ 3=cm (default=2) |
2値画像で注意すべきなのは、BitsPerPixelが省略できる点である。これはBitsPerPixelのdefault=1だからである。
グレイスケールイメージ
| Tag | 名称 | Count | Data Type | 説明 |
|---|---|---|---|---|
| 0x0100 | ImageWidth | 1 | SHORT/LONG | 画像の横の長さ |
| 0x0101 | ImageLength | 1 | SHORT/LONG | 画像の縦の長さ(height) |
| 0x0102 | BitsPerSample | 1 | SHORT | 画像の深度 4か8 (Default=1) |
| 0x0103 | Compression | 1 | SHORT | 1=なし、32773= PackBits、しかし理論的にLZWやJPEGなどが有り得る |
| 0x0106 | PhotometricInterpretation | 1 | SHORT | 0 白が0 1 黒が0 |
| 0x0111 | StripOffsets | n | SHORT/LONG | 画像格納領域のOffset n=ImageLength/RowsPerStrip を切り上げ |
| 0x0116 | RowsPerStrip | 1 | SHORT/LONG | 一つの画像格納領域に格納されている画像の縦の長さ |
| 0x0117 | StripOffsets | n | SHORT/LONG | 画像格納領域のサイズ(byte) n=ImageLength/RowsPerStrip を切り上げ |
| 0x011A | XResolution | 1 | RATIONAL | 画像の解像度(横方向) |
| 0x011B | YResolution | 1 | RATIONAL | 画像の解像度(縦方向) |
| 0x0128 | ResolutionUnit | 1 | SHORT | 解像度の単位 1=なし 2=インチ 3=cm (default=2) |
BitsPerSampleが省略されたグレイスケール画像は２値画像である。
インデックスカラーイメージ
インデックスカラーイメージは、パレットを使った256色以下の画像である。
| Tag | 名称 | Count | Data Type | 説明 |
|---|---|---|---|---|
| 0x0100 | ImageWidth | 1 | SHORT/LONG | 画像の横の長さ |
| 0x0101 | ImageLength | 1 | SHORT/LONG | 画像の縦の長さ(height) |
| 0x0102 | BitsPerSample | 1 | SHORT | 画像の深度 4か8 (Default=1) |
| 0x0103 | Compression | 1 | SHORT | 1=なし、32773= PackBits、しかし理論的にLZWやJPEGなどが有り得る |
| 0x0106 | PhotometricInterpretation | 1 | SHORT | 3 Indexed RGB |
| 0x0111 | StripOffsets | n | SHORT/LONG | 画像格納領域のOffset n=ImageLength/RowsPerStrip を切り上げ |
| 0x0116 | RowsPerStrip | 1 | SHORT/LONG | 一つの画像格納領域に格納されている画像の縦の長さ |
| 0x0117 | StripOffsets | n | SHORT/LONG | 画像格納領域のサイズ(byte) n=ImageLength/RowsPerStrip を切り上げ |
| 0x011A | XResolution | 1 | RATIONAL | 画像の解像度(横方向) |
| 0x011B | YResolution | 1 | RATIONAL | 画像の解像度(縦方向) |
| 0x0128 | ResolutionUnit | 1 | SHORT | 解像度の単位 1=なし 2=インチ 3=cm (default=2) |
| 0x0140 | ColorMap | n | SHORT | カラーマップ n=BitsPerSample=4なら16*3,8なら256*3 |
PhotometricInterpretationは必ず3になる。またColorMapがBYTEではなくSHORTなので注意が必要である。一般的に下位8bitを無視することが多い。
RGBフルカラー
総天然色
| Tag | 名称 | Count | Data Type | 説明 |
|---|---|---|---|---|
| 0x0100 | ImageWidth | 1 | SHORT/LONG | 画像の横の長さ |
| 0x0101 | ImageLength | 1 | SHORT/LONG | 画像の縦の長さ(height) |
| 0x0102 | BitsPerSample | 3- | SHORT | 画像の深度 (8,8,8) |
| 0x0103 | Compression | 1 | SHORT | 1=なし、32773= PackBits、他にLZWやJPEGなどなどが有り得る |
| 0x0106 | PhotometricInterpretation | 1 | SHORT | 2 RGB |
| 0x0111 | StripOffsets | n | SHORT/LONG | 画像格納領域のOffset n=ImageLength/RowsPerStrip を切り上げ |
| 0x0116 | RowsPerStrip | 1 | SHORT/LONG | 一つの画像格納領域に格納されている画像の縦の長さ |
| 0x0117 | StripOffsets | n | SHORT/LONG | 画像格納領域のサイズ(byte) n=ImageLength/RowsPerStrip を切り上げ |
| 0x011A | XResolution | 1 | RATIONAL | 画像の解像度(横方向) |
| 0x011B | YResolution | 1 | RATIONAL | 画像の解像度(縦方向) |
| 0x0128 | ResolutionUnit | 1 | SHORT | 解像度の単位 1=なし 2=インチ 3=cm (default=2) |
| 0x0140 | ColorMap | n | SHORT | カラーマップ n=BitsPerSample=4なら16*3,8なら256*3 |
PhotometricInterpretationは必ず3になる。TIFFのBitsPerSampleは基本的にByteで分割されるので(8,8,8)以外はほぼあり得ない。BMPと異なり2byteに(5,6,5)や(5,5,5)と言う変則的な格納を認めていない様である。ただしalphaチャネルを追加した場合(8,8,8,8)になりうる。またExtentionを利用すると(u8,float,float)と言うおかしな実装可能は規格上可能だが解読できるライブラリは、ほぼ存在しない。
風変わりなタグの解説
PlanerとChuncky
PlanarConfigurationで設定されるのがピクセルの格納方式である。ChunkyフォーマットはRGBRGBRGBと言う順番でピクセルがワンセットで格納されている方式である。PlanarはRRRR..GGGG...BBBB...とピクセルの要素が別々に格納されている方式である。現在Planarフォーマットはほぼ無いので無視しても良いだろう。
PlanarはCPUが8bit,16bitの時代の遺産で、8bit CPUは一度にアクセス出来るメモリが64KBで、16bit CPUは一般的に1024MBだったのである。しかし現実の8bitは256byteで16bitは64KBまでしか使えないのである。そのためCPU側ではアドレスのbit拡張やバンク切り替えと言う手法を使って扱えるメモリを無理矢理増やしていたのである。
同時に使えるメモリが少ないため、グラフィックデータはバンク切り替えと言う手法を使い、グラフィックに使えるメモリを仮想的に増やしていた訳である。そのため別々のバンクに色データを格納していたわけである。
――――という訳でグラフィックボードに於けるPlanarフォーマットは過去の遺産なのだが、JPEGはPlannerフォーマットを利用しており、8x8のブロック単位でY[8x8]Y[8x8]Y[8x8]Y[8x8]Cb[8x8]Cr[8x8]と言う順で格納されていたりする。
Compression
TIFFの基本的な圧縮はLZWだけである。しかし、なぜかFAX用の圧縮サポートがかなり充実しておりFAXのオンライン化にTIFFが使われて居た時代もある。しかしFAX系は、実装が面倒な割にリターンが少ない。PDFで履きだしてくれるものを使おう（TIFFでサポートされている圧縮は大体pdfにも実装されている）
LZW
TIFFのLZWはGIFのLZWとは互換性がない。ただし若干のコード書き換えで動作する。GIFと同様に特許爆弾を食らっていた。
PackBits
Packbitsは簡単なランレングス圧縮である。どの程度簡単かといえばBMPのRLEより単純。5分で実装できる。
Old JpegとJpeg圧縮
TIFFにはJpeg圧縮の実装が二種類ある(Compression=7,Compression=8)。それはTIFF6.0の初期の仕様ではJpegのメタタグをバラバラにして埋め込んだため、おかしな実装が大量に発生したので実装方法を変えたからである。そもそもTIFFのJPEGを展開する場合、TIFFのヘッダからJPEGのヘッダを生成すると言う面倒な作業が発生するだけで時間の無駄なのだ。そのためバラバラのタグに格納していたJpegのメタタグをJpegTablesタグだけみれば良い様に変更したのがNew Jpegらしい。BMPの用にJpegのファイルを丸ごとぶっこんで終わりにすれば良かった気がするのだが、それではTIFFの設計思想に反するらしくメタデータはTIFFのタグにしか格納されていない用だ。
なお新しいJPEGはV6.0 Technote2に書かれている。開いてみたらAdobe Photoshop拡張だった。ちなみにTechnote2ではDeflate圧縮(zlib)も追加されている。
そもそもの問題としてJpegの仕様とTIFFの仕様が非常に相性が悪くYCbCrで格納した場合、Y:Cb:Crが4:1:1か4:2:1などの情報もTIFFに格納しないといけないのである。これを嫌ったのかTIFFに格納されているJpegは概ねRGBかCMYKの様である。
Adobe Deflate
Adobeの資料にはzlibと書いてあった。zlibに投げ込むだけである。要するにTiff HeaderのPNG。
CCITT Fax
modified Huffman RLE/Group 3 fax/Group 4 faxの三種類実装されているがCCITT modified Huffman RLEのTiffがなかなか見つからない。ただしmodified Huffman RLEはヘッダ以外はほぼ Group 3 faxの一次元符号化と同じ。G3とG4もヘッダの実装が異なるだけで圧縮方式には違いが無いのでデコーダ一つで全てまかなえる。
TIFFタグ一覧
BASELINE
ベースラインは最低減必須のTIFFのタグである。ただし、Compressが実装されているとは限らないし、
過去の互換性だけのために載せてあるタグもあり全てが必須な訳ではない。画像ローダではFAX系圧縮をサポートしないケースも多いかも。BASELINEはLZWはサポートしなくても良いらしい。
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 254 | 00FE | NewSubfileType | 1 | LONG | サブイメージのデータの種類(新) |
| 255 | 00FF | SubfileType | 1 | SHORT | サブイメージのデータの種類(旧) |
| 256 | 0100 | ImageWidth | 1 | SHORT/LONG | 画像の幅のピクセル数 |
| 257 | 0101 | ImageLength | 1 | SHORT/LONG | 画像の長さのピクセル数 |
| 258 | 0102 | BitsPerSample | 1 | SHORT | Number of bits per component. |
| 259 | 0103 | Compression | 1 | SHORT | 圧縮方式 1=None,2=Modified Huffman run length 32773 = Packbits |
| 262 | 0106 | PhotometricInterpretation | 1 | SHORT | 色空間 0=２値画像(白=0) 1=２値画像(黒=0) 2=RGB 3=インデックスカラー 4=透過マスク |
| 263 | 0107 | Threshholding | 1 | SHORT | 白黒画像を２値画像にする場合の方法 |
| 264 | 0108 | CellWidth | 1 | SHORT | ディザリングの横情報 Threshholdingに依存 |
| 265 | 0109 | CellLength | 1 | SHORT | ディザリングの縦情報 Threshholdingに依存 |
| 266 | 010A | FillOrder | 1 | SHORT | bitの格納順 1=MSB 2=LSB (defualt=MSB) |
| 270 | 010E | ImageDescription | n | ASCII | 画像の解説情報 |
| 271 | 010F | Make | n | ASCII | スキャナのメーカ |
| 272 | 0110 | Model | n | ASCII | スキャナの機種名 |
| 273 | 0111 | StripOffsets | n | SHORT/LONG | Strip単位のオフセットの位置 |
| 274 | 0112 | Orientation | 1 | SHORT | データの格納順 座標(0,0)の位置 |
| 277 | 0115 | SamplesPerPixel | 1 | SHORT/LONG | 1Pixelの情報数(Glay/Index>=1,RGB>=3,YMCK>=4) |
| 278 | 0116 | RowsPerStrip | 1 | SHORT/LONG | 何行でデータを分割しているか |
| 279 | 0117 | StripByteCounts | n | SHORT/LONG | 分割単位のデータbyte数 |
| 280 | 0118 | MinSampleValue | 1 | SHORT | 画像データの最小値 |
| 281 | 0119 | MaxSampleValue | 1 | SHORT | 画像データの最大値 |
| 282 | 011A | XResolution | 1 | RATIONAL | 横方向の解像度 |
| 283 | 011B | YResolution | 1 | RATIONAL | 縦方向の解像度 |
| 284 | 011C | PlanarConfiguration | 1 | SHORT | 1=Chunky 2=Plannar(defualt=1) |
| 288 | 0120 | FreeOffsets | n | SHORT/LONG | 自由なデータのoffset(TIFFでは使用しない) |
| 289 | 0121 | FreeByteCounts | n | SHORT/LONG | 自由なデータのbyte数(TIFFでは使用しない) |
| 290 | 0122 | GrayResponseUnit | 1 | SHORT | GrayResponseCurveに含まれる情報の解像度 |
| 291 | 0123 | GrayResponseCurve | n | SHORT | n = 1<< BitsPerSample 光学濃度の情報 |
| 296 | 0128 | ResolutionUnit | 1 | SHORT | 解像度の単位(なし、インチ、cm) |
| 305 | 0131 | Software | n | ASCII | 画像を作成したソフトウェア名 |
| 306 | 0132 | DateTime | 20 | ASCII | 画像の作成日時 |
| 315 | 013B | Artist | n | ASCII | 製作者名 |
| 316 | 013C | HostComputer | n | ASCII | 制作したOS名 |
| 320 | 0140 | ColorMap | n | SHORT | カラーパレット n=3 *1<< BitsPerSample |
| 338 | 0152 | ExtraSamples | m | SHORT/LONG | 追加データの利用用途 m:RGBの場合 SamplesPerPixel -3 |
| 33432 | 8298 | Copyright | n | ASCII | 著作権情報 |
要注意なのは、SHORT or LONGの両方を取るタグで、Big Endienの場合、データ型が間違っていると値が異なってしまう。
- ExtraSamples = アルファ値などを格納する追加のサンプルの内容。一般的にグラフィックボードのフルカラーでは32bitを利用することが多く1byteを利用していない。この方式の利点は計算速度にある。24bitの場合、byteに分割して再格納する必要があるが、32bitの場合long型でそのまま処理出来る。例えば、このイメージをそのまま格納する場合、ExtraSampleを0にしないといけない。
Extention TIFF
Extentionは拡張されたTIFFのタグである。JPEGなどの圧縮をサポートするために必須のタグもここに含まれている。
汎用
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 269 | 010D | DocumentName | n | ASCII | ドキュメント名 |
| 285 | 011D | PageName | n | ASCII | ページ名 |
| 286 | 011E | XPosition | 1 | RATIONAL | Xの始点 |
| 287 | 011F | YPosition | 1 | RATIONAL | Yの始点 |
| 700 | 02BC | XMP | n | Undef | XML形式のXMPのデータ |
XPositionとYPositionはRATIONALで定義されるので印刷用に使われるタグだと思われる。XMPはAdobe’s Extensible Metadata Platformの略で、Adobe独自のメタデータがXML形式で格納されている。
Predicator
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 317 | 013D | Predictor | 1 | LONG | 2 のとき前のピクセルの差分を記録する |
PNGのフィルタに近い機能 Pack Bits/LZW/Deflateあたりが利用する。3はPhotoshop拡張、34892にDNG拡張がある。
Tiled Images
Tiled Imageは画像を矩形ブロックに分割して保存している場合に指定するタグ。ほぼJPEG用。
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 322 | 0142 | TileWidth | 1 | SHORT/LONG | タイルあたりの幅 |
| 323 | 0143 | TileLength | 1 | SHORT/LONG | タイルあたりの長さ |
| 324 | 0144 | TileOffsets | n | LONG | タイルごとのオフセット |
| 325 | 0145 | TileByteCounts | n | SHORT/LONG | タイルごとのバイト数 |
Tiled Imageの場合、rowStrips/rowOffsetsが設定されていないので読めないローダも多い。
G3 Fax Compression
- Compression = 3
- 通常 fillBit = 2 (LSBtoMSB)
G3 Fax Compressionを実装する時に使う拡張タグ。二値画像を格納するときに使われて居る。
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 292 | 0124 | T4Options | 1 | LONG | bit1 = 1 の時 3G2D bit2 = 1 のときUncompress bit3 = 1のときEOLのまえにFILL |
解説：G3 Fax圧縮を利用する時のオプション、Uncompressモードはサポートしているライブラリがほとんどない。3G 2Dに至っては、ほぼ別の圧縮に変わる(ほぼG4 Faxに近いので同時実装可能)
G4 Fax Compression
- Compression = 4
- 通常 fillBit = 2 (LSBtoMSB)
G4 Fax Compressionを実装する時に使う拡張タグ。G4 Fax CompressionはPDFに二値画像を格納するときにまだ使われて居るらしい（ただし、さらに圧縮率の高いアルゴリズムも存在する）
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 293 | 0125 | T6Options | 1 | LONG | Uncompress modeを許可する時にbit2 = 1にする |
解説： G4 Fax圧縮を利用する時のオプション。ほぼ無視していい。――というのもUncompressモードをサポートしているライブラリがほとんどないのと推奨されていないから。
TIFF-F
TIFF-FはFAX受信機がTIFFに受信内容を格納したときに使うメタデータ。RFC-2306で定義されている。
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 326 | 0146 | BadFaxLines | 1 | SHORT/LONG | AX受信機が検出した不良ライン数 |
| 327 | 0147 | CleanFaxData | 1 | SHORT | 0=不良ラインなし 1=不良ラインが存在したが回復された 2=不良ラインがある |
| 328 | 0148 | ConsecutiveBadFaxLines | 1 | SHORT/LONG | 連続した不良ライン数 |
TIFF-FX
TIFF-FXはTIFF-Fの拡張(TIFF Fax eXtended)で、Internet Faxとして定義されている(RFC-2301)。TIFF-FXではCompressionにグレイスケールにMH(≒G3 1D)/MR(≒G3 2D)/MMR(≒G4)/JBIGを、カラーにJPEG/JBIG/MRCをサポートしているらしい。
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 400 | 0190 | GlobalParametersIFD | 1 | LONG/IFD | TIFF-FX用のIFDのオフセット |
| 401 | 0191 | ProfileType | 1 | LONG | TIFF-FXのデータ仕様 0=未定義 1=G3 FAX |
| 402 | 0192 | FaxProfile | 1 | BYTE | TIFF-FXのプロファイル（後述） |
| 403 | 0193 | CodingMethods | 1 | LONG | TIFF-FXの符号化方法 |
| 404 | 0194 | VersionYear | 4 | BYTE | FaxProfileのバージョン 1997なら '1' '9' '9' '7' |
| 405 | 0195 | ModeNumber | 1 | BYTE | TIFF-FXのモード番号 混合ラスターコンテンツで使用する |
| 433 | 01B1 | Decode | 2 * SamplesPerPixel | SRATINAL | 色空間がITULABの時のマッピング値 |
| 434 | 01B2 | DefaultImageColor | SamplesPerPixel | SHORT | 画像データがない領域のデフォルトカラー |
| 559 | 022F | StripRowCounts | n | LONG | TIFF-FXでRowsPerStripの置き換えで利用 |
| 34732 | 87AC | ImageLayer | 2 | SHORT/LONG | 混合ラスターコンテンツで使う |
FaxProfile
- 最小限のロスレスモノクロ画像 プロファイルS
- 拡張ロスレスモノクロ画像 プロファイルF
- ロスレスJBIGモノクロ プロファイルJ
- 非可逆カラー＆グレースケール プロファイルC
- カラーおよびグレースケールのロスレス, プロファイルL
- 混合ラスターコンテンツ プロファイル M
Coding Methtod
- ビット0：指定なし圧縮。
- ビット1：一次元符号化、ITU-T Rec. T.4 (MH - Modified Huffman) Group 3 一次元符号化と同等。
- ビット2：二次元符号化、ITU-T Rec. T.4 (MR - Modified Read)に準拠。 Group 3 二次元符号化と同等。
- ビット3：二次元符号化、ITU-T Rec. T.6 (MMR - Modified MR)に準拠。 Group 4と同等。
- ビット4：ITU-T Rec. T.82 符号化、ITU-T Rec. T.85 (JBIG)を用いる。
- ビット5：ITU-T Rec. T.81 (ベースライン JPEG)を使用する。
- ビット6：ITU-T Rec. T.82 符号化、ITU-T Rec. T.43 (JBIGカラー)を使用する。
- ビット7～31：将来使用のため予約済み
Sub IFD
Sub IFDはサムネイルなどを格納する時に使われる。
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 330 | 014A | SubIFDs | 1 | LONG/IFD | 子のIFD オフセット |
Open Prepress Interface
OPIProxyは高解像度もしくは低解像度の画像が他にあることを示しているらしい。TIFF6.0ではなく、Adobe PageMaker 6.0のTiff仕様書で定義されている。
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 351 | 014A | OPIProxy | 1 | SHORT | 0=これ以上高解像度の画像はない 1=高解像度の画像がある |
| 32781 | 800D | ImageID | n | ASCII | 高解像度画像のフルパス、ファイル名（TIFFとは限らない） |
YCrCb Image
YCrCbとRGBをコンバートする時に使うタグ
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 529 | 0211 | YCbCrCoefficients | 3 | RATIONAL | RGB YUVの変換係数 defualt ITU-R BT.601 Lr=0.299,Lg=0.587,Lb=0.114) |
| 530 | 0212 | YCbCrSubSampling | 2 | SHORT | YCbCrのサンプリング計数 x軸,y軸 Defulat[2,2] YCbCr = 4:1:1と同じ |
| 531 | 0213 | YCbCrPositioning | 1 | SHORT | Cb,Crの範囲(-0.5,0.5)もしくは(0,1.0) |
RGB Image
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 532 | 0214 | ReferenceBlackWhite | 6 | RASIONAL | 白と黒のサンプリング値 例えばBT.601の場合 黒は(16,16,16)になる。 |
CMYK
PhotometricInterpretation=5 (CMYK)の時に利用するタグ。ほぼプリンタ関係のメタデータ。
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 332 | 014C | InkSet | 1 | SHORT | インクの種類。default=1 (CMYK) |
| 333 | 014D | InkNames | n | ASCII | 各インクの名前 |
| 334 | 014E | NumberOfInks | 1 | SHORT | インクの番号 |
| 336 | 0150 | DotRange | n | BYTE/SHORT | 各インクのドットレンジ(0%-100%) |
| 337 | 0151 | TargetPrinter | n | ASCII | 印刷環境の説明 |
印刷
YMCKとかぶる。
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 321 | 0141 | HalftoneHints | 2 | SHORT | ハーフトーン化のヒント |
ディザリングのヒント。ほぼプリント用
CIELab/XYZ
PhotometricInterpretation=8,1976 CIEL*a*b*色空間を利用する時に使うタグ。Lab方式で格納されているデータをRGBに変換するにはWhitePointが必須。
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 318 | 013E | WhitePoint | 2 | RATIONAL | 画像のWhite Point |
ITU-R BT.709の場合、Wx=0.3127,Wy=0.3290になるので、3127/10000,3290/10000を格納する様である。
CIEXYZ色空間を利用する時に使うタグ。CIELabを利用した時、XYZ色空間から更にRGB色空間に変換するために利用する。
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 319 | 013F | PrimaryChromaticities | 6 | Rasitional | XYZ色空間とRGB色空間を変換するためのメタデータ |
red[x], red[y], green[x], green[y], blue[x], blue[y]の順で格納されている。
ITU-R BT.709の場合、Rx=0.64,Ry0.33,Gx=0.30,Gy=0.60,Bx=0.15,By=0.06に定義されているため、640/1000,330/1000,300/1000,600/1000,150/1000,60/1000が格納されるはずである。
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 301 | 012D | TransferFunction | n | SHORT | 変換方式 |
| 342 | 0156 | TransferRange | 6 | SHORT | 変換の範囲 |
n = {1 or 3} * (1 << BitsPerSample)
色空間の変換テーブルを格納する。
JPEG(旧)
COMPRESSION=7のJPEGで使われるタグ。サポートされるJPEGはベースラインとロスレスのみ。
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 512 | 0200 | JPEGProc | 1 | SHORT | JPEGのSOFnのnに相当ただしサポートされるのは1(BASELINE)と14(LOSSLESS)のみ。ちなみにSOF14は算術符号ロスレスだが定義されているのはSOF7のハフマンロスレス。 |
| 513 | 0201 | JPEGInterchangeFormat | 1 | LONG | JFIFの中身らしい |
| 514 | 0202 | JPEGInterchangeFormatLength | 1 | LONG | JFIFの長さ |
| 515 | 0203 | JPEGRestartInterval | 1 | SHORT | DRIマーカと同じ |
| 517 | 0205 | JPEGLosslessPredictors | SamplesPerPixel | SHORT | Predicatorの値。ロスレスで使う。SOS内で定義 |
| 518 | 0206 | JPEGPointTransforms | 1 | SHORT | ロスレスで使う。SOS内で定義 |
| 519 | 0207 | JPEGQTables | n | LONG | 量子化テーブルのオフセット DQTに相当 |
| 520 | 0208 | JPEGDCTables | n | LONG | DC Tableのオフセット DHTに相当 |
| 521 | 0209 | JPEGACTables | n | LONG | AC Tableのオフセット DHTに相当 |
ここからJPEGをデコードする場合、ヘッダを作成する必要があって非常に面倒かつ異なる仕様が多い。
JPEG
あまりにややこしいので簡便化したCOMPRESSION=8のJPEG。このモードで使うタグは1つ
| tag | hex | name | # | type | 概要 |
|---|---|---|---|---|---|
| 347 | 015B | JPEGTables | 1 | LONG | 量子化、ハフマンテーブルをまとめたもの(ヘッダ)のオフセット |
ただし、ヘッダも本体もSOI EOIで囲まれているので、余計なSOI、EOIを除去する必要がある。それさえすればそのままくっつければ大体デコード可能。ただし、RowsPerStripやTileWidth/Heightで画像が分割されている場合がある。その場合はヘッダを使い回す。
Other pixel format
339|0153|SampleFormat|n|SHORT|サンプルごとのデータ形式
340|0154|SMinSampleValue|n|*1|サンプルの最小値
341|0155|SMaxSampleValue|n|*1|サンプルの最大値
n = SamplesPerPixel
*1 SampleFormatで指定している型と対応する。確定するにはBitsPerSampleの情報が必要
Sample Format は、
- 1 = 符号無し整数
- 2 = 符号付き整数
- 3 = IEEE浮動小数点
- 4 = 定義無し
――になるため、理論上はSampleFomatを利用することで小数点で画像データを扱う事が可能である。ただしデコード出来るかは別の話。このあたりはLab(0-100,-128-128,,-128-128)やXYZ(0.0-1.0,0.0-1.0,0.0-1.0)色空間でデータを格納する時に使う気がする。
Discussion