タイムシートの指示

私は作画もやってコンポジットもやるので、自ずとタイムシートの書き方には慎重になります。

 

タイムシートの指示上で「いき違い」がないように‥‥と、こと細かくタイムシートに指示を入れるのは、実は「逆にNG」なことも多いものです。

 

妙に気合を入れて、タイムシートに必要以上の細かさで記入するのは、かえって逆効果です。

 

「いき違い」を軽減したいのなら、むしろ「できるだけ質素で単純明快」がよろしいです。

 

 

撮影スタッフ・コンポジターの技量を「標準レベル」と想定して、いわば「信頼して」必要最小限で記入するのが原則です。

 

タイムシートを必要以上に細かく記入しても、決して撮影上がりの品質は上がりません。タイムシートで挽回できる性質ではないことを認識しておくべき‥‥ですネ。

 

私は撮影監督もやってましたから、タイムシートの記述を「どのようなAfter Effectsの実際の操作にするか」をジャッジする役割でもあったので、いくつかの代表的な具体例を挙げることができます。

 

 

厳選して列記しますと、まず‥‥

 

After EffectsやPhotoshopの実際のフィルタ名で指示を書くのは、実質、意味が無い

 

‥‥です。「ガウスブラー」とか「カメラレンズブラー」とか「メッシュワープ」とか書いても、無意味です。なぜかというと、実際に用いるフィルタはその時々で最適なフィルタが選ばれるので、例えば「ガウスブラー」と指定してあっても、実際は「Fast Blur」で処理することも多いです。

 

じゃあ、どう書けば良いかというと、「ボケ」、「ブラー」(=ぼかしの意)とか一般的な用語で書けば良いだけです。あくまで「大づかみ」な表現でOKなのです。ピントを外したボケにしたいのなら「ピンボケ」で十分です。

 

ガッチリした線で描いてほしいから‥‥と言って、絵コンテやレイアウトバックに「三菱鉛筆UNIの4Bで作画」とか記入してあったら、「そんなのは、作業する側が、作業する環境で最適なものを選ぶから、いちいち鉛筆の銘柄まで指定するな」と思うでしょ? ‥‥それと同じです。

 

私はボックスブラーを状況に応じて適宜使うことがありますが、これはカメラレンズブラーの代用品で、四枚絞りバネに似たニュアンスが出せるからです。滑らかにぼかしたいのなら、ガウスブラーなんて使わなくても滑らかブラー(Fast Blur)で十分なことが多いです。「ガウスブラー」と指示を記入した原画マンか演出さんに「なぜガウスブラー? 滑らかブラーではダメな理由を教えて」と聞いてまともな返事が返ってくるとは思えないですしネ。

 

フィルタの指示は「あくまで汎用的な表記」を心がけて、コンポジット作業時に実際に何を使ってオーダーを実現するかは、撮影スタッフ、コンポジターに任せれば良いのです。

 

結果、仮に映像の仕上がりが悪いとしても、「ガウスブラー」や「ベジェワープ」なんてタイムシートに書いたところでコンポジットの質なんて上がりません。細か過ぎるタイムシートの記入など、結局は「悪あがき」なのです。もし撮影・コンポジットのクオリティに不足を感じるのなら、きっぱりと「別のスタッフ」に撒き直すことを検討すればよいです。

 

 

セル(レイヤー)の透明度は「気持ち」

 

タイムシートを書く方も、受け取って読む方も、「素材の透明度の数値はキモチの表現」と心得ましょう。「Cセル50%」と書いてあったら、「半分くらい透ける雰囲気が欲しい」というように解釈します。

 

間違っても、After Effectsのレイヤーの不透明度をタイムシート通りに50%にするようなことを、指定してもいけませんし、実際に操作するのもマズいです。

 

「なぜ?」と思うかも知れませんが、明確な理屈があります。

 

現在はまず、撮出しがおこなわれていませんから、背景とセルを合わせてみて、イメージする透明度にするためには、何%が正解か?‥‥がほとんど先読みできません。ましてや、原画マンに至っては、線画の段階しか関与していないのですから、「まともなパーセント指定ができるはずがない」のです。

 

色彩の知識になりますが、真っ黒の背景に、真っ白なセルを乗せた場合、不透明度が10%でもかなり明るく見えます。逆に、真っ黒の背景に、暗いセルを乗せると、50%でもわずかに見える程度です。

 

つまり、背景の色と、セルの色の、それぞれの素材の明るさ暗さや色彩によって、レイヤーの不透明度など「いくらでもルックが変わってくる」のです。

 

だったら、「20%くらい〜うすく見えるくらいに」とか、「ほとんど後ろが透けない程度で〜90%くらい?」と書いておいた方が、コンポジターにイメージが伝わります。

 

妙に具体的な数値を書くより、「%くらい」とイメージを伝えるだけにとどめ、実際のコンポジットの質はコンポジターの解釈の能力に預けて、映像の仕上がりの「実」をとるべきでしょう。

 

 

カメラワークのイーズは許容を広く

 

カメラワークの加速減速など「フェアリング」とも呼ばれる操作を、自分のイメージ通りに、今のタイムシート標準の記述法で書くことは困難です。そもそもイーズのカーブの記述法が制定されていません。

 

なので、カメラワークは「ストライクゾーン」を広めにとっておいて、大まかなA-B-Cなどのフレーム指定と「加速減速」の添え書きで「よし」とするか、目盛りで指定するかの2択で、「手打ち」にしておきます。

 

A-Bのフレーム指定でも、イーズ次第でいくらでもカメラワークの雰囲気を操作できますが、それを現在のタイムシートに指定することは無理なので、作画しか関われないのであればなおさら、大まかな指定によるイーズでカットが成立するように設計しておくのが肝要です。

 

‥‥実は、このあたり、結構「根深い」問題を孕んでいるので、別の機会に採り上げたいと思います。

 

 

まだ色々とありますが、ひとまずこの辺で。

 

 

絵コンテで原画作業のこと細かい指示ができないのと同様、撮影に対してタイムシートで指定する際も、過剰な記入は単なる情報のオーバーフローに過ぎません。

 

「必要なことだけを書いておけば」良いのです。

 

「でもそれだと、思った通りに上がってこないんだよ」とやきもきしても、それはタイムシートの記述ではなく、当該のスタッフの技量です。絵コンテにどんなに丁寧にト書きを書いても、絵コンテを素晴らしく綺麗に清書しても、実際は担当する原画マンの技量によるじゃないですか。それと同じです。

 

あまりにも色々なことが書き込んであるタイムシートは、それだけで「ああ、つまりは頭の中で映像の設計の折り合いがついてないので、思いつくままに書いてるんだな」と悟られてしまうのです。タイムシートにやたらめったら書き込めば、映像がゴージャスになると思うのは、残念ながら「NO」です。

 

まあ、ごくごく稀なカットで、どうしてもシートが複雑で書き込みも多くなることはあります。しかし、一般的には、タイムシートはシンプルで明快なのが一番です。

 

 

BOOKがどのセルの上にくるか‥‥とか、T光が含まれるのは何セルなのか‥‥とか、そういう基本的なことを書かずして、「ガウスブラー」とか書くのって、それだけで担当原画マンの経験の浅さ(もしくは手抜き)をタイムシートから読み取られてしまうのです。

 

必要なことは最低限踏まえて全部書いてある。撮影技術上の伸びしろや采配は撮影担当者に任せてくれている。‥‥私の考えるタイムシートの「スタンダードとしての理想」はそんな感じです。

 

 

 

要は、タイムシートに頼って運用している以上は、タイムシートの限界の中で工夫して作るべき‥‥なのでしょうネ。

 

アニメーターが、どうしても複雑な撮影・コンポジットを経て、完成させたい映像イメージがあるというのなら‥‥‥‥、それはもう、自分でコンポジットまで担当するしかないのです。

 

なぜかって、タイムシートに「そこまでの許容はない」からです。

 

タイムシートに書けないことを映像で表現したいのなら、本人がコンポジットするしかありません。

 

もしその「現状の限界」に「限界を感じる」のなら、タイムシートを捨てて、タイムシートに代わる新しいシステムを作るのが肝要です。私は半々で、タイムシートをベースとした仕事と、タイムシートの存在しない仕事をやっていますから、決して無理なことではないと実感します。

 

 

 

ただ、タイムシートは、長年の運用に耐えてきただけあり、さすがによく出来ております。コストの増大を抑制する効果すら盛り込まれていますしネ。

 

タイムシートをどのようにして使うか。

 

原画を「デジタル」で描くようになっても、タイムシートはまだまだ当分は、カットごとの「設計のキモ」になりそうですネ。

 

 


新型はすぐ使う

買い時が微妙なのは、新型が出る周期が解っていて、それが3月なのか6月なのか10月なのか‥‥という時期です。iMacの新型の発売は、3月ではなく、もう少し先‥‥な感じの空気が漂い始めましたが、さて、如何に。

 

機材の絶好の買い時は、新型が発売されて直ぐ‥‥か、「新型の2型」にマイナーチェンジして直ぐ‥‥です。新型は、刷新された性能や機能が、そのまま直に仕事に活かせますし、新型の2型(新型が出て次のマイナーチェンジモデル)は、製品「1型」の不具合がフィードバックされていると同時にコストの簡略化に走る前なので「質が良い」ことが多々あります。

 

 

iMac 5Kも、iPad Pro 12.9インチも、発表されて発売開始に直ぐに買いましたが、早く買ったぶんだけ、十分「もと」はとりました。化粧直しした程度の新型ならば、慌てて買う必要はないですが、「これなら仕事に使える」と解っている新機軸を盛り込んだ新型は、「とっとと買ってしまって、とっととソレで金を稼ぐ」のがよろしいのです。

 

iPadとApple Pencilは、買って半年くらいは手探り状態でしたが、今ではもう「うんざり」するほどのiPad作画の日々で、来る日も来る日も、iPadとApple Pencilで絵を描いております。

 

「iPadでほんとに仕事ができるかなぁ」なんて迷い続けて未だに買ってなければ、右も左も前も後ろもiPadでこなす仕事だらけの現在の状況なんて、決してありえなかったです。iOSは縛りが強い‥‥とは言いますが、「仕事となれば」いくらでも抜け道や迂回路は見つかるものです。

 

ソフトがどうだ、ハードがどうだ、‥‥なんて石橋を叩いて叩いて叩きこわすほどに慎重に構えてても、年月はただ過ぎるだけですもんネ。
 

 

 

 


雑感

作業の手間を効率化するために、急場でAfter Effectsのスクリプトを作りました。特定のエフェクトのプロパティのキーフレーム群をイーズインアウトに変更しエクスプレッションでループ化する‥‥というものです。山ほどプロパティとキーフレームを設定しなければならない場合、手作業でいちいちキーフレームを操作していると、時間も手間もじくじくと消費します。After Effectsのスクリプトフォルダに自作のスクリプトを入れておいて、簡単に実行できるようにすると、積もり積もって結構な作業力の節約になります。

 

山ほどのキーフレームの操作‥‥なんて、今までのアニメの撮影では珍しいですが、コンピュータで描いた絵を動かすとなると、100〜200のプロパティそれぞれに、5、10、20のキーフレームがある状態では、あっという間に500〜2000個のキーフレーム数になります。膨大なキーフレームの操作に対し、手作業の作業形態を放置したままだと、能率が一定以上で頭打ちになります。「できるのに諦める」「可能を不可能にする」状況に甘んじてしまうのです。

 

スクリプト1つで、ぐんと能率が上がることも珍しくはありません。

 

 

キーフレームの操作に直接関わるスクリプトを作ってて思ったのは、旧来のタイムシートで標準化されている指定や記述は、かなりの部分をスクリプトで自動化できる‥‥ということです。‥‥あれ? これって、ブログで昔にも似たようなことを書いたような気がするな。

 

パーティクルやテクスチャハリコミは、そもそもタイムシートでは正式にはサポートしていない標準から外れた、最近のエスカレートした撮影要求(=そもそも撮影の仕事ではなく、作画管轄の技術です)なので、自動化は無理です。しかし、通常のタイムシート標準仕様であれば、「タイムシートを真の意味でデジタルデータ化できれば」かなりの自動化は可能です。

 

セルのタイミング(コマ打ち)、BGやBOOKやセルの重ね順、PANやZOOMなどのカメラワーク、カメラワークの加速減速(イーズ)、透過光の処理、ディフュージョンなどの定型の光学フィルタ(のシミュレーション)は、タイムシートの記述法をデジタルデータで規約して定義できれば、タイムシートを記述する行為が撮出しとタイミング撮を兼ねることも可能になります。

 

まあ、撮出しは「現物を見て、フレーミングを再考する」工程でもあるので、現物を見ないままで完全な「撮出し」なんてできませんが、「レイアウト通り・シート通りに素材が上がって入れば」という仮定の上で、セルワークとカメラワークをタイムシートでかなりガッチリとコントロールすることは可能でしょう。あくまで、真の意味で、タイムシートがデジタルデータ化できたなら‥‥です。

 

しかし、この15年くらいで、すっかりと撮出しは「なかったもの」になり、言うなれば「後撮出し」、つまり、「ラッシュチェックで初めて素材が組み合わさったのを見て、リテーク出しというかたちで撮出しをする」手順に業界全体が染まった感があります。ここ10年くらいの間に業界入りした人の多くは、撮出しの意味すら解らない人も多いでしょうし、実質「ムダ撮」で本撮を撮り切って、リテーク出しからが本番だ‥‥なんていう現場も多いでしょうしネ。

 

‥‥なので、作業を完了することに必死すぎて、先回りしてルーチンワークの自動化だの管理の自動記録だのなんて、タイムシートのデータ化、ひいては作業の自動化がどれほどの人の心を動かすのかは、何とも先が読めません。

 

エフェクトの必要ない、ほんわかした作風のアニメなら、タイムシートのデジタルデータ運用規約が出来上がってしまえば、一人で撮影することも可能でしょう。人間が関与するのは、ルーチンワークでは対応できないカットのみに絞って、通常の芝居のシーンなどは自動化でかなりのところまで完了できます。‥‥「デジタルタイムシート」のソリューションが「記入ソフト」のレベルを凌駕し、素材の管理や撮影コントロールの領域まで発達すれば‥‥ですけどネ。

 

いや〜、でも、それは現実的には無理っぽいですね、今までの現場の動向から考えても。「誰が開発するんだ?」のところでスタート直後で躓きますもんネ。

 

各方面の「識者」「経験豊富な技術者」を招集したところで、無様なほどにコケていくプロジェクトは、それはもう、いくらでも‥‥ありましたよネ。

 

 

 

「デジタル作画」を推進しても、作業に関わる様々な事柄の制定とデジタルデータ上の規約が揃っていなければ、ネットワークとデータに囲まれていても、「デジタルの孤島」で活動する作業グループになってしまいます。

 

自分たちの新しい「デジタルベース」の現場における、様々なインフラや規格や体系は、自分たちで形作っていくしか、実質的な道は開けません。規模の拡大を目指すのなら、現場作りに相応の手応えを得た後で、徐々に周囲を取り込んでいく‥‥というのが、現実的な道筋でしょう。

 

私自身、残りの半生を旧来技術のお世話に消費するよりも、まだまだ幼い新技術の育成に力を注ぎたいので、旧来制作システムは適当に付き合いつつも、本命は新しい制作システムと技術体系です。

 

タイムシートをはじめとした、様々な要素の「新定義」は、新しい作画技術やコンポジット技術と同時に推し進めていくべき、重要な課題です。

 

 


果てしない水汲み

アニメを未来に渡って作り続けるには、どうしたら良いんだろう。

 

若手アニメーター、月給10万円未満が50%超 「死に体で支えている」苛酷な生活実態とは(調査結果)」を読むと、今の作り方の限界を感じます。おそらく、誰もが。

 

こうした話題を前にした時、多くの人は制作費のことを持ち出しますが、私が考えるに、今の作り方を維持しつつ、原画・動画だけでアニメーターが歳相応に正常に生活できるようになるためには、現在の作業単価の4〜5倍は必要で、さらに単一単価制度は廃止しないと、問題は大きく改善できないでしょう。

 

でも、それをできる会社、ぶっちゃけ、ないですよネ。

 

「大変な作業を請け負えば、相応の報酬が得られる」というあたりまえ過ぎることを、まずは現場で成立させないと、お金はいつのまにかどこかへと消えていくだけです。

 

作画だけじゃなくて、撮影でも同じで、派手で大変なドンパチのカットが盛りだくさんなシーンを、他の日常芝居のシーンと同じ「秒単価」でぬけぬけと伝票を切ってきた時は‥‥‥‥‥

 

 

でもね、もういいんだよね、そういうのは。

 

過去の幻影です。

 

 

現場の技術自体、現場の制作構造自体、現場のお金の感覚自体、現代とあまりにもズレすぎているのです。

 

どうやったら、よくなる? ‥‥なんて、「今の住処」に居続けたまま、話し合うだけ無駄。

 

どうせすぐに、内輪で「あなたのほうが1畳多いのはズルい。」「あなたのほうが日当たりが良くて不公平だ」なんていう骨肉の争いが始まるだけだもん。彩色単価からお金をカットして動画単価に補填すべきだ‥‥なんていう人がいるくらいだからね。

 

そんな人々が集う狭い住処で、現在の基準だと建蔽率でひっかかるから、柱だけは残して、全面改築だ!‥‥なんていう取り組みが、果たしてどれだけ有効か。

 

 

数キロ離れた川に、バケツを両手にもたせて、水を汲みにいかせといて、「大した量を運べない奴だな」なんて、あまりにも酷い話です。でも、アニメ業界の制作技術って、延々と現在でも、そういうことをやってるんですよ。

 

バケツによる水汲みは大変だから、水の単価を上げよう!‥‥って、アホすぎると思いません?

 

なぜ水路を作って、電気でポンプを動かそうとしないんだろう? 電気は電球を灯すだけにしか使えないと思っているのだろうか?

 

バケツの水汲みをしていた人は、水を扱う様々な新技術の技術者として再出発すれば良いのです。

 

でもね‥‥、「水路を作るのって、大変じゃん」‥‥というのが、業界の総意なんだよね。

 

 

まあ、だから、私はもう、既存の現場にどうこうと提案するのはやめたのです。今までの現場の流儀が気に入っている人々に、余計なお節介なんて、すべきではないと達観しました。

 

だってさ‥‥。今の場所に、新しい住処を作るのって、実質的に無理じゃん? 今いる人々を一旦でもどかさないと、新しい建物なんて建てられないですもんネ。

 

 

 

必要なのは、古い考え方に固執する人がいない、今の現場とは違う場所に、新たな設計に基づく、新たな住処を建築することです。少なくとも、私はそう思います。

 


鉄輪の赴く先

iPhoneが登場した時、日本において、結構な地位の偉いさんやアナリストの方が、「iPhoneは日本では流行らない」と言ってしまった理由は、既に各所で分析されていますが、要は「何かの延長線上でしか見れなかった」から‥‥ですよネ。携帯電話の延長線上、パソコンの延長線上、そして人々の今までの使い方の延長線上‥‥と、何かしらの延長線上にiPhoneを当てはめようとしたのは、当人の思考の性質そのものだったのでしょうネ。

 

iPhoneが発売からしばらくのあいだ、売り上げが伸び悩んだ頃に、

 

「iPhoneは、一時的にはブームになるだろうと思っていた。だが、端末が一般の人に魅力的かは疑問。こういう流れは想定していた」

 

‥‥だそうな。

 

でもまあ、その次の流れは想定できなかったんですネ。今では驚くほど、会う人会う人がiPhoneを持っているような普及ぶりです。

 

言うなれば、今までの流れの中だけで、新しい何かを捉えることの難しさを、iPhoneの日本での大流行の一件は物語っているのでしょう。

 

 

なんか、同じ思考形態で、4Kをはじめとした未来の高品質映像フォーマットについて語っている人、特にアニメ業界で多くないでしょうかネ?

 

 

4Kを「解像度が上がった2K」と考える人は結構目や耳にします。驚くのは、すでに「デジタル作画」を取り扱っている人間でも、4Kを「解像度が上がっただけ」としか認識していない人がいることです。

 

延長線上から一歩外れて、「解像度が上がるということは、何を呼び寄せるのか」をちょっと考えてみただけでも、「流れにどのような変化が生じる」のかがイメージできる‥‥と思うんですよ。実際に「何ピクセルのキャンバスに、何ピクセルのペン先で」絵を描いている人ならば、特に‥‥です。

 

 

iPhoneの時と、同じ勘違いが、また「再演」されるのかな。

 

 

作画の延長線上で未来の映像フォーマットを理解しようとする。現在の身の回りの機材の知識だけで、未来の現場を思い描く。人々のアニメに対する印象の延長線上で未来のアニメを考える。つまり、既存の何かの「直線的な」延長線上でしか思考できない状態です。

 

何かと何かが衝突して生ずる新しいベクトルとエネルギー‥‥とか、多かれ少なかれ、考えてみたりしませんかネ?

 

直線的な延長線上の視界しか持てない人にとっては、例えば、ハチミツを水に溶かして瓶詰めして放っておいたら、やがてミードになった‥‥なんて魔術としか思えないのかも知れませんネ。

 

 

日頃、iPhoneを使っているのなら、なぜ、「日本におけるiPhoneの顛末」を、思考のイメージとして活かせないのかな? ‥‥特に、自分らの仕事の未来イメージにおいて。

 

‥‥私は、私なりのレベルゆえに考えが及びきらないまでも、あーでもない、こーでもないと、色々と角度を変えて考えて、自分らの技術開発の基軸に活かそうと心がけますけどネ。iPhoneが日本で「売れちゃった」のって、「思索の好材料」だと思うのですよ。

 

 

 

単一直線上に、物事が大人しく在り続けたことって、逆に「稀」ですよネ。

 

物事は、したたかに、動的に、クロスオーバーさせつつ、取り扱っていきたいもの‥‥ですネ。

 

 

私は今、昔ながらの作画スタイルの仕事をiPadで、新しい技術ベースの仕事もiPadで、別方面の新しい技術ベースの仕事はMacで、畑の違う映像の仕事もMacで‥‥と、「重い鉄輪」がゆっくりと動き出した感慨をしみじみと実感しています。「動き出し」はいつも、傍目からはまるで静止しているかのように、ゆっくりと動き出します。

 

その鉄輪が歩む軌道は、いくつも交差しながら、見知らぬ新しい土地へとつながっています。

 

 


マスター

SD時代、あんなに苦労して作ったテレビシリーズが、720x486(D1)の寸法でしかオリジナル映像が残っていないのは、今にして思えば、「もったいない」です。しかもプルダウンした画像で、簡単にはプログレッシブな画像に戻せないというオマケ付きで。

*WSSWWの各カットの映像を、編集で切って繋いでいるので、簡単には戻せないのです。

 

フィルムなら、スキャンし直して‥‥という手段もありましょう。16mmは結構キツいとは思いますけど、それでもグレインをスキャンする技術進化に打って出ることはできましょう。しかしビットマップ画像はどんなに叩いてもひっくり返しても1ピクセルは1ピクセルでしかありません。Googleの超解像技術でも使う?

 

でも、そもそも、以前のD1サイズの「デジタルアニメ」は、720pxが解像度の全てではありませんでした。

 

制作現場ごとで違いますが、D1サイズの映像を作るのに、作業サイズまでD1サイズであることは稀でした。最低でも960pxで作業しており、私が関与していた作品は4:3の昔の動画用紙の150dpiだったので、千数百ピクセルでした。細かい数値は忘れましたが、アップコン次第で2Kにも通用するピクセル寸法だったのは確かです。

 

1Kオーバーのオリジナルサイズで、24pの映像ファイルにしておけば、様々に活用できたのにな‥‥と思います。

 

720x486では、限界が低すぎますもんネ。編集工程を中心とした、当時の「運用上」の限界だったので、しょうがないと言えばしょうがないですが、素材サイズもコンポジットも、もとは1Kオーバーだったのに‥‥と惜しまれます。

 

ちなみに、私がメインで担当した2004年のテレビ作品のOPは、マスターは1280か1440px(どっちだったかパッと思い出せない)で、24pで残っています。当時はProResなんてなかったので、映像のマスターはPSDの16bit(各色)連番で可逆圧縮=事実上の非圧縮で保管してあります。‥‥まあ、技術仕様はいかにも、前の年まで作業していた劇場映画の影響を色濃く反映していますね。

 

当然ですが、テレビで放映したりDVDで発売した0.7K映像より、1.3Kのオリジナルのほうが遥かに鮮明で繊細です。

 

なぜそんな「当時としてはオーバースペック」なことが、テレビにおける「デジタルアニメーション」の黎明期である2004年にできたかというと、OPワンパッケージで取り仕切れたからです。どんな制作的な内部構造でも、納品するものに問題がなければOKで、自由に作業フローも規約も制定できたのです。

 

一方、テレビ本編は、編集上の縛りから、D1でプルダウン映像(24 to 30)でした。当時は、高品質で軽量で取り回しの容易なQuickTimeのコーデックも存在しなかったがゆえに、D1サイズのアニメでは「当時としても昔ながらの」アニメーション圧縮のロスレスが定番でした。2017年の今でも、アニメーション圧縮のロスレスが定番だと思っている人にたまに遭遇することがあって、D1時代の名残を感じます。2Kが標準の現在、アニメーション圧縮なんて使ったら、そもそも色深度が足りなくてトーンジャンプの元凶になりますし、低画質高容量の代名詞になってしまいます。Macを使っているのならProRes、WinならDNxHDやDNxHR、共通ならCineFormあたりが選択肢ですが、………当時はそんなもんないので、アニメーション圧縮のロスレスは中間コーデックの定番でした。

 

 

歴史は繰り返す。

 

現在、高詳細で繊細な絵でアニメを作ろうと思うのなら、1.5Kではなかなか難しいです。ペンタブで描いてて、ヒシヒシと感じますよネ。iPadで1.5〜2Kのキャンバスで絵を描くと、その解像度の荒さがペン先で実感できます。

 

都合、ビデオ解像度を上げることになりますが、せっかく作った高詳細の絵を、当座の編集や納品サイズが2Kだからといって、2Kをマスターにする必要はないよネ。

 

特に、短尺の場合は、内部的な融通も効きますから、様々な技術的な運用も兼ねて、高解像度でマスターまで作ってしまって、当座の納品サイズにダウンコンすれば良いです。グレーディングの技術を応用すれば、ダウンコンの際に生じる僅かな不整合(フォーカスのエッジ感やグレインサイズなどの特性の差)も吸収できますしネ。

 

まあ、テレビ本編では通用しない考え方ですが(現在のテレビ本編の作業費で、4Kとか作っちゃマズいですもんね)、お金的にも余裕のある短尺では、未来に向けて様々な取り組みを徐々に実践しておくのが肝要と心得ます。

 

 

今も昔も共通しているのは、アニメ制作現場には「マスターを作る」という概念自体が乏しいことです。あくまで「納品仕様に合わせる」のであって、「マスターを作っているわけではない」意識が色濃いです。

 

まあ、完全に請負の仕事ならば、「発注に応じた納品」に意識が集中するのは致し方なし‥‥ですが、自社で権利を保有しているにも関わらず、作り方が「納品合わせ」なのは、ちょっと‥‥いや、かなり、「もったいない」です。10〜20年後に再レンダリングなんてマシン環境の変化によって不可能なことが多いのですから(データを残しておけばいつでも再レンダリングできると思う人がいて困ります)、作業時オンタイムでマスターを作っておいて、納品にはコンバートで対応するのが「未来を考えるのなら」有用です。

 

でもこういうことは、制作現場全体の意識とも言えるので、やっぱり行き着くのは、「制作現場のリストラクチャー」なのでしょう。メーカーの宣伝として機能していた昔のテレビアニメの制作構造をずっと引きずったまま、品質だけは作品内容重視の2017年仕様‥‥という不整合は、もうそろそろ終息させても良いころだ‥‥だと思います。

 

作品の内容が重視される時代に移り変わったのであれば、完成映像=マスターに対する意識や概念も移り変わって然るべき‥‥だと思っています。

 

 


とはいえ、オールデジタル。

最近、ほんの少しだけ作画の修正の仕事を引き受けたんですが、引き受けた後で「あ。紙の道具は机から亡くしたんだった。やってもうた。」と気がつき、必要最低限の鉛筆を引っ張り出してきた次第です。鉛筆はやっぱり、レイテンシーもなければ、ガラスの厚みもないので、ダイレクト感があって描きやすいです。しかし、コンピュータのような「融通」は利かないですネ。

 

iPad ProとApple Pencilが出て、ようやく、紙とコンピュータの格差をグンと詰められた感は大きいです。ここ数日、紙で作業してみて、改めて実感しました。私はもう、紙でなくても、十分、やっていけます。

 

実は私は、かなりの保守派ではあるのです。「うそこけ」とか言われそうですが、思想の根本や道具への愛着は、何か、絶対的なものすら、我ながら感じます。鉛筆に対する絶対的な信頼は今でも変わることはありません。

 

と、同時に、「プラグマティスト」でもあるので、この先に絵やアニメで喰っていこうとする時に、鉛筆に頼り続けるのは「現実的でない」と思うし、実際にApple Pencilで絵が思い通りに描ける「現実」があるので、サバサバと表面上の行動指針を変えているだけです。

 

 

 

オールデジタルのプロジェクトはあっちこっちで頓挫していますが、こと、私らの作業グループにおいては、基本はオールデジタルで、たまに、紙の現場との折衷案としてプリンタやスキャナにご登場願うだけです。

 

プリンタなんて、まさにストレスの中心的存在。紙詰まりとか重送とかインク詰まりとかトナー切れとか位置ズレとか、トラブルの総合商社です。加えて、ランニングコストは高いですしネ。オールデジタルに移行して久しい私らの作業グループにおいては、「紙に戻る」のがひと苦労です。

 

基本的なシステムがすでにあって、インフラもそこそこ整って、作業する人間も特に意識することなく、「デジタルオンリー」の作業に慣れていれば、オールデジタルはストレスのない環境です。現実世界の媒体に起因するトラブルは全くないので、データの保全を完備しておけば、トラブルはかなり抑えられます。‥‥まあ、最近のAfter Effectsのキャッシュ問題などソフトウェアの不具合はちょっとストレスを感じますが、紙をバッサバッサと取り回すなどの日頃の小さなストレスによって確実に蓄積していくストレスよりはマシです。

 

逆に、基本的なシステムがまだ無くて、インフラも整っておらず、作業する人間が今からソフトウェアやネットワークの扱いを覚えて‥‥みたいな、何もかも「始まったばかり」では、オールデジタルはストレスの連続でしょう。オールデジタルを標榜した現場で、「足止めばかり。何もかんもトラブルの連続」と感じる人々も、多いんじゃないでしょうかネ。

 

でもそれは、やはり環境が整ってないから‥‥なんですよネ。簡単に言っちゃいますけど。

 

環境の整備や、人々のノウハウの充実なんて、口で言ってどうにもなるわけでなし。快適さや合理性を確信して、肌身で実感している人間たちが成功事例を積み重ねて、徐々に周囲を取り込んでいくしかないでしょうね。特に、日本の国民性の中においては。

 

 

 

いやあ‥‥ほんとに、オールデジタルが「真の意味」で充実してくると‥‥「楽」ですよぉ。紙の時代を経験していますから、なおさらそのギャップが解ります。‥‥まあ、「楽」とか書くと、大きな誤解や誤認を産むんですけど、あえて「楽」と書いておきます。

 

「楽」は決して「簡単」と同義語ではないですけど、「技術の運用」を「デジタルデータ時代の映像制作」で展開するのなら、今までの苦労が大きく軽減できますから、やっぱり何と表現しようと、全部を「デジタル」ベースにしてしまえば「楽」になる‥‥としかいいようがないです。快適で、合理的です。余計な負荷を削ぎ落とせます。

 

 

でも、システムもフローも含めた総合環境が充実してなければ、オールデジタルは絵に描いた餅。‥‥いや、現実の「餅」でも、そのまま生かじりしようとしてるのが、今のオールデジタルの現状です。餅は炙って柔らかくして食わないとダメでしょ。‥‥でも、その炙るコンロをちゃんと常備してないですよネ、多くのアニメ会社は。

 

まあ、今のところは「時間」をまつしかないですネ。「皆が気付くまでの時間」はどうしても必要です。

 

 


オールデジタルの頓挫

私が、自分の経歴の中で幸運だったと思うのは、前世紀末の「デジタルアニメーション」立ち上げの時期に深く関与できたことです。コンピュータを導入した制作システムなど存在しないところからスタートし、色々なことを解決しながら、徐々に長尺が作れるように発展していった経緯を、極めてリアルに体感できました。当時、20代後半でしたが、物事を柔軟に吸収できる年頃に「システムを構築する」方法を自然とマスターできたのは、大きな収穫であり、現在まで続く得難い財産です。

 

2016年から今にかけて、「オールデジタル」を標榜して、結局成し遂げられなかったプロジェクトを、いくつも耳にします。作画部門にPCとソフトウェアを供給すれば「デジタル」を具現化できるわけではないのを、今の時期、色々な人が痛感していることでしょう。

 

ペンタブで作画すれば「デジタル化」できるわけじゃないもんネ。実は、作業の動作を「デジタル」化するのと同じくらい、いや、それ以上に、作業行程周辺の整備が必要なんですよネ。

 

何に注力すればシステムが出来上がっていくのか。‥‥一番重要な知識が、システムありきでキャリアをスタートした人間にはよくわからないのです。かくいう私も、「デジタルアニメーション」の取り組みを1996年に開始するまで、絵に描いたような「業界システムの箱入り息子」で、単に「作業をコンピュータに置き換えれば、デジタルでアニメを作れる」と勘違いしてましたもん。

 

時は経ち、2017年。同じ勘違いが、そこかしこで繰り返されているんだと思います。‥‥普通、そうなるわな。システムの作り方なんて、社会システムの中でぬぼーっと生きてれば、学ぶ機会なんてないもんネ。

 

「ノウハウさえ溜まってくれば」‥‥なんて思う人もいますが、それも大いなる勘違いです。「ノウハウ」が溜まることは、決してシステムの構築には結びつきません。むしろ、「ノウハウ」で現状をやり過ごすことだけを覚えて、システムの設計をゼロから見直そうとする気運を妨げる、「障害の原因」にすらなり得ます。

 

2017年の「オールデジタル」の経緯って‥‥

 

  • 新しい土地を購入しました
  • ワラを敷いてとりあえず座ってみました
  • 壁があったほうが良いと思って板で四方を囲ってみました
  • 雨が降ってきたら濡れてしまうので、屋根もつけてみました
  • 住みにくいけど、工夫でなんとかなると、自分を勇気づけてみました
  • ふと、トイレがないことに気づきました
  • なので、部屋の中に便器を置いてみました
  • 急場は凌げましたが、部屋の中に便器を置くことは異常だと思いました
  • 加えて、下水道がないので、色々とヤバいことになってきました
  • 夜になると電気がないのでまっくらにもなりました
  • ライフラインが開通していないので、旧市街から物資を調達しました
  • いくら土地があっても、ちゃんとした家とインフラがないと暮らしていけないと、改めて解りました
  • 新しい土地を離れ、昔住んでいた家に戻りました

 

‥‥みたいな状況も多いんじゃないですかね。

 

今まで、普通に暮らして来れたのは、様々に環境の行き届いた「家」があったからで、「土地」を漠然と購入しても、そのままでは暮らしていけないことを、昔の家を飛び出してみて改めて気がついた‥‥という、めちゃくちゃ「ありがち」なオチです。

 

家の建て方も知らないのに、土地だけ買っても、そこでは生きていけません。‥‥普通に考えればわかることですが、なぜか、自分たちの身になると、気がつかないものです。

 

 

解決法はシンプルです。

 

家を建てることをちゃんと意識して、建築する方法を実践すれば良いのです。ただそれだけ。

 

 

その際、最初から鉄筋のマンションを建てようと、素人が誇大な夢を見ないことです。小さなコテージから始めます。

 

数十秒のアニメ映像を、まずは「オールデジタル」のプチシステムで作ってみることからスタートします。その際に、決して「個人の器用さ」に頼って作るのではなく、その場その場の取り回しで作るのではなく、どんなにミニサイズでも「システムで運用して」作るのです。‥‥実はこれが「極めて重要」です。

 

数十秒の短尺だから、命名規則もフォルダ構成も、レイヤーの名前も、テキトーでいいじゃん。===ダメなのです。そういうことをしてるから、いつまでたってもシステムが作れないのです。

 

「小さい作品だから、個人の手際や器用さで、作っちゃえば良い」だなんて、チャンスを無駄にする典型です。「小さい作品だからこそ、システムのプロトタイプや雛形の運用テストができる」のです。小さい作品こそ、「手弁当ではダメ」なのです。

 

おそらく、「オールデジタル」で頓挫するのって、現場を構成する作業者各個人がコンピュータを扱える状況を、システムができたと誤認したがゆえ‥‥でしょう。各作業者がコンピュータの扱いに慣れて、器用に個人プレーで立ち回って場当たり的にこなせるようになったことを、ワークフローができたとか制作システムができたなどと勘違いするのは、ほんとに‥‥‥‥‥‥よくあること、、、なのですよ。

 

 

実のところ、ファイル名やフォルダ構成、レイヤー名だけをパッと見ただけで、当事者のシステム運用のスキルやレベルがわかります。システムが構築された現場で扱われるファイル名は、とても「整然として美しい」ものですが、システムが出来てない現場のファイル名は「無残に汚い」です。各作業者が個人プレーで状況を切り抜けていくような現場だと、それはもう、ファイル名もフォルダ構成も支離滅裂になります。

 

こんな風に書くと「そうか。決め事をどんどん決めていけば、システムが作れるんだ!」と思いがちですが、それも大いなる勘違いです。

 

ワークフローの設計、ネットワークの設計など、様々なシステム要素を鑑みた上で、「設計上から決め事が浮かび上がってくる」ようにするのが「正解」です。

 

何の根拠ももたない一時的な決め事で、作品制作が成立するのは、個人制作の短尺の自主作品だけです。その場のノリで決め事を乱発しても、うまく統制できるわけがない‥‥ですよネ。

 

あくまで、決め事はシステム設計全体から滲み出していくものなのです。

 

 

 

システムを軽んじる人、システムの重要性は知りつつも困難にブチあたる人、手堅くシステムのステップアップを進める人。2017年から数年は、色々な思惑と状況が錯綜する数年となりましょう。

 

 


高詳細の痛撃

私は、新しいアニメーション技術を用いる際は、基本的には清書を自分でおこないます。つまり、動画工程の清書まで自分で作業するわけですが、これは事「イラスト」的に考えれば、ごく自然な流れです。私はProcreateを常用しますが、Clip Studio(既にバリュー版が満期になってライセンスを1つ持っております。クリッピーは溜まる一方‥‥。)でも同じことがごく普通に可能です。

 

もし新しい技術スタイルで、清書作業を現在の動画作業者に依頼する際は、そもそも今までとは違う高詳細な絵を、丹念に清書するわけですから、作業費目は動画ではなく他の費目にします。もちろん、作業単価も「数百円」なんてことはないです。‥‥ありえんでしょ、普通に考えて。

 

4Kを常用している私自身が日頃感じていることですが、絵はなんだかんだいっても、キャンバスが大きくなれば細かくなっていきます。なので、作業する作品が2Kの場合は、故意に絵の密度を下げるようにして描きます。

 

しかし、そもそも、4Kがフォーマットとして存在する意義はまさに「4K=2Kより高詳細であること」ですから、4K作品の制作が開始された際は、実写だけでなく、アニメでも、高詳細な絵を作るのが必然的になります。ミッフィを描くのでもなければ‥‥です。

 

 

一方、現在のアニメ業界の標準的な作画工程。

 

世間の流れに抗いきれず、もしアニメ業界で4K作品を旧来のワークフローで生産した場合、おそらく4K24pで作業することになると思いますが、それは何よりも動画作業とその作業者に痛烈なダメージをあたえることになるでしょう。

 

現在ですら、新人で平均10万円以下だとも言われる収入が、より一層、かなり落ち込みむのではないでしょうか。仮に今の数百円の動画料金が2倍になっても、2倍以上の作業時間がかかったら、収入減になります。つまり、新人の脱落の度合いが一層高まって、「新人が育たない」‥‥というか、育ちたくても生きていけない状況に猛烈な拍車がかかる‥‥のではないでしょうか。

 

今の萌絵の流行がまだ続いたとして、その萌絵の内容は止め絵のイラストを見れば、止め絵とばかりにかなり描き込んだものも多く、その緻密な描き込みに「同じとは言わないまでも」かなり迫った作業を4Kで「やらされる」ことになるのは必至です。そんな絵を8〜12fpsのままだとはいえ、何千枚も描くことになるのは、何よりも動画作業者に痛撃を与えることになるのは、アニメ業界関係者なら誰でも容易に想像できますよネ。

 

 

私が現在の、どこかの誰かたちが牽引しようとする「デジタル作画」の風潮に、どうしても同調も賛同もできないのは、そういう都合の悪い未来には全く言及しないからです。タブレットで作画するようになって、2Kでも4Kでも8Kでもキャンバスサイズが設定可能になって、拡大作画も簡単にできるようになって、その次に来るのは‥‥‥を、全く言わないじゃないですか。

 

「大丈夫ですよ。アニメで4Kなんて、作るようにはならないですから」‥‥と言う人がいれば、ぜひ、その言動をiPhoneか何かで撮影して映像証拠として残しておいて欲しいです。

 

私は、アニメであっても、映像コンテンツ産業の一角として存在する以上は、高詳細だけでなくあらゆる高品質化の波に呑まれていくと思います。

 

16ミリで撮影した昔のアニメですら、HDのリマスタリングで「高品質化の波を利用」して商売してるのです。現代の趣向を色濃く反映して作っている作品が、「高品質化の波」を脇目に、独自の価値観だけで生きていけるわけがない‥‥と、少なくとも私は思います。アニメキャラのデイザインを、しんちゃんやタラちゃんやカツオやミッフィに限定してそれ以外は禁止!‥‥には、到底できないでしょう。

 

 

なんかさあ‥‥、「デジタル作画推進」の流れって、とにかく皆にコンピュータの作画環境を所有させてしまって、その後で「後出し」で高詳細なキツい作業を「なし崩し的」に標準化してしまおうという、「悪どい流れ」すら感じてしまうのですよ。

 

「そんなつもりはない」と言ってても、実際に未来の顛末がそうなれば、同じことです。

 

そんなつもりはなくても、「どうなっていくか」は想像できているはず。物理的制限のあるA4用紙と違って、ソフトウェアの許す限り、キャンバスサイズを大きくできることを、まさか「デジタル作画」に関与している人で、「そんなの知らなかった」なんて言う人はいまい。

 

ゆえに、作業費の問題とデジタル作画推進は、「同じまな板の上」だと思いますけどネ。

 

 

私は、新しい技術においては、旧来の料金体系は一切白紙に戻して、「然るべき技術をもった作業者が、然るべき作業時間を要した際に、技術者の報酬として然るべき金額」を全て検証して、それが制作費の中に収まるべく、制作に関わる人間すべてで「再定義」していきたいと考えています。新しい技術には、新しい作業費の制定が不可欠です。

 

「そんなの無駄。だって、作業の手間も人員も変わらないんだから」と言う人もいましょうが、たしかに、それは正しいです。結局、同じ工数と人員で作業してたら、再定義しても実質は変わりませんよネ。どんなに座る席を変えても、L寸のピザを20人で分け続けていたら、いつまでたってもビンボーですもん。

 

だから、新しい技術においては、作業のフローも所要人員も大きく様変わりするのです。「作業の手間も人員も変わる」から、「無駄」ではないのです。今やっている短尺の仕事は、映像を作る実質のスタッフ数が3〜4人で完結してしまいます。しかも、工期は変わりません。品質は技術の性質が良い方向に作用するので、通常より高くなります。もちろん、4KにもスタンバイOK‥‥です。

 

私は、このブログでも日常の会話でも、コンピュータの良い部分と悪い部分を包み隠さず言うようにしています。そして、次世代の高品質映像フォーマットをターゲットにするということは、かなりのリスクを伴うことも、ゆえに、競合も少なく有利に‥‥は、まあ、何度もしつこく繰り返し書いてることだから、いいか。

 

 

「赤信号、みんなで渡れば怖くない」というは、もしかしたらアニメ業界の嫌な流れかも知れません。「赤信号だとわかってて渡って、トラックに轢き殺されても、皆一緒だから、痛み分け」みたいな‥‥ネ。それじゃまるで、「ネズミの集団自殺」じゃないですか。

 

でも、ネズミの集団自殺は、実は追い詰められたそれぞれのネズミが、自発的に「海の向こうを目指して泳ぎに飛び出す」行為だとも聞いたことがあります。

 

ネズミは、ある時には猫をも噛み、ある時には大山を鳴動させることもありましょう。ネズミは群れに依存しているときは弱い存在かも知れませんが、一匹となってブチギレた時には恐ろしい攻撃力を発揮する‥‥のかも知れませんよ。


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
      1
2345678
9101112131415
16171819202122
23242526272829
30      
<< April 2017 >>

selected entries

categories

archives

links

profile

search this site.

others

mobile

qrcode

powered

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