TGA

いまさら気付いたんですけど、Targaって、解像度情報を持てないんですね。TGAって、受け取るばかりで、出力するのはかなり稀だったので、今の今まで、解像度がundefinedとは気づきませんでした。

 

紙ありきの現場でもう20年以上使われていたファイルフォーマットだったので、てっきり、紙スキャンの解像度を持っているのだとばかり、思い込んでいました。

 

私がトラブったのは、「デジタル原画」の体裁を整えて出力する際でした。規定の解像度情報が必要だったのです。‥‥う〜〜〜む‥‥、変な気をまわして、Targaなんて使うんじゃなかったな‥‥。裏目にでました。

 

 

私がローカルで取り回す際は、PSDかTIFFかJPEGです。たまにPNGも。‥‥なので、解像度でトラブったことはなかったのです。

 

解像度情報を使う場合は適宜処理して使えば良いし、無視して使う場合(ピクセル寸法の情報だけで取り扱う場合)は無視すれば良い‥‥という感じでした。

 

しかし、Targaは、バッチやスクリプトで解像度情報を書き換えて上書き保存したつもりでも、全く何にもなってなかった‥‥です。うーん、我ながら、マヌケ。

 

 

例えば‥‥

 

 

上図のようなAfter Effectsから出力した大判サイズの原画を、Photoshopで72dpiから150dpiに変更すると‥‥

 

 

‥‥のように変更されて、解像度情報だけを変更できます。

 

いわゆる、何ドットが何インチかを表す情報だけを書き換えて、ピクセル寸法は変更しない画像解像度の変更です。

 

Photoshopのウィンドウの情報を見ると‥‥

 

 

‥‥となっており、あたかも解像度が変更できたかのように思えます。「ファイルを変更しました」を表す「米印」も表示されます。

 

 

上書き保存すれば、解像度の変更を反映したファイルを保存できた‥‥と思いがちです。

 

しかし、これはあくまでPhotoshop上のドキュメントのインスタンス内で一時的に保持されているプロパティであって、上書き保存したTGAファイルを他のソフトウェアや、Photoshopで再度開いて、解像度を確認すると‥‥

 

 

 

‥‥のように、解像度情報は記録されておりません。Macの場合は、昔から72dpiがデフォルトなので、「72dpi」と表示されているだけです。いっそのこと、解像度情報がないのなら「Undefined」とか「情報なし」と表示してくれれば良いのに‥‥。

 

 

‥‥で、この記事を書いている途中でフォーマットの仕様書をネットで探して、Targaのデータのディスクリプションを調べてみたら、たしかにレゾリューションのプロパティは無いですね。

 

ファイルのデータは、いきなり画像のデータ本体が始まるのではなく、先頭に「どんなファイルの内容か」を記すヘッダ部分があります。HTMLやメールでも、最初にどんな文字コードを使っているかなどのヘッダがあるように、TIFFやJPEGなどのファイルもデータ先頭のエリアにファイルの様々な情報が付記されています。

 

例えば、JPEGならば、デンシティユニット(Density units、カタカナ訳でスマんす)で解像度の基準を記述し、XとYのデンシティ(Xdensity, Ydensity)を記述する項目があり、それが解像度の内容を示しています。Xdensity, Ydensityで、ピクセルレシオも表現できますよネ。

 

Targaは以下のような感じ。データのどの位置にどんな情報が記述されているかを表しています。

 

- - - - -

OFFSET              Count TYPE   Description
0000h                   1 byte   Length of image identification field (below)
0001h                   1 byte   Color map type :
								 0 - no color map
								 1 - 256 entry palette
0002h                   1 byte   Image type :
								  0 - no image data included
								  1 - Uncompressed, color-mapped image
								  2 - Uncompressed, RGB image
								  3 - Uncompressed, black and white image
								  9 - RLE encoded color-mapped image
								 10 - RLE encoded RGB image
								 11 - Compressed, black and white image
								 32 - Compressed color-mapped data, using
									  Huffman, Delta, and runlength encoding.
								 33 - Compressed color-mapped data, using
									  Huffman, Delta, and RLE.  4-pass quadtree-
									  type process.
0003h                   1 word   Index of first color map entry
0005h                   1 word   Count of color map entries
0007h                   1 byte   Number of bits per color map entry
0008h                   1 word   X coordinate of the lower left corner of
								 the image.
000Ah                   1 word   Y coordinate of the lower left corner of
								 the image.
000Ch                   1 word   Width of the image in pixels
000Eh                   1 word   Height of the image in pixels
0010h                   1 byte   Bytes per pixel
0011h                   1 byte   Flags (bitmapped):
								 0-3 : Number of attribute bits
								   4 : reserved
								   5 : Screen origin in upper left corner
								 6-7 : Data storage interleave
									   00 - no interleave
									   01 - even/odd interleave
									   10 - four way interleave
									   11 - reserved
								 The byte should be set to 0. Don't know why.
0012h                   ? char   Image identification string, usually not there,
								 when the length (see up) is 0.
????h                   ? byte   Color map data
								 Depending on the number of bits per color map
								 entry, the entries here have a different size.
								 4 bytes : 1 byte for blue
										   1 byte for green
										   1 byte for red
										   1 byte for attribute
								 3 bytes : 1 byte for blue
										   1 byte for green
										   1 byte for red
								 2 bytes : Bitmapped as a word in Intel byte
										   order as follows :
										   ARRRRRGG GGGBBBBB
????h                   ? byte   Image data
								 For images of type 9 (using RLE), the image
								 data is divided into packets, the first byte
								 being the indicator for repetition or copy.
								 If bit 7 of the first byte is set, then repeat
								 (first byte and 07Fh+1) times the next byte,
								 otherwise copy first byte+1 pixels from data
								 stream. RLE packets may cross scan lines !

 

- - - - -

 

‥‥たしかに、無いすネ。解像度関連。

 

あるのは、「Width, Height of the image in pixels」くらいで、単に縦横のピクセル寸法の記述だけです。インチやセンチあたり何ピクセルかを実質的に表す項目は無いですネ。

 

無念。

 

 

 

あー、ほんとに、変な気を回さず、TIFFかPSDにしときゃよかった。

 

でもまあ、こういう細かい部分をちゃんと確認せず、「多分、そうだろう」で使った私も悪い。

 

 

 

ちなみに、Photoshopのバッチで、Targaを処理すると、処理後の「保存して閉じる」際にRLE圧縮が外れるようで、それもまた困りもの。バッチ前まで1MB未満だったファイルが、いきなり数メガバイトまで肥大化します。

 

TIFFの場合はLZW圧縮のファイルはちゃんとLZW圧縮をしてバッチ処理を終了してくれます。

 

 

Targaって、PICTやSGIなんかと同じくらい古いファイルフォーマットで、PICTがもうとっくの昔に死滅したのに、TGAはアニメ業界標準のファイルなので、今でもバリバリ現役ですよネ。

 

古いファイルフォーマットは、実は運用実績が高くて、時代に即している限りは、何の問題もないのです。

 

しかしまあ、「紙」という現実世界の実寸をもつ媒体が存在するわりに、アニメのフローって解像度情報のないTargaを長く使い続けてきたんですね。スキャンした後は紙に戻ることはなかったから、問題にならなかったんでしょうかネ。‥‥「デジタル原画」の「紙戻し」するまで、まさか解像度のプロパティを持たないファイルフォーマットだったとは、気づきませんでした。

 

まあ、今後はTIFFかPSD、プレビュー用に軽くしたい時はJPEGにしときます。



calendar

S M T W T F S
    123
45678910
11121314151617
18192021222324
252627282930 
<< June 2017 >>

selected entries

categories

archives

links

profile

search this site.

others

mobile

qrcode

powered

無料ブログ作成サービス JUGEM