動き補償i/p変換の実力 -Compressor 3.5

2021年02月09日

先日購入したCompressor 3.5を私はMacBook Pro Retina, 13-inch, Late 2013にインストールしました。

迚も楽しみに待っていた動き補償i/p変換、その実力を先日までにアップロードした画質サンプルの中で尤も不満に思っていたこちらの動画の元素材(非圧縮10bit/4:2:2, v210Codec)をProRes 422(HQ)に変換して試してみました。
Appleは動き補償ではなく動き補正と呼んでいる様ですね。

結果ですけれども飛び立つ飛行機の機体に描かれた赤と青あわせて二本のラインに生じていたジャギーも垂直尾翼の輪郭に生じていたジャギーも中々綺麗に消えました。
尤も完璧という訳ではないのですけれども改善効果は非常に大きく現れた様に思います。

実際の映像から切り抜いた画像を以下に掲載させて頂きます。
↑「最高品質 (動き補正)」(MotionCompensation)
↑「高品質 (動き適応)」(MotionAdaptive)
↑「高速 (線補正)」
↑「ブラー」(Vertical-Temporal)
↑「奇数」(Spatial Interpolation)
↑「偶数」(Spatial Interpolation)
↑「シャープ」(Temporal Interpolation)

既存の方法を一通り並べて比較をした所、動き適応でも他と比較して非常に良好な結果を得られている様に思えて来ました。
それでも気になる明らかなエラーは存在しており、それを改善し本来の像に近い像を得るにはやはり動き補償が必要であるとも思いました。
静止画部分では時間的内装を行なう方法が最良の結果を示す所に動き検出とその適応制御に残る問題と改善の余地を感じました。

Compressor 3.5のi/p変換出力はデフォルトではソースのフレームレートの等倍となるようです。
出力フレームレートを指定すればフレーム補完無しできちんとフィールドレートの等倍で出力させる事も可能ですけれど、この辺りはFinal Cut Pro Xとは異なる様です。

上記の画像はフレームレートの等倍で出力した物となります。

しかし良い事ばかりではありません。
Compressor 3.5のi/p変換には以下の様な問題がありました。

フィールドレートの等倍で出力させた場合に静止画でも目立ったフリッカーが発生します。これは先ほどのカットで画面中央にスーパーインポーズされている「LaserDisc DEMONSTRATION」のロゴで特に気になります。(動画)これはFinal Cut Pro Xでも概ね同様であり以前から迚も不満に思っている問題の一つでした。
理論上はフィールドレートの等倍で出力させても静止画にフリッカーの生じないi/p Convertorの実現は可能ですけれども残念ながらCompressor 3.5はそうではありませんでした。
それでも動き補償と動き適応の差異はきちんと出ています。

動き補償を用いた場合に輝度の非常に低い箇所ではノイズが発生します。まるで記憶層の状態の悪いLaserDiscに生じるカラーフラッシュの様な有様で迚も使えたものではありません。
原因は定かではありませんけれどもモーションベクトルの検出で何かエラーを起こし輝度, 彩度のおかしな点を動き補償フィールドに生成してしまっているのでは無いかと私は考えております。

動き補償を用いた場合に画面上下の端がマゼンタやグリーンになる事もあります。この問題の発生傾向からこれは画面外からの動きがあると判定された箇所で生じるエラーなのでは無いかと私は考察しております。
画面外の画は無いので動き補償を行なえません。本来であればそれを識別する情報を付加しその箇所を動き適応処理に切り替える事でエラーの発生を避けるべきではないかと私は思います。
これは迚もお粗末なエラーではないかというのが私の本音で有り製品として売り物になっている物でこれが生じてしまうのは正直頂けない様にもいます。況してや業務用の製品で有り、Final Cut ProがNLE市場で50%以上のシェアを誇っていたといわれる全盛期の製品ですからとんでもない様に思うと頃でございます。

ノイズが多かったり同期が不安定であったりする劣悪なソースに動き補償を用いた場合は像がぶれちらつくなどの問題も確認出来ております。
多少のノイズや乱れに影響されてしまうようでは問題ですけれどもこの場合はソース側の問題が大きい場合ですので難しい所です。

以上の様な問題があり、Compressor 3.5のi/p変換は一概に良いとは言えない事が残念ながら現実です。
上記のうち最初の3つの問題は専用ハードウェアの入手を待つばかりですけれど最後3つの問題はソースに合わせカット毎に異なる方法を用いて変換し後に繋ぎあわせるなど工夫したオペレーションを行なう事で対処して行く事が好ましい様にも思いました。
特に静止画に生じるフリッカーの問題は競合他社のピクセルベース動き適応i/p変換器に対する優位性として4フィールド分析による確実な動き検出を宣伝している専用ハードウェアに期待してしまいます。

また、Compressor 3.5とFinal Cut Pro Xでは動き適応i/p変換の挙動に差異を確認出来る事からCompressor 4.5のi/p変換が如何であるかについても迚も気になる所です。
明言されていないだけで動き補償i/p変換が継続若しくは改良され搭載されている可能性を捨てきれずにいます。

Compressor 3.5で動き補償i/p変換を行なうにかかる所要時間、MacBook Pro Retina, 13-inch, Late 2013で525/60iソースを525/60pで出力した場合は3分 53秒のソースに対して1時間 21分 51秒でした。
これは実時間の約21倍程となります。
信号処理としてはMPEGにエンコードしている様な所ですから負荷が重く所要時間が長くなるのも当然の事です。
動きベクトルの算出は元々複雑で負荷が重く、またフレームサイズが大きくなればなるほどに高い精度を実現しようとブロックサイズを小さくとれば小さくとる程に演算負荷が増大し所要時間が長く掛かる事となります。

そのリアルタイム処理を今から23年前の1998年の段階で実現, 実用化に留まらず製品化し、それも負荷低減を狙ったブロックマッチング法を用いず最高の精度を得られるピクセルマッチング法で実現していた某専用ハードウェアは今になって考えてもやはり凄いと迚も感心します。
尤もその専用ハードウェアは1024の処理装置を持つ専用のSIMD(Single Instruction, Multiple Data)Processorチップを25チップ搭載したボードを6枚搭載した恐らくは当時最大規模のGAPP(Geometric Arithmetic Parallel Processor)Processorでしたけれども。

Compressor 3.5と動き補償i/p変換を実際に使用してみて予想通りに良い部分もあれば前々からの懸念があたってしまった部分や予想外の問題に気付く事もありました。
動き補償i/p変換の有効性を確認出来た事が今回尤も重要であると認識しております。
動き補償の画面端でのエラーに対する対処、動き補償は動き適応i/p変換の適応制御の選択肢に新たな選択肢を追加するものとして解釈しその適応切り替えエラーを回避する思想で設計する事で行なえたのでは無いかと思いますけれど実際にはそうなっていなく大変歯痒く思います。
低輝度部や劣悪なソースでの動き補償エラーこれらの可能性を私は完全に見落としておりよい勉強になった様に思います。
今回の経験は専用ハードウェアの優位性と必要性を再認識する事にも繋がりました。