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

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

>>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の方が無難という事かな

FlashVSRってポータブル版でUltraFastでやっても結構かわる？

>>898
%TEMP% を開いて、Jasna-～～ってついてるフォルダと
torch_tensorrt_engine_cache ってフォルダを消したらいけるかも

>>897 検証おつ
作者がv0.11.3をリリースしたときにDiscordに書いてたコメント(意訳)

正直なところ、ほとんど違いは分からないからデフォルトは 2-step（Standard）にしている
4-stepはクローズアップのシーンや特にお気に入りの動画なら使う価値があるかもしれない
8-stepは十分に高性能なGPUがない限り、コストに見合うほどの差はないと思う
Top Qualityについては、正直あまり効果を感じない

v0.11.3のlibtcc.dllでウィルスチェック-アウトになりましたが、大丈夫ですか？

>>903
その情報だけだとわからん、使ってるスキャンソフトとどんな指摘だったか書かないと
jasnaは相性悪いソフトあるよ

rtx5070tiとrtx5060ti 16gbのユーザの人達に聞きたいです。元動画の何倍の処理時間掛かりますか？　標準で。

>>899
Less Overlap はさほどの時短効果がない上、余計なノイズが走ることがあったりして、肝心な所で萎えてやり直しとか考えると、OFF固定が無難だと思う。

>>902
ぶっちゃけると、マンコくぱぁガン見するのが大好きな変態かどうかで意見が分かれると思うｗ
んなもんちょっと気持ち悪くてハメてるシーンだけでいい向きにはStandardで充分、
マンコのドアップで目ん玉がこぼれるくらいガン見する変態にとってはHDかFHDかでかなり違うし、ノイズだの論外、どうかすると今のLTX-Topでも不満があったりする
（完璧を求めるなら人の顔の生成するのと同じロジックを適用して、目鼻口のようにマンコの各パーツを固定＆表情＝くぱぁとかクリ剥くとか尿道口やらヒダがどうとか、っていうマンコ生成専用のディフュージョンモデルが必要だと思うｗ）

海外の無修正とかって意外にマンコどアップでほれほれ見るがいい、みたいなシーンて滅多に無いんだよね。
日本系のカリビとかにはあるけど女優の質が圧倒的に違う（ごめん）
イキオイ表のJAVのそういうシーンを食い入るように見てしまうオレみたいな変態にはLTXの結果が有り難いことこの上ないのだけど、まだまだ完璧では無い、っていうのが正直な所。

というわけで、ドアップはTop、引きのシーンはStandard、って分割して破壊に勤しんでおりますｗ

マンコ特化型あればいいね

なんか話聞くとまだまだ8KVRは夢物語って感じやね
とはいうものの今更旧verで加工する気にもならないし、困りますな

遂に5060ti 16GBポチッてしまいました！

実際チンコの再現クォリティは極限まで到達した
でもマンコはまだまだだな
正直オレはチンコやフェラはどうでもいいんだわ
マンコの再現にこそ、破壊は全力を尽くして欲しいと思うね

5060Tiって今十三万もするのか。
数ヶ月前に9万で買って、3060Tiが2万ちょっとで売れたのはいいタイミングだったんだな。
Qwen がサクサク動くしな。
やっぱりGPU性能よりVRAM容量で選んで正解だったわ。

98堂とかロダの有料の動画配布サイトではもうJasna LTX以外の動画はダウンロードもされなくなった
近いうちに破壊職人は全部LTXになるだろうな

>>908
お、おうｗ
ところでクロースアップ好きなら効きそうだけど
書き換えキャンパスサイズを768pxに拡げるSharper large mosaic設定は使ってる?
時間は更にかかるけどVRAM 16GBあれば動く

丸々1本変換しようとしなければ、今でも十分早くなったと思うけどね

>>914
できれば何で破壊したかわかるようにしてリリースしてほしい

STEP4/4の合成・保存に時間がこんなにかかるのはどうにかできないかな？
動画の4割ぐらいの時間がかかっている（2時間なら50分程度）
5080のCudaは98％前後で動いてるけど、GPUエンコードはほぼ稼働なし、NVMeのディスクアクセスもほぼ無し。

>>918
そこは単にエンコードしてるんではなく、実質二次修復してると思ったほうが近いの
エンコードしつつ同時にディティールを書き足してる

>>918
ステップ3が速くなってステップ4の割合が相対的に大きくなってるよね
ステップ4（VAEデコードと書き出し）の時間は、ほぼすべてLTXのVAEデコーダが占めてて、GPUの演算で律速しているので正常な挙動
フレームの読み込み、合成、NVENCエンコードは、その裏で並行して進んでいて表に出てこない
Claude Codeに公開ソース（v0.11.3）を読ませてVAEデコード高速化の余地を聞いたら
品質を落とさない最適化の余地は数割程度（未計測の推定）で、今の倍にするのは難しく
倍を狙うならFP8化やデコーダの軽量化みたいな画質とのトレードオフになりそう