■ 不可逆圧縮のエンコード

　動画を作る場合、それが実写にしてもCGにしても、元の

ソースのビットレートは巨大なモノになる為、これが最終

出力のメディアに記録されるものと同じレベルの圧縮され

ることはありません。つまり、BDレコーダーに録画されて

いる放送やBlu-Rayなどのメディアで記録されているモノは

相当圧縮された状態なので、制作前のソースとは別物です。

 

　ただし、こうした書き出しを行う物にしてもマスタリグ段

階で仕様に合わせて出すにしても然るべきビットレートが存

在しています。

 

　例えば、MPEG-4 AVC/H.264でフルHDの動画を出すとし

た場合、17Mbps以上が妥当で、24～28Mbpsで出すと綺麗に

感じるはずです。当然、現状における100Mbps以上のソース

でそれまで落とすと言う条件ですが、結果的に、元のソース

が高品位であっても、圧縮公邸で劣化はします。

 

　そうなると、ビットレートは品質に見合わない状態と言う

のは、処理が出来た内に入らないと言う事になります。と言う

のも【　画質の伴わないエンコード処理と言うのはただのベン

チマークテストでしかない　】ので、映像制作でない以前に、

ファイルの圧縮や第ルの整理ですらない訳です。

 

　とりあえず、同一コーディックで4Kを想定すると、やはり、

この条件から75Mbps～100Mbpsが妥当と言う事になりますが

コーディックの圧縮率が高く品質も担保される場合には、内容

が異なります。

 

　現状のコンシューマのソースだと、2160/30pですから、コレ

を前提に考えると、8bit/4:2:0のそれを100Mbpsで圧縮すると

言う考え方になります。現在はMPEG-H HEVC/H.265があるの

で、圧縮率でいうと、55%位削減してくれます。

 

　つまり、同一ソースの場合、45GB位まで圧縮できるわけです

が、Ultra HD Blu-Rayは100Mbpsです。この理由は、

 

　■　色深度が倍

　■　フレームレートが倍

 

と4倍くらい違うので50Mbpsの4Kを想定した場合で同じような

状態の圧縮をしてるようなイメージになりそうです。ただし、音

声コーディックが高圧縮になるので音声部分での優位性はあるよ

うですが【　10bit/4:2:0の2160/60pだと100Mbps位になる　】

というのが現状の考え方になります。つまり、これ以下で考えて

もHEVCの50~75Mbps位になります。

 

　では、8Kだとどうだろうか？と言う事になりますが、この場

合、誰がどう考えて見ても、400Mbps以上のHEVCになります。

 

　とりあえず、これに対してピークレートを1Gbps位に指定し

て調整し、最低のレートもあまり下げない感じになりそうです

が、VBRで処理（これは、動きの差のないフレームは間引いて

圧縮するので容量が小さくなる方式です。）するわけですが、

こうして見てもらうと、解像度に比例してビットレートは高い

のが当たり前になっています。

 

　こうした内容ですが、実写のようにビットレートが高くな

りやすい素材（これはロスレスを使った場合の圧縮率の差で

出てきます。Lagrithなどを使うとアニメーションやセルシ

ェーダーやトゥーンシェーダーやペンシルなどのシェーダー

だと1/3以下まで圧縮できるのですが、実写だとあまり圧縮

できません。つまり、映像においての平面的かつ変化のない

部分が少ないものほど高圧縮にあり、ディテールの変化が多

いものほど圧縮率は低くなるため、容量が増える訳です。）

の場合だと、ビットレートを下げても大丈夫と言う条件は存

在しません。と言うよりも映像品質が悪化するだけなので、

品質の出ない無駄なエンコード作業と言う事になりますから、

その選択が存在しないわけです。

　

　その為、エンコード及びレンダリング時間を考える場合に

おいて【　何がどの程度の速度で書き出せているのか？　】

は重要で、【　ロスレスみたいに品質が落ちない物ならい

ざ知らず、ビットレートの指定をする必要があるロッシー

のエンコードだと、当たり前のビットレートや設定がなさ

れていない場合、速度の判断には至らない　】と言えます。

 

　ちなみに、MikuMikuDanceでの8Kの書き出しは非圧縮

で1フレームが3-4秒で、Blenderで読み込んだ後にVSEで

ストリップを配置してレンダリングをするのにHuffYUVや

MPEG-4 AVC/H.264のロスレスで1フレーム4秒位で終わ

るといのは【　ロスレスなので品質の担保が出来てる内容

　】ですから、まかり間違っても【　8MbpsとかのHDで

すら破たんしそうなビットレートで8Kの書き出しをしてい

るわけではない　】ので当たり前の書き出しの話になりま

す。

 

　結果的に動画や音楽を汎用性のある軽い物にエンコード

する場合、【　最終出力結果の品質ありきの話　】なので

【　エンコード時間を計測するのが目的ではない　】ため、

然るべき縁故ーｄの設定が必要になるのですが、この辺り

からずれると、無知にも届かない間違いに至るので注意が

必要です。

 

　現状でいうと、

 

【　個人の用意できそうな8Kのソース　】

 

　■　4000万画素クラスのDSLR製品のRAW

　　　(14bit RGB/Adobe RGB)

 

　■　4000万画素クラスのDSLR製品のJPEG

　　　(8bit RGB/sRGB)

 

　■　MikuMikuDanceの非圧縮AVIでの書き出し

　　　（8bit RGB/sRGB）

 

　■　BlenderでのGLレンダリング＠Open-EXR

　　　（16bit リニア/ACES）

 

ですが、OSSでもOpen-EXRを使えるソフトが多いので、A

CESサポートか否かの問題はありますが、シーケンシャルと

8bitRGBでの動画の書き出しについては8K以上のモノを作る

事が可能になっています。

 

　とりあえず、そのマスターが出来上がった状態で8Kでの

エンコードをする場合、YouTubeや他のサービスのように

 

【　アップロード段階でサーバサイドでのエンコードが

　　入るような仕様　】

 

だと、ロスレスの一択になりますが、個人が所有して利用

する場合だと、汎用性を持たせて家電で利用する場合だと

メディアやハードウェアでサポートしているプロファイル

やLevelなどの仕様に合わせた設定にしておく必要があり、

然るべき仕様で調整する事になります。

 

　そうした場合、異様に低いビットレートでのエンコード

の設定と言うのは存在しなくなるので、然るべきビットレ

ートを選択する事になります。

 

　MikuMikuDance＝＞BlenderのVSEは個人的にお勧め

なんですが、この作業で作れる映像ソースは

 

　【　8bitRGBのRGBの色空間のソースを元にして

　　　作ったロスレスなど　】

 

なので、本来のSHVの色空間の広さや色数はありません。

 

　ちなみに、ネイティブな8K SHVですが、

 

　■　7680x4320/120F

　■　MPEG-H HEVC/H.264

　■　HDR対応（放送はHybridGammaになるっぽい）

　■　10bitカラー

　■　22.2chのサラウンド（3層の高さの異なるサラウンド）

 

ですから、こうしたモノとは少し違う物になります。また、

HDRなので、14stop以上のダイナミックレンジでの撮影ソー

スを使う事になるので、8bitRGBだとやはり階調が足りませ

んから映像ソースとしては異なります。

 

　ある種、ダイナミックレンジでいうと、14bit DNG相当の

14bit RAWのシーケンシャルが色空間が異なる物のダイナ

ミックレンジが担保されたものとして利用できるため、個人

でもHDR書き出しが可能なソフトがあれば対応できるのです

が、エンコードを行う場合には、解像度だけでなくHDRやカ

ラービット数やフレームレートなどが増加すれば、必要とな

るビットレートも当然のように増加するため、エンコード時

のビットレートは、ロッシーを使った出力においても高くなる

傾向があります。

 

　ちなみに、作業段階で中間ファイルを作成する場合におい

てProRESやAvidや別の形式を出す場合がありますが、これ

は、個人が動画を8bit環境でいじる場合に、LagrithやAVCの

ロスレスやHuffYUVを使うのと同じです。つまり、MAC環

境でのProRESやWINDOWS環境でEDIUSを使った場合の

GlassValley HQXのようなイメージです。

 

　これは、作業段階で結構高いビットレートの物に置き換え

て作業しているので、ビットレートの低い物に置き換えるよ

うな作業とは全く違います。（というか、CDのリッピング

レベルの内容と、こうした作業工程は全く違います。また、

ただの作業工程の一部でしかありません。）

 

　とりあえず、8Kを作る場合には8bit RGBのソースですら

非圧縮で出すとストレージ区画が8TB位あったほうが安心で

きると言う状態なので、そういう代物なんですが、最終的に

エンコードを行う場合でも8KだとHEVCを使っても容量が

巨大になる傾向があります。

 

　MikuMikuDanceやアニメーションなどだと容量が小さ

くなりますが10bitの非圧縮や14bitや16bitのDNGベース

となると、この比ではないですから、実際のSHVの映像の

場合は、そういう作業ですから、コンシューマのそれとは

別物になります。

 

　エンコード段階でエンコードスピードについての記述が

ある場合、ビットレートがどの辺りで映像に見合ったレー

トでの処理なのかを見て判断すると間違う事がないと思い

ます。

 

　とりあえず、8Kに関しては、解像度だけでいうと個人

でも作る選択肢が出ている（VRや360°のコンテンツもそ

うですが）のですが、そうした場合の映像のビットレート

はロッシーでの書き出しをする場合だと150Mbps以上に

なります。

 

 

■ 3DCGでの8K

　現在は、3DCGツールも8K以上で書き出せるものが存在

しており、画像ではなく動画でそうした選択が存在してい

ます。10年前だとパノラマ写真の解像度だったそれも既に

動画の解像度で来年には放送が始まるのですから、10年ひ

と昔と言いますが、時代に取り残されて情弱をしてると、

現実とどんどん乖離していくことになります。

 

　さて、3DCGツールでのこうした解像度ですが、元から

印刷を前提にした高解像度の選択は存在したため、4Kや8K

を画像として考えた場合にはその出力に対応したモノはあり

ました。

　

　その為、解像度がソレに満たない出力だったと言う内容は

平面も3Dも存在していませんから、CGに関してはそれに対応

しているわけです。

 

---

個人が使える物なのか？

---

　以前、アメブロで掻いた通り、

 

【　サイレンスだと64bit版のMikuMikuDanceで書き出し可能　】

 

と言うのを書いた通り、書き出しは出来ます。あと、こうした

出力については、BlenderレンダーやGLレンダーによる書き出

しもできますから、出力環境は複数あります。

 

　現状だと、MikuMikuDanceやBlenderは個人が使いやすい物

ですから、コストの敷居もなく、ソフトを使う事が出来ます。

 

　その為、動画の書き出しと制作においては、ソフトが存在し

ているわけです。

 

　ただし、モデリングで8K品質を想定した場合どんなことをしな

くてはならないだろうか？まで考えると少しない世が変わってき

ます。

 

---

パストレはGPUを使っても8Kは重たい

---

 

　まぁ、解像度が上がれば当たり前の話なんですが、レンダリン

グ時間は8Kは極端に長くなります。その為、重たくなる要素が入

ると劇的に重たくなります。あと、アップスケーリング系のレン

ダリングをしてみたのですが、これも、絶望的な重さがありまし

た。その為、そういう重さがあると言う事を前提にしたほうが

いいです。

 

　こうして考えると、

 

　■　Blender Render+コンポジション

　■　GPUレンダリング

　■　落ちない場合は、MMD+シェーダー

 

と言う選択が個人の手持ちのマシンの場合だと選択肢として残

るような気がします。

 

　とりあえず、VSEを使ってみた感じだと、Core i5 650だと

8Kは絶望的だったので、厳しい気がしました。

 

　その為、遅いマシンだとこれは無理と言う事だけ付け加えて

おきます。あと、基本的に4K以上の解像度の作業は64bitアー

キテクチャでの話になるので、32bitアーキテクチャでは色々

と厳しい事にも言及しておきます。

 

---

モデル＆テクスチャー

---

 

　基本的に、LODで遠くのものをリダクションすれば軽くなる

のですが、カット割りで間引けない物もあります。その代表例

が【　CU　】【　BS　】【　WS　】辺りのよりです。

 

　これは、被写体が何であってもそうなんですが、マクロ撮影

の時のディテール感が必要になるので、当然のようにテクス

チャーはデフューズ・ノーマル・ルミナンス・スペキュラーな

どを用いて、多層で構造する必要が出てきます。

 

　基本的に、

 

 　■　テクスチャー　：　模型の塗装

　■　マテリアル　　　：　模型の材質

 

と言う認識をすれば解りやすいと思うのですが、マテリルで

材質の質感を決めて、それにどういう形で塗装が来ているの

か？を考える（と言っても透過処理とかがあったり、ディス

プレイスメントやノーマルマップのようなパテでの処理のよ

うなのもあるので一概に塗装とは言いかねる部分もあります

が）わけですが、この時に使うモデルのポリゴン数も多くな

るのと、テクスチャーサイズも寄りの場合は解像度の高い物

を使う事になります。

 

　そうした内容から、

 

【　シーン内のそうポリゴン数が嵩む　】

 

と言う問題が出てきます。その為、そうした処理が可能な環

境を用意する必要が出てきます。

 

---

基本的には

---

　

　■　動画のレンダリング

　　　複数台のマシンがある場合、それぞれのシーンを個別に

　　　レンダリングしたほうが速度が稼げる

 

　■　画像の場合

　　　分割レンダリングと言う概念が存在しない場合、ネッ

　　　トワークレンダリングを行ってリソースを増やす

 

と言う条件になりますが、あまりにも単独でムリな場合には、

後者で処理する事になります。

 

　解像度が上がると、フォトリアルにするほどに処理が重く

なるので、どうやって、その辺りを品質を落とさず、処理を

軽くするか？を考える必要が出てきます。

 

---

背景抜きでやってみたらきつかった内容

---

 

　まぁ、書き出せることが解ったら、試す訳ですが、従来

のフルHDの書き出しでも重くなる処理はやはり厳しい物が

ありました。

 

　その代表例が　【　ダイナミクス　】　です。

 

剛体は既に軽い部類なので、複雑な動きをするものだと話

は別なんですが、

 

　■　ソフトボディー

　■　クロスシミュレーション

　■　流体力学系

 

は絶望的な重さがありました。あれは素材として書き出し

ておいて合成したほうがいいのではないだろうか？と感じ

るレベルです。（とりあえず、ルミナンス合成用の素材辺

りで）

 

　次に、パーティクルですが、これも群衆のように動かす

とたまらない状態になったので、環境が弱いのもあります

が【　シーンと混ざると恐ろしい重さになる　】と言う特

性があります。その為、この辺りも使う場合にはどう処理

するか？を考える必要が出てきます。

 

　とりあえず、8Kでノードエディタを使って、素材の合成

をして平気な場合は大丈夫なんですが、それが厳しい場合

 

　【　その処理を内部でどうにかしておく必要性が

　　　出てくる　】

 

ので、マシンスペックが低いと、単独でのレンダリングで

厳しくコンポジションではさらに厳しくなる場合があります。

 

　その為、【　性能によって出来る事が変わってくる　】の

でその辺りの確認は必要になります。

 

---

 

　とりあえず、GLレンダリングで処理できた場合、レンダリ

ング時間を稼げるので動画をの出力も意外と選択肢に入って

くる訳ですが、GLSL+テクスチャー表示での出力と言うの

はBGEと似たような状態になるので、ゲーム機のHLSLのシ

ェーディングよりも品質は下になります。ただ、通常のレン

ダリングのように反射が使えないので、BGE的なアプローチ

でシーン構築をする必要が出てきます。

 

　ちなみみに、BGEのMirror.pyはビデオテックスチャーを

使った応用ですから、テクスチャーで対応すれば出来る物の、

現実的なそれの配置はGLレンダリングでは無理と言う事にな

ります。

 

　その為、ディテール確認用の出力などでは効果を発揮しま

すが、品質確認用では使えません。とりあえず、パーティク

ルなどは出せるので、Blenderレンダーのマテリアル指定で

GLSL対応のものだと利用可能と言う感じになります。

 

　この辺りは、マテリアルベースなのかテクスチャーベー

スなのかで変わってきますがBGE同様にテクスチャーの適

応にはUV展開が必要でテクスチャーも通常のプリレンダリ

ングの時のように認識されていない状態ｄも絵それが出る

と言うようなものではないので、ちゃんとファイルとして

書き出して読ませるようにする必要があります。

 

　とりあえず、シェーディングで考えるとBlenderレンダー

のほうがまだ選択肢が多いのですが、シェーディングによっ

てはGLレンダリングも使えなくもないです。ただし、あま

りしっかりとした表現は無理なので、テクスチャーで対応し

ていくことになります。

 

---

結果的に

---

　当たり前のモノを当たり前の品質で作るとなると4Kでも個

人向けのPC（特に一体型デスクとトップとかスレートとか）だ

と難しいのですが、レンダリングを長時間行うことが前提にな

るので、デスクトップ構成のように放熱対策がしやすいマシン

のほうがそうした作業には向きます。

 

 

　タブレット型の末尾がUのBGEなプロセッサの構成ですが、こ

れについては素材制作は問題ない物の、レンダリングとシーン構

築ではやはり不安を感じるので、すべての作業が出来る物として

の選択肢には入りません。

 

　処理能力があったとしても長時間その負荷をかける条件で安

全だろうか？と考えると、やはり厳しい物はいくつかあるので、

用途によって構成が変わってきます。

 

---

とりあえず...。

---

　MMDだとシーン構築とモーションファイルとキャラモデルを

用意いて、それを動かすと言うのは即座にできる訳ですが、ソレ

を行ってみて、ソフトが落ちない処理や、ちゃんと動画が書き出

せるレベルがどこか？を探る必要はあります。

 

　Beldnerのレンダリングについては、TreeGeneratorで森を

作ってみて、どんな感じで処理が出来るか？やｐモーション付

きのハイポリモデルを用意して挙動を確認するなどしてみると

所有したPCでの作業の上限と、そのポリゴン数やレンダリング

時間を考慮した映像のアプローチは見えてくると思います。

 

 

 

 

 

 

 

 

 

 

■ 8Kの表示など

　8KのモニターがDELLから出るようなので、いよいよ8Kも

個人で表示できる時代になりそうです。とりあえず、この選

択にモニターが登場したので、ベゼルレスで8Kが出る環境が

登場することになります。

 

　もともと、8Kの選択と言うのは、コンシューマでも可能で、

HDMI 1.4a時代には、3480x2160/30MHzは出ていましたか

ら、HDMIを4系統か、もしくはその時期のDisplayPortを使う

と30MHzのそれを出せる状態にあったわけです。つまり、この

時に【　4Kモニターx4の選択が必要　】なので、

 

　■　4k映像を4ストリーム同時再生できる

　　　処理能力を持つマシン　

 

　■　複数の出力に対応したＧＰＵ

　■　処理能力の高いＧＰＵ

 

と言う条件が存在すれば、可能だったわけです。

 

　ある意味、1つのGPUで2ストリームの2160/60pの処理が可

能であれば、2GPUでその処理が可能なので表示を各2系統づつ

用意すれば、4320/60ｐの動画の処理が出来なくもないと言う

話になります。つまり、ストリーミングのさせ方の話になりま

すが、理屈的にはそうなります。

 

　表示については、DP1.2を8系統でMSTの4Kモニターx4なの

で8Kになるのですが、モニターアームで固定して8Kにする感じ

になりますが、NVIDIAのMOZICなどで統合して8K出力と言う

流れになります。

 

　こうした出力も、4Kプロジェクターで色合わせをして、4Kx4

で出すと言う方法はパネル出力と作業的には同じですから、プロ

ジェクションについては、GPUの処理能力と出力系統数の分だけ

解像度を高くすることが可能で、8K以上の選択肢も存在していま

したが、動画を再生するとなるとコーディックの問題があるので、

そうしたモノは特殊な処理になる傾向がありました。

　

　また、8Kの場合、非圧縮にしてもロスレスを使うとしても、

転送レートが凄まじいことになるのでそうした点でHEVCのよ

うにはいかないのでその点も難し部分があったと言えます。

 

　ただ、表示に関して8K以上の選択肢というのは、プロジェク

ションとマルチモニターソリューションと言う条件でいえば、

存在したことになります。

 

---

動画として考えた場合の処理の重さ

---

 

　多分多くの人が体験してるはずなんですが、YouTubeの動

画を、解像度の低いモニターでフルHDや4Kで再生した場合に

は大丈夫だけど、4Kパネルで再生してみたら重くてひどいこと

になったなどがあるはずです。つまり、解像度が高くなると、

処理が全く違うので、消費するリソースも増えます。その為、

再生支援のない環境での動画再生では無理が来ます。

 

　こうした内容は、フルHDで4K動画を見た場合には大丈夫

だったのが、4Kにしたら無理が来たとかと同じように、8Kも

ネイティブ８K再生環境にするといきなり恐ろしいリソースが

必要になります。

 

　これが、コンシューマの8bitソースでも発生する内容なので

そこは注意が必要な訳ですが、環境構築時に注意したい点とも

いえます。

 

　こうした部分が未知数だったのが過去の状態で、それが業務

用ソリューション臣でコンシューマのGPU出は関係なかったの

が過去の話になるのですが、今後はそれをテストできるパネル

が発売される（一般向けの30インチの8Kディスプレイ）ので

そうしたテストも可能になります。

 

　その為、こうしたものは水死用環境がどの辺りになるのか？

も注視したい部分ですが、動画についてはYouTubeに既に、8K

の動画が存在するので、それの再生辺りから確認できるように

なってくるようには思います。

　

　ただし、こうしたソースはアップした動画を再生するよりも

それ用の動画を制作するのほうがリソースの消費は高いので、

そうした情報もそろって出てくることになると思います。

 

　基本的に、そうした条件が存在するので、環境構築の場合、

ハードのスペックも注視しないと8Kは厳しいと言えそうです。

 

---

メモリーとストレージ

---

 

　動画の場合、GPU・メモリー・ストレージのパフォーマンス

が高くないとダメなんですが、制作時にはRAMプレビューの関

係から大容量メモリー環境が必要になります。GPUは動画再生

支援とプレビュー時のアクセラレーションになるのですが、こ

うした保持がない場合、制作しているモノの際背が難しくなり

ます。

 

　こうした場合、プロキシをストレージ内のあらかじめ制作し

てそれを参照して差処理するとか、合成がある場合には部分レ

ンダリングをして軽くするなどの手法がありますが、やはり、

こうした処理もCUDAコア数やメモリー実装量の多さGPUの

性能あっての話になります。

 

　その為、この辺りは大抵は注視すべき内容として挙げあら

れています。現在、ストレージについてはあまり触れられて

いませんが、8Kを使う場合、8bitの非圧縮であっても4Kの

業務用ソースと大差のない重さになりますから、コンシュー

マのCG素材とかを使う場合でもこの場合には、そうしたソ

リューションでの作業と同様のスペックを用意したほうが

よくなります。

 

　そうした場合、ストレージの選択も、NVMeのSSDでス

トレージ容量も大容量のモノを選ぶ事になります。

 

　こうした内容から、8Kの場合、マシンスペック自体が高く

なるという傾向はあるのですが、8bitカラーの作業でもそう

なります。

 

 

---

とりあえず

---

 

　再生環境がコンシューマに降りて吐きますが、ハードの敷居は

高くなるのでそこに注意が必要が、表示に関しては複数の選択肢

が存在しています。

 

 

■ 8K

　コンシューマでも8Kの解像度は扱えるようになってい

ますが、現状においての選択肢は限定されています。

 

　そこで、アップスケーリングしたエンコードと言うの

はなしにして、8K以上の解像度のソースで何かを作る

と言う当たり前の事での内容に触れておこうかなと思い

ます。

 

---

基本的に環境構築をすると恐ろしいことに

---

 

　これに関しては、8K表示がないと言う問題があります

が、度解像度がそれを満たしてる製品は今春、DELLから

国内向けに8Kモニターのリリースが発表されるようです

から、アマゾンや小売店でも購入できる世になるかもし

れませんが、基本的に、8Kで見ると言う選択肢は出て

きます。

 

　この場合、Thunderbolt3x4とかになるのかなど、接

続がどうなるのか？も気になるところですが、今後は、

DPのポートを複数消費するような8K出力の選択肢が出

てくるわけです。

 

　そうなると、コンシューマのボードでもハイクラスの

選択になるので、フルHD時代の4Kがほとんど見かけな

い時期のそれと同じようなレベルで表示をする流れにな

りそうです。

 

　まぁ、HDMI 2.0を2系統包含しているのが、USB 3.１

のType-Cなので、二系統なのかな？と言う気もしなくも

ないのですが、ネイティブなSHVだと120Pとなると4系に

なりそうですが、とりあえず、8Kの解像度でバレの問題

は解消できそうです。

 

　しかし、問題なのはここからで、これを表示すると劇

的に重たいので、GPUの性能も上位に限定される状態があ

り、現状では、4KのHEVCはアクセラレーションが存在す

るものの、8Kは存在しない為、今後はそうした流れも包含

されるのかもしれません。

 

　とりああえず、今年から、8Kに関しては、コンシューマ

でも【　表示可能なモノ　】になるので、制作においても

【　ネイティブな8Kで表示して確認する　】と言う事がで

きるようになります。というよりも、こういうパネルが出

てくると確実に、高画素政策をしたモノクロのアナグリフ

を見てもらいたいのですが、

 

【　ディテールの多い物を撮影して作った場合、3Dの

　　印象が変わる　】

 

レベルで別世界のが底に存在しています。カラーアナグリ

フの場合、色の干渉の問題があるので、モノクロにして色

彩情報による干渉を回避したほうがっ立体感への影響がな

いので解像度における恩恵を考えると、そうしたほうが便

利なですが、4Kパネルもそうですが、8Kの解像度は中判

のそれ（まぁ、この分野は1億画素を超えているので、写

真が表示機材の解像度を上回ると言うのはいつもの事です

から、中判と言うくくりは少し前の話になります。）です

から別世界なのは言うまでもありません。

 

　ただ、8Kで作って8Kで表示するという選択肢が存在し

ているので、そうした事が可能になったと言えます。

 

---

コンシューマの機材で作る8K

---

　とりあえず、3DCGについては、次回の話にしておく

として、コンシューマでも8K以上の解像度で作業する

事は可能なので、選択肢がないわけでもありません。

 

　こうした場合、シーケンシャルを使う事になるので、

手法としては、セルアニメの登場する前のアニメーシ

ョンの手法やジョルジュ・メリエスやエジソンの時代の

特撮のような手法で制作すると8Kの解像度での撮影は

可能になります。

 

　基本的にアニメーションの原点はモデルアニメ系で、

これと特撮があさった作品と言うのは20世紀に存在して

いますから、アニメと特撮というのが源流においては、

接点があります。

 

　そうした、アニメーションの基本は、

 

【　連続した画像が存在しそれが挙動を記録している事　】

 

なのですが、フィルムでコマを3フレームづつ刻むので、

こうした撮影を【　コマ撮り　】と言いますが、ストップ

モーションアニメの場合8fpsなのは、フィルム時代の名残

で24Fのそれを3コマづつ撮影するので8fpsで、12fpsとい

うのはこの撮影時の1コマを２フレームで記録している状態

になります。

　

　24コマでモーションを付ける方法もあるのですが、コマ

の数が増えると中割りが増えるので、作業が膨大になるた

め12か8で作るのがスタンダードです。

 

　とりあえず、現在においては、コマ撮りに関しては、4K

だとカメラの実装機能で撮影可能になっているので、当たり

前にJPEG合成ですが、それを撮る事が可能になっていますが、

この機能がコンシューマのデジカメ辺りでも実装されている

ので、こうした撮影手法も特別なモノではなく個人が気軽に

楽しめるものになっています。まぁ、スマホアプリでもそう

したモノはあるので、撮ろうと思えばスマホを持ってるだけ

で撮れるわけですが、現状において8Kの解像度を超えている

製品が複数あるのでそれを使うと、そうした撮影が可能に

なっています。

 

　とりあえず、

 

　■　645Z

　■　α7RII

　■　α99II

　■　EOS 5Ds

 

などがそれで、1億画素を超えている中判だと当たり前にそう

した手法の撮影が可能です。

 

　JPEGだと、SIGMAのDPシリーズでそれが可能なんですが、

ストップモーションアニメの場合だと、内部合成系の処理でも

大丈夫なので、OM-D EM-5 mkIIの64M RAW（要：現像）と

かを使うと、8Kの解像度は得られます。

 

　企保ｔ根機にカメラで撮影する場合、

 

　■　14bitのネイティブRGB

　■　Adobe RGB

 

での記録が可能なので（非圧縮とロスレスがある）基本的に、

撮影後のソースでは、そうした色調のモノを使える状態になり

ます。つまり、8bit/4:2:0のsRGBよりも階調は広い状態で

記録できるわけです。

 

　ただし、コストはやはりそうレ相応にかかってしまうので、

4Kのようにはいかない部分はあります。

 

　とりあえず、シーケンシャルを持ち帰る選択肢ではそうした

モノが存在しているわけです。

 

---

ワンショットと合成の違い

---

 

　とりあえず、DPシリーズや4000万画素オーバーのワンシ

ョットで8Kにできる製品だと、これの場合、動体が混ざって

も問題がないので、

 

　■　風景の撮影（タイムラプス）

　■　欲しの撮影（スターストリーム）

　■　星空のインターバル撮影（赤道地球儀を使った物）

 

が可能になります。つまり、選択肢が多くなります。また、

是が不置いている場合でもブラケットがない状態で撮影が

可能な場合だと大丈夫なので、屋外の植物でインターバル

撮影をするなどの条件でも優位性が出てきます。

 

　つまり、ワンショットでなければ増がぶれるので無理な

撮影だと向かない撮影が福栖あります。こうした撮影は実

際の映像制作でも使われており、シーンでそういうのが入

る物もありますが、時間お流れを早く進める手法は基本的

にコマ撮りです。

 

 　そうした内容から、解像度が高くなればそれが可能と言

う条件ですから、こうした撮影手法はカメラの解像度が高く

なればおのずと行えるようになると言う訳です。

 

　こうした場合に、明るい大口径の単焦点レンズを使うと

描写がよくなるので、レンズにも気を配って撮影する事に

なります。 

 

　ちなみに、動画ではないので、写真用のレンズで撮るの

がこうした手法になります。

 

---

撮影段階で注意が必要になる事

---

 

　8Kになると、解像度が高くなるので、当ｚ根のようにディ

テールの粗さが存在した場合それがそのまま出てしまいます。

 

　その為、ストップモーションアニメをする場合、解像度と

フレーム内に配置したモノの品質は比例するので、カメラで

撮影する機材のを性能を上げると、当たり前のようにフレー

ムの中に存在する、構造物の品質も上げないと無理が来ると

言えます。とりあえず、フルHDの16倍ですからそうした品

質のモノを用意する必要が出てきます。

 

　そうなると、ストップモーションアニメをする場合でも、

ディテールの追及が必要になるので、結果的に機材ではな

く制作するシーンやセットのコストが高くなると言う問題

が出てきます。

 

　こういうのは物を作ると当たり前に出てくる内容ですが、

そうした事も当然のように発生してきます。

 

　その為、動画＝カメラと言う認識しかない場合、実写で何

かをを作る場合、大半コストが抜け落ちているので、そうし

た

 

【　ファインダーをのぞいた時に見えるカメラの向こう

　　側にあるフレーム内の構造物のコスト　】

 

は当然のように発生するわけです。

 

　自然や景観のタイムラプスやスターストリームの場合、

赤道儀や自動雲台などを使う事がありますが、これは、

被写体のコストがかからないとしても撮影時間は恐ろ

しくかかります。

 

　まぁ、インターバル撮影と言うのは、現在はスマホの

カメラアプリでも可能になっていますから、当たり前に

取ることがどういう物かの理解はできるいい時代になっ

ていますが、実質的に、

 

　■　シャッタースピード

　■　インターバルの間隔

　■　枚数

 

の設定はします。つまり、インターバルの間隔の中に露

光時間は包含されるので

 

　【　インターバルの間隔ｘ枚数　】

 

ほど時間がかかります。そして、制作が24Fなのか、60P

なのかで全く違う訳ですが、星のように露光時間が1分とか

かかるようなものだと、1秒の映像制作用の24コマの撮影で

24分。1分の尺だと24時間の撮影時間が必要になります。

 

　インターバルを1分入れて2分にした場合、48時間の撮影

時間を要するというわけです。

 

　完全に色彩情報が抜け落ちたスターストリームの場合だと、

デジカメでもできますが、あれは秒数を短くすると色彩情報

が抜け落ちるので、少し長めにする感じになりますが、それ

でも48時間まではいきませんが、数時間の撮影をすることに

なります。

 

　つまり、インターバル撮影の場合、その場所に滞在する時

間のほうが長くなるので、そういう撮影手法になるわけです。

つまり、そのカットを難病撮って、シーン全体でどれくらい

その手法で使うかで撮影プランが全く変わって来る訳ですが、

そうした撮影の手法も選択肢として存在しています。

 

　天の川を入れてタイムラプスをするとかになると構図もそう

なんですが、どの時期のそれなのか？も包含されてきます。

 

 そうなると、機材の選択はある程度決まってきます。

 

---

8K対応ソフト

---

　基本的に動画の書き出しの上限と読み込める画像のサイズは

全く違うので、現状において8Kの写真が読めないソフトは皆無

と言っていいです。

 

　と言うのもPowerDirector 14 Ultraは4K書き出しまでですが、

MikuMikuDanceで書き出した8Kのサイレンスは読めましたから

動画と画像の双方でそれに対応していると言えます。

 

　ただし...。基本的にRAWでのとなると、業務用ソフトを使っ

たほうがいいのは確かです。というのもRAWが読めるのと読め

ないのでは大違いだからです。

 

　基本的に、RAWの読み込みと8Kが大丈夫なソフトだと、

Blenderもそうなんですが、一旦oPen EXRとかで書き出さな

いとファイル形式で影響が出る場合もあります。そうなると、

 

【　現像して、最適なモノで書き出して、それをシーケ

　　ンシャルで読み込む　】

 

というのが、コンシューマでのソフトの作業になりそうです。

 

　以前、アメブロで書きましたが、

 

　【　きしめん＠サイレンスを出してみたら

　　　　怒涛の90GBになった　】

 

と書いたように

 

【　8Kは容量とストレージの転送速度を要する作業になる　】

 

ので、環境によっては、JPEGとかで作業しないと無理が来るの

で現像で色が劣化しない状態でで書き出してそれを行う事にな

ります。

 

---

古い環境ではどうなのか？

---

 

　とりあえず、Core i5 650/8GB/Quadro K620/SATA HDD

の環境ですが、この環境では、8K再生が出来ません。ｗ

 

　あと、動画のレンダリングをBlenderで行うとすると無理が

来ます。ペガシスのソフトの体験版はまだ使っていないので、

アレで作業した場合は度な感じなのかも謎ですが、Core MA

よりは新しい初期のCore i5の廉価版では全く無理な作業だと

言えます。というのもプレビューが出来ませんから。

 

　しかも4K未満の表示でそんな状態ですから、基本的にアー

キテクチャが古いだけ得作業になりません。ｗ

 

　と言うよりも、コンシューマの4K動画＠100Mbpsのトラッ

キングで無理なので、UHDもできる事と出来ない事がある為、

環境を選ぶ感じです。

 

　とりあえず、コストで考えると個人が扱うには結構高額にな

る感じがあるので、コンシューマであまり色彩を気にしない人

が4Kを弄りたいけど何かないのか？と言う選択肢で探すレベル

のモノを揃えても、結構すさまじいことになるのですが、撮影

においては、ストップモーションアニメなどのシーケンシャルの

手法を用いた場合にはそれが可能になります。

 

 

■ つぶやき

■　素材制作
現状において、動画のコンポジションについては、実写だ と撮影段階で、グリーンバックを使えば、クロマ合成が可能 となっていますが、背景が実写である場合もそうでない場合も、 これは、 【　カメラの整合性を撮る必要がある　】 ので、同 じカメラアングルで同じ露出で、同じ焦点距離と言う 条件と、 同じカメラワークと言う条件も付きます。 　その為、動きが入る場合には、モーションコントロールカ メラと言うロボットのように挙動を入力してその通りに撮影 できる カメラを使う事になります。これに対して、映像に3 DCGの背 景を合わせてコンポジションをする場合、 〇　映像が背景で3DCGが前面のモノの場合 　　映像のトラッキングを行って、マッチムーブをする 　　　（同じ素材をマーカー入りとマーカーレスで 　　　　撮っておくと便利） 〇　映像が前面の人物で、背景が3DCGのもの 　　カメラが定点だと単なる合成 〇　前述の条件で、カメラワークがあり、視点が 　　変わる物 　　グリーンバック撮影でスクリーンにマーカーを 　　用意しトラッキングを行い、3DCGのシーンを 　　マッチムーブする と言う三種類の撮影方法が存在します。実写と それ以外でも そうした手法が存在するのですが、 当然のように、CG素材が 発生する場合、その素 材の制作が必要になってきます。 　そうした場合に、素材制作ツールの存在が出てくるわけです が、こうしたセットの構築というのも 虚偽の吹聴が過ぎるのが、 酷い間違いを垂れ流しているので誤認をしている人もいます。 　とりあえず、素材と言うのが、何がどういう合成で作られる のか？については、アニメーションとコンポジションの工程で は似たような部分があるので、そこに ついて触れておきます。 　まず、コンポジションですが、マットペイントと言う作業が あります。これは、 　【　背景絵師の描いた絵を使う事　】 なんですが、美術で背景を入れてアニメーションをするのと同 じように立て書き看板のように絵を入れて、それを利用する手 法です。 　大昔の手法で、背景の映像にプロジェク ションで写した映像 を使うと言うやり方が存在したの ですが、あれは、動いている 物を出すための選択肢 がない時代の手法になりますが、動きの ない 遠景だとした場合、これは、ポスターでも問題がないわけ です。当然、出力した写真でもいいのですが、結果的に、 【　看板であっても構わない選択肢　】 になります。 　これは、動きのない背景については、アニメーションでは美 術で固定された風景画を入れますが、それと 同じ手法です。と いうか、実写でもそういう手法があるので、結構共通点はあり ます。 　では、コンポジションだとどうなのか？と言うと、この 場合、 アニメで美術を合成して使うように、写真を入れても大丈夫な 場合だとそれを使います。ただし、デプスと空気間があるので、 そのレイヤーに関しては色調補正で調整する場合もあります。 　これが、移動方向の整合性が取れた動画素材だと、クロマと 同じ状態になり、背景が、あからさまに 違う場合だと、そこに 素材を重ねて、その風景を作ることになります。 　素材を重ねる場合、写真でも大丈夫な条件と言うのは 　■　移動がないコト 　■　カメラワークによる影響がないコト 　■　光源があっている事 などです。人物が遮光で右からの光源なのに、背景 は真逆に光 が差してるとかはダメなので、そうした素材 を使う事は出来ま せん。あと、 【　キャラが歩く場合、その導線上に干渉するような 　　ものを置いてはならない　】 と言う常識的なモノもあります。 　とりあえず、動かないもの配置だと、これは、立て書き看板 と同じなので解像度の違和感がないレベルで画像を使えば対応 できるという事になります。 　しかしキーイングで合成できるものには透過素材が存在する ため、各手法で背景を抜いた素材も合成が出来る訳ですが、3D 空間上のカメラオブジェクトの変異が存在しない平面的な構成 （もしくは、3Dのマッチムーブ素材を透過のシーケンシャルな どで書き出して平面的に 合成するなど）の場合、当然のように モーションの入った動画素材を合成する事が可能です。 　現状においては、フリーウェアでNive2やJavie【要JRE】の ようなレイヤー方式のコンポジットツールがあり、ノード方式 だとBlenderがありますが、こうした処理をする環境という のも特殊では なくなったと言えます。 　このように、映像の素材という物はコンポジションを想定し た場合、実写映像でも写真や透過処理をして背景となじむよう に調整した物を使うので、素 材制作と言うのは、スーパーや テロップのようなグラフィッ ク以外のモノも存在しているわ けです。
■　3Dオブジェクト実写の合成
これも、実写素材と同じなんですが、光源の状態が合っ ている必要がある為、その条件を満たす必要性が出てきます。 これと同時に、 　■　透過 　■　屈折 　■　反射 　■　映り込み などを反映させる必要が生が出てきます。こうした場合に その条件の整合性を撮る手法として、IBLを使います。 　この場合、全天球のパノラマを 　■　色深度の深いRAWを使用 　■　色空間はAdobe RGBのように広い物を使用 　■　ブラケットで階調を多く残すように複数枚撮る と言う必要性が出てきます。ある種、VR映像用のリグに魚 眼レンズの付いた高解像度のカメラを複数実装してシンク ロさせてブラケット撮影するような手法で持ち帰り、それを ステッチしたらよさそうな状態ですが、個人がそんな物々し い物を用意出来る訳がないので、通常 は 　【　魚眼レンズの2視点か、6視点　】 になります。そして、これはステッチしてパノラマ合成を行 いHDRIとして、光源の情報として利用します。 　この手法ですが、PS2のある時代にはゲームで利用されて いるような手法なので、映像でもコンポジションを行う場合 には当然のように存在していた手法になりますが、基本的に 周辺の光源及び全天球の空間の像が存在するため、前述の条 件がすべてクリアできる訳です。 　つまり、10年以上前からそういうのは出来ていたという話 になりますから、基本的にできて当たり前のものだと言えます。 　とりあえず、実写とCGを合わせる場合に、当たり前に環境 の状態に合わせたソレにするとなるとそうした状態になりま すが、 【　映像の場合、逆光だとレフを入れ、暗所だと 　　ライトを入れる　】 ので、それが主題でライティングをどうするかで使い方が 変わるのですが、その環境で撮影した場合の素の素材のよ うな状態だとそうしたモノが得られます。 　つまり、オブジェクト自体はモデリングを行い、リグを当 ててウェイト調整をして、アクションの登録をして必要なモ ーションで動かすことになる訳ですが、光の状態だと、そう したIBLの利用を行うと映り込みや光源の情報なども 得られ ます。 　ただ、円周魚眼の場合、情報量が少なくなるので、 カメラ 自体が高解像度で、6視点で撮るほうがディテー ルが残るの で向いていますが、基本的に、地面と真上の必要ない場合だ と、4視点でカバーする事もできます。 　つまり、CGの素材でも実写と合わせる場合だと、その環境 のライトで合わせる方法もありますから、それに準じた合わせ 方をするとソレにできると言う訳です。 　スタジオのセットで、照明を使って作った場合にはどうしよ うか？と言う内容が出てきますが、カメラの向きで透過がある 場合だと、 バックドロップで背景を入れるか、もしくは、板 ポリゴンで それを用意して対応するだけなので問題がないの ですが、視点が変わる上にライトが必要だと、そのシーンのパ ノラマかライ トボックスなどの素材を作成して適応する事に なります。