読者です 読者をやめる 読者になる 読者になる

unsuitanの日記

パソコンの神様 公式ブログ!

waifu2xでアニメをアップコンバートする

コンピュータ 二次元

もう世の中で話題すぎて仕方が無いwaifu2xです(説明はしないので各自ぐぐれ)。

ultraist.hatenablog.com

ところでwaifu2xを見て、皆さん思いませんでしたか?

waifu2xでSD画質のアニメのアップコンバートしてえ!

でもWebアプリだしアニメのアップコンバートなんて…と思ったらGithubでコード公開されてるし、AWSのPublic AMIもあります(北カリフォルニア ami-75f01931)。

自宅でwaifu2xサーバを立てるのもいいですが(その話はまた後日にでも書きますけど)、もうサクッとAWSにg2.2xlargeのスポットインスタンスを立ててしまいましょう。1時間7円くらい、1日170円くらいですよ。

というわけでこのブログの筆者、いまさらAWS童貞を脱出…



※追記(注意!)

本件では2015/5/22~27でのg2.2xlargeの最安スポットインスタンス(北カリフォルニアリージョン 約$0.065/1h 為替レート$1=約122JPY)を使用しています。

スポットインスタンスのレート変動の特性を考慮の上、作成と最高価格の設定をお願いします。



では早速、waifu2xで実際にSD画質のアニメをアップコンバートしてみます。

今回の素材。いまTOKYO MXで再放送やってるこいつだ!

f:id:unsuitan:20150527164250p:plain

苺ましまろ」もBD化されてませんので、アップコンバートの素材としては丁度いいでしょう。

※追記(2015/08/21) 苺ましまろ BD-BOX発売決定!

www.hmv.co.jp

・「苺ましまろ」をwaifu2xでアップコンバートするとこうなる

では手順説明の前にアップコンバート結果から。

左が地上波そのまま(以下TS)、右がwaifu2xでアップコンバートして最終処理としてh.264エンコードしたもの(以下waifu2x後)をWindowsMPC-HCで再生させてキャプチャしたものです。

f:id:unsuitan:20150527175747p:plain

コッポラちゃん尊いんですけど、エッジのドット妨害やクロスカラーがきちんと除去されています。SDソースのHD再生でありがちな色のぼやけも無くなって均一感が出ています。

ただ環境によって見えるかもしれませんが、TSで若干見える肌色化けがwaifu2x後で増幅されています。いまこれ書いていて気付きました(MBAだと見えるけど別の液晶だと見えない)。動画だと分からないんですけど…


f:id:unsuitan:20150527181641p:plain

アップコンバートでよく比較されがちなテロップです。

さすがにwaifu2x後ももう一息という気はしますが、それでもTSと比べると雲泥の差ですので合格でしょう。TSなんてもはや虹色って感じですよね。


f:id:unsuitan:20150527183044p:plain

萌えアニメだけど若干動きがあって、しかもブランコの鎖なんてすごく苦手そうな箇所ですが、waifu2x後はきちんと仕事されてるという感じですね。


f:id:unsuitan:20150527183230p:plain

SDのアップコンバートで一番厳しいのはこういう引きの映像で、元の解像度が低いからどうしても潰れて残念な結果になりがちですけど、ノイズリダクションがきちんとかかると印象もずいぶん変わるものです。

※追記 確かにフェンスの網が潰れちゃってますね…こういうのは仕方ないところなのかも。キャラに目が行って気付かなかったです。


f:id:unsuitan:20150527183743p:plain

懸念してた「被写界深度の表現が死なないか」です。スクーターの奥はノイズリダクションがかかって平準化されたせいかボケが無くなったように見えますが、スクーターの手前の草が揺れているところのボケは死んでいません。この草はスゴイと思いました。

しかし萌えアニメなんでこれ以外の被写界深度の表現がある場所を探すのも厳しいんですが、もしかすると「手前は得意だが奥は苦手」とかの弱点はあるかもしれません。


今回の手順は以下になります。

大まかな流れは「動画のフレームをJPEG化してwaifu2xにかけて、Motion JPEGで繋ぎ合わせて必要に応じてエンコ」という感じです。かなりの力業ですね。頑張りましょう。




(1) 動画のフレームをJPEGに切り出し、ついでに音声も別に抜いておく

FullHD(1920x1080)の動画を生成するのが目標となりますが、waifu2xは2倍スケーリングができますので、欲しいJPEGの解像度は「960x540」になります。

色々と方法はあると思いますが、我が家は「TMPGEnc Video Mastering Works 5」がありますのでそいつでJPEGに吐き出しました。解像度とか設定して処理開始して待つだけです。

はい。55245枚(合計17GB)JPEGファイルが生成されました。

ffmpegでやりたいという人が圧倒的多数と思いますが、やり方は以下になります。

出力先のファイル名前は「img_0000000.jpg」からスタートして7桁の数値部分がインクリメントされる前提です。

$ ffmpeg -i [動画ファイル名] -f image2 img_%07d.jpg

ffmpegで生成すると…55253枚(合計2.8GB)。どちらを信じて良いかわかりません。

ffmpegの場合、この後にアスペクト比を16:9に変更したり(地デジソースだと1440x1080のため)、960x540にリサイズする必要がありますが、このあたりは各自でうまくやって下さい。

音声の抜き出しは…まあ各自適当にやってください。ffmpegでこんな感じですかね。

$ ffmpeg -i [動画ファイル名] -acodec copy [出力先ファイル名]

とりあえず今回はTMPGEncで吐きだしたほうを使ってみたいと思います。AWSに持って行くのつらいけど…

別に容量の少ないffmpegの吐き出したJPEG使ってもwaifu2xが何とかしてくれそうですし(waifu2xってそういうソフトですから)、真っ当な脳味噌の持ち主なら2.8GBのffmpegを選ぶでしょうが、

TMPGEncffmpegで枚数違ったら、データ量が6倍違ってもTMPGEnc信じるなあ」

という感じです。AWSの転送量もinboundは無料ですし。

(2) waifu2xでアップコンバートする

なんとかしてサーバ側にJPEGファイルをアップロードするなりなんなりして(手段は各自で考えて)、実際に55000枚オーバーのファイルのアップコンバートを始めます。

waifu2xの動かし方はGithubのドキュメント読めという感じです。

github.com

さすがに枚数が枚数なので、普通はシェルスクリプトを書くことになるはずですが、環境(ぼかした表現)によってはth実行時のカレントディレクトリがwaifu2x.luaのあるところでないとダメなようです。あとスクリプト内では$PATHとか$LD_LIBRARY_PATHとか通しておきましょう。

waifu2x自体の実行書式はこんな感じですが、ノイズリダクションレベルは処理速度に影響しないようです。

$ th waifu2x.lua -m noise_scale -noise_level 2 -i [元ファイル] -o [変換先ファイル]

処理速度についてはAWSのg2.2xlargeで1枚ずつ処理すると約4.8秒/1枚ですが、2枚同時に処理すると8.0秒/2枚になり若干早くなるようなので、2本を並列で動かしたほうがいいでしょう。

どこまで並列でいけるかは後日ネタにしたいですけど、g2.2xlargeでこういうケースだと3本以上はそんなにメリットはなさげなのと、7本を超えるとエラーが出始めるので、2本でいいと思います。

ちなみに今回は何も考えずに1枚ずつ処理してしまったので55245枚を処理するのに83時間(3日と11時間)かかりました。理論値上では74時間くらいですが、処理の最中にちょっと実験してみてたのと、多少の誤差やオーバーヘッドが積み重なったのがあると思います。

2本並列だと3日切れるかな?という感じでしょうか。

なおwaifu2x変換後、JPEGの合計サイズが17GBが6.1GBに縮んだことをお知らせします。

(3) JPEGを繋げて動画にする

処理が終わったらJPEGファイルを繋げて動画(Motion JPEG)にします。ついでに音声ファイルも繋げ合わせます。TMPGEncではできないようなのでffmpegを使ってます。

フレームについては地デジソースなので29.97fpsに設定していますが、このあたりはうまいことソースに合わせて下さい。

入力ファイル名の連番は先ほどの「img_0000000.jpg」から始まる7桁の整数前提です。

「-qscale 0」は無劣化でそのままパラパラ漫画化するオプションです。昔は「-sameq」だったようですが現在は廃止されてます。

$ ffmpeg -r 29.97 -i img_%07d.jpg -i [音声ファイル名] -vcodec mjpeg -qscale 0 [出力先動画ファイル名(.avi)]

これで再生できる動画ファイルは完成です。ファイルサイズは6.8GBになりました。

ただやはりサイズが大きいのと、このまま再生させるとインタレースがキツいので、インタレース解除ついでにMPEG4にエンコードします。

エンコについては各自でうまいことやって下さい(こういうのはTMPGEncが楽)。インタレース解除は地デジソースの場合はトップでどうぞ。

・感想

思った以上に良い結果が得られました。画質は。

ただ手間ヒマとか時間はかかります。AWSを使ったとしても処理や通信の時間を考えると30分アニメ1本で3〜4日は見ておいたほうがいいでしょう。

そしてAWSのg2.2xlargeを4日回すと700円近くかかります。

では家で回したらどうなのかというと次回のネタにしようかと思いますが、Core i5+GeForce 730の物理環境で適当に検証したところ、1枚の処理時間が約20.5秒でした。55000枚を処理するのにオーバーヘッドも考えると約16日かかります。

CUDA Core数はGeForce 730が384、g2.xlargeは1536ですので、Core数と処理速度は上手い具合にスケールしています。

でも家でこれやるとして、CUDA Coreが1536もあるようなGPU回す?ボード自体のお値段も高いし、ブン回し続けると電気代とかは…?

GeForce 730は消費電力25Wだからぶん回すのも苦じゃないけど、16日。「放っておけばそのうち終わる」と考えられなくもないですが。

そんな感じで色々と金とか時間とか色んなモノを勘定をしつつ、手持ちのSD画質のアニメのリストを眺めて「マイナーすぎてBD-BOXなんぞ出ないだろうなあ」とか思いながら、実行に移すか考えるといいんじゃないかなと思います。

ワシ?うーん。もうやらんじゃろうこんなんw