【超解像】Lada part6

女子目線の印象によると、結局男は女性器よりちんこの方が好きなように見えるらしい。
性的な意味ではなく。

>>2
フェラッチョも挿入も興味ないの？ｗ

mac版のmiohが404

mac book proユーザーだからlanaのGUI版使ってるけどすごく時間かかるね。
40分の動画でも10時間くらい？
window買ってもいいけど、どのくらいのスペックあれば快適なんだろう・・・

>>9

あまり需要がなくってプライベートにしてる

>>10

M5 Pro 48GBで160fps

>>11

公開した。

OS27必須と思って。

SeedVR2+LoRA一次復元の改善が行き詰まり気味なので気分転換にJasna modi版のFlashVSR二次復元をメンテした
・scale 2倍を追加(inline/offline両対応)：512px処理なのでinlineで約4〜5倍速くVRAM 3.5GB減、offlineだと約2.5倍速くVRAM 5GB減
・色補正を常時適用：復元領域だけ色味がずれていたのを、BasicVSR++ 一次復元の色調に合わせるようにした
・clip 32上限撤廃：inlineは通常の --max-clip-size(既定90)がそのまま効き、offlineは --flashvsr-max-clip-frames の既定を32→90にした
　これでFlashVSRの処理時間がほぼ半分になる
VRAM 16GB でscale 4を使う人は --flashvsr-tiles 2 を付けてくれ (scale 2はtiles無しでOK)

>>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は元素材によって変わってしまうので何とも。

>>35

FHDだとして等倍ぐらいの速度は出てます？

>>34
把握、感謝