ちりとまとチャンネル

チリトマト好きがゲームや動画などについて取り扱っています
トップ → 動画作成およびエンコード関連

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

AviUtl使用フィルタ紹介(輪郭補正系)

この系統の役割は、
画像をシャープに(エッジを強調)したり、逆にギザギザ(ジャギー)を低減するなど。

・シャープフィルタ(AviUtl標準)
・エッジレベル調整MT
・アンシャープマスクMT
・モスキートノイズ低減フィルタ(低周波成分保護とスムージングフィルタの複合)





■シャープフィルタ(AviUtl標準)
標準フィルタの例に漏れず、処理は軽くエッジ強調フィルタとしての性能はそれなり。




■エッジレベル調整MT(配布場所
エッジレベル調整MT

同じ名前のものがありますがオススメするのはrigaya様の作成されたものです。
判定表示の機能が追加されており、どの部分に強調が働いているのか一目でわかるようになっています。
これを見ながら閾値を調整するとよりよい結果が得られます。
初期値の特性10は強すぎるかもしれない。無難なラインは3~5程度。
実写やリアルタイムCGにはあまり向かないと思います。




■アンシャープマスクMT(配布場所
unsharpmt_20121123165158.png

画像をぼかし、元の画像との差分を取り出して、それを元の画像に合成する…という仕組みらしい。
輪郭周りにハイライトみたいな効果が付与され、クッキリ見えるようになる。
エッジレベル強調と比べると、輪郭の形というよりは色に働きかけてシャープネスを作っている。そんな印象。

初期値はちょっと効果が強すぎると思います。
適応量10、範囲5程度からスタートして、大丈夫そうであれば徐々に増やしていくのがいいかも。
強いていうなら、エッジレベル調整に比べればこっちのほうがソースを選ばないかなって気がする。

本来は輪郭補正フィルタなのですが、最近の私はもっぱらノイズ確認のために使ってたりします。
やり方は、適応量を最大、それ以外は最小に。
こうすると、映像上のノイズが強調されて見えるようになる。
ブロックノイズの境目や輪郭周りのモスキートも一発でわかるようになります。
あとはこれを見ながら、ノイズが消えるようにフィルタを調節していくだけ。
完全に消すのではなく、多少残すくらいの気持ちでいくと画質のバランスがとれるでしょう。

ノイズ表示という名前のフィルタがありますが、
輝度ノイズに関してはアンシャープのほうがわかりやすく、
フィルタ自体も安定してるのでオススメです。




■モスキートノイズ低減フィルタ(配布場所
ノイズ除去系じゃないの?と名前を見て思われるかもしれません。
もちろんモスキートノイズの除去にも使えますが、このフィルタの実態は
「低周波成分保護を備えたスムージングフィルタ」であり、
エッジをなめらかにする元々の用途にも有効です。

従来のスムージングフィルタは、
画像内の全ての画素に同じ効果がかかる、副作用でとがった部分まで丸めてしまう、
といった副作用がありましたが、低周波成分保護とあわせることでそれを軽減しています。

[ブラーの範囲拡大]はチェックON推奨。
初期値だと安定してますが、やはり上げすぎは注意。
readmeでは[復元]はいじらないほうがいいとのことですが、
なめらかさだけを重視するなら、多少は下げてもいいかもしれません。
強度を30前後とか極端に上げるくらいなら、復元も少しずつ下げてみて確認したほうがいいです。

エッジのギザギザ対策はスムージングフィルタの系統が一つあれば大丈夫だと思います。




■その他

・warpsharp系
アニメ専用。3Dゲームや実写などもってのほか。
ジャギ消しつつシャープ化できるが、油絵っぽさとのトレードオフになるのでオススメしかねる。
上級者向け。こちらの記事が詳しいです。
スポンサーサイト

AviUtl使用フィルタ紹介(ノイズ除去:NL-Means系)

■NL-Means系
現時点で最強とも言われるノイズ除去フィルタです。
2000年代初頭に考案されたアルゴリズム「Non Local Means」(非局所平均)を使用します。
ボケやすいですが、標準フィルタとは段違いの除去能力があります。
また調整して弱めにかける分には、輪郭を残しつつ綺麗に安定してノイズを取ることができます。
ただし環境によっては非常に重いフィルタなので要注意。一般的にはアニメ向きとされている。

以下nodchip氏版の付属テキストから引用。

NL-Meansは対象画像中の設定された範囲の中で類似した箇所を探し出し、
それらの中心の画素の画素値を平均化することによってノイズの除去を行います。
このため色の変化が少ない部分では範囲全体が平均化されきれいなグラデーションとなり、
エッジ付近ではエッジ部分の画素のみが平均化され、エッジが十分に残ることになります。
エッジが特に重要となるアニメ画像等において、NL-Meansフィルタは大きな効果を上げるものと思われます。
(実際の計算では画像同士の類似度を用いた重み付けにより平均化されます)





■種類

・本家(配布場所
要GPU、激重。現在はおすすめできない。

・Light for GPU(配布場所
本家から色差成分の時間軸方向の処理などを省けるようにしたもの。
グラボのついてるPCには個人的に一番おすすめ。

・Light(配布場所
GPU不要、さらに軽くしたもの。オンボードグラフィックな人はこちらを。
輝度成分のみを扱い、時間軸方向の処理などが省かれている。

その他…for DX11(DirectX11対応GPU用)、for AMD GPU(AMD製GPU用)
※興味があればどうぞ



■NL-Means Light for GPU
この系統のプラグインの中では最も新しく安定しているのでまず入れるならコレ。

nlmlgpu.png
空間…計算するピクセルの範囲。増やすほどノイズを消せるが計算量が増える
時間…前後のフレームを参照する時間軸方向の範囲(0で時間軸処理を行わない)
分散…大きいほど平均ぼかしに近くなる(ノイズが消える代わりにボケる)
保護…低周波成分保護機能の効き目を調整する。0で機能OFF

(推奨値※あくまで参考に)
空間 : 2以上
時間 : 1が無難。場合によってはそれ以上
分散 : 初期値でボケが気になるなら20程度がおすすめ
保護 : 元の映像が綺麗なら100で問題ない。ノイズを消したければ50~60程度(輝度分散の調整が必要)



■NL-Means Light
グラフィックボードを利用しないバージョン。
オンボードグラフィック環境や、何世代も前の化石パーツを積んでいるのであればこちら。

nlml.png
同じフレーム内での輝度成分の処理しか行わない。
色差や時間軸方向の処理には別のフィルタと併用する必要がある。




■備考
他のものを試す場合は、効き具合に違いがあるため分散の値を調整する必要あり。
いずれにせよ、CPUとグラフィックの両方にしっかりしたパーツを使っているのであれば、
そこまで処理時間に大差は出なくなってきている…ような気がする。

【AviUtl】NL-Means系フィルタの速度?

条件

win7HP SP1 64bit
i7-3770
Radeon HD7850 Catalyst12.8

ULY2 1280x720 4442フレーム(2分27秒)→mp4 シングルパス 音声なし
設定は高画質重視の重めなやつ。

以下、特に書いてなければ輝度、色差それぞれ空間2、時間1
分散は輝度が20、色差が30(普段はこの値にしてる)




■NL-Means light for GPU TypeC

保護あり、updatesurfaceオン
13.12 fps 総エンコード時間 : 5分37.4秒

保護あり、updatesurfaceオフ
12.19 fps 総エンコード時間 : 6分 2.9秒

保護なし、updatesurfaceオン
14.14 fps 総エンコード時間 : 5分13.0秒

保護なし、updatesurfaceオフ
14.43 fps 総エンコード時間 : 5分6.7秒

GPU使用率はだいたい5~15%
保護を切ると速い。updatesurfaceは保護のありなしで結果が逆になった。



■NL-Means for DX11
14.26 fps 総エンコード時間 : 5分10.5秒

使用率はだいたい20~30%
速いが、保護機能を切ったlight for GPUとそんなに変わらないか。



■NL-Means for AMD GPU
12.02 fps 総エンコード時間 : 6分 8.2秒

使用率は5~10% ほとんど働いてくれない
厳しい結果となった。今のグラボだと性能出し切れないんだろうか。
空間や時間を増やせば増やすほど(要するに重い設定にすればするほど)、
速度面では他より有利になる。とのことだが…。



以下参考までに。


■NL-Means 計算モード3(本家)
13.88 fps 総エンコード時間 : 5分18.9秒

他の計算モードはふざけた速度しか出なかったので測定放棄。
平常時は20~30%だが振れ幅が大きい。一番GPU使ってる感じ。
なんか保護機能ありのlight for GPUより速いんですけど…どういうこと。
しかしまぁ使うかと言われれば微妙です。
フォルダに入れるだけで明らかにAviUtlが重くなり、
パラメータ弄ってると2012年現在のミドルPCですら止まりそうになることがあります。



■標準時間軸ノイズ除去(範囲3)+NL-Means light+色差ノイズ除去
13.85 fps 総エンコード時間 : 5分19.6秒

内臓GPUな人向けのCPUしか使わないノイズ除去フルコース。
普通に速いやん…。



なんか色々とやり方悪い気がする。けどどうすればいいかよくわからい。
もっと性能落としたほうがはっきりと差が出るだろうか。
いずれHD7000世代とかではNL-Meansがほとんど負荷になってないので。

…まぁ正直light for GPUひとつあればいいよねぇ。
速度はそこまで気にするほどの差は出ないし、
低周波成分保護といううれしいおまけもついてくるし。

それと、パラメータは極力揃えてみたのですが、
ノイズ除去のかかり具合は同じNL-Meansでもかなり違うようです。


上とほとんど同じエンコードオプションで、品質基準15で出力した時のサイズが以下の通り。


フィルタなし 350,086,717byte

for AMD GPU 344,508,109byte

light for GPU(保護60)216,940,081byte

本家 194,196,469byte

light for GPU (保護0)175,534,837byte

for DX11 158,103,623byte

GPUなし三点セット 151,225,665byte


for AMD GPUではほとんどサイズが縮んでません。
オリジナルとは係数やパラメータが異なるらしいので、
もっと分散とか増やさないといけないっぽい。

逆にかかり具合が強かったのがDX11版。ぼけてるのが一発でわかりました。
他のフィルタと同じ設定値を使うと危険かもしれません。

一番サイズが縮んだのは…CPUだけ使うフルコース。
時間軸ノイズ除去の範囲3、閾値16。ほんのわずかにぼけてる気がした。
ちょっと高すぎたかな。

【AviUtl】エラーとかへの対策メモ

看過できなくなったので自分用にメモ。何かわかれば随時追加。
大概は自分の使い方のせいなので自業自得ですが。



・最大画像サイズ
自分が扱うサイズの上限をあらかじめちゃんと決めて、設定しておいたほうがいい。
一部プラグインがメモリを使いすぎてエラーになる危険性も下がる。
普通の使い方なら1920x1080で十分。ニコニコベンチマークとかしたいなら自分でがんがれ。

・最大フレーム数
あんまり弄る人はいないだろうけど、これも盛りすぎるとアウトみたい。

・キャッシュフレーム数
エラーというよりは、AviUtlの快適さに関わる項目?
盛りすぎると逆に重くなるとか。

・LargeAddressAwareを有効にする
4GB以上のメモリを積んだ64bitOSの場合のみ。管理者権限が必要な場合あり。
AviUtlが使えるメモリを増やす。4GBまでは使えるようになるらしいが…。
マシになるような気はするものの、
自分の環境では、NL-Means系とノイズ表示などのノイズ系でメモリエラーがとても出やすい。
ひどい時はGPU使わないlight版や標準のノイズ除去すら無効化される。
発生頻度を緩和できないか検証中。


・モジュールエラー(発生モジュール : KERNELBASE.dll)
アドレス0x74c5b9bcで例外0xe0434f4dが発生しました

発生モジュール : KERNELBASE.dll
オフセットアドレス : 0x0000b9bc
備考 : OUTPUT_PLUGIN_TABLE::func_output()[拡張 x264 出力(GUI)ex]

0xe0434f4dとやらはFramework由来のエラーらしい。
発生場所がKERNEL32.dllとかならFrameworkのバージョンとかインスコに問題があった可能性大。
SPが新しいものになってるか、日本語パッケージも入ってるか、破損したりしてないか要確認。

しかしKERNELBASE.dllの対策は調べても全くヒットしない。
自分のパソコンのFrameworkはバージョン確認しても特に問題が見つからない。
Windows Updateで更新プログラム当てても改善なし。
x264でエンコを開始しようとすると、初回は必ず発生する。
処理を継続しますか?ではいを選ぶと、ただ出力に失敗するだけ。
その状態でもう一度エンコ開始しようとすると、なぜか普通に処理を始めてくれる。

AviUtlの最大画像サイズを5120x2880にしていたが、これを落とすと発生しにくくなった気がする。
Psy-RDのtrellisを0にすると起こりやすくなるような時がある。
オプションの兼ね合いの問題…?原因不明。


・モジュールエラー (発生モジュールがプラグインフィルタらしき場合)
使い方が悪いか相性が悪いか、その環境で使うには厳しい可能性がある。
たとえば、Wavelet系プラグインはフォルダに入れてるだけでエラーを吐くようになることがあるらしい。
ある時からエラーが頻発するようになったときは、新しく使い始めたプラグインとか、
フィルタの組み合わせ等、チェックしてみるといいかも。

自分の環境では、ノイズ除去系とか超解像がエラー出すことがある。うろ覚え。
メモリエラーに比べればたいした頻度ではない感じ。

h.264 Bフレーム設定に関する覚書

(追記 2012-10-26)
IvyBridge世代(HD Graphics 4000搭載CPU)
でようやくインテル内臓GPUの再生支援バグが改善されたそうです。
ただこの問題が完全になくなるのは当分先の話になる気がします。





設定の中でも重要度が比較的高いと言われるBフレームの設定についてメモ。


Bフレームは圧縮率に関わる項目です。
そもそもh.264/AVCは、Iフレーム、Pフレーム、Bフレームという三種類のフレームから成り立っています。

Iフレーム(キーフレーム)は完全な1枚絵。画質は一番良いが、サイズも一番大きい。
Iフレームが多いほど高画質、低圧縮率な動画ということになる。
シーク(早送り&巻き戻し)の基準となるフレーム。

Pフレームは直前のIフレームから予測して作られるフレーム。
基準となるIフレームから変化した部分"だけ"をデータとして記録しており、
IにPを重ねることで次のフレームとして表示する。
このためIフレームよりサイズが小さく、組み込むことで動画の圧縮率が上がる。

Bフレームは直前と直後のI、Pフレームを参照して作られるフレーム。
前のフレームと後のフレームの差分だけをデータとして記録している。
必要最低限のデータしか持たず、最もサイズが小さい。


つまり、Bフレームが多いほど圧縮率が上がります。
これがh264の高い圧縮効率に関わる要素の一つということです。



■設定項目

・最大Bフレーム連続数(--bframes)
Bフレームを最大何枚まで連続して挿入して良いかの設定。
初期値3、範囲0~16。0でBフレームを使用しない。

・適応的Bフレーム挿入(--b-adapt)
最大連続数の範囲で、Bフレームに適するフレームか否かを自動で判別する。
Bフレームに適さないものはPフレームとして処理する。
無効(0)にすると常にBフレーム連続数で設定した枚数を連続して使う。
完全(2)は簡易(1)より正確な判定を行うが、Bフレーム連続数が多いほど遅くなる。

残りの項目はデフォルトから変える必要がないので割愛。



■調整した際の影響、推奨値の検討

まず、Bフレームを使うならb-adaptは完全にするのが望ましいです。むしろ必須レベル。
無効にすると、動きの多いシーンでも表現力の低いBフレームが機械的に入れられるため、画質も下がります。
これを無効にするのはbframes0の時だけでいいです。

完全にしてBフレームを増やしていくと、画質面ではプラスに働きます。
変わらない可能性もありますが、それでも画質を維持しつつ圧縮率を上げられると考えて下さい。
適正値から上げても下げても結果的に劣化する、と言われたりしてましたが、
Bフレーム挿入を完全にさえしていれば、どれだけ増やしても劣化はしないはず。
(しても人間では知覚できないレベル)

また、エンコード負荷もbframesの値に応じて1passの時間が増える…という程度なので、
オプション類の中でも費用対効果は高い方です。


デメリットとして、上げれば上げるほど再生側の負荷が増加し、互換性が低下します。

有名な話として、bframesが4以上だと、
IntelのLGA1156ソケット系のGPU再生支援で映像が乱れることがあります。
もっともこれは回避法があるので、3より増やすかどうかは投稿者の判断に委ねられてる状況です。
PS3では3より増やすと問題が発生するらしいですが、未確認。

また、動きの多い動画よりは少ない動画の方が効果が高くなります。
「動きが多い=Bフレーム入れすぎると劣化する→あまり入れるな」
とBフレーム挿入で判断されるので。


ニコ動まとめwikiでのbframesの推奨値は3~5。
互換性や効果から考えるとbframesは3が最も無難ではあるかもしれません。
アップロード前提の場合、そこまで動きが激しくなければ有効値は6くらいまででしょうか。
SD解像度の30fpsだと、6より増やしても効果は期待できません。

…が、これが60fpsとかそれ以上のフレームレートだと、bframesの伸び代は若干増えます。
60fpsでIntelのGPU支援バグとかを気にしないなら、個人的に6以上をオススメしたい。
場合によっては12も有効かもしれません。13以上はさすがに趣味の領域という感じ。



結論。
アップロード&PC視聴が目的で面倒が嫌なら、やはりBフレーム連続数は3が安定。
ニコ動の標準解像度で30fps以内なら、上げるとしても6まで。
60fps以上の動画とかなら6以上も視野に入れる。その場合も有効値はせいぜい12くらいまで。

ちなみにbframesは3の倍数が望ましいという話があったのでそうしてます(参考


ゲーム動画とか、そこまで高画質が要求されないジャンルなら3推奨。
上げるとしたらまず3→6ですが、
それによるメリットとデメリットが釣り合ってるかどうかは…ソースにもよりますがなんとも。
9以上はガチで高画質を狙うためのもの、12から先は実験目的用…という感覚です。


ここまでこだわりたい人は、出力ログとかでBフレームの挿入結果をチェックしてみて下さい。
consecutive B-frames とか。

AviUtl使用フィルタ紹介(リサイズ系)

リサイズ。文字通り動画のフレームサイズ(解像度)を変更するフィルタです。



■AviUtl標準(クリッピング&リサイズ)
リサイズ精度はそこそこで処理が速い。
拡大時はボケやすい。SD解像度までならそこまで気にならないが、HD以上は厳しい。
その代わりとしてファイルサイズは縮みやすい。
使い勝手も少々悪く、基本的に使う価値はありません。



■Lanczos 3-lobed 拡大縮小
Lanczosの読み方はランチョス、あるいはランツォシュとか。
ちょっと前までは多くのサイトでオススメされていたリサイズフィルタです。
拡大時のシャープ化効果が数あるアルゴリズムの中でも特に強めで、
くっきり綺麗にアップスケーリング出来ることから、特にアニメエンコードにおいて紹介されました。
デメリットはサイズが膨らむ、リンギングが大きい、の二点。
ほぼ同精度でより高速なLanczos方式を使えるフィルタ(後述)の登場によりオワコン化。



■リサイズフィルタ(配布場所
resize.png
現在の主流と思われるリサイズフィルタです。
特にSpline36というアルゴリズムがよく推奨されています。
Lanczos3との違いは、ほんのちょっとだけシャープ効果弱めで、
リンギングが小さくサイズが若干縮むことなどです。
バランスが良く、アニメやアップロード用動画のリサイズ方式として優れているとされます。

またLanczos3も(窓関数を3にすれば)使えます。
開発者様曰く、"Lanczos 3-lobed 拡大縮小"のLanczosとは、リサイズ結果が厳密には異なるそうです。
…が、どうせ普通の人にはわからないレベルの違いです。
さらに、同じアルゴリズムのLanczos 3-lobed 拡大縮小に比べて処理が速いというメリットつき。

処理速度に関しては、
 標準>リサイズフィルタSpline36>リサイズフィルタLanczos3>>Lanczos 3-lobed

となっているので、Lanczosが好きでこの方式を使うにしてもリサイズフィルタを推奨します。
(参考:ここここ

リサイズフィルタでどのアルゴリズムを使うかについてですが、
LanczosBicubicBlackmanSincSpline16&36のいずれかを選びましょう。

あとはシャープ感や滑らかさ、他のフィルタとの兼ね合いによる調整のしやすさ等を考慮して、
自分に合った方式を選びましょう。

窓関数について。
・Lanczos(半径)
増やすとシャープネス効果が強くなり、減らすと逆。
半径3がSpline36に近い画質。
実写でファイルサイズを考慮しない場合は、splineよりいいかもしれない。
ぱっと見て違いを見つけるのは難しいが。2か3を推奨。

・Bicubic(シャープ)
3~4くらいでだいたいSpline36と同じ。0だとボケボケ。

・BlackmanSinc(半径)
低いとギザギザになってしまう。4程度を推奨。

アニメや低ビットレートのエンコードでノイズを抑えたい場合はsplineで。
Spline16と36の違いも、ぱっと見わかりやすいのはやはりシャープ感です。
よさそうな方を選びましょう。

よくわからない、一つで済ませたいという人にはやはり万能選手のSpline36がオススメです。
これらの方式は窓関数の効き目が同じくらいなら、
ぶっちゃけほとんど違いがわからないレベルなので…。
輪郭なら別のフィルタでも調整出来るので、そういう意味でも癖の少ないsplineは使いやすいです。



■超解像(テスト)(配布場所
superres.png
あまり有名ではありませんが、個人的に面白いと思うのがこちら。
東芝のホームページにあった『超解像度技術』を参考にしているそうです→詳しくはこちら

凄くややこしそうですが、説明すると
・Source
"Clip Enable"にチェックでクリッピングが出来る

・Destination
解像度の指定。サイドパネル・レターボックスとはいわゆる黒帯を付けるかどうかの設定。

・Algorithm
アルゴリズムの選択。Lanczos2か3を推奨。

・Super Resolution(test)
このプラグインの目玉、超解像度モードの設定。チェックで有効。

超解像モードの仕組みは、

まず選択したアルゴリズムで拡大

拡大前のサイズに縮小して、元画像と比較。これより差分を得る

差分を目標サイズと同じ大きさに再び拡大

拡大した差分データに係数を掛けて、最初に拡大した画像へ合成する

…まあわからなくても大丈夫か。


重要なのは、k*100という部分、差分データに掛ける係数の設定です。
100~150が適正値だそうです。大抵はデフォルトの100で大丈夫です。
50でも効果ははっきりわかります。他の拡大と比べるとボケ感がだいぶ少ないです。
微妙に違う縦横比へのリサイズにも有効です。
(元々狂っていた等やむを得ない場合であり、出来るだけ黒縁追加などで同じ縦横比を維持したほうがいい)
デメリットとして係数を増やすほどジャギやノイズが強調され、強烈なシュートが発生し、
非常にキツイ見た目の映像が出来上がります。
多少は好みの問題ですが、どんなフィルタもやりすぎはよくありません…ということで。

また"detect coefficient automatically"にチェックを入れると、
現在のフレームで最適となる数値を自動的に計算してくれます。

この状態でシークバーを動かすと、右下の数値が変化します。
あちこちに動かして数値を見たら、チェックを外して、出た数値の平均あたりか、
それより10~20くらい下げて値を入力しましょう。

超解像は良くも悪くも元の画質に忠実にリサイズを行うので、
元がそんなに綺麗じゃないor汚いと、あまり綺麗にアップスケーリングしてくれない
(下手すると汚さを際立たせる)ことになります。
ノイズ除去フィルタを前に置くなどの工夫が必要。
リサイズフィルタより重く、プラグインとしては不安定なので万人向けではありません。



■その他

・SharpenResize
要GPU。
リサイズやノイズ除去、輪郭補正など一通りの工程をCPUからグラボに分散させることで高速化を図る。
低周波成分保護オプションまでついてくる。
色々やらせるのでローエンド製品では厳しいかもしれない(readmeにも書いてある)
そんなにいっぱいフィルタはいらない、パラメータもそこまで慎重に弄らない、
という人にとってはコレ一発で済ませられるのでおすすめできそう。
リサイズのみと比べると、とりあえず初期値のままでも「おおっ」ってなるくらいには違いがある。

・Upsample
エッジ部とそれ以外で違うアルゴリズムを使う…という発想は面白いですが、
個人的にはそれほど有用性を感じませんでした。
ぼけ低減オプションも私の嫌いな油絵っぽさが出ていてダメでした。

・nnedi3フィルタ
インターレース解除と拡大機能を持つ不思議なフィルタ。
重いが精度はとてもよい。ただ、元のサイズの整数倍にしか拡大できないので、
ごく限られた使い方しか出来ない。

AviUtl使用フィルタ紹介(ノイズ除去系)

ノイズ除去系(NRとも)フィルタの役目はだいたい以下の感じです。

1.元々ノイズが乗っている映像を綺麗にする
2.ファイルサイズを縮める

1.はソースが昔のもので、映像が汚い場合は特に有効です。
またノイズが少ない最近のソースでも、アップロード前提でサイズを少しでも削りたい場合などは、
違いがわからない程度に閾値などを下げて弱めにかけるのが、視覚的品質の面でもベターです。

またノイズ除去は、強度を上げるほど映像がボケていきますが、
エンコードの際には映像がボケているほどファイルサイズが縮むという理由もあります。
(ディティールが曖昧になることで再現に必要なビットレートが減る)

ノイズが多いとビットレートの消費量が増えるので(ノイズを再現しようとするため)、
ファイルサイズが大きくなる傾向にあります。
ビットレート指定の場合だと、ビットレートがノイズに回されるため全体的な画質が低下します。

ノイズ除去は強度を上げた場合、
煙や地面、肌などの質感が次第にのっぺりしていき、上げすぎると映像がぼやけて見えます。
そのため、こまめに見ながらパラメータを調整するといいです。



■AviUtl標準(ノイズ除去&時間軸ノイズ除去)
それなりの性能で軽めの処理が特徴。
ソースのノイズが少ない場合はこの二つでも十分かもしれません。
ただし除去性能のもっと高いフィルタが存在するので、
画質にこだわるならもっと上位のフィルタを導入したいところです。

容量節約のために使うなら、閾値を10くらいにして様子を見ながら上げていきます。
私はもし使うとしたら、両方とも初期値から閾値を10~16くらいです。
ゲームや実写だと、20以降からボケ始めるように感じるので。

時間軸の方のみ、ソースによってはもう少し高めの閾値にしたりします。
(ぼかしてでも綺麗に見せたいくらい元の画質の悪い場合とかですが)
ちなみに時間軸ノイズ除去は、極端に強くするとボケるだけでなく再生時に残像が発生します。
…といってもそこまで極端な設定はまずあり得ないですが。
これは一応、時間軸系ノイズ除去フィルタの傾向です。



■NL-Means系
アニメ向きで今メジャーなノイズ除去。
詳しくはまとめページで(こちら



■Wavelet系
輪郭の潰れにくさと除去能力のバランスが優れている。
準備とエンコードにかかる手間を惜しまないのであれば、
実写~3Dゲームにおいては最強のデノイズフィルタではないかと思う。
(紹介ページは作成中)



■色差ノイズ除去(配布場所
chnr.png
AviUtl標準のノイズ除去相当のフィルタを色差成分のみに適用するフィルタです。
先述した通り、NL-Means Lightでは扱わない色差ノイズをカバーする時などに使います。
基本的にはこのフィルタ単体でのサイズ縮小率は、輝度ノイズを除去した際の縮小率に及びません。
ほぼ見た目を変えることなくサイズを少し削れるので、
余裕があれば使わないよりは使った方がいいフィルタです。



■PMD_MT(配布場所
pmdmt.png
AviUtl標準やNL-Meansに比べてインパルスノイズに効果を発揮するフィルタです。
上記のフィルタでは(ボケ過ぎるくらいに強度を上げないと)消せないような、
ポツポツとした粒状のノイズ(インパルスノイズ、ゴマ塩ノイズ)を消すのに便利です。
また比較的輪郭が潰れにくいフィルタです。ただし輪郭ではないと判定された部分はのっぺりしやすいですが。
性質上、アニメにも向いている?

ソースを見て必要そうであればこのフィルタを追加します。
閾値は、よほど状態が悪くない限り実写やゲームだと80以下が望ましいと思います。
初期値の100以降だと顕著にボケます。
useExpはオンにすると閾値の計算方法が変わり、輪郭を強調するようになるらしい。お好みで。
回数はノイズ除去をかける回数。
強度と閾値を抑えて回数を増やすほうがたぶん綺麗にフィルタがかかる…
と思われますが時間もかかります。



■メディアンフィルタ差分保護(配布場所
mda.png
開発者様曰く「とにかく高速なノイズ除去を目標にした」そうです。
こちらもゴマ塩ノイズに強いフィルタです。

初期値のままだと実写系や3Dゲームでは強すぎになります。
画質面ではあまり安定しない印象があるので、ノイズ除去のメインとしては使いません。
私の場合はMSEを出来るだけ低くして(30程度、ソース次第)、
PMDでも消し切れなかったノイズを少しなりとも減らしたい場合に使用しています。
この用途だと速度的なデメリットも少ないので使いやすいかな。回数についてはPMDと同様。





■その他
他によく目にするものだとウェーブレット3DNR、FHT|DCT2Dとかありますが、
前者は解像度720x480まで(現時点のα版では1920x1080まで対応できるそうです)、
後者は画像サイズ8の倍数(ただし一般的なサイズには大抵対応できます)
という前提があったりして使いにくく、
今のところは上で紹介したものが揃っていれば十分かな~と思ってます。

IIR-3DNRは3D型のノイズ除去(前後のフレームを比較して除去するタイプ)で、
標準の時間軸ノイズ除去と同じタイプのフィルタです。
個人的に、3D型NRは標準のもので十分な気がしているので試してからは使ってません。

あとは昔のアナログでかなり質の悪いソースを扱う場合に限って、ドット妨害除去等?

AviSynth&MVToolsによるフレーム補間

フレーム補間とは、ぬるぬる化である。

一般的に動画は30fps(1秒間に30枚の静止画)や29.97fps
もしくはそれ以下のフレームレートが用いられていることが多い。
フレーム補間ではこういった動画のフレームの間に新たなフレームを計算して作り出しフレームレートを上げることで、
より滑らかな動きの動画にすることが可能である。大体60fps化されることが多い。

ちなみに30fpsなどの動画を60fpsなどにしてエンコードしただけでは
再生負荷が高まるだけでぬるぬるにはならない。フレーム補間には専用のプラグインが必要である。

(ニコニコ大百科記事より)


導入方法はこちらのブログの記事がわかりやすいです。



こういう動画が需要あるかどうかは別として、
興味があったので色々と試行錯誤してみた経緯などをストレージしておこうと思います。





■フレーム補間のメリット
動きが滑らかに見える(ぬるぬるするという表現の方が正しい)
同程度のBPPが確保出来ていれば、同じ30fpsの動画に比べて高画質に見える(停止中を除く)

既に見たことのある動画が(うまくいけば)全然違った印象になって楽しいです。
昔のフレームレートが低いソースとかでやって視聴すると感動するかもしれません。


■フレーム補間のデメリット
何よりもファイルサイズの肥大化。
30fpsが60fpsになれば、単純にデータの量も二倍になります。

同じ画質を維持するために、ビットレートも倍必要です
h.264の場合、倍までは必要ありませんが、同じビットレートだと結構劣化します。
アップロード目的でサイズ制限などがある場合、
ビットレートを満足に振れない結果として30fpsのものより画質が悪くなる可能性が高いです。

当然、30fps→60fpsとなることで再生負荷も倍増します。
SD解像度の60fpsなら、一昔前のデュアルコアCPUでも何とかなりますが、
(それでもGPUがショボイorオンボードだとコマ落ちが起きるので厳しい)
HD以上となると再生できる環境を選びます。
フレームサイズに対してCPU(GPU)の性能が足りな過ぎるとコマ落ちしまくりで本末転倒。

また、ソースの向き不向きの差が大きいことには要注意。
そもそも動きがほとんどないような動画だと容量が増えるだけで意味がありません。
元からボケボケな映像、ブラーがかかっているようなシーンにもあまり効果がありません。

動きが単純な方が効果がわかりやすいです。
スクロールとかワイプのようなものに対してはメチャメチャ強力です。
最たる例がエロゲーのムービー。
ただ、色の変化については大して違いがわかりません。

あと、補間の設定はスクリプトを書いて行うのですがこれが厄介でして。
MVToolsのフレーム補間は、動きや色の変化が激しい部分ではブロックノイズが発生します。

これは設定で減らすことが出来るのですが、
基本的には減らす方向に振るほどぬるぬる感がなくなるため妥協が必要です。
というか、どれだけノイズを減らす設定にしても抑制しきれないことがあります。
なのでソースの見極めと妥協が重要になります。
何も考えずにやると、ブロックノイズのせいで画質が悲惨になって逆効果です。

また、設定のコツなどを解説しているサイトは日本では皆無なので、
英語のわからない人だと暗中模索になってしまいます。

ブロックノイズ比較_フレーム補間処理後
ブロックノイズ比較用処理前
上が補間処理後、下は処理前です。
極端な例ですが、何も設定を考えずにやるとこうなってしまいます。
ブロックノイズは他のノイズに比べて誤魔化すのがかなり難儀というか、無理に近いですからね…。



それと一つ。MVToolsが作る補間フレームは決して完璧じゃありません。
MVToolsは物体の微妙な加減速や移動方向の変化まで計算してくれないからです。
AのフレームとBのフレームの差分の平均を取ってぼかしているようなイメージで、
シーンによってはかえって動きが不自然というか、不快に感じることが多々あります。

30fps前提で、絵として一枚一枚作られるアニメとかでは、
確かにぬるぬるにはなりますが、動き方が全然違うイメージに見えてしまう可能性もあります。
実験としてはアリですが、見せる目的でアニメをフレーム補間するのはオススメしません。

ちなみに、フレーム補間した動画は動画としては滑らかで美しくなりますが、
一時停止して静止画として見るのには向いてません。



というわけで、ぶっちゃけ問題のほうが目につきやすい書き方ですが、
それでも設定がうまく行った動画は見てて楽しいです。

いい加減にやられても見る側としては迷惑ですし、
投稿者の自己満足という側面も否定できませんが、
動画作成の一つの手法として追究していくには十分面白いかなと。




■スクリプトの記述について

記述方法の説明→http://avisynth.org.ru/mvtools/mvtools2.html(英語)


先に述べたように、日本語で丁寧に解説しているサイトはほとんどありません。
私も英語がわからない人なのですが、わかる範囲でちょっとだけ紹介します。

#記述例

AVIsource("#")#変換する動画のパスに書き換える
#ConvertToYUY2() #動画の色情報がRGB等の場合は最初の#を外す
SetMTMode(2)
super=MSuper(pel=1, hpad=0, vpad=0)
backward_1=MAnalyse(super, chroma=false, isb=true, blksize=32, blksizev=32, searchparam=3, plevel=0, search=3, badrange=(-24))
forward_1=MAnalyse(super, chroma=false, isb=false, blksize=32, blksizev=32, searchparam=3, plevel=0, search=3, badrange=(-24))
backward_2 = MRecalculate(super, chroma=false, backward_1, blksize=16, blksizev=16, searchparam=2, search=3)
forward_2 = MRecalculate(super, chroma=false, forward_1, blksize=16, blksizev=16, searchparam=2, search=3)
backward_3 = MRecalculate(super, chroma=false, backward_2, blksize=8, blksizev=8, searchparam=1, search=3)
forward_3 = MRecalculate(super, chroma=false, forward_2, blksize=8, blksizev=8, searchparam=1, search=3)
MBlockFps(super, backward_3, forward_3, num=60, den=1, mode=0)
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last



MTモードというのは、確かマルチスレッドの設定です。
これでエラーが出る場合はおそらくAviSynthとかがマルチスレッドに対応していません。
よくわからなければ~MTmode~の記述は全部消しとけばいいです。


"pel"
動き予測の正確さ。設定できる値は1、2、4のいずれか。初期値は2。
1で1ピクセル、2で1/2ピクセル、4で1/4ピクセルの精度。
増やすと滑らかさを損ねずにブロックノイズが減少するが、エンコード負荷が飛躍的に増える。
また常に4にすればいいというわけでもないらしい。
2か4を推奨。

"blksize"&"blksizeV"
ブロックマッチング法で使用するブロックの横および縦(Vertical)のサイズ。
4、8(初期値)、16、32を指定できる。
大きくするとソース自体のノイズに影響されにくくなり、処理が軽くなるが、補間フレームの正確さが失われる。
16以下を推奨。フレームサイズが小さく良ソースならもっと低めにしていいかもしれない。

"searchparam"
動き予測方式に対する追加的パラメータ。デフォルトは2。
このスクリプトでは下げるとブロックノイズが減るが、滑らかさが失われる。
2~3程度を推奨。

"search""
動き予測方式。0~7の指定した値に応じて予測方式が変わる。
上と合わせてx264の動き予測オプションみたいなもの?
3はx264のExhaustive search、デフォルトの4はHexagonal searchに相当するらしい。

"plevel"
penalty factor lambda level scaling mode…?調べたがわからなかった。
指定できる値は0、1、2。
デフォルトは0。2にするとブロックノイズが減るが、滑らかさが失われる。

"num"
目標とするフレームレート。30fps化なら30、60fps化するなら60を入力。

"mode"
これも調べたがよくわから(ry
0-5(5はデバッグ用)。初期値0。
2にするとエンコード負荷が増え、ブロックノイズが減るが、滑らかさが失われる。
0はエンコード負荷最小。


■その他知っておくとよさそうなこと
AviSynthに読み込ませる動画は、リサイズフィルタで可能な限りアップスケーリングしておくと、
ブロックノイズが控えめの綺麗な補間フレームを作ってくれます。
(ただしそれなりに状態の良いソース限定です)
もちろん処理は重くなるので、妥協点をうまく探して下さい。



とりあえずソースを見ながら上で挙げた部分を弄る感じになると思います。
こんな有様なので、ここはこうじゃない?などの情報提供は大歓迎でございます。



↓実験例を集めたマイリストです(自分のと他の方のを一緒にしています)

BPPで目標とする画質ごとの最適ビットレートを計算してみる

ニコ動は一般会員だとビットレートは600Kbpsまでしか指定できません。
プレミアムだとビットレートは無制限ですが、うpできるファイルサイズが100MB以下なので、
それなりに再生時間のある動画だと、結局のところ

ビットレート→サイズ制限ギリギリの量を指定


という感じになることが多いです。

2~3分程度なら4000~5000Kbpsという贅沢な値を指定できますが、
上げすぎるとシークバーの溜まりが遅くなって再生途中で止まります。
しかも、ニコ動の標準解像度(512x384や640x360)だと、
画質は大して変わらないのに無駄に重くなってるという可能性が高いです。


そこでアップロード制限は置いといて、どれくらいビットレートを振ればいいのか
(これ以上増やしても画質が変わりにくく、重くなるだけというライン)を考えてみる。


しかしネット上でその線の情報を調べても、
保存用途が前提でありったけ高いビットレートを推奨していたり、
「この解像度ならこれくらいあれば綺麗に見える」という主観的な情報が多くて悩みました。



そんな時に、よさげなものが見つかったのでご紹介。
http://service.jp.real.com/help/faq/prod/faq_4226.html


BPPとは Bits Per Pixel(ピクセルあたりのビット数)、
つまり1ピクセルにどれくらいビット数を割り振るかを意味します。


サイズとフレームレートが決まっている場合、

ビットレート = BPP × フレームレート × 幅 × 高さ

という計算式を使うことで、自分が望む画質を得るにはどれくらいビットレートを振ればいいかがわかります。
BPPには下の表のような数値を当てはめます。

動作品質
最高
高度0.2250.1750.1250.100
中度0.2000.1500.1000.075
低度0.1750.1250.0750.050

動作は映像の動きの激しさで、この表では以下のように分けられます。

高度-スポーツやミュージックビデオ
中度-映画
低度-ニュースなど


例えば、映画をHDかつ最高品質でエンコードする場合、

ビットレート = 0.2 × 30 × 1366 × 768 = 6294528 となり、

目的の画質を得るためにはビットレートが約6300Kbps必要になると考えられます。



ここまでなら同じような内容を載せているページは結構あります。
それじゃあ、ニコ動くらいのスケールではどうなるんだ?という話をこれから致します。

よくありそうな設定では、ゲームのプレイ動画を16:9サイズかつそこそこの画質でアップしたい場合、

0.1×30×640×360=691200 →約690kbpsが必要です。

つまり、一般会員の制限である600kbpsでは正直苦しいです。
(実際は656kbpsとすると、音声に80kbpsは使うとして映像部は最大でも560~570kbps程度)
そんなに動かず、グラフィックがシンプルとかなら十分な画質になるかもしれませんが、
アクション、特にFPSとかだとキツイです。


もっともh264はそれ以前のコーデックより性能がいいので、
そこまでこの表のBPP値を真に受けなくても大丈夫です。
動きが多いか少ないか、アニメか実写かでも結構違います。

プレミアムに関しては、BPP=0.12前後(640x360で830kbpsくらい)あれば十分な画質になります。
動きの激しいアクションやFPS、弾幕ゲーとかだとBPP=0.14~0.15(1000kbpsくらい)、
極端なケースだともっと必要かもしれません(MHP3のラスボスとか)


ひたすら高画質にしたい!という場合、BPP=0.165程度として
・512x384なら970Kbps(音声96Kbpsで13分)
・640x360なら1140Kbps(音声96Kbpsで11分)

くらいを目標にするといいでしょう。
それでもまだビットレートに余裕があって画質が不満なら、
あとはご自身の目で確認しながら満足するまでビットレートを振って下さい。



最近はニコ動のプレイヤーの標準解像度より大きい動画も増えてきたので、そっちにも触れてみる。


ニコ動のプレイヤーが通常モードで等倍表示できるのは、アス比4:3で512x384、16:9で640x360(か384)。
それよりデカいサイズとなると、基本的にはフルスクリーン表示での視聴が前提となります。

当然ながら解像度を上げるほど、画質を維持するのに必要なビットレートは増えます。
そしてビットレートを増やしすぎると、
サーバからの読み込みが遅くなって再生が止まり止まりになります。
1500Kbpsくらいなら大概は安定しますが、休日の10時~12時とかだとこれでもキツイかったりします。

最も混雑する数時間さえ避けてスムーズに再生出来るならいい!というのであれば、
人と時間帯にもよりますが4000Kbpsでも行けないことはないです。

フルスクリーン再生を前提とする動画は、高画質を売りにしたい場合が大半なので、
むしろ多少のリスクを負ってもそれくらいのビットレートは指定していいかもしれません。


いずれにせよ解像度とビットレートを上げすぎるとフルスクリーン表示でコマ落ちが発生したり、
再生中で止まったりと害も多くなるので、限度があります。

HDサイズの場合 BPP=0.13 すなわち、

0.13 × 30 × 1366 × 768 = 4091443.2 →約4090Kbps

この辺りを限度にしといたほうがいいでしょう。

よほど動画にコダワリがあるとか、視聴者のPC性能を試したいとか、ベンチマーク上等ォ!
という場合を除き、これ以上はやらないほうがいいです。


実際はフルHD(1920x1080)の動画もニコ動には上がっていますが、
フルHDは同じ品質を維持する場合、HDに対して二倍ものビットレートが必要であり、
BPP=0.1の並品質ですら6000kbps以上というシャレにならないビットレートを要求されます。

マトモに再生できない環境&時間帯のほうがおそらく多くなるので、
実験とかベンチマークでない限り解像度はHD程度で留めておくほうが無難です。
エンコードする方も相当キツイですからね…。

ニコニコ動画向け記事まとめ

・ニコニコ動画まとめwiki(http://nicowiki.com/
動画サイト向け動画の作成方法はこちら

・VIPで初心者がゲーム実況するには@wiki(http://www18.atwiki.jp/live2ch/
ゲーム映像の生放送、動画の作成方法はこちら

・上記サイト内 キャプチャーについての総説(http://www18.atwiki.jp/live2ch/pages/266.html


エンコードオプションについてはこちらが参考になります。
拡張 x264 出力(GUI)Exの設定項目とその機能について
魔道学研究所 動画エンコード ニコニコ動画 2011ねん9がつごう

この辺りを抑えることが出来れば、とりあえず立派に投稿するところまでは行けると思います。
当ブログでは、動画作成についての記事は一通りエンコードと投稿のやり方がわかるという方向けに書く方針。



■関連記事

・AviUtl使用フィルタ紹介
 ノイズ除去系
 >NL-Means系
 リサイズ系
 輪郭補正系

【AviUtl】エラーとかへの対策メモ
BPPで目標とする画質ごとの最適ビットレートを計算してみる
h.264 Bフレーム設定に関する覚書
AviSynth&MVToolsによるフレーム補間
【AviUtl】NL-Means系フィルタの速度?
SSIMによる画質の個人的な目安(あまりアテにならないので非公開に)


あくまでメモを晒す以上の目的はないので、基本投げっぱなしです
質問に対しては私の知識の範囲内でしかお答えできませんのでご了承ください。



うp主の制作環境
(2012年10月現在)

OS : Windows 7 Home Premium 64bit Service Pack1
CPU : Intel Core i7-3770 3.40GHz
RAM : 8GB

キャプチャーデバイス : DC-HA1

録画ソフト:アマレコTV(utvideoコーデック使用)
編集ソフト:Aviutl version 0.99m/拡張編集プラグイン version 0.90d3
h264出力:拡張 x264 出力(GUI) Ex version 1.57

その他:
GIMP(画像切り抜き用)
SofTalk/棒読みちゃん(ゆっくりの声)
MediaInfo(エンコード設定を確認したい時)
bitrate viwer(ビットレート変動幅のチェック)


(2012年9月以前)

OS:Windows Vista Home Premium 32bit
CPU:Intel Core 2 Duo T7250 2GHz
メモリ:2GBx2(実質3GB)

使用キャプチャーボード
DN-UVC231C(PSP専用)
DN-UVC252C(据置ゲーム用、DC-HA1のおかげで完全レガシー化)

録画ソフト:アマレコTV(utvideoコーデック使用)
編集ソフト:Aviutl version 0.99i8/拡張編集プラグイン version 0.88b

その他:
GIMP(画像切り抜き用)
SofTalk/棒読みちゃん(ゆっくりの声)
MediaInfo(エンコード設定を確認したい時)
bitrate viwer(ビットレート変動幅のチェック)
AviSynth/MVTools2(フレーム補間60fps化用)

h264出力:拡張 x264 出力(GUI) Ex version 0.27
(最新版は1.18なので注意。バージョンアップHAEEE)


↓古いのでアテにしないで下さい。いい加減何とかしたい…


aviutlで使っているプラグインフィルタ


※はAviUtl標準フィルタ
系統/使用頻度常用状況に応じて使用検討中あまり使わない・使わなくなった
リサイズ系リサイズフィルタ超解像(テスト)Lanczos 3-lobed 拡大縮小
色補正系色調補正・改AviUtl標準※UVダウンサンプリング
色褪せ軽減β
ヒストグラム先鋭化2
ノイズ除去(NR)系

色差ノイズ除去
NL-Means Light

メディアンフィルタ差分保護
PMD MT
ノイズ除去(時間軸)※
輪郭補正系エッジレベル調整アンシャープマスクMT
スムージングフィルタ
WarpSharpMT
非線形先鋭化
シャープフィルタ※
輪郭保持平滑化
その他虫眼鏡
ノイズ表示
縞検出ジャンプ
インタレ縞低減++
拡大ツール
自動フィールドシフト

とりあえず常用のフィルタはかなりオススメ、むしろ必須級だと思ってます。
主に扱うソースがゲームやCGムービーなので、アニメエンコードでよく紹介されるものはあまり使いません。
というか使いこなせません。例としてはNLSとかWarpSharpとかバンディング低減とか。
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。