【超解像】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スケジューリング＞オフ

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

5060ti16g、きっと無謀だろうなと思いつつ4Kの3時間をぶっ込んでみたらETAは10時間以下だった（標準•高速）
昔を考えたら全然問題ないな

0.11.2で初めてLTXやってみようと思ったら、マシンキー取得できずで足止め
0.11.3でやっとできると思ったら、ESET（NOD32）がジャマをする
jasnaフォルダを除外に入れてようやく動いて、仕上がりの凄さに感動
ただ、筋と指の線を区別できなかったのか、ずぼずぼ入れている指が消えることがあって笑った

書庫展開したらウィルスバスターに1ファイル削除される。

>>800
それ、多分 Step1/4 だけの時間だよｗ

ETAは2/4からじゃないと表示されない気がしたが

Step1はモザイク解析時間でETAはStep2以降の残り時間
なので長時間高解像度高ビットレートの動画であればStep1は比例して伸びるよ

新しいVersionでLTXモデルがダウンロード済みでltx-restoreフォルダーにあることを教えることはできないのかな？
前のVersionからフォルダー一式をコピーして起動しても毎回矢印ボタンクリック時にダウンロードに行くんだけど

>>806
モデルファイル（.enc）ファイルをmodel_weights\ltx-restoreに移動させるだけで認識するよ
標準画質ならltx-restore-alpha1-distill2-int8.safetensors.enc
もちろんjasna起動中にファイルを移動させたならjasnaの再起動が必要だけど

何だろう俺たちは他人のイキリ立ったチンポを如何にして鮮明に再現するために必死になっているのだろうか

そこにチンコ(or マンコ)があるからさ

顔面モザスキップ機能が欲しいね
恐ろしく時間がかかるから

>>810
わかる

ここへ来て供給源が絶たれるとはな
PHPめw

FANZA等のエロサイトは皆メンテ中か

顔モザって破壊されるの？中途半端にぐにゃぐにゃの顔が出てきたら萎えるんだけど。
あと、素人設定の動画で女の子の顔モザのがあってそれが取れるならちょっとうれしい。

オチョナンさん出てくるからやめとけ

まあ無理だよな

顔のモザイクの復元よりも、デビュー作の冒頭で時々ある、卒業証書のモザイクの復元に興味がある。
卒業証書が作り物の可能性もあるだろうが、どこまで本物に似せて作ってあるのかとか、卒業証書の生徒名は、女優名なのか、本名なのかとか、その辺が気になっている。

>>817
それは今の復元モデル(BasicVSR++やLTX)の学習範囲から外れてるだろうからjasnaでやることではないなｗ

Macでも独自実装でLTX動いてる。

M5 Pro 18core 20 GPU 48GBで9fps。
たぶん4倍近く時間かかるね。

>>819
LTXのモデルってどうしてるんですか？

>>820

LTXでNSFWを追加学習したモデルがあって
それを使って独自に追加学習して使っています。
sulphurってモデル。

https://huggingface.co/SulphurAI/Sulphur-2-base

Jasnaのどのバージョンでも、設定いろいろ変えてもモザ残りとボケが出る　大〇聖〇の羽目シーンがLTXで完璧に仕上がりました
これは画期的、時間はかかるけど結果がこれなら許せる

他にも出来の悪い素材をTMPGEnc Smartレンダラーでお好みシーンだけ切り出してLTXで再処理します

>>803
朝起きて確認したらトータル8時間で完了してた

>>821
そういうモデルがあるんですね
出力の品質次第ですが、LTXモデルで実時間の4倍なら悪くはないと思います

>>823
マジすか！( ﾟДﾟ)

【Jasna 0.11.3】長尺動画処理結果
■まとめ：1時間45分の動画を新既定の標準画質 + Fast modeオンで通した、LinuxとWindowsの比較
・Linux：89分、動画の長さの0.85倍、つまり実時間より速く終わった
・Windows：100分、0.96倍　※初回のスピードテスト2分は除く
・この動画はモザイクが少なめ（ウィンドウ数が他の作品の7割くらい）なので、普通の作品だと
　動画長の1.1〜1.3倍くらいになりそう
・<参考> 別PCのWindows＋RTX 5060 Ti 16GB（同じ動画、同じ設定）：221分、動画の長さの2.1倍

■動画の情報、LTX処理設定
・1080p 29.97fps H.264、1時間45分（188130フレーム）、モザイク327トラック、1285ウィンドウ
・設定は標準画質、Fast modeオン、Less overlapオン、HEVC 10bit CQ14 preset p7
・同じPC（RTX 5080）のdual bootでUbuntu 26.04とWindows 11(26H2)を1回ずつ処理
■処理時間詳細
・1ウィンドウあたりLinux 4.2秒、Windows 4.7秒
　※0.11.0-rcで旧既定の高画質Fastに2時間18分の動画を通した時は8.8秒で動画の2.6倍（6時間弱）だった
・内訳（Linux）：ステップ1（検出）7分、ステップ2（VAEエンコード）17分、ステップ3（復元）28分、
　ステップ4（VAEデコードと書き出し）37分
・VRAMピークは両方10.5〜10.6GB、Fast modeオンだと48ブロック全部VRAMに載る
■WindowsとLinuxの差
・全体で1.12倍、内訳はステップ1（検出）1.35倍（444→328fps）、ステップ2（VAEエンコード）1.08倍
　ステップ3（復元）1.05倍、ステップ4（VAEデコード）1.19倍（1ウィンドウ1.45→1.73秒）
・0.11.2の時の30秒1.55倍、140秒1.2倍から、長い動画ほど差が縮む傾向のとおり
　残ってる差は固定費じゃなくてステップ1・2・4（検出とVAE）のスループット
■別PCのWindows＋RTX 5060 Ti 16GB（同じ動画、同じ設定）
・処理内訳：ステップ1（検出）20分、ステップ2（VAEエンコード）42分、ステップ3（復元）73分、ステップ4（VAEデコードと書き出し）87分
・Windows＋5080との比はステップ1が2.1倍、ステップ2が2.2倍、ステップ3が2.5倍、ステップ4が2.0倍、全体2.2倍
　カタログ比（CUDAコア0.43倍、メモリ帯域0.47倍）の逆数と同じ水準

>>826
5080だと約1倍の速度で処理出来るんですね…でも買えない
自分の5060Ti(16GB)だと0.11.3でも4倍くらいかかってしまう（標準画質+高速モード、rfdetr-v6、しきい値0.15）
どこか設定が良くないのかな？

>>827
lada-yolo-v4でしきい値0.1で良くない？

>>827
自分もv0.10まで仕上がり時間に影響しなのでしきい値0.15で使ってたけどデフォのしきい値0.35と0.15じゃ全然時間違うよ、考え直し中

>>829
0.35も考えたけど、時間かけた結果ダメだったらつらいので、0.15にしてる。
LTX plan: 215726 frames, 229 scene cuts, 3699 tracks, 4803 windows
2時間もので、この数値は多いのかな

>>830
2時間で4803ウィンドウは多めだと思う
1時間あたり約2400ウィンドウで、今回の動画（737）の3.3倍、これまで自分が測った他の作品（1000〜1300）の2倍くらい
また、気になるのは3699トラックのほう、1時間あたり1850トラックで、今回の動画は既定で187、0.15でも577だった
ウィンドウ数÷トラック数が1.3なので、計算上はほとんどのトラックが1ウィンドウ（120フレーム、30fps動画で4秒以下）で終わってる
普通はモザイクが何秒も続いて何ウィンドウにもなるはずなので、短い断片がかなり混ざってそう（総集編的なやつ？）

いきなり本番じゃなくて、しきい値0.35で検出だけ回してウィンドウ数を見てみるのはどう？
--log-level infoで「LTX plan」が出たら止めればいいので(GUIの場合はログウィンドウの所で確認できる)、2時間ものなら25分くらいで済むと思う
それで半分以下になるなら、数分の区間だけ0.35で処理して見逃しがないか確認してから本番やるとか

数字では見えないが処理範囲指定のツールでスキャンしてから閾値をイジると検出範囲がリアルタイムで色が付くから目安には使える
誤検出かどうかはプレビューで確認できるし取りこぼすシーンがわかっているなら検出されてるか否かの判断も付けられる

>>831
しきい値 0.15: 215726 frames, 229 scene cuts, 3699 tracks, 4803 windows
しきい値 0.35: 215726 frames, 229 scene cuts, 941 tracks, 1861 windows
重なりを減らす+ しきい値0.35で再開 ETAでは4h56m (終わってみないと判らないが) 2時間ものなので2.5倍まできた

>>824

実際はもっと遅かったです。
4fpsとか…

>>834
Claude Codeで調べたらSulphurはLTX-2.3と同じ構造なので、復元学習済みのモデルがあれば重みの変換だけで
jasnaのコードはほぼそのまま載せられそうとのこと
LoRAなら業務用GPUレベルを使わなくても追加学習できそうなんですが、その追加学習はLoRA（v2v / IC-LoRA）ですか？

さすがに今のLTXモデル並のレベルには到達できないと思うけど、どこまで行けそうかは興味あるｗ

認識漏れはbasicvsrで試してからltxで作業してる
正しいかわからんが

認識漏れはモデル別に確認できるやん

>>835

IC-LoRAとのことでした。

画像だけ渡すと勝手に改変するので改変しないように輪郭を教える感じ。

>>833
2時間物完了、処理時間は5h15minでした。
動画を確認したが、しきい値0.35で全く問題なかった

確認やが、増やすと時短になるしきい値て検出しきい値の事？シーンカットのごく短い動画やが、ワテの環境やと0.10から0.25に上げても時短にならず少し時間増になった。50のグラボや無いから？

IPZ-722のJasnaで破壊したやつが無修正なみに凄かったんですがこれって普通クオリティですか？
VKで見ましたが驚きました
https://www.sehuatang.net/forum.php?mod=viewthread&tid=3842089&highlight=

LTXモデルで処理したやつなら
標準でも高画質でもGridPlayerとか使って同時に表示してよーく見ないと見分けつかないよ

>>840
そう、検出しきい値のこと
処理するモザイク量はステップ1で計算してて、ここは50系のFast modeオンは関係ない
>>833 みたいにしきい値変えたらLTX planの数字がどう変わったか確認すればよいと思う

30秒とか1分の短い動画だとモデルロードなどの固定的にかかる時間の割合が大きいので
この処理時間のブレとかがあるかもね(何回か測って毎回同じ結果になるのか、とか)

>>839
自分もいくつか処理してみたけどv6のしきい値0.35で問題無さそうだわ

>>843 教えてくれてありがとう、もう少し試してみるわ。

TecoGANの時代を考えればRTX5060(8GB)でも結構やれる。

FHD(1Hr)動画、編集済でほぼ全編モザイクありのLTX復元が6時間40分で終わった。
LTXの設定は・良好画像・高速・v6・検出0.35
1分の動画で色々テストした時は元尺の10～20倍かかったので悲観していたのだが
短い動画ではオーバーヘッドが大きくてあまり参考にならないようだ。
復元結果が素晴らしすぎて、時間がかかってもBV++には戻れない。

>>841
確かにこれすごいですよね。自分で同じものをやってもここまでならなかったです。
何か特別な設定をしているとかしか思えない。

URLが怪しくて踏む気がしないが普通画質でやっても無修正か分からないレベルで
高画質で処理しならなおさら、大差出るとは思えないけどなあ

破壊という名目で流出売るメーカー出ないかな

Discordで2015年頃の動画が綺麗に処理できるか議論あったけど、後処理でSLPとか通してるんじゃないの

3090で2160p動画を使って最高画質を試してみたらoomエラーで止まってしまった。nvfp4が使えないからだとおもうけど、vramにモデルが乗ればいいってわけじゃないのね。

>>841 >>847
一体何を言うとるのや って感じだがｗ
jasna0.11.1から実装されたLTXはもう従前のBasicVSR++とは別世界なのよ　無修正と区別つかない
短時間のサンプル動画用意して自分でやってみ　すげえから

>>852
すでにやってます。けど仕上がりが自分のより一段上という印象があります。

>>841
は？LTXマジでこのレベルになるんか…やばいな…(クラウドライセンス待ち勢

>>853
返事さんくす。
なるほど、FANZAの元動画は720pでBlurayも出てないタイトル、でもリンク先の動画は1080pなんだ。
処理終わってからTVAIとかで全体アプコンする、とかしか思いつかんなぁ。
その後で仕上げにコントラスト調整までやってそう。

確かに中華勢の中には0.10.0以前からすごいレベルのが混ざってたね。
リンク先の職人も達人とか呼ばれとるしｗ

vsrでも相性良い奴は無修レベルにはなったから、きっとそれだろうな
その相性探しが一つの楽しみだった
でも、もうそんなのはすべて無駄
現役の高画質JAVが最高の素材になった

5060Tiが届いてウキウキためしてみようと思ったら、
処理がスタートしてしばらくでエラーってなってしまう。
Jasnaをインストールしなおして、システムチェックもすべてチェックなんだけど
どうして？教えてくだされ…

LTXの方はいけました。
BasicVSR++の方が処理始まって
初回起動は時間がかかる場合がありますをOKして
しばらくしたらエラーになっちまいます。(>_<)

>>857

ログとか貼らないと、何も言えないよ

昔のデカモザはだめですね

02:48:01 PM INFO PermissionError: [WinError 32] プロセスはファイルにアクセスできません。別のプロセスが使用中です。: 'C:\\Users\\user\\AppData\\Local\\Temp\\jasna-a303fa8de22d76b5f9143b08662da2cd\\cuda\\.gclock'

これが原因ぽいです。

>>858
復元モデルをfull版に差し替えてたらエラーになる

>>862
特にいじらず、解凍してCドライブに置いて使ってるんですが、
どこがよくないのでしょう？

なぜログをすべてAIに放り込まないのか

>>863
jasnaのクリーンインスコをお勧めしたい。
多分、初回コンパイルってのがGPUボードに最適化する作業を含んでて、それでアンマッチが出てるんではと。
jasnaのフォルダを全部削除してから、DL＆展開したてのやつを展開して起動するだけ。
コーヒー奢ったライセンス情報とプリセット情報は別フォルダにあって引き継がれるから問題無し。

>>863
ごめん。>>865はもうやったんだね。

あとは、NVIDIAドライバのアップデートやってみるとか。
最悪はBVSR++の時だけ旧バージョンでやるとか。

ワイも11になってbasicvsrエラーになるわ。10まで使えてたのに。

グラボを4060Ti 8GBから5060Ti 16GBに換えただけなんですが…
このままだと4060Ti 8Gに最適化されてるだろうから、
元の圧縮ファイルから改めて解凍して置き直してやってます。

クロードさんに「以下のエラーの原因と対処方法が分かりますか？Windowsです。」＋>>861の内容
で質問してみて。一般的回答が返ってくるけど参考にはなると思う。

ちなみに返ってくる返事↓

【原因】
WinError 32 は、別のプロセスがそのファイルを開いたまま（ロックしたまま）なので、操作（削除・移動・リネームなど）できないという意味です。

今回のファイルは Temp\jasna-xxxx\cuda\.gclock で、アプリが一時フォルダ内に作ったロックファイル（排他制御用）です。よくある原因は次のとおりです。

前回起動したプロセスが残っている（異常終了やクラッシュ後のゾンビプロセス）
同じアプリを二重に起動している（複数のインスタンスが同じ一時フォルダを使っている）
ウイルス対策ソフトやバックアップ・同期ソフトがスキャン中（Windows Defender など）
終了時の一時フォルダ削除と、バックグラウンドのスレッドや子プロセスのファイルアクセスが競合している


【対処方法】（上から順に試してください）
残っているプロセスを終了する
タスクマネージャー（Ctrl+Shift+Esc）を開き、python.exe、jasna 関連、ffmpeg など、関係しそうなプロセスを終了します。
迷う場合は PC を再起動するのが確実です。
一時フォルダを手動で削除する
プロセスを止めた状態で C:\Users\user\AppData\Local\Temp\ にある jasna- で始まるフォルダを削除し、もう一度実行します。
削除できない場合は、そのフォルダを使っているプロセスが残っています。
二重起動していないか確認する（複数のウィンドウやターミナルで同時に動かしていないか）
ウイルス対策ソフトの影響を確認する
一時的にリアルタイム保護をオフにするか、Temp 内の該当フォルダを除外設定にして再実行します。
どのプロセスが掴んでいるかを調べる
リソースモニター（resmon）の「CPU」タブ →「関連付けられたハンドル」で .gclock を検索すると、掴んでいるプロセスが分かります。
Sysinternals の handle.exe や、PowerToys の「File Locksmith」でも調べられます。

NVIDIAドライバ最新にしてダメなら一度DDUでクリーニングしてからドライバ入れ直してもいいかもね

ドライバはSUTUDIO 617.42です

>>858
それテンプレのlada-yoloに差し替えてないか
今のjasnaだと無理になってる

>>874
>>641

検出モデルはデフォのrfdetr-v6でやってます

細かいとことよく分かってないので、ダウンロードしてきて、解凍して、設定いじらずやってます。
なんでBasicVSR++はうまくいかないんだろう…

グラボを4060Ti 8G から 5060Ti 16GBに換えてドライバ最新のにして
やってみました。LTXの方は問題ないのですが、BasicVSR++の方だとエラーが出ます。

>>860

大きいモザイクモードでもダメなの?

自分はＧPUのVRAMが12GBなので試せてない。(VRAMの空きが12GB以上ないと有効にならない)

>>878
4000番と5000番は全く違うとおもうので先のコメのDDU＆CUDA関連もきれいさっぱり再インストールじゃな

やってみます

まじめにちんこ擦り切れ対策した方がいいなこれは

>>882
つ てんが

ローション使ってちんぽ擦り切れ回避しろ

MacでLTXかけた結果。めちゃおそ。

https://discord.gg/cwxSBK9Tk

jasnaの方見たこと名かからわからんけど、どう？

>>853
720Pからの高画質化は例えばFlashVSRX4使えば行ける、肌の質感を自然にする力が凄い高いモデル
このスレでも紹介されてるから興味あったらスレ内検索して調べてみてね
X2だとグッと処理が軽いし十分綺麗になるけどモジャ毛を増やかす傾向がちょっと強い

アソコがグンニャリ潰れたように加工されちゃってた動画もLTXならきれいにやれるかな？

無事に動作するようになりました！

Jasnaを終了した状態で `%TEMP%` フォルダを開き、その中の
`torch_tensorrt_engine_cache` フォルダを削除しました。
その後、Jasnaを再起動して再度試したところ、
TensorRTエンジンのコンパイルが正常に完了しました。

ありがとうございました

LTXはモザ無しシーンもなんかやってるから、動画1本喰わせるとめちゃめちゃ遅くなるね
モザ無しシーンだけ切り出して大きなモザのみLTX2%の設定にしてもそれなりに時間かかった
この辺改善されると良いなー

>>889
モザなしシーンでモデルは動いてなくて、重いのは全フレームのデコードと再エンコードだと思う
--ltx-auto-split 指定ならモザなし部分は勝手にコピーしてくれるから、切り出しの手間はいらない
小さいモザは BasicVSR++ でいいなら%大きくすれば速くなるし、2% だとほぼ全部LTX行き

>>887
バカでかいモザの場合、
動きがあるやつはそこそこ破綻少なく生成してくれるけど、やっぱグニャリはあるね
特にくぱぁのまま動きがないやつとかはマンコが1秒ごとに入れ替わったりするのでとても没入できないｗ

>>889
LTX自体はモザなしと認識したフレームでは何もやってないのでは
LTX planでモザだと認識したフレームだけでしょ

出力先もNVMeしたら早くなる？

>>893
自分も出力先の".ltx-****"という暫定フォルダの中にたくさんファイルを作っているようだったので
出力先をNASからローカルに変えてみたけど処理中もタスクマネージャーでのディスク稼働率が全く上がってないので、またNASに戻そうと思ってる。

手マンうぜえ

>>896　つづき　文字が小さくなる基準がわからんスマソ( ´Д`)

処理結果の違いについて
・StとTopで処理部分の形状が異なるということは無い
・一方、処理部分の解像度はSt：Top＝HD：FHDって感じに違うことが多い 差が無いことはレア
・処理時間は St/Top＝1/3〜1/4
・Less Overlap ONで処理時間は縮む でも脇で余計な負荷入れると簡単に効果無くす
・Less Overlap ONで処理部分が一瞬ボケたりノイズ入ることあり
・Less Overlap ONとOFFで 処理部分の形が違った結果になることがある どっちが良好とも言えない
・全体的傾向としてクリ周りの形状がころころ変わる傾向あり 顔だったら鼻の形が見るたび変わるみたいな感じ、特にマンコドアップのシーンでクリ周りの形がジワジワ変化することもある、この傾向はLess Overlap ON の方がかなり顕著になる、
・クソデカいモザでマンくぱで動きがないシーンとかは破綻こそしないもののマンコの形が1秒毎に変わったりするので始末に負えない、LO-ONの方がひどくなる、こういうレベルのモザはStでもTopでもどうしようもない、しかしデカモザでも何とか観れるレベルにまとまる場合もあるので事前に短いサンプルで試した方がいい

ちなみにクソデカいサンプルは2017年4月リリースのムテキな夢川さんのやつｗ

初めてJSNAを導入したときは初回のコンパイルは普通にできたんだが、新しいバージョン出るたびに毎回初回にやるコンパイルがエラー出まくり。

何回もやればそのうち走るんだが、新しいバージョンが出る度に毎回これで普通に使えるようになるまでに時間がかかるのがストレス。因にグラボはRTX4090。メモリも十分積んでるだが、何が原因なんだろ？

>>897
時間かかっても高い完成度を目指すなら「重なりを減らす(実験的·高速)」はOFFの方が無難という事かな