【超解像】Lada part6

前スレ
【超解像】Lada part5
https://egg.5ch.io/test/read.cgi/software/1782703217/

■　URL
Lada
https://github.com/ladaapp/lada/releases

Jasna
https://github.com/Kruk2/jasna/releases

Lada-EX
https://codeberg.org/comman/lada-ex

検出モデル　v2_accurate
https://huggingface.co/zelefans/vrmr/tree/main　の
lada_vr_mosaic_detection_model_v2_accurate.pt

除去モデル　basicvsrpp-generic_v1.2_full
https://huggingface.co/ladaapp/lada/tree/main　の
lada_mosaic_restoration_model_generic_v1.2_full.pth

■　不具合があった場合に試してみる事

・GPUスケジューリング　オフ
スタートメニュー＞設定＞システム＞ディスプレイ＞グラフィックの設定
ハードウェア アクセラレータによるGPUスケジューリング＞オフ

・最新グラフィックスドライバに更新

>>14
今日アップデートされてた

flashvsr_inline_secondary_restorer.py
flashvsr_inline_worker.py
flashvsr_offline.py
flashvsr_phase2_driver.py

この4つを書き換えればおｋって事？

>>15
git使ってｗ
他にも更新しているファイルがあるから git pull してくれ

>>16
実はこのへんのファイルを既にいじってる(offline処理でFlashVSRX4＆クリップサイズ512で実行に設定して、最大でVRAM消費が11G弱)ので
とりあえずバックアップをまるごと取ってからアプデしてみるね
色目は確かにズレた違和感あったので合わせられるとありがたそう

>>8と>>18は女より男が好きらしい。

>>2だった

そんな必死に否定せんでもええがな

きっしょ

flashvsrの4倍めちゃめちゃ時間かかるね
4fpsぐらいしか出ないから5分の動画の処理に30分以上かかりそう

>>14
13700＋4070の環境で
・一次basicVSR＋二次FlashVSRX2(タイル分割処理なし)＋inline設定(一時修復プロセスのブロックごとに即実行、でいいのよね？)
　Maxクリップサイズ=512程度なら、1080Pソースの処理にVRAM消費11GB前後で行ける
・これまでよりすげー速くなった、もうJasna本家に導入されてもいいくらいでは…
・修復部位の色合いの違和感が消失
・FlashVSRX4はタイル4分割なら実行可能だった、X2との仕上がりの違いは試した範囲だとあまりわからなかった

2次修復の精細度はJasnaの画像修復に近い精細度を動画でやれてるくらいな感じ
毛のディティールが過剰になりがちなのはFlashVSRの癖っぽい？
一つ気になったのは2次修復まで終わってエンコードに入っても、VRAM消費が高止まりなままだった事

次の更新いつくるんだろ

復元モデルもアップデートして欲しい
でも重くなりそうだな

>>24
VRAM消費が高止まりのままだったのはoffline指定で動かした時の挙動？
jasnaの処理が終わってもVRAMを開放せずに残っていたとかだったらまずいんで
もし不具合っぽい動作があったらgithubのissueで報告してもらえると助かります

>>27
inlineのほう
短すぎない動画で実行すると、修復とエンコードがある程度同時？交互？進行していてVRAMを保持しているのは分かるんだけど
修復が100％終了して、エンコードのみ残ってる状態でもVRAMは修復実行中と同じく、11G前後使ってるままで最後まで進む
エンコードも終われば解放される(複数動画をまとめて登録して実行した場合も大丈夫)
offlineでの起動はまだあまり試してないので判りません

>>28 なるほど
進捗バーの100%は「修復完了」じゃなくて「デコードと検出が終わった」時点で到達するんだわ
なので100%になった後もキューに残ってる分をFlashVSRがまだ修復中
VRAMがつかみっぱなしに見えるのはそのためで、裏でまだ働いてる状態
解放はパイプライン全体が終わってモデルを捨てるタイミングなので、残りの修復が片付くまで保持
inline版はモデルを常駐させる作りなのでこうなってます (offline版は別経路)

あと、クリップサイズ512だと1クリップが閉じるまでが長いので、100%の後に残る処理もその分長くなって余計目立つと思う
ちなみにinline版はクリップを小分けにして流す作りで、その小分けの単位はクリップサイズとは別にFlashVSR側で固定されてる
クリップサイズを大きくしても小分けの数が増えるだけでサイズは変わらないので、FlashVSR側のVRAM常駐量はほぼ一定だったりする

>>29
じゃあ心配しないでこのまま使いますね
二次修復の出来は個人的にはladaが登場した時レベルの衝撃、素晴らしいお仕事

>>13
thx
012の app/Contents/Resources に runtime 以下が含まれていなかったので
010から拝借したらモデルのcoreai変換できた

>>31

報告ありがとうございます。
同梱するようにしました。

もしよかったら環境とfpsどれくらいでてるか？教えてください。

>>29
ちょっと質問
>inline版はクリップを小分けにして流す作りで、その小分けの単位はクリップサイズとは別にFlashVSR側で固定されてる
この「FlashVSR側で固定されてる」クリップサイズって数値はいくつ？
これに合わせて・あるいは等倍で設定しておいたほうが能率よかったりする？

>>33
FlashVSR側で固定なのは「サイズ」じゃなくて刻み
クリップを8k+5フレーム(最低21)に切り上げて、先頭21→あと8ずつ回す作り
合わせるなら8k+5の値(93、125、181)が候補
効率に効くのはクリップを長くするほう(既定(--temporal-overlap 8)だと境界ごとにoverlap 16フレームを二重処理してるので)
実測で90→93が−4%、90→181が−10%、240で頭打ち、VRAMは181で+0.2〜0.4GB

目安: VRAMに余裕があれば181、16GBでscale 4の1080pみたいにギリギリなら93
(既定の90のままでも損失は4%程度)

>>32
早速の対応ありがとうございます
今後も期待
Mac mini M4 16Gですが、fpsは元素材によって変わってしまうので何とも。