「32K の壁」 坂口 裕靖 2K が 4K、そして 8K になったとして、 0.00111mm あたりに 1pixel が可視光を ある。それに、そもそもエンターテイメン HDR 対応とかハイフレームレート対応とい 使う限りの物理的な密度限界ということに トを前提とするのであれば、被写体のスキ った、今までとは違う次元の拡張があるわ なる。今、仮に対角線が 1 インチの 16： ャンとモーションキャプチャ、バーチャル けだけれども、基本である空間解像度につ 9 センサを考えると、横方向のサイズは スタジオ的な組み合わせによって、光学像 いてはスケールアップである。なので、こ 0.8716 インチ、22.138mm である。こ の制限を超える解像度も当然達成可能であ の空間解像度の部分は今後いくらでも増や れを 0.00111 で割ると、19,944.2 と ろう。そこまで手間かけるべきかどうかは していけると思いがちだが、割とそうでも か。つまり、1 インチのセンサでは横 20K 何とも言えないのだが。 なかったりする。 解像度を超えると、オーバーサンプリング というわけで、実写映像が 32K を上回 まず最初に、実在する被写体を可視光線 になってしまう。もちろんこの数字はレン ることは大変難しそうであることが分かっ でスキャンする場合、光源波長によるサン ズ系による解像度の低下とかを無視してい たわけだが、この 32K で 16：9 という解 プリングレートの上限が存在する。仮に Y るのだが、一つの目安であることも確かだ。 像度もなかなかやっかいである。仮に控え 信号に一番近い、G チャンネルについての 36x24mm のフルサイズセンサだとして、 めに考えて、マルチスペクトル方面には進 限界を考えてみると、例えば 555nm の 同様の計算をしてみると 32,432.4 とかで 化しないとしてみよう。その場合、3ch/ 波長の場合、焦点面上のセンサ密度がこの あり、この 32K が一つの壁となるのでは pixel となる。さて、それぞれのチャンネ 倍程度以上の間隔でないと、単にオーバー ないだろうか。もちろん今後レンズを使わ ルが何ビットかだが、仮に HDR を前提に サンプリングしているだけであり、解像 ない光学系も多々出てくるだろうし、そう 考えると、少なくとも浮動小数点フォーマ 度的には意味がない。とすると、555nm いったニューウェーブによって解像度の上 ットである必要があり、その意味では最低 x 2 ＝ 1,110nm ＝ 1.11 μ m ＝ 限が突破されることは大変望ましいことで でも 16bit あたりが落としどころになるだ マイクロフロート 単 精 度 浮 動 小 数 点 数 が 32bit、 倍 精 度 浮 動（ 以 下 略 ） が から 120 まで、32 通り指定できるようになっていた。これが 64bit、4 倍精度（略）が 128bit で、単精度の半分の 16bit 単なる整数じゃなくて、符号ゼロ、指数部 2 ビット、エクセス で表すのが半精度浮動小数点数、 略して half とか binary16 とか。 − 3、仮数部 3 ビットの 5 ビットなマイクロフロートを使って 正の最小値は 5.96x10^-8、正の最大値は 65,504 で、あんま るのがミソ。実際のリピートレートはマイクロフロートの値を り大きな数は表せない代わりに、それなりに小さい数を扱うこと 4 で割った値で、2.0、2.1、2.3 と等比級数っぽい形になって ができる。単精度に比べると消費メモリが半分ですむため、でき いて、大変気がきいてるのであった。同じような考え方をする れば積極的に使っていきたいわけだが、DirectX だと勝手に単精 と、符号ゼロ、指数部 4 ビット、仮数部 4 ビットの 8 ビット浮 度に変換されてしまい、使えなかったりする。OpenCL では使 動小数点で、1 から 507,904 まで表すことができるよ、とい える模様。値域が 0 ∼ 1 とか、− 1 ∼ 1 の係数とかを扱う場合 ったことが http://www.mrob.com/pub/math/floatformats. に固定小数点よりは精度が高いので、大変便利。 html に色々書いてありますな。なんかここいらへんのちまちま こういった 16bit 幅より狭いデータオブジェクトで浮動小数 した浮動小数点数、GPGPU 等々の物量計算関係で、意外と重 点数を表すものを、一般的にミニフロートと呼ぶらしい。そし 要になってきそうな予感があります。してみると、The Art of て、16bit より狭い浮動小数点数オブジェクトのことをマイク Computer Programming の Vol.2 第 4 章に浮動小数点数を割 ロフロートと呼ぶ模様。例えば IBM-PC のキーボードではリピ いてるのはさすがの一言ですな。 ートレートを指定できるのだが、これが 5 ビットのデータで 8 34 FDI・2016・05 ろう。この際アルファは無視して考えると らへんを割り切れば、データの入出力は可 れが 3D 映画でオーバーラップをしようと し て、16bit/channel、3channel/pixel、 能である。windows bmp の場合も縦横各 すると、OL 前後のカットで同じような奥 1920x1080 の 4:4:4 非 圧 縮 画 像 は 約 32bit でサイズを保持している。が、縦方 行き感、視線方向にしておかないと、違和 12MB/frame で あ る。 こ れ が 32K に な 向については「負の数の場合は上下逆」と 感が盛大に発生する。二つの三次元空間が ると、およそ縦横各 16 倍、全体で 256 いう規約があるため、実質的には 1 ビット 融合して違和感を持たせないような空間構 倍 だ か ら、 約 3GB/frame と な る。 ア ル 減って 31bit、2Gpix までしか対応してい 成は大変難しい。うまくいくと空間が溶け ファチャンネルも同様のビット深度が必要 ない、と考えることができる。というわけ るような、なかなか素晴らしい効果を生む だ か ら、 合 成 系 だ と 4GB/frame だ。 こ でサイズの方は大丈夫だが、フォーマット のだが。カットつなぎも同様で、2D 映画 れ、32bit な整数じゃ扱いきれないという 上 32bit/pixel よりビット深度を深くする のつもりでカメラの切り返しを多用すると、 ことですな。無理矢理符号無し整数を使っ ことができないので、単純に半精度小数点 目が（というか、脳が）ついていけなくて てもギリギリで、ちょっとスクロールする の画像を保存することは出来ないだろう。 酔ってしまう。2D の切り返しについてい ような素材はもうアウト。なので、最低で 無理矢理収容するなら、画像上の 1 ピクセ けるのは、空間の再構築作業が必要ない（と も 64bit 整数じゃないといけない。まあ今 ルをファイル上の 2 ピクセルに分割して、 いうか、平面ということで空間部分の認識 時 64bit じゃない OS はほとんどないの 縦なり横なりに展開して保存するしかない。 処理が発生しない）からだ。というわけな で、パソコン界隈では気にする必要もない 処理の都合を考えると横に並べるのが良さ ので、映像ストリームのスケールアップが のだが。それ以前の問題として、最終出力 そうだが、見た目はぐちゃぐちゃになりそ 難しいからという理由で奥行き方向、Z の が 16bit/channel の場合、おそらく途中 うだ。まあ、とりあえずず tiff や OpenEXR 情報を入れることは、テクニカルには可能 の処理は 32bit/channel で進めるんじゃ なら対応できるので、そこまで無理して だろうが運用上は大変難しいのではないだ ないかしら。その場合 16GB/frame であ bmp を使う必要も無いだろう。というわけ ろうか。一方で、ご家庭用カメラはほとん る。現時点のそこらで売られてるパソコン で、少なくとも交換フォーマットについて どが撮って出しなので、Z の付加価値は結 だと、メインメモリを書き潰しても読み込 は、32k どころか 2G ぐらいまでは心配す 構ありそうな気がする。 みきれない。ましてや GPU をや。 る必要がなさそうだ。 いずれにしろカメラフォーマットは素材 さて、空間解像度が高くなっているのだ 空間解像度の上限が 32k で、現在 8k に を左右するため重要だが、一方で出力の方 から、当然時間解像度も高くなっているに 手が届くところにいるとすると、上限まで はネットということになると、そもそもア 違いない。仮に現状と同じ 30fps だとし はあと 2 世代しかないという話になる。こ スペクトすら固定されない状況になるだろ ても、3GB/frame の場合は 90GB/s。こ れ以上空間解像度の変化が難しい場合、今 う。 れが 120fps とかになると、単純に 4 倍 後何を目指すべきなのだろうか？ この世界では 32K だろうが 64K だろ で 360GB/s。まあ中間ファイルを非圧縮 映画が映画として成立するには、演出的 うが、帯域幅が許す限りは表示できるだろ で保存するというのは非現実的かも知れな に自由に時空間を移動できる必要がある。 うし、逆に言えばフォーマットは全く重要 いが、仮に 2 時間の素材を保持するとして これを実現するのがオーバーラップだった ではなくなる。今後の進展がどうなるのか、 2.6PB。現状手軽に手に入るストレージは りカットつなぎだったりするわけだが、実 楽しみである。 たかだか TB クラスなので、これが PB ク はこれが成立するのは「画は画だから重ね ラスになるようでないと、32k の素材をカ ちゃえ」 「コマに変わりないからつなげち ジュアルに扱うのは難しいだろう。という ゃえ」という、演出空間内の物理法則持続 か、そもそもバスのスピードが 3 桁あがっ 性を無視した、天 てくれないと、こんなものまともに扱える 才的なヒラメキが ようにはならないだろう。 あったればこそだ。 ち な み に、PNG の フ ォ ー マ ッ ト 上 は 演出空間上は時空 16bit/channel、4channel/pixel ま で は が重なったり飛ん 許容しているし、画像解像度も 4byte で持 だ り し て る の に、 っているため、縦横各 4G ピクセルまで対 普通の映画でオー 応可能ということになっている。もっとも、 バーラップに違和 ここでいう 16bit/channel はリニアが前 感を感じないのは、 提であるため、半精度浮動小数点を食わせ 見つめているスク ると、多くのビューワで変な見た目になる リ ー ン が 平 面 で、 だろうし、γ補正をしているようなシステ 奥行きがない「画」 ムだとぐちゃぐちゃになりそうだ。そこい だからである。こ Hiroyasu Sakaguchi （株）IMAGICA イメージワークス 祝・創刊 200 号 35 FDI・2016・05
© Copyright 2024 ExpyDoc
