【超解像】Lada part7

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

■　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スケジューリング＞オフ

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

ladaというより
BasicVSR vs LTX　やろ

広く知られるとやばそうだから今の一定のハードル(高くない課金、クレカ必要)があるくらいでいいんじゃないか
ここまで言われてもやらないなら価値観が違うで話は終わり

0.12.2のVR処理、魚眼も非魚眼もグリッド模様が残っていかんわ
やはりVRはJasnaとは別で分割変換してやったほうがいいな

VRとモザイクは直接関係ないんだから作者に無理強いすんなよ

>>518
VR処理は、VR-Video-Toolbox-CEで片目ずつ分割→Jasnaで片目ずつ処理が良い？
画面端部の台形モザイクの対処とか、Tipsなどある？

basicvsr++とLTXは処理の仕組みが違うからね
比べても仕方がない

8KVRは一応実用的な時間で処理できるようになった、42分ほぼモザイクシーンあり動画で
5080で4時間半ぐらい、claudeに頼んでVR動画の結合を約1.5～2倍速くした
元動画は8bitだがJasnaの出力は10bit、結合時にデータ量が倍の10bitフレーム
GPU↔CPU間で何度もコピーしていて、特に8Kで詰まっているとのこと
対策: GPU上で先に8bitへ変換してからCPUに渡すようにした、コピー量が半分になる、元が8bitなので画質は落ちない
結果: 8Kテストで19→37fps、実運用で約1.5～2倍、残像なし
効かなかったこと、エンコード設定の高速化、新しいffmpeg、全GPU合成(残像が出た)

>>520
俺環ではVR-Video-Toolbox-CEはなぜかスムーズな動画ができないから
ノーマルのVR-Video-Toolboxでやるわ
ここの猛者たちがClaudeでやってることのほうが上を行ってるのかもしれないけど自分はそこまでしてない

>>510
BasicVSR＋の高速化も検出モデルのアップデートもJasna（の人）が進めてたわけで
そしてBasicVSR＋はそのまま使えてるんだからLadaに戻る意味はもうないんでない？

VRはVR_Video_Toolboxを使ってたんだけど、JasnaのLTXにも対応してる？
それとも今はもうJasnaに搭載されてるVR対応機能でやった方がいい？

>>495
処理にとにかく時間がかかるが大きなリターンがあります。
品質は子供が描く絵とカメラで撮影した写真くらいの差があります。
天と地のレベルで品質が違います。

こんなグラボ価格爆上げ中にLTXなんてものを作りやがって

>>495
あと大きなモザイクも問題なく再現されます。無修正に近いレベルで再現されます。

マシにはなったがモザイクが重なったときはまだイマイチだな

ましになったのレベルじゃなさそう

>>529
「重なったときはイマイチ」だけだとただの感想文ｗ　誰も確かめようもない
せめてどの設定使ったか書いてくれ

>>502

エロいものだよ

>>525
VR_Video_Toolboxの中のVR分割結合ツールだけを使ってる
分割した動画はJasnaで処理して、結合ツールで戻す

Jasna v0.12.2で増えた「LTXエンコーダー/デコーダー」(VAE)設定について

LTXは「動画を読み込む→AIが直す→動画に戻す」の3段階で動いてて、VAEは最初と最後の「読み込む」「戻す」担当
選べるのは full(一番きれい、一番遅い)、half(速い)、max(最速、少しやわらかい)の3種類
自動(既定)だと、Basicは軽いhalf+max、Standard以上は一番重いfull+fullになる
v0.12.1まではStandardも軽い方だったから、v0.12.2のStandardが遅くなったのはこれが原因

■測定サンプル(RTX 5060 Ti、1080pの30秒、高速モード)
・Basic + 軽いVAE(既定):156秒
・Standard + 軽いVAE:170秒
・Basic + 重いVAE:180秒
・Standard + 重いVAE(既定):195秒

■見た目
5通りの結果を同じ場面で見比べたけど、この動画ではどれも違いがわからなかった
数値で比べると少しずつ違うけど、目で見てわかる差ではなかった

■結論
・長い動画はBasic + 高速モード(VAEは自動のまま)が一番お得、Standardより2割くらい速い
・Basicがぼやけて見える動画なら、Standardに上げて、VAEは軽いhalf+maxにする
　「Basicのまま重いVAE」より速くて、変化も同じくらい
・Good以上のモデルは、VAEを変えても速さはあまり変わらないから自動のままでOK

■設定のしかた
GUI:エキスパート表示の「LTXエンコーダー」「LTXデコーダー」
CLI:--ltx-vae-encoder half --ltx-vae-decoder max

■補足
・試したのは実写1本の30秒だけ、大きなモザイクのアップ、4K、アニメだと差が出るかも
・組み合わせを変えて最初の1回目は準備(数分)が入る
・VAEはモザイクの取り残しやちらつきには関係ない、そっちは検出しきい値や--ltx-overlapなどで調整する

>>534
＞この動画ではどれも違いがわからなかった

だよな、フェラとまんのアップ二つを60秒ずつLTX基本、標準、高画質で処理したけど視覚差ない
差が出るフレームはシードの揺らぎみたいな差異でどっちが良いか判断できなかった

>>534
丁寧な説明助かります、有難う。

ファイル名に2バイト文字が含まれるとこけるんだけどウチだけ？

>>339
v0.12.2でも駄目で結局BIOS更新で無事通ってオフライン実行出来るようになった
ファンコンをBIOSでしてたから設定初期化されて面倒くさかった

>>537
2バイトでコケてるんじゃなくて長さでコケてるんじゃね？

ltxだとアニメもいけるのか