【超解像】Lada part4

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

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

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

jasna v0.6.0系でGPUスケジューリングをONにしてても
最初のシステムチェックで弾かれるのと最後の合成をずれないように出来ないのかね

>>679
GUIのシステムチェックはソースを直さないとガードが外れない感じだね
CLIはffmpeg/ffprobe/mkvmergeのバージョン番号しか見てないからGPUスケジューリングがONでも動く
が、Claude Codeに調べてもらったところjasna v0.6.0系の動画処理パイプラインは問題を抱えていて
GPU処理の順番待ちができていない所があり、まだ処理中のデータを別の処理が読んだり上書きすることがある
同じ動画でも実行ごとに微妙に中身が変わり、検出位置が不安定になっているようだ(これがカクカクになる原因)
頑張って問題箇所2つ見つけて9割がたの処理はうまくいくところまできたが、完全解決は至っていない
GPUスケジューリングをOFF(LinuxだとCUDA_LAUNCH_BLOCKING=1)にするとこのGPU処理の順番待ち問題が出なくなるのできれいに処理できる

>>680
詳しい解説をありがとう
暫くは再起動しながらやっていきます

jasna v0.6.0で音ズレする原因がわかるかたおられますか？

jasnaの作者さん活動再開したっぽい

jasna v0.6.1、システムチェックは通るけどファイル読ませて実行しようとするとといきなりプログラムごと落ちる

jasna v0.6.1変更点を勝手に解説

＜重要事項＞
Torchスタックが更新されたのでエンジンファイルの使い回し(コピー)不可
以前のバージョンでコンパイルされたエンジンファイルがあったら消すこと

＜変更点＞
9fdfda2 NVIDIA ドライバ要件を 580+ に緩和 (#117)
02b7a91 frozen バイナリ時に jasna-cliがある場所のmodel_weightsディレクトリを見に行く >>650 の作者さん対策版
94a4222 PATH に無い nvidia-smi を一般的なインストール先から探索
23f93f7 GPU適用の .cube カラーLUT対応（CLI/GUI、#142）− 新機能
5879815 unet simplification（unet4x_secondary_restorer を簡素化）
f4b57d7 separable conv（blending）>>665 の対策が本家に入った 作者さんのGPUだと4kの効果が顕著
903b005 fp16/fp32 fixes（restorer/crop_buffer 周りの dtype 整理）
37d2098 update pytorch（torch 2.12 化）>>662 の内容と一緒
ce239ab bt601 support（HEVC VUI 書き換え＋BT.601 経路）>>662 の内容の一部を作者さんが実装
45abf01 stream sync（video_decoder.py）→ d346efc で 即 Revert（=v0.6.1）
d2029a2 mute warnings（_suppress_noise.py、torch/tensorrt の起動時警告抑制）

＜特記事項＞
・Linux版バイナリ配布は今回もなし
・カクカク問題は作者さんもまだ格闘中 (45abf01入れたが即リバート)
　なので、Windowws/Linux設定でのGPUスケジューリング対策は継続必要

>>665
すごいな

0.5.0からどう変わったかおせーてください

githuのログくらい確認しようぜ
VRAM使用量が減って速度が上がった感じか
特に4K

Jasnaの話がよく分からず、開発途中だから手を出さずに読み流してるんだけど
結局、Jasnaって本家Ladaと比べてどういう機能が便利でみんな使ってるのん？

俺は処理の速さとRTX Super ResによるSecondary Restoration機能 (Lada-EXもそうだが)

本家は線ががたがたになるときあるけどそれが起きない

pt/pthファイル差し替えてlada-yolo-v4で再コンパイルしてみたがonnxでエラーが出たわ

>>689

>>589

>>692
v0.6.1のソース確認したが、jasna.specファイルにyolo系のエンジンビルドに必要なパッケージ(”onnx", "onnxslim", "onnxruntime")が定義されてないから
このspecファイルを使って凍結バイナリを作っていたらyolo系はコンパイル通らないな

作者はrfdetr推しだと思うし、仕様か不良かグレー

lada-yoloが使えないと処理が遅くてしょうがない

>>690
>>693
ありがとう。どっちかつーとモザイク検出力よりも処理速度重視なのね

v0.6.1　進化あったのかな･･･？あまり変化を感じなかったが

>>697
v0.6.1の修正内容は性能デグレ対策、バグ対、BT.601対応、model_weightsの読み方改善など
細々したものが多いが作者が更新再開したことに意義があるんじゃね
今後に期待

>>680 の続き
残っていたカクカクはvaliのデコーダをcuvid → nvdec に変えることで解消できた
従来の cuvid だと動画の先読み処理がGPU計算とぶつかり、これが元で表示のズレが起きていたようだ
これを nvdec 経路を作って切り替えたら順番どおりに安定して処理できるようになりズレが解消
Windows/Linux側の設定でGPUスケジューリング対策をしなくても俺環ではカクカクが出なくなった！

なお、この方式は vali の修正と再ビルド・再インストールが必要

作者に報告したいが、現在githubのアカウントがシャドバン中・・・
金曜に+modiブランチの方に中華ニキがLinuxカクカク問題のイシューを報告してきたので
そのやり取りしていたら無邪気にNSFWな動画のBefore/Afterリンクを貼り付けてきた
すぐ消すように伝えて消してくれたけどgithubの監視に引っ掛かった模様

申し立てしたけど、いつ直ることやら

v0.6.1のソース確認したが、lada-yolo-v4で再コンパイルしてみたがonnxでエラーが出た
どうすればいいでしょうか？

試してみたけど、コンパイル済みエンジンがコピー不可で、しかもyoloはコンパイルできない
どうやら締め出しのようなのでαに戻しました

yolo不可か、見送りだな

ストリーミング再生とシーク時の反応が良くなっているのでストリーミング再生時だけv0.6.1を使おうかと思ったけど、
しばらく再生していると、映像と音声がかなりずれてしまっていた
元動画によるのだろうか？

yolo-v4より標準のrfdetr-v5の方が性能高いから無理してyolo-v4を使う必要ないぞ

jasna v6.0.2が出た
更新早いな
・カクカク問題(たぶん)解決
　Windows/Linux側の設定でGPUスケジューリング対策不要に
・yoloモデル対応(onnxは入れ忘れだったみたい)

>>704
別のyoloモデルに差し替えて使いたい層がいる
検出モデルは好みもあるので良し悪し議論は荒れる

>>705
0.6.2は他の（旧）バージョンと共存できるのですかね？

>>705
すまない。6.0.2です。

お、Linux版 0.6.2 が出たな、Jasna

zelefsnsと組み合わせているがjasnaの処理の部分は0.6.0alpha5から比べて10倍位速くなってる。

>>706
凍結バイナリを別のフォルダに展開すれば別バージョンとも共存出来る
但し、v6.0.1でtorchスタックが更新されたので以前のバージョンからエンジンファイルをコピるのはNG
また、GUIの設定ファイルは%APPDATA%配下に保存されるから、これは前のバージョンと共有される
別バージョンで設定を更新したらその内容が新しいほうにも伝搬するので注意

>>705
やっぱりonnxは入れ忘れだったんですか…　昨日苦労して諦めましたが、元々問題あったとは。
今度入れ替えてみよう…

こんだけやる気出してくれたならtodoのVRサポートも期待できるな
ここでやり方共有してくれる人いたけどワイにはハードル高かったから

検出モデル　v2_accurateはリネームして使えるのでしょうか？

>>713
>2 のやり方が使える
>4 のやり方で lada_mosaic_detection_model_v2.pt にリネームすると lada-yolo-v2 で選択可能になる
(v4_fastと共存できて、選べるモデルが3つになる)

カレントフォルダ問題だけど、jasna-cli0.6.2（0.6.1も同じ）で初回コンパイルがある時、カレントドライブにexe本体がある時は正常に動作するけど、別ドライブだとエラーする
コンパイル済みの場合は、別ドライブにあっても正常に動作する
まだまだ修正が甘いな

ここに書いても作者見てないから
改善して欲しいならgithubで報告して

0.6.0alphaで普通に完走するファイルが0.6.2だと途中エラーが出て未完になるな
仕上がりに違いは無いからalphaのが良い

おま環だろ、それ

>>714
ありがとうございます。無事出来ました。稼働も問題ないです。
後、細かい設定ですが、二次修復などはどれがベストでしょうか。自分は全てULTRAにしています。

v0.6.2を起動しようとしたら、マカフィーに隔離された。今までのバージョンでは起きたことなかったんだけどな。

jasna v0.6.2 でカクカク問題が本当に解消したのを確認
1080p, 31524フレームの動画を同条件で2回処理 → 検出結果が完全一致(処理毎の非決定性ゼロ)
LinuxとWindows(GPUスケジューリングON ＝一番症状が出やすい条件)の両方で確認できた
これで性能デグレとカクカク問題の両方解決！

>>714
好みによるから自分が良いと思ったものがベスト

0.6.2の検知モデルrfdetrでエラー、yoloは完走
21:58:56 PM ERROR [primary] thread crashed
Traceback (most recent call last):
File "jasna\pipeline_threads.py", line 171, in primary_restore_loop
File "jasna\restorer\restoration_pipeline.py", line 101, in prepare_and_run_primary
File "jasna\restorer\basicvsrpp_mosaic_restorer.py", line 70, in raw_process
File "torch\nn\modules\module.py", line 1778, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)

>>722
ちょうど横でClaude Codeで作業してたんで聞いてみた
砕けた感じの回答↓

それ検知(rfdetr)のバグじゃないっす。落ちてんのは一次復元のBasicVSR++のほう。
ログ末尾が raw_process → self.model(...) なんで、rfdetrは引き金なだけ。

rfdetrとyoloで差が出るのはたぶんVRAM。rfdetrは検出多め＆768pxの常駐エンジンで重いから、
yoloより先に足りなくなるパターンかと。crop準備は通ってるしshapeは正常っぽいんで、
CUDA OOMくさいです。

ただ貼ってくれたログ、_call_implの直後で切れてて肝心のエラー文が見えないんよね。
もしよければ
・その下の続き(RuntimeError: CUDA out of memory…みたいなやつ)
・GPUとVRAM
貼ってもらえればもっとわかるかも。

>>722
rfdetrは性能が高いから小さすぎるモザイクも検出しちゃう
小さすぎるモザイクだとBasicVSR++でエラーが起きる
しきい値を少し大きくすれば消える
って上の方に書かれてたやつだろ、それ

>>723
ログ出力してなかったから改めて試行、0.6.2、rfdetr-v5

05:11:19 AM ERROR [blend-encode] thread crashed
Traceback (most recent call last):
File "jasna\pipeline_threads.py", line 301, in blend_encode_loop
File "jasna\pipeline_threads.py", line 90, in decode_detect_loop
File "jasna\pipeline_processing.py", line 129, in process_frame_batch
File "jasna\mosaic\rfdetr.py", line 131, in __call__
File "jasna\mosaic\rfdetr.py", line 85, in _preprocess
torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 380.00 MiB. GPU 0 has a total capacity of 8.00 GiB of which 0 bytes is free. Of the allocated memory 712.48 MiB is allocated by PyTorch, and 453.52 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation. See documentation for Memory Management (https://docs.pytorch.org/docs/stable/notes/cuda.html#optimizing-memory-usage-with-pytorch-cuda-alloc-conf)

NVIDIA GeForce RTX-4060 Laptop GPU 8.00GB
GeForce 591.4 WHQL DCH-[r591_66]

>>725
CUDA out of memory って出ているからClaude Codeの見立てて合ってる
回避策は環境変数 PYTORCH_CUDA_ALLOC_CONF=expandable_segments を設定する
そうするとCUDAエラーを回避できる可能性がある (できない場合もある)

それでもだめなら >>724 指摘の通り検出しきい値を少し大きくする

処理設定次第だけど、rfdter+Secondary Restorationとか使っているなら
経験的にVRAM 8GBだと1080p解像度でRTX Super Res x4, Quality ultraとかは荷が重い

検出モデルや除去モデル変わらなきゃ大して変化ない？
いまだV0.5.0alpha10

>>727
仕上がりに差はないよな？

まだ数本しかやってないが、v0.5.0アルファ10と仕上がりと時間は同じ程度じゃないかな。

jasna v0.6.2ではWindowsのGPUスケジューリングONで処理してもカクカクしなくなるが、元々OFFで使っていたら仕上がりは変わらないな
ゲームやる人がいちいちリブートしなくて良くなるメリットはある
性能デグレは使っているGPUと処理動画の解像度により効果が変わると思う
>>709
みたいなケースもある

v0.5.0-alpha10からだと性能デグレが直っただけか
v0.6系でブレンディングの仕方が変わっているからその辺は仕上がりに影響あるかも

>>726
rfdetrは検出しきい値0.95まで上げてもエラー、1.00にすると完走、復元未処理ファイルが出力された
yoloは検出しきい値0.10でv2v4共に完走
0.6.2のrfdetrはおれ環で使用不可という事で、新しいの出たら再度試してみる

yolo後に更にrfdetrをするとより鮮明になる気がするが気のせいかな？

もう２D対応の基本性能は完成に近いだろ
VRはまだずいぶん取りこぼしがあって興ざめ

>>732
俺環のWindowsデスクトップのRTX4060だと1080pの動画でもrfdetr-v5+RTX Super Res 4x, quality ultraは完走した
デスクトップ向けとノートPC向けの4060はそんなに性能違わないみたいだが、なんだろね
メインメモリの容量とか関係するのか？
あとできそうなのは、Max Clip Sizeをデフォルトの90で使っているなら60に下げてみるとか
初回にBasicVSR++のコンパイルがもう一度走るけど使用するVRAM量は減るはず

>>732
お前だけの特殊ケースだ
そもそも問題だらけの GeForce 591.44ドライバーを使っているのが悪い

zelefansさんの別プロジェクト？CUDA特化版
https://github.com/zerochocobo/VR-Video-Toolbox-CE

2D→3D面白そうだな

SteamVRアプリにautodepth image viewer
ってリアルタイムで2Dを3D表示するのがあったな

>>739
サンキューベリーマッチ

2D⇒3Dはいいな

zelefansの人は色々わかってる人のようだ。

iw3みたいな機能か

>>739
空間を見渡せるだけじゃなくて、物体の側面に回り込めるのが凄いよね

モザイク検出と復元に関して情報共有

当方、素人物の顔面モザイク破壊が好きで復元できないモザイクや復元できてもウネウネや目のギラギラがどうも苦手
そこで元動画の明るさを弄ると是正できる可能性がある
※方法がめんどくさいのとそれ以上聞かれてもわからないので興味がない人はスルーしてくれ

・おれ環　12700の3070tiでドライバ最新
・jasna v0.5　GUI版
・RTX Super Resはオフ
・元動画を編集ソフトで「露出」のみを月明り程度になるまで暗くする（自分は最下限値まで落としてる）
・復元後、編集ソフトで露出・輝度・シャドウを弄って元の明るさに調整する

モザイクが検出できない動画や復元後ウネウネする場合は試してみるといい
検出や復元具合はどうも元動画の明るさにも相関があるらしい
※当然画質は落ちるから、あくまでモザイクの向こう側を見たい方推奨。もし無駄足踏ませたらすまん

0.6.2　カクカク出てます

GPUスケジューリング　ONでもOFFでもカクカクします
おれ環かもだけど　原因不明
同じ解像度、色空間で、カクカクする素材としない素材がある
いろいろこれからやってみます

>>746
NVIDAのGPU種類と使っているドライバのバージョンは？

zelefansの新型で2D to Depth VR試してるけど全面緑色基調でノイズが乗ったような画面になってしまう。
導入手順のどこかでミスってそうだがda3のこともっと調べないと正解まで遠そう。

それは残念だけどまだ初号機だからな
iw3desktopのリアルタイムが素晴らしいから
事前変換するなら大幅に超えて欲しいと期待してしまう

>>745
良情報ありがとう！
顔モザ外し、専用ソフトじゃないからあんまり上手くいかなかったから試してみる！
だいぶ露出を暗くするってことで良いのかな？
復元の際のモデルもおすすめがあると嬉しいです。

色々いいじってみる！

>>748
全画面緑基調のアーティファクトが出る問題は経験ある
BT.601動画の処理で必要な色変換テーブル(�@YUV→RGB、�ARGB→YUV)で�@の変換時に�Aを使っちゃうとそうなる
何で使うテーブルがおかしくなっているかはわからんが、最近出たClaudeのFable 5に調べてもらえば解決すると思う
別件で昨日モザイク検出→復元パスの問題をFable 5に調べてもらったら速攻で原因特定・対策してくれて驚いた
課金必要だけど

>>749
iw3.desktop教えてくれてありがとう
スゲーの一言

>>747
610.47 studioドライバです
RTX3060　12GB

素材をHandbrakeでH265-10bit　カラースペースBT.709フィルタ入れてエンコするとカクカクしなくなります
元素材はSD BT.709です

>>753です
追記します
Handbrakeでエンコしてから0.6.2処理するとカクカクしないの意味です
0.6.2は。SD、FHD素材にかかわらずエラーがでるものがあり、その素材もHandbrake H265-10bit カラースペースBT.709フィルタで
エンコしてから0.6.2処理するとエラーを吐かなくなります

jasnaは従来 HEVC / 10bit(P010) / BT.709 固定だった GPU エンコード出力をv0.6.1でBT.601 対応はしたけど、まだ色空間やビット数対応が狭いと思う
ここから外れる動画は >>754 のように再エンコが必要なのかも

>>753
Fable 5に調査してもらった結果

カクカクの本命は素材側のタイムスタンプ(PTS)やフレーム構造の汚さで、Handbrakeの再エンコードがそれを正規化したから直った、と読むのが自然です。

jasnaの出力はソースのPTSをそのまま出力タイムコードに使います。つまりSD素材にありがちな VFR・壊れたPTS・テレシネ/インターレース由来のフィールド単位タイムスタンプが、そのまま出力の表示タイミングになります。
さらに video_encoder.pyでは重複PTSを「+1 tick ずらす」だけで処理するので、重複タイムスタンプを持つ素材だと2フレームがほぼ同時刻に詰まり、明確なジャダーになります。
fps は ffprobe の r_frame_rate から取りますが、インターレースSDではこれがフィールドレート(2倍値)で報告されることがよくあります。
Handbrakeで再エンコードすると、デインターレース/デテレシネ込みでクリーンな CFR・単調増加PTS のストリームになるので、上記すべてが消えます。「H265-10bit + BT.709フィルタ」が効いたのではなく、「再エンコードしたこと自体」が効いた可能性が高い。BT.709フィルタと10bitはほぼ無関係のはずです。
「エラーが出る素材」の方も整合します video_decoder.py:57 はデコーダ出力が NV12(8bit 4:2:0) か P10(10bit) の二択である前提で書かれています。NVDECが対応しない 8bit 4:2:2 H.264 などのプロファイル、あるいはストリーム破損があると例外で落ちます。Handbrake→HEVC 10bit 4:2:0 は NVDEC のど真ん中フォーマットなのでエラーが出なくなる、という説明がそのまま付きます。

俺環ではTMPGEnc Video Mastering Works 7でNVENCでエンコした物はカクカクになる。x264ではカクカクしない。理由は不明

インターレースの対応方法によっては実fpsと設定情報上のfpsと合わないとかもある。

>>757
NVENCが悪いんじゃなくて、TMPGEncのNVENC側だけインターレース保持とかプルダウン付きで出力されてる可能性が高い
x264側はプログレッシブで出てるから差が出てるだけだと思う

>>756に書いた通りjasnaはソースのPTSとr_frame_rateをそのまま信じる作りだから、
・インターレースのままだとfpsがフィールドレート(2倍)で誤認される(>>758の言う通り)
・VFRや重複PTSがあるとそのままカクつきになる

対処は出力設定で
・インターレース解除ON＋プログレッシブ固定
・プルダウン出力なし
・フレームレートは「ソースと同じ」じゃなくCFR固定（23.976とか29.97）
・色形式は4:2:0 (HEVCならMain/Main10)

0.6.2出てたけど>>2のやり方だとうまくいかないね

>>760 おま環じゃない？
>>713 が試して >>719 でうまく行った報告してる
正確には >>2 + >>4 をやったと思うが

バッチ処理中に動画ファイルの問題でアプリが落ちると今まで対症療法的に再エンコしてたが、
実行前に問題起きそうかチェックする PowerShell 製のツールを作った

・lada-ex / jasna 両方に対応
・ffprobe / ffmpeg を使って動画のメタデータ・PTS/DTS・ビットストリームを調べ、
　両ツールの仕様 (コンテナ / コーデック / 色空間) に合っているか、
　PTS の壊れ (欠落・負値・重複・逆行・大きなギャップ) が無いかを事前に確認
・問題が見つかった場合は、その原因の説明とあわせて、そのままコピペして実行できる
　修復用の ffmpeg コマンドを提示
・対処コマンドをファイルに書き出してPowerShell スクリプトとして一括修正も可

詳しくは github.com/sh202603/lada-jasna-input-check を見てね

これ、Fable 5を使って作っていたら、例の件で突然使えなくなって途中からOpusに引き継ぎ・・・

>>761
おま環というか、止めたつもりがプロセス残ってて悪さしてたわ
動いたけど、何が変わったのかよくわからん

>>762
使ってないけどいつもありがとう

>>762
尊敬するわ

で、
破壊精度は向上したんかね？

破壊精度 = 検出精度+復元精度なら最近はこんな感じと思う

jasna：検出精度の変化はなし、復元精度はWindowsでGPUスケジューリングONでもカクカクしなくなった (動画自身に問題ないとき)
lada-ex：検出精度の変化はなし、復元精度は向上(複数モザある時の復元取りこぼし減少、--tensorrt指定時の品質向上)

lada-exで--tensorrt指定で処理してた動画はやり直したくなった

ん？今ladaexのがクオリティ高いの？

>>768
いいや
今までのlada-exに比べれば、って話
画像の中に複数モザそんなに離れていない距離にあるような俺テスト動画を
双方のツールで同じ検出モデル(v4-fast)＋TenroRTのYOLOルートを指定して処理するとjasnaの方が多く復元できてる
その差がどこから来るのか調査中
PyTorchのYOLOルートだとそうはならんのだけれど、今となっては処理が遅いから何とかしたい

1ヶ月頑張ったけどアニメの修復モデルの学習は断念した
アーティファクトが出やすいのとシーンによって線が不安定になるのが直せなかった

>>739
今更だけどこれめっちゃ良いわ
柚子故障のやつ破壊してVRでこれ使って観ると捗る捗る

あとは淫尻とかでケツがアップになるやつとか、逆さアングルのは大変相性良し

必死にマシンパワー使ってVR素材破壊してボケボケになるより、被写体の演技もいらないような同人の観察系動画を無修レベルにしてautodepthで鑑賞した方がいいまであるよな
プロの作品でもメーカーとか年代によっちゃ（自重

>>767
766
ありがとうございます
劇的な進化はしていない、と理解
ブレークスルーが起きたら起こしてください

永眠した模様

2回回したら復元精度があがるとか書いてた人いたけどほんまなん

ボケボケにならないが…

>>771
顔をAI加工してるやつで抜けるのがすごいわ

ちんこまんこをAI加工しているスレでそんなこと言われても。。。