Zenn
👨‍⚖️

Tiffの話

2022/05/28に公開
#
tiff
tech

TIFFとは

画像フォーマットの一種である。歴史は古くインターネット普及以前の代物である。基本的にはオフラインで使うために設計されたフォーマットでオンラインには向いていない。これはTIFFの仕様上ファイルシークが大量に発生するため、ストリーミングには向いていないのである。この部分はJPEGとは対象的である。JPEGはファイルシークが発生しないのとある程度のエラーリカバリーが可能なのでストリーミング向きである。

TIFFフォーマットの仕様

TIFFの制限

TIFFの制限は、offset情報が4byte固定になっている点から来ている。つまり4GBを越えるデータを扱えない。それを扱える様に拡張したのがBig TIFFと呼ばれるものであるが、ここでは扱わない。4GBを越える画像がほぼ無いから。超高解像度の印刷用データを無圧縮で扱う時に出てきそうではある。

ヘッダの仕様

TIFF

+0000 +----------+
      | II or MM |
+0002 +----------+
      |    42    |
+0004 +----------+
      |IFD offset|---> IFD
      |          |
      |          |
+0008 +----------+
  1. HEADER ヘッダは、'II'もしくは'MM'で始まる。IIはリトルエンディアン、MMはビッグエンディアンでデータが格納されていることをしめしている。
  2. ヘッダに続く2byteはバージョン情報が入っている。バージョン情報と言ってもほぼ固定で42(0x2A)である。ところがTIFFはバイ・エンディアンを採用していることから、最初の2byteがIIで始まる場合は[0x2A,0x00]であり、MMで始まる場合は[0x00,0x2A]になる。
  3. 続く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のタグの情報

ほぼ網羅しているサイトは以下だけではないだろうか？

https://www.awaresystems.be/imaging/tiff.html

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

  1. 最小限のロスレスモノクロ画像 プロファイルS
  2. 拡張ロスレスモノクロ画像 プロファイルF
  3. ロスレスJBIGモノクロ プロファイルJ
  4. 非可逆カラー＆グレースケール プロファイルC
  5. カラーおよびグレースケールのロスレス, プロファイルL
  6. 混合ラスターコンテンツ プロファイル 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

https://www.itu.int/rec/R-REC-BT.709-6-201506-I/en

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