技研公開 2016

去年に引き続き、技研公開 2016に行ってきたのでその感想。

今年は8月から8Kスーパーハイビジョンの試験放送が始まるとあって、やはり主役は8Kだったけど、去年に比べHDR(High Dynamic Range)推しだった気がする。

Giken2016_07.jpg


今年もわかめなみなさんにお会いでき、楽しかったです。ありがとうございます。



ことしも大勢の人が来ていたNHK技研。

Giken2016_01.jpg

Giken2016_02.jpg

やっぱり8K推しなのでした。

劣化の(ほとんど)ない8K映像は、すばらしく高精細なので大画面でもきれいなのと、その高精細感と60Hz/120Hzの高いフレームレートによって、かなり立体感を感じることができてすばらしい。4Kだとこの立体感には限界があって、本当に劣化のない映像を近くで見ないと感じることはできない。

下の写真の映像だと、8Kの高精細さというのを強く感じることができた。fullHD(2K)とかだと、遠くのほうが解像度の不足によってボケてしまうのに対し、8Kでは遠くのほうであっても詳細に描き切ることができ、より自然に見える(肉眼で物を見た感じにより近づく)。

まあ、それ以外にもパネルとしても(あたりまえだけど)とてもよくて、特に黒いところがちゃんと黒く、きれいだった。ああいうのを見るとグレアはやはりいいなと思うし、やっぱりノングレアは買う気が起きない。

Giken2016_03.jpg

次にアピールしていたのがHDR(High Dynamic Range)。いまの画像は輝度のレンジと分解能が限られているので、明るいところや暗いところが完全に同じ色につぶれてしまったりする。でも人間の目は輝度(特に暗いところ)には敏感で、本来もっとよく識別することができるので、映像でもちゃんとこの辺りを表現できるようにして、より自然な映像にしたい、というようなことを高ビット深度化(10bit/12bit)と合わせて実現するのが大雑把に言えばHDRなんだと思う。

実際には8K + HDRに対応したカメラと、そのモニターが展示されていた。

謎の看板。

Giken2016_04.jpg

こちらがそのカメラ。

Giken2016_05.jpg

実際に撮影したものをモニターに表示したり、

Giken2016_06.jpg

HDR映像を流したりしていた。

Giken2016_07.jpg

8K / 疑似120Hz / 12bitとさすがのスペック。HDR対応なのでコントラスト比も非常に高い。ただ、消費電力は1440Wなのでした…。コンセントからとれる電力の限界(15A x 100V = 1500W)に挑戦してますね。暑そう。

Giken2016_08.jpg



HEVCの次世代コーデックを開発中らしい。

Giken2016_09.jpg

基本はHEVCの延長で、ループフィルタの改良、さらなるブロックサイズの大型化(256x256(!))と、イントラ・インター予測をさらに高精度化し、これを積み重ねることで20~30%の圧縮率向上を目指すもの。

DCT系の圧縮方式は、ブロックに切ることでどうしてもブロックノイズが発生しやすいのだけど、これをループフィルターやSAOやらで解決しようとしてきた。x265などではだいぶ圧縮率を高めても極端なブロック状のノイズは見えなくなってきていると思う。結構容量をつぶしても、圧縮後の映像でパッと見で劣化が目立たないのがx265の良いところ。(まあx265がそうなだけでほかのHEVCの実装例でどうかはわからないけど)
で、次世代コーデックではさらにこのループフィルターのあたりにも改良を加えるみたい。

ブロックサイズの大型化は、まあ、理屈としては解像度の向上とともにブロック内の情報量が少なくなる場合もあり得るから、ブロックサイズをどんどん大型化していくというのはわかるのだけど、パッと考えればわかるように、あり得るブロックの切り方の候補がもの凄く増えるため、これは最適なブロックサイズに切るのに膨大な演算が必要となることになる。HEVCの64x64でも演算量が増大しているのに…。加えて動き予測も33方向から65方向ということで、こっちも大変そうだ。

というわけで、演算コストはHEVCの6~8倍らしく、うーん…。この手の処理は分岐も多くGPU向きではないので、結局CPUをぶん回すか、HWエンコするしかなく、HWエンコはあまり画質が上がらないことを考えると、ちょっと実際に使うには厳しいんじゃなかろうか、という感じ。




あとは、超解像とか。

Giken2016_10.jpg

超解像について、いろいろ細かく説明してもらえて非常に面白かった。

画像の拡大は、要するに低解像度の情報量の少ない画像からどうやって高解像度の情報を復元するか、という話になる。つまりきれいに高解像度にするには、足りない情報をどっかから持ってこないといけない。これについて、例えばフレーム内の似たようなところを探してきたり、違うフレームの同じ場所を探してきたりして、足りない情報を補っていうようだ。最終的には集めた相似な図形を重ねていき、適切にフィルタ処理するといい感じに拡大処理ができる、ということみたい。

今回紹介された超解像は上のようにマッチングとフィルターを使うものだけど、最近だと、Waifu2xのように、DNN(Deep Neural Network)を使って、いわゆるDeep Learningによって超解像を行うのも考えられる。これは大雑把に言えば大量の低解像度→高解像度の画像の組み合わせから、「拡大するときはこんな感じに拡大すべき」みたいな情報を学習させて、拡大するようなものだと思う。足りない情報量を、フレーム内とか周辺フレームからではなく大量の学習データから注入している感じ。ただ、この方式は大量の学習データと演算コストが必要なので、動画に使うにはまだ難しいのかも。



ほかにおもしろかったのは、映像から文字を認識して自動でタグ付けとか。

Giken2016_11.jpg

結構頑張って認識できていたけど、「ク」を「ロ」「り」の間で迷っていたりして可愛かった。文字認識は、日本語の場合漢字が複雑で、特に漢字に「へん」と「つくり」があると分けるべきか分けないべきかとか、結構難しそう。英語はなあ、文字が少ないからなあ…。

Giken2016_12.jpg



シート型ディスプレイとか。

Giken2016_13.jpg

有機ELのパネルみたいで、1Fに展示してあったけど、本当に薄かった。というか有機ELであの大きさ作れるようになったんだ…。

シート型ディスプレイ、家の布団の上の天井に貼ってPCの画面映せば完璧だと思うのです。 布団で寝ながらPC操作できて、素晴らしい夢のような自堕落な生活が…



あとは8K PCとか。8K/22.2chを映像4系統、音声3系統のケーブルで出力していた。100万以下で組めるらしい…って十分高いけどね!

Giken2016_14.jpg



ことしの技研公開も少しづつ進化していてとても面白かった。来年も期待。

まあでも8Kのよさは十分わかるんだけど、それでも今年試験放送開始とか、まだ早すぎる気がする(夏季オリンピック合わせなのはわかるけど)。お値段とか、あと、そういえば消費電力とか。1440Wって…うーん、東京なら暖房いらんかもね。夏は冷房全開。


スポンサーサイト

コメントの投稿

非公開コメント

No title

レポートありがとうございます
もう既に次世代コーデックの開発が進んでいるんですね
エンコードが大変そうですが……
規格が固まる頃にはH.265エンコが気軽に出来る世界であることを祈るばかりです

Re: No title

たしかにx265でもまだだいぶ遅いですからね…。CPUが昔みたいにどんどん速くなってくれればよいのですが…。

No title

>次世代コーデック

h265に比べて6-8倍とか説明されたけどそんなに速くできるのかなと思いました。

>超解像

動き補償でやろうとしたけど破綻した時が大変で諦めざるを得なかったという説明がありましたね。

他にはシーケンシャルアクセス向けの超高速バッファメモリーとして磁気テープなんだけど読み取りヘッドではなくパルス波でデータ自体を移動させるものとか、PTPを使ったタイムコード同期の話とかがありましたね。

No title

せっかく画質が高くなっても表面処理はグレアかノングレア。
(ハーフとかも一応ありますが・・・)
実際目で見る景色のほとんどがテカってない訳で、結局の所「きれいに見えてるっぽい」グレアが未だにきれいに見えるというのが二者択一の何ともアナログな感じがします。

何か革新的な表面処理(表示方法?)は開発されていないのでしょうか。

No title

>h265に比べて6-8倍
これはおそらく演算コストのことで、まあだいぶ遅くなるという話かと思います。

>表面処理
結局のところ、外光をどう処理するかの問題ですよね。なるべく吸収できればよいのかもしれないのですが、それも難しいので、結局反射するか散らすか…うーん。
プロフィール

Author:rigaya
アニメとか見たり、エンコードしたり。
連絡先(@を半角にしてください!)
rigaya34589@live.jp
github

最新記事
最新コメント
カテゴリ
月別アーカイブ
カウンター
検索フォーム
いろいろ
公開中のAviutlプラグインとかのダウンロード

○Aviutlプラグイン
x264guiEx 2.xx (ミラー)
- x264を使用したH264出力
- x264guiExの導入>
- x264.exeはこちら>

x265guiEx (ミラー)
- x265を使用したH.265/HEVC出力
- x265.exeはこちら>

QSVEnc + QSVEncC (ミラー)
- QuickSyncVideoによるH264出力
- QSVEncCはコマンドライン版
- QSVEncC 導入/使用方法>
- QSVEncCオプション一覧>

NVEnc + NVEncC (ミラー)
- NVIDIAのNVEncによるH264出力
- NVEncCオプション一覧>

VCEEnc + VCEEncC (ミラー)
- AMDのVCEによるH.264出力

ffmpegOut (ミラー)
- ffmpeg/avconvを使用した出力

自動フィールドシフト (ミラー)
- SSE2~AVX2による高速化版
- オリジナル: aji様

エッジレベル調整MT (ミラー)
- エッジレベル調整の並列化/高速化
- SSE2~AVX対応
- オリジナル: まじぽか太郎様

バンディング低減MT (ミラー)
- SSE2~AVX2による高速化版
- オリジナル: まじぽか太郎様

PMD_MT (ミラー)
- SSE2~FMA3による高速化版
- オリジナル: スレ48≫989氏

透過性ロゴ (ミラー)
- SSE2~FMA3によるSIMD版
- オリジナル: MakKi氏

AviutlColor (ミラー)
- BT.2020nc向け色変換プラグイン
- BT.709/BT.601向けも同梱

○その他
x264afs (ミラー)
- x264のafs対応版

aui_indexer (ミラー使い方>)
- lsmashinput.aui/m2v.auiの
 インデックス事前・一括生成

auc_export (ミラー使い方>)
- Aviutl Controlの
 エクスポートプラグイン版
 エクスポートをコマンドから

aup_reseter (ミラー)
- aupプロジェクトファイルの
 終了フラグを一括リセット

CheckBitrate (ミラー, 使い方, ソース)
- ビットレート分布の分析(HEVC対応)

チャプター変換 (ミラー使い方>)
- nero/appleチャプター形式変換

エッジレベル調整 (avisynth)
- Avisynth用エッジレベル調整

メモリ・キャッシュ速度測定
- スレッド数を変えて測定

○ビルドしたものとか
L-SMASH (ミラー)
x264 (ミラー)
x265 (ミラー)

○その他
サンプル動画
その他

○読みもの (ミラー)
Aviutl/x264guiExの色変換
動画関連ダウンロードリンク集
簡易インストーラの概要

○更新停止・公開終了
改造版x264gui
x264guiEx 0.xx
RSSリンクの表示
リンク
QRコード
QR