Kindle HDX 8.9

Kindle HDX 7 のディスプレイに大問題アリ‥‥という事で、HDX7への関心は全く薄れ(次期モデルに期待)、関心の矛先はHDX8.9へとすっかりシフトしました。職業柄、OODA癖がついてるので、Decide(意思決定)はそれなりに速いのれす。

HDX8.9の解像度は、2560x1600。2013年だと、この解像度のPCモニタを持っている人も少ないくらいなのに、小さなタブレットの8.9インチ画面の中に、ビッシリとピクセルが詰め込まれているのです。私は、未来の映像周りは、大画面ではなく、今と同じ画面サイズで高詳細になっていくと考えていますが、まずは小さなタブレットで先鞭をつけるわけ‥‥ですネ。

ぶっちゃけ、前モデルのHD8.9〜1920x1200でもかなりの高密度だとは思いますけどネ。HD8.9は割引特価20,800円で、売り切り気配満載です。

で、HDX8.9。ビデオ解像度は2.5kか‥‥と考えてたら、QTの容量も相応に大きくなるという当然過ぎる事に気付き、さらには、今までの「必要容量」の感覚では不足がでるかも‥‥と連鎖的に想い浮かびました。QTファイル数は変わらなくても、容量は大きくなるんですよネ。

でもまあ、そもそもHDX8.9の許容するムービーファイル解像度がどこまでなのかも判らないですし、クアッドコアの処理能力に応じたビットレートの上限も判りません。どれだけ、容量と処理能力を喰うのかは、実物で試してみないと何とも言えないです。Kindleを買ってみるのも、そこらへんのテストがしたい事もあるので、テスト目的が実行可能な32GBモデルあたりが無難なように思います。

200〜300MbpsのオリジナルQTデータを、Kindleで見る際には5〜15Mbpsまでダウンコンするわけですよネ、恐らく。‥‥色々模索しないと、ダメぽ、です。

今すすめている新方式のアニメーション技法は、400〜600dpi(紙ベースの場合)・4Kキャンバスで、髪の毛1本、まつ毛1本、木々の葉っぱ1枚が48・96コマでフルアニメーションする、ややクレイジーな内容ですが、その技法の意図は未来の高詳細モニタで報われるのです。HDX8.9は2.5kではありますし、FPSの上限は30コマくらいかなとは思いますが、まずは小画面高詳細がどれほどのものか、この目でしかと確認したいとウキウキしております。

Kindle HDX 7を買おうと思ってたんだけど‥‥

Kindle HDXの7インチを買おうと以前から考えてたのですが、今日、ネットで調べていてビックリ、画面の周辺部に青いグラデが入っている‥‥との事です。???‥‥マジすか。

 

http://pc.watch.impress.co.jp/img/pcw/docs/623/849/html/56.jpg.html


<アマゾン製品ページより引用>

Kindle Fire HDX 7はこれまでのAmazonの7インチタブレットで最高のディスプレイを搭載しています。323ppiの高解像度、忠実な色彩を再現する100% sRGBのディスプレイを採用し、豊かで鮮やかな色彩を実現しています。

Kindle Fire HDXはこの豊かな色彩のため、白色LEDではなく青色LEDを採用しました。これにより、豊かな色調を再現しながらも、20%電力効率を改善し、端末重量を軽くしています。

この青色LEDによって、読書中やウェブサイトの閲覧時など、背景が白い場合にディスプレイの端にうっすらと青い線が表示されることがあります。すべての液 晶ディスプレイには端に光の放射が発生しますが、Kindle Fire HDX 7のディスプレイの端に見られる光が青いのは忠実な色彩を再現するための技術によるものです。


なんて言うか、アマゾンらしい文章表現スね。‥‥「うっすらと青い線(とうかグラデ)」が表示されちゃう時点で、「忠実な色彩を再現する」とは言えないのでは‥‥と、誰もがツッコむかと。 青いグラデが覆った部分は変色しちゃう(色彩が再現されない)んだからさ‥‥。

これはマズい。かなり昔、こんな感じの液晶モニタがあった(液晶モニタ自体が珍しかった頃)けど、今の品質感覚でこれはヤバすぎです。昔懐かしいCRTモニタの、デガウスボタンを押したくなるス‥‥。

これは「製品上の仕様」との事らしいので、どうにも回避できません。と言う事は、少なくとも、私の使用目的(映像や画像の閲覧)においては、完全にNGです。sRGBとか高詳細とか以前の、基本的なレベルの問題だと感じます。

危うく買いかけるところでした。寸止めでセーフ‥‥。まだ発売前だからキャンセルは可能だとは思いますが‥‥。

8.9インチモデルのほうは大丈夫らしいので、そっちに変更かなァ‥‥。iPad Airは、Apple以外の製品を試してみたいというのがあるので、今回はKindleでいこうと思ってます。

PHPのライブラリ

PHPロゴ私はWebを構築する際、HTMLとPHPを用います。PHPはとっつきやすい言語で、JavaScriptに慣れている人なら、少々の読み替え・シフトで、すぐに使えるようになると思われます。「My Name Is Hisashi.」と「Mein Name Ist Hisashi.」くらい似ています。

私は今、「atDBx」という「アニメーション制作技術データベース」をチクチクと開発・構築し続けていますが、AppleScript用、JavaScript(ESTK)用のatDBxライブラリに続き、PHP用もそろそろ作る段階に差し掛かってきました。PHP用ライブラリを作らないと、データベース上の情報を人間の目でみる事ができないのです。情報データをWebブラウザで閲覧するには、それ相応の計画と工夫、そして実際のプログラムが必要です。

atDBxの前身であるatDBでも、PHPとの連携をおこなうライブラリは作っていたのですが、「どんなライブラリを作れば良いのか?」という基礎的な部分から手探りだったため、場当たり感満載でおよそ流用には適さない状態となってしまいました。とにかく「すぐに動作する」事が優先されたので、計画性に乏しく、無理に流用すると弊害も出そうでした。

何でもそうなんでしょうけど、最初から良い出来のものは作れませんよネ。「何が良いのか?」も解らないのですから、まずは手をつけて経験をつまないと、先には進めないのです。今のご時世は、最初から完璧なものを目指して(実は「完璧とは何か」すらわからないまま)、期待した結果を得られなければ即撤退‥‥という感じですが、技術はニジニジとした蓄積が必須なのですから、長丁場を覚悟しないとダメなんですよネ。何でも「自販機感覚」で手に入るわけじゃないのです。

今、私が取り組んでいるのは、各言語への「ライブラリの共通化」です。言語毎の文法はともかく、呼び出すサブルーチン・ファンクションくらいは共通化を図ろう‥‥というわけです。外部ファイルをそれぞれ用意しておいて、load script、readとeval、includeで各言語共通の命令系統を実現する仕組みです。以前は言語毎にバラバラだったので、コード記述時の効率が悪かったのです。

ライブラリ作成は、すなわちスクリプト作成・アプリ開発のお膳立てなので、ライブラリが存在しなければスクリプトを書き始める事もできないわけで、焦っていると「ライブラリなんて作らずに、すぐ作り始めちゃえ」となりがちです。‥‥でも、その行動が後になって、とんでもないフリクションロスやカロリー損失につながるのです。この辺の事は、同じような体験をした人なら解ってます‥‥よネ。

ライブラリを用意しておけば、実際のプログラムはスリムで明快な構造で作成できます。私のような映像制作の片手間でアプリを作る、プログラム専任ではない人間ほど、実はライブラリの構築が重要ではないか‥‥と思うのです。

リアルタイム系の指使い

最近は、公私共に新たな展開を目指してヒートアップしている影響で、趣味や娯楽というものに全く時間を割いておりません。仕事もプライベートもアニメと映像の無限ループです。まあ、それでも全然構わないわけですが、どうも体のナマりが忍び寄っている予感がします。これは、回り回って事業にも影響するので、焦ってばかりいないで、少しは気分転換したほうが良いかも‥‥と思っております。

絵を描く、ソフトウェアを操作する、ストーリーを考える、プログラムを作る、写真を撮る、録りためたビデオを見る、資料制作をする‥‥の、「映像関連ヘビーローテーション」 だと、何かキモチ的に澱が溜まるというか、偏りが出るなあ‥‥とつくづく実感します。映像関連の中で趣の違うものをローテーションさせても、やっぱり煮詰まってきます。

加えて、数年前に引越を自前で慣行して以来、指の間接が固くなってしまったような感じで、それを解消する運動もしていないので、今でも引きずったままです。指が固くなっていると、もうすぐソコに老化が忍び寄っているようでコワいです。

そういえば、もう10年以上まともにピアノを弾いていないので、ここはひとつ、数日に1〜2時間でもピアノを弾いて、指の凝りをほぐすのも良いかなぁ‥‥と思い始めています。家には20年近く前に買ったデジタルピアノが半ば物置台のようになっているので、発掘して弾いてみるのも金がかからなくて良いかも知れないですネ。

ピアノの指使いは、プラモ制作やキーボードタイピングと比べて、複雑かつリアルタイム系なので、「指をナマらせない」用途にはピッタリです。プラモ制作も指先の細やかさが必要ですが、リアルタイム性はそれほど問われない(=テンポにのらないとOUT!なんて事はない)かわりに、0.05ミリ精度の動作が要求されるので、ドッと神経が消耗します。キーボードは毎日打ってて疲れるばかりだから論外。やっぱり、ピアノかギターをちょい復活させるのが良いのかも。

20代の頃は、行き詰まるとよくピアノを弾いてモヤモヤをほぐしたものです。鉛筆を持つポーズで何時間もいると、手が凝固するような感覚に陥って「ぬがー」「うきー」となっていたのです。そんな時に、多声的な楽曲を無理にでも弾くと、こんがらがっていた何かが1つずつ解けていくのです。対位法の大家・バッハの楽曲などは「解きほぐし」にピッタリでした。

自身が何かしらで固まってわだかまっていると、やっぱり音も団子になって固まりますもんネ。ピアノを弾くと、自分の状態の客観的な審査結果が、音として即座に表れるのです。今思うと、ある種の「音楽療法」だったのかも知れませんネ。

20年前は、10万円クラスは安物、20万円以上が普通だったデジタルピアノも、今は随分と買いやすくなっているようです。音質もかなり進化して、心地の良い音になっていますね。ローランドのF-120なんかは、10万円を切る実勢価格の下位モデルですが、充分過ぎるほど音は良いですネ。10万円以下で充分、楽しそう。(生ピアノと比べても?‥‥とか野暮な事は言わないで)

とりあえず安く弾きたい!‥‥感じなら、ヤマハのP-105・スタンドセット(ペダル付き)で5万を切る激安モデルでも良いかもです。しかし、この値段でこんな音が出るのだから、今はスゴいっすね。生ピアノの代わりにはなりませんが、音を出すだけの目的ならこのクラスでもニーズを満たしてくれるように感じます。

まあ、私は20年前のクラヴィノーバで充分です。音は無機質ですが、ソレはソレで構いません。指のもつれをほぐして、脳を明晰度を上げるのが目的なので‥‥。

 

AmazonのMP3

Amazonで懐かしいサントラを数枚買いました。007の「ロシアより愛をこめて」「ゴールドフィンガー」などのジョン・バリー氏の楽曲、「セーラー服と機関銃」などの星勝氏の楽曲など、多数のサントラCDが1000円の価格で発売されているのを知り、急遽購入したのです。

そしたら、合計で400円の「MP3ダウンロード 割引」が付いたので、早速MP3を買ってみました。Amazonは100曲で200円とか価格破壊商品があるので、ソレ目当てです。

久々にのぞいてみたら、格安のアルバムがかなり増えていました。今回買ったのは、ラフマニノフの100曲シリーズと、バッハの鍵盤作品全曲集です。

ラフマニノフは、まずトップはピアノ協奏曲第3番で幕を開け、メジャーなものから珍しめのものまで、色々100曲(というか100トラック)入って、何と1セット160円です。1曲ごとに買うと1曲150円なので、もはや価格設定の意味も崩壊しております。あまり耳にする事のないピアノ協奏曲の1番(よく聴くのは2番か3番ですよネ)とかノクターン(ラフマニノフのノクターンは珍しいですね)など、単に入門編に留まらないのが良いです。
*ピアノ協奏曲第3番は当初ラフマ本人かと感じたのですが、私の所有するCDとは演奏が大きく異なりますし、トラックの表記もいー加減なので、よく解らないです。ラフマニノフは結構インテンポで極端なダイナミクスをつけずに弾いてる(私の所有音源だと)のですが、アマゾンの音源はどうも違います。

バッハの鍵盤作品全曲集は、377トラックで600円。これもスゴいですネ。再生時間は15時間超えなので、10数枚のCDボックスのボリュームです。ハープシコードによる演奏で、モノラルとステレオのトラックが混在する点から、古い音源と思われます。ダイナミクス&エンハンスが不安定なトラックもあり(強めのゲートとか)、必ずしも良い状態とは言えないのですが、全曲をさらうにはコストが半端なく安いです。あと、真作か否か(バッハ本人の作曲か)の疑問が残る作品は収録されていないものもあるようです。BWV905とか。

この他にまだ沢山、「缶ジュース2〜3本の値段で100曲」のシリーズがあるので、また物色しようと思っています。
 

雑文

最近、プログラム関連に比重を置いていましたが、映像制作は作品表現・映像技術・運用の3つが不足なく必要なので、一時的にどれかに偏るのは、まあ、仕方のない事なのです。私はアニメーター出身なので、作品や技術の方面に傾倒しがちですが、運用が脆弱だと表現や技術が「カタチにならない」ので、焦燥感をなだめながらでも、運用システムは定期的に積み上げていく必要があります。

作品表現・映像技術・運用は、三つ子の兄弟・姉妹のようなものです。表現が欲する技術が生まれ、技術が欲する運用が編み出され、運用や技術が表現を触発するのです。アイデアを実現する先駆者の存在はあるにせよ、例えばライト兄弟がいきなり全金属製のレシプロ機を飛ばす事はないのです。

ただ、人がひとたび、「空を飛べる」と知れば、どんどんエスカレートしていきます。その時代の様々な要素が強力に後押しするからです。これは映像作品についても同じ構造が再現されるように思います。

ちまたでは今でも、「作画」vs「3D」の二元論で論じられる事が多いようです。でもまあ、それはしょうがないか。「新たな2D」はまだまだ水面下ですしネ。「作画でなければ3D」という思考は、もはや、コンピュータ活用の黎明期の考えだと感じます。作画=2Dという概念も‥‥です。

例えば、以下の参考ムービー。After Effects上のパスでテキトーに作った内容ですが、3Dレイヤー&カメラで舞台セットを組んでいるので、カメラを動かすと視野が連動して動きます。

 
*空BGや草BOOKの付け根がバレてますが。
*パス(ペンツール)で描かれた絵なので、カメラが寄って線は太くなっても、ジャギは全く出ません。

こんな簡素な仕掛けも、今のアニメ業界のフローでは不可能です。なぜって、タイムシートが「こういう事に対応していない」からです。紙のレイアウト上で指示をしても、セルやBOOKそれぞれのZ位置までは指定できません。After Effects上では、距離をコンパクトにまとめて被写界深度を深く表現する事もできますし、距離を広げて深度を浅くする事もできますが、フレーム指示ではフレームの絵収まりしか指定できないのです。

なので、こうしたAfter Effectsの機能は、現アニメ業界フローでは何年も「封印」状態のままです。

‥‥この技術は、いくつもある技術の中の、ほんの氷山の一角〜言わば「ひろピョン石」なのですが、おおやけに使われる事は今でもありません。実は、2005年のホリックの劇場アニメで既に使っていたのですけどネ‥‥。8年も前の事ですヨ‥‥。

1996年から16年、コンピュータを導入したアニメ制作現場の様子を見てきて、業界がフローに対して根本的な大改革をおこなうとは、もう思えないのです。私の近年の行動は、そうした実感に基づいています。

ですから、一方では、今の業界フローは今のまま、これ以上発展させなくても良いのでは?‥‥とも考えています。明確に、伝統芸化してしまうのです。需要はまだまだ沢山あるでしょうし、そもそも紙ベースとデジタルの齟齬を回避できます。キャラだけでなく、手描きのメカやエフェクトが熱かった80〜90年代の作画意識を取り戻して(絵は今風でも)、観客を圧倒するのが実は一番「デジタルに真似できない事」なんじゃないでしょうか。作画の熱さはそのままに、デジタルは高機能ペイントと高機能フィルム撮影台の役割に徹するわけです。

中途半端に、面倒な作画はデジタルに頼る気風だから、プライドも覇気もトーンダウンしているのかも‥‥。

* * * *
私は相変わらず、コンピュータグラフィックス路線です。90年代の中頃から、その辺はブレておりません。素手で描線を描こうが、コンピュータで処理すればCGッスよ。そもそも「デジタル」に踏み込んだのも、作画+セル彩色+フィルムカメラという組み合わせに限界を感じていたゆえですから、郷愁を感じたとて、戻る事はありません。

私が日頃のBlogで少しだけ公開しているのは、やはり氷山の一角です。Blogで単発的に出せるものだけ、公開しても支障のない無難なものだけ‥‥です。似たような事を考えている同志・ライバルに、間接的・比喩的に「みなさんはどんな感じでっしゃろ」と呼びかけているつもりです。似たようなソフトを使っているのだから、同時多発的にやがて各所で皆が頭角を現すのではないかと思っています。少なくとも、米某社はかなりのレベルまで、既にイッちゃってますからネ‥‥。

周囲から「何をトンチンカンなことを」と思われていても、新たな2Dの可能性に確信をもっている人は世界各地に点在している‥‥と思います。「見えている」人にはもう見えているはず。大多数の常識的な意見や認識など、新しい取り組みの前には、何ら気にかける事はありません。今じゃあたりまえの「デジタルアニメ」だって、90年代の中頃は多くの人々がスルーして懐疑的な視線で傍観していたのですから。

After Effectsのゾンビ変数

ここのところ、作り続けていたグレーディングシステム用のパイプラインアプリですが、ほぼ完成し、あとはバグ潰しや機能改善をチクチクと地道に進めていくのみです。どんなに気を配ったつもりでも、実際に運用すれば、ポコポコと穴は出てくるものです。

After EffectsをAppleScriptで駆動する方法は、丁寧にAppleScriptとAfter Effects間でやり取りするのではなく、ESTKの命令文を作って丸投げする方法です。AppleScriptでPhotoshopを操作する際は、様々な返値を利用できるのですが、After Effectsの場合は貧相なexitCodeしか返ってきません。exitCodeは整数のみで、文字列などは扱えないので、スクリプトを実行した結果は実質受け取り不可能に等しいです。例えば、コンポジションのレイヤー名一覧を外部から取得する‥‥なんて事は通常の段取りではできないのです。

じゃあ、どうやってAfter Effectsをスクリプトで転がすかと言うと、ソケットや独自のクリップボードを使う‥‥などもありますが、環境の整備がそこそこ面倒なので、私は「変数を泳がす」方法で切り抜ける事が多いです。恐らく、一番安易で簡単です。

After Effectsの変数はゾンビのように、After Effectsが死ぬ(アプリ終了)まで生き続けるので、これを利用して、「ゾンビ変数に値を持たせたまま泳がせて」外部から上手く操作するわけです。

AppleScriptなど外部からは、変数・定数の中身ではなく、あくまで変数名だけで、転がしていきます。つまり‥‥
 
//Script 1
var _OUTPUT_COMP=app.projects.item(1);

‥‥として、変数に普通に代入しておけば、スクリプトを一旦終了しても、After Effectsが終了しないかぎりは、いきなり、
 
//Script 2
_OUTPUT_COMP.layer(1);

‥‥と書き始めても、undefinedになる事もなく、普通に取り扱い可能です。変数の中身は外界に取り出さずに、変数自体を外部からあっちゃこっちゃと転がして、上手くいった場合は0、そうでない場合は0以外をexitCodeに代入して、「result as integer = 0」でBooleanに変換し「結果報告だけを聞く」カタチにするのです。

いつまでも変数が死なないこの習性(?)を利用すれば、結構自由にAfter Effectsを「遠隔操作」で転がせるのですが、反面、変数が暴走(大袈裟ですけど)する危険性もあります。JavaScriptはDimとか宣言しなくても、おもむろに変数を使う事ができますが、ゆえに、既に前の前の前のスクリプトで使用済みの変数を、意識無しに使ってしまう可能性もあります。なので、ゾンビ変数を意識的に転がす際は、変数の名前のお約束を自分の中で定義してキッチリと運用する事が必須となります。


変数 i に10が代入されたところでスクリプト終了。


別のスクリプトで 変数 i をおもむろに使うと、既に10の値がセットされているので、結果は30。うひー。‥‥もちろん、変数 i の使用前歴がなければ「iは未定義」となってエラーです。スクリプト作成者の「管理能力」が問われる仕様ですネ。undefinedねらいの軽妙な文面でなく、しっかり変数の宣言と初期化をやっておかないと、後で弩壷にハマる仕様となっております。


‥‥ちなみに、エクスプレッションはそういう事(ソンビ)はないようで、1レイヤー1フレームごとに値はクリアされるみたいです。まあ、全てのエクスプレッション上の変数が生き残りまくってたら、わけがわかんなくなるでしょうからネ。

 

AppleScriptのcontinue

AppleScriptは、Macユーザかつスクリプトを常用している人間でないと使わないので、マイナーなアプリではありますが、その能力はあなどれません。私の自作ツールのほとんどはAppleScriptベースですが、業務の生産効率を左右するほどの影響力があります。

ただ、AppleScriptに何も不満がないわけではなく、こんなのがあるといいのにな‥‥と思う機能はそこそこあります。すごく基本的なところではループ文における「continue」です。

AppleScriptでも「continue」はあるのですが、「処理を続ける」という命令で、ループの処理を抜けて次回へスキップする内容ではありません。JavaScriptのcontinue相当はどうもAppleScriptには存在しないようです。breakはexitでイケるんですが。

要は、処理を抜ける構造が実現できれば良いので、以下のようにしてcontinueと同等の動作は実現できます。

set myList to {}
repeat with i in {1, 2, 0, 15, 2, 2.1, 2, 3}
    repeat 1 times--continue実現の為のrepeat
        set i to i as number
        if i = 2 then exit repeat
        set myList to myList & i
    end repeat
end repeat
return myList
--結果は{1, 0, 15, 2.1, 3} 
〜変数「i」が2の時はexit(break;)して、以降の処理はスキップします

入れ子のrepeat上でexitを使えば、exit以降の処理は実行されずにスキップされるので、continueと同じ働きをします。

しかしなんでしょ‥‥、行儀は悪いですよね。continue実現のために、repeatを本来とは違う目的で用いているのですから。

インクリメントとかは、単に「set i to i+1」とやればよいので、文字数の冗長さにガマンするだけで済むんですが、continue模倣の為だけにrepeatを使うのは、後になってコードを読み返した際に「何でここでrepeatを使ってるんだ?」と自分でも判らなくなりそうで、面倒でコワいです。

ちなみに‥‥。参考文中の「set i to i as number」を読んで、「なぜ、そんなクドいキャストを?」と思う人もおられるかもしれません。変数 i には当然Numberクラスが代入されていると思うわけですが、その変数 i を「is」「=」の比較演算子を用いて評価すると、実際はうまくいかないのです。AppleScriptにはありがちな動作ですネ。「item 2 of {1,2,3}(つまり2ですネ) 」は、2ではない‥‥という比較演算‥‥。でもまあ、もう16年もAppleScriptと付き合ってると、他の言語にはないクセもお馴染みなので、もはや混乱する事はあまりないです。AppleScriptが「何でヘソを曲げているのか」は大体察しがつきます。しかし、JavaScriptなどの他の言語に慣れた人がAppleScriptを使うと、「???」の連続かも知れませんネ(苦)。

Mac After Effetcs 12.1のマウスホイール

バグです。

After Effects 12.1のMac版にて、映像表示部の拡大縮小をマウスホイールで操作しようとすると、反応が鈍くてイラッときます。

この症状は米国のAdobeスタッフも認めるところで‥‥

We have verified this bug internally in After Effects 12.1 on Mac OS, with a variety of mouse hardware. The problem does not occur on Windows.

The issue is related to scrolling speed. If you scroll very slowly, the scroll action is not recognized. If you scroll at a faster speed, the scrolling action is recognized. This is true for scrolling in all panels, not just viewers; it's possible you only see it in viewers because your intent to zoom via scroll requires more precision.

Apologies for the bug. We are investigating the cause and a fix. In the meantime, my recommendation is that when you need to zoom in via small increments in a viewer, use the keyboard shortcuts, or switch briefly to the Zoom tool.


‥‥だそうな。フォーラムより抜粋。

要は、「After Effectsのマウスホイールの問題は当方でも認識しており、Mac版でのみ発生する。問題が解決するまで、ショートカットなど他の手段でよろしゅう。。。」という事です。

むきき。職場のは12.0だけど、自宅のは12.1にしちゃったんだよねェ。

ちなみに、ズームイン&アウトは、テンキーじゃないほうの「.」「,」です。半角英数字入力で。

あー、もっとはやくフィードバックしておけば良かった。。。まさかAE側の障害とは思わんかったです。

上方修正

グレーディング作業におけるパイプラインプログラムの導入効果は、予想以上に高く、当初3日分と見積もっていた作業量を1日でこなせる勢いです。同時に撮影業務も少々兼務していますが、そちらは相変わらずのペースで、様々な場面で効率を落とすトラップが仕掛けられています。撮影もStandardizationを実現できれば、効率化も夢ではないとは思いますが、現状では部署単独で改善に望む事は実質不可能とも思います。

でもそうやって、互いの部署同士が干渉を避けてきた結果が、今の状態と言えます。30年以上、基本的な制作システムが変わってこなかった‥‥つまりは、制作システムの技術革新をしないまま現在に至った状態です。それなのに、やる事をどんどん増やしているのだから、昔と同じ状態を保てるわけがない、歪みが出ないわけがない‥‥ですよネ。

やる事が増えたから金を増やしてくれ‥‥という考え方もあります。でも一方で、やる事が増えるのに伴って、生産システム内部での技術革新を模索していないのはどういう事か。言わば、自分の健康維持を、医者や医療制度のせいだけにして、自分の生活習慣は何も改善しない‥‥のでは、かなり説得力に欠けると思うのです。

何をするにも巨象のようなカロリー消費が必要な、今の業界制作システムでは、保守的な「成功例のある」作風に終止せざる得ないと感じています。

もし運用技術の革新を実現して、フットワークを軽くできたなら‥‥。それは、作品企画でも実制作でも雇用面でも、大きなシフトチェンジになるように思います。旧来からの状態を維持‥‥という考えを捨てられない限り、新しいフェイズへは進出できないのではないでしょうか。

ゆとり世代って、世間ではイジられる対象みたいになっていますが、私は結構、Unique(=独特)な面白い人材が多いと感じています。不思議ちゃんもいれば、才人・才女もいて、バラエティに富んでいるように見受けられます。‥‥私の周りがたまたま‥‥なのかな? 自己の感覚に準ずる一方で、思考を巡らす習慣を持つ‥‥というか。‥‥でもまあ、世の「ゆとり世代は」と嘆きたがるオジさんたちから見れば、行動パターン要素の「配列順」が気に入らないのかもしれませんけどネ。若い人間が現アニメ業界から学ぶべき「しきたり」は沢山ありますが、30年前の構造を絶対的だと信じ込む必要はないですし、「泳がされた世代」なのが反ってThink differentの可能性を秘めているようにも思うのですヨ。業界のシステムの非合理(昔は合理だったかも知れないけど)を純粋かつクールに観察できるのは、セル用紙やフィルムから遠い人間かも知れませんネ。


calendar

S M T W T F S
 123456
78910111213
14151617181920
21222324252627
282930    
<< April 2019 >>

selected entries

categories

archives

profile

search this site.

others

mobile

qrcode

powered

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