【超解像】Lada part4

>>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系でブレンディングの仕方が変わっているからその辺は仕上がりに影響あるかも