掲示板お問い合わせランダムジャンプ

トップスペース

2009年03月15日
RGB→YV12の変換で発生するチラツキの軽減
 自分が作ったAviUtlのUVダウンサンプリングフィルタ(ここで公開)にはlanzosによるダウンサンプリングの機能がありますが。その機能において気づいたことがあるので書いておきます。

 百聞は一見にしかず。下のアニメーションgifを見てください。「YUV420:平均」ではオリジナルにないチラツキが発生していますが、「YUV420:lanzos3」ではそのチラツキが軽減してます。

オリジナルオリジナル(RGB)
ダウンサンプリング平均YUV420:平均
ダウンサンプリングlanczos3YUV420:lanzos3
ダウンサンプリング色差ぼかし+平均色差ぼかし+平均

 ゲーム動画では背景がスクロールしているものが多いのでこのチラツキが発生しているケースは多いのではないでしょうか。
 これはおそらく「モアレ」や「エイリアスノイズ」といった類のものだと思われます。lanzosの縮小は高周波成分を削る(ローパス)ので、このチラツキを抑制できたのではないでしょうか。
 ちなみに、色差をぼかしてから平均によるダウンサンプリングをしてもチラツキは抑止できます。しかし、エッジがだらしなくなって色がかなり褪せます(色褪せは色調補正でなんとかなりますが)。


 ここでもう一つ検証。
 ISP imaging-developers - CZPによる評価というページで紹介されているCZP (Circular Zone Plate) を用いたリサイズ品質評価を真似して、ダウンサンプリングの特性を比較検証してみます。CZPについての詳細はリンク先を見てください。

 まず下の画像はCZP画像からRGBのGreenを取り除いたものです。
改造CZPオリジナル

 これをダウンサンプリングしたらどうなるのか試してみます。

改造CZPダウンサンプリング平均YUV420:平均
改造CZPダウンサンプリングlanczos3YUV420:lanzos3

 「YUV420:平均」では何やら模様が出現してます。
 CZP画像は中心から外に行くほど高周波成分があるわけですが、高周波成分をうまく除去(ローパス)できないと模様が出現します。この残った高周波成分がモワレの原因らしいです。
 つまり「YUV420:平均」ではモアレが発生していて、そのモワレがチラツキとなっていた、ということです。

 結論:lanzosの縮小はかなり優秀。
[ 投稿者:うえぽん at 23:59 | AviUtlや画像処理 | コメント(0) | トラックバック(0) ]

2009年03月14日
PhenomII X3 720 Black Edition を買った
 CPUを720BEに換装しました。当たりを引くと4コア化できるという今話題のCPUですが、うちのマザーボードでは無理なので諦めてます。

 とりあえずこのCPUを使ってて不思議に思ったのは、以前なら1コアだけ使用率が100%になったようなプログラムが下の画像のように3コアに負荷が分散することです。(下の画像はSuperπ実行時のもの)
PhenomII SuperPI

 この特性のおかげなのか、CPU使用率が100%になっても重くなったりしません。x264でエンコしているときでもネットを閲覧する余裕があるのは特筆ものです。
 ただこの特性のせいでCool'n'Quiet(省電力機能)の効きが悪いです。CPU使用率によってクロックを上げ下げする機能ですが、上の画像のように1コアあたりのCPU使用率が低いためにクロックを上げるタイミングが遅くなってるようです。まあ、Cool'n'Quietを切って k10stat で閾値を設定すれば改善しますが。


 さて、なんとなくマルチスレッド性能が高いような気がするので、ためしにx264のエンコでスレッド数を増やす実験をしてみました。
 エンコのオプションは下のよな感じで --threads を1 ~ 9にしてエンコし、結果のfpsをメモしました。エンコした動画はニコニコ動画で“きしめん”と呼ばれているものです。ついでの実験として--b-adapt 2で--bframesを増やすとマルチスレッドの効率が落ちるらしいので、--bframes 16の結果も取ってみます。
--crf 21 --aq-mode 0 --psy-rd 0.5:0 --qpmin 1 --qpstep 16 --scenecut 54 --min-keyint 1 --keyint 300 --8x8dct --partitions "p8x8,b8x8,i8x8,i4x4" --bframes 3 --b-pyramid --weightb --b-adapt 2 --ref 5 --mixed-refs --direct "auto" --me "umh" --subme 9 --merange 64 --trellis 2 --deblock -2:-2 --cqm "flat" --no-fast-pskip --no-dct-decimate --threads 1
 結果は以下の通り。
--threads--bframes 3--bframes 16
110.137.24
215.969.98
320.9612.29
425.4314.82
527.1615.40
627.6115.74
728.0116.08
828.2516.36
928.3816.22

 グラフにすると
x264_threads
 一番下のグラフは1スレッド時を1.0とした時の倍率です。3コアなので3倍ギリギリまで使おうとしてますね。「コア数を増やしてもコア数倍にはならない」と言われていますが、PhenomIIが凄いのかx264が凄いのかわかりませんが、なかなか健闘しているのではないでしょうか。
 あと--b-adapt 2で--bframesを増やすとスレッド効率が落ちているのも分かります。
[ 投稿者:うえぽん at 00:12 | 雑記 | コメント(0) | トラックバック(0) ]