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

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

ladaもjasnaもドキュメントが説明不足すぎる

>>570
ああ、それでよかったのかな？一からやり直してしまった。

昔のモザイクだとほぼ完全破壊できるね

>>570
>>572
それでよいよ
v0.6.0-alpha5のリリースノートに、エンジンコンパイル避けるため前のバージョンのmodel_weightsフォルダをコピるの忘れるな、と書いてある
github.com/Kruk2/jasna/releases

まぁ、コピらなくても初回実行時にコンパイルを待つことになるだけだ

>>574
次からはそうする

Traceback (most recent call last):
File "jasna\pipeline_threads.py", line 86, in decode_detect_loop
File "jasna\pipeline_threads.py", line 314, in blend_encode_loop
File "jasna\blend_buffer.py", line 94, in blend_frame
File "jasna\blend_buffer.py", line 144, in _apply_blend
File "jasna\tracking\blending.py", line 45, in create_blend_mask
File "jasna\tracking\blending.py", line 19, in _box_blur
File "torch\nn\functional.py", line 5418, in pad
return torch._C._nn.pad(input, pad, mode, value)
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: Padding size should be less than the corresponding input dimension, but got: padding (60, 60) at dimension 2 of input [1, 1, 60, 221]

っていうエラーはどうしたらいいの？

>>576
検出しきい値を上げる
0.05にしたら動画によってたまに出るけど、うちでは0.1では出たことない

ChatGPT に聞いたら、検出したモザイク範囲が小さすぎると起きるみたいだな
しきい値あげたらエラーは出なくなるけど小さいモザイクは取りこぼすようになるってことか

検出しきい値0.05でやってるけど、エラー出なければ0.1にする必要はないってことか
それとも0.1の方がより良いって点あったら教えてくれ

やっとアニメ用のNSFW検出モデルができたよ
1100枚以上の画像にラベル付けするのしんどかった
今度はこのモデル使って切り出した動画3200個の仕分けだ…

LADAってもう完成なの？

ladaにしろjasnaにしろほぼ完成形に近いからなー…あとはモデルアップデートしてもらいたいものだが…

VRは全然だめだわ

マムコについては、もう一段の進化をして欲しいな
スジマンは綺麗に破壊するけど、中身開くとぐじゃぐじゃになるのを何とかして欲しい

めちゃくちゃビギナー感想で申し訳ないが、jasnaって範囲指定がguiだとできないのかな。
いや別のソフトで出来るし事足りてるんだけど、
その点はladaのguiのほうが便利に思えてくる。
jasnaの目玉は2次修復なんすね。
自分はそのあとトパーズaiで全体修復をかけるのでそこはあまり重要視してないし、かけない。
他にも利点があるのかな。
昔の歪んだモザイク
(正確にはモザイク部分を魚眼ぽくゆがませてから同時にモザイクをかけるタイプ)にも
対応できるモデルがあるなら嬉しいんだけど。

>>585 jasnaの目玉はスピードやろ、pcスペックにもよるやろうが少なくともladaの2倍は速い。破壊後がイマイチの場合は、2度掛けする。駄目なら諦める、俺の場合。

VRは体位によってはモザイクがそのまま残っちゃうね
あとメーカーによって(モザイクの種類？)うまくいくやつとダメなやつがある
対面座位をなんとか破壊できればなあ

SBSのVRでフィッシュアイのやつは、左右の欠けた部分の縦が1/3強のやつならうまくいく
しかし、めっちゃ上下に長いやつだとデフォルトの変換ではダメで、fovの値などをいじる必要があると思われるが、正解はまだわからない

>>585
lada/lada-ex と比べたJasna の有利な点

1) NSFW モザイク検出の高性能なモデル rfdetr-v5 が使える
　v2_accurateとかlada_vr_mosaic_detection_model_v2_accurateとか要らない
　顔モザは自動的に無視してくれる点もGood！

2) 一度 Pytorchコンパイルをしてしまえば圧倒的に高速

3) RTX超解像でモザイクだった部分のみを対象に二次修復を高速処理
　（TVAIで全体修復なんて時間がかかりすぎて話にならない）
　（lada-ex なら同じことは出来る)

Windowsでのことなのだけど、jasnaで
RuntimeError: PytorchStreamReader failed locating file data.pkl: file not found
っていうエラーが出るようになって詰んどる

jasnaのlada_mosaic_restoration_model_generic_v1.2.pthを追加学習する手順をチャッピーに相談して、
言われるがまま PythonとGitとCUDAをインストール、
その後GPUボードを RTX2080Tiから4080Superへ換装、
しばし沼った後PCは立ち上がったが、jasnaがあかんようになった
一旦PythonとCUDAとNVIDIA関係のアプリを全部アンインストールしてからNVIDIAドライバだけ4080Superのをインストールし直し、
jasnaのフォルダは一旦全消しして、7zファイルの解凍したてのやつに入れ替えてもダメ
ladaは問題なく走る

どしたらいいかわかるひと、いる？(TДT)

>>590
エラーの内容をAIに相談してみた？
Google検索のAIモードでGeminiに聞いたら以下のメッセージが出たが
「このエラーは、PyTorchのモデルファイル（.pt や .pth など）が破損しているか、ファイル形式が正しくない（または互換性がない）ことが原因で発生します。」
Jasnaの7zファイルを展開した後に自前の復元モデルに差し替えてエラーが出ているならお察し
--log-level debug をつけてjasna-cliを実行すればもう少し手掛かりが得られるかもね

>>589
モデルごとに相性いい動画とかあるんかねほんとに。変わらん気がする

>>589
Jasna-gui使ってるけど、検索モデルをrfdetr-v5からlada-yoio-v4に変更して、
速度が速くなってモザイク消去箇所もかなり増えた。
相性次第な面もあるかもね。

>>590
システムドライブのユーザーフォルダ内のAppData\Loamingのjasnaフォルダを消してみては?
設定のプリセットとかが悪さをしているのかも

>>590
MCP使えるClaudeに任せてしまえばいいじゃない。

>>590です。皆様コメント有難う。解決したので経過をまとめて書いときます。

【OS】Windows11
【使用のjasnaファイル】7zで必要なファイルが全部揃ってる方（ビルドではない）
【不具合症状】
GPUボードを2080Ti→4080Superへ入れ替えた後、jasnaがエラーで動かなくなった
エラーログのメッセージは RuntimeError: PytorchStreamReader failed locating file data.pkl: file not found　
【復旧手順】
・使ってるjasnaのフォルダの中にある model_weights フォルダを全消去
・7zファイルを展開した直後の model_weights フォルダをコピー
・>>2をやるならここでやっておく
・その後jasnaを起動→最初の動画処理で環境構築(コンパイル?)が30分ほど入り、その後は正常

ボードの入れ替えから足掛け２日間これで潰してもうたorz
>>591のコメントで、んっ？と思って、まずなんとなく他のドライブに7z展開後のまっさらのファイル置いて起動してみたら正常で。
ここでしみじみmodel_weightsフォルダの中身を見てみたら、7z展開直後のものはファイルが３つしか無いのに、初回の起動が終わった後はなんかいっぱい増えてる、ってことにここでやっと気付きまして。
ここを全消去するのがキモでしたのに、既存ファイルを後生大事に全上書きしてたのがダメポイントでした。(´Д`)
Python、Git、CUDAの影響は多分無いっす。（念のためGitはアンインストールしといたけど。）一旦の復旧後、改めてCUDAのインストールしても問題なかった。

ちょっと気になるのが、7zファイルの展開直後のまっさらで改めてjasnaを起動しても、Presetに記憶した条件は残ってるのね。ここまで初期化することが必要となると記録されてる場所がどこなのか見つけなきゃいかんのだが、一向に見つけられんのよ。
>>594がコメントしてくれてるやつとかはチャッピーにも言われて、590を書き込む前にもさんざん探したんだけど、未だに分からずじまいっす。(´Д`)

とりあえず2080Tiでダメだった4Kファイルも4080Sだったらいけそうだし、まずはよかった。
残るはmosaic_restoration_modelの強化チャレンジですわ。

>>590
復旧乙でした
エンジンビルドに時間がかかっているから使っているのは0.5.0-alpha10かな

>>594 コメントの答えは、正確なのが >>45 に書かれてます %APPDATA%\jasna\settings.json

アプリのバージョンが上がって中で使っているPyTorchやTensorRTのパッケージが更新された時など、エンジンファイルが引き継げない場合もあるから注意が必要だ
例えばここ↓
github.com/Kruk2/jasna/releases/tag/v0.5.0-alpha11

0.5.0-alpha10から0.5.1や0.6.0-alpha5へはエンジンファイル引き継げない

復元モデル強化頑張れ！

>>589
1)の検出モデルについては動画次第・個人の好みもあるのでコメントはやめておく
2)の性能に関してコメント
・性能に関してlada/lada-exをひとまとめにするのは実態に合っていない
・コンパイルすると圧倒的に高速になるのはjasnaの0.5.x系列(0.5.0-alpha10や0.5.1)
・jasna 0.6.0-alpha5は性能がデグッていてコンパイルしてもladaより遅くなる場合あり
・色々な構成でFHD動画を俺環(Ryzen 7 9700X+RTX5060ti 16GB)で処理した結果
＜共通＞
　動画の長さ：17:31
　復元モデル：v1.2_full、検出モデル：vr_v2_accurate、RTX VSR：使わない
＜結果＞
lada 0.11.0： 10:12 (Win) 07:29 (Linux)
lada-ex 0.12.1： 05:45 (Win) 03:36 (Linux) ※最速設定時(*)
jasna 0.5.0-alpha10： 05:39 (Win) 04:27 (Linux)
jasna 0.6.0-alpha5： 13:27 (Win) 06:32 (Linux)　←Winのデグレが大きい

* --tensorrt --fastpipeline --torchcodec-encoder

＜参考＞
・jasnaの検出モデルはlada-yolo-v4 (v4-fast)が一番速い
・rfdetr-v5はlada-yolo-v4の倍くらい時間がかかる
・今回使ったvr_v2_accurateはlada-yolo-v4より2割位遅い

>>596
蛇足になるかもしれませんがAPPDATAフォルダは隠しファイル属性だからエクスプローラーの設定を変えないと表示されません

>>597 ありがとう！もう無理だべと思いながらエクスプローラーで「PC」を選んどいて settings.json で検索かけて、放ったらかしで風呂入って帰ってきたら、あった！ｗ
おれ環の場合は　C:\Users\sync\AppData\Roaming\jasna\settings.json でした。
使ってるjasnaのバージョンは 0.6.0-alpha5 だけど、CPUが古い(i9-9900KF)せいで時間かかったのかも。
モデル強化はホントにできるかわからんけど、とにかく着手してみます。

>>599 ありがとう。そこのリテラシーはギリセーフでしたｗ

zelefansからladaかjasnaかのどちらかを呼び出せるようになった。
まだ少々問題があってjasnaにパスを通してもカスタムパラメータにモデルを絶対パスで指定してもモデルが見つからないってエラーになる。
そこで、強引にzelefansの
vr_remove_mosaic
/GUI/VR_Video_Toolbox直下にjasna v0.5.1一式を配置したら動いてくれた。どうするのが正解なんだろうか？

これ書くと反応する人がいるけど、jansa-cli が model_weights をカレントフォルダから読む挙動になっているから
今はそのやり方が正解なんじゃないか
あとはAIに相談して改善してもらう

JASNA GUI v0.6.0=alpha5 での話
タテ型動画を変換するとき、検出しきい値を0.10で処理すると
処理後エラーが表示されていで、動画が途中で止まっている時がある
そんなときの対処方法
1)検出しきい値を 0.15 0.20 0.25 と増やしながら
　エラーが出なくなるまで再実行してみる
2)それでもダメなときは
　検出モデルをlada-yolo-v4に変えてやり直してみる
元動画次第だけど、２）まで試してダメだったことは私の経験では無い
どうも横型に比べ、タテ型動画の方がエラーが出やすい気がする

603です

>>598
・jasna 0.6.0-alpha5は性能がデグッていてコンパイルしてもladaより遅くなる場合あり

上記書き込みを読み、もしやと感じ、JASNA GUI v0.5.1 Latest で同じ処理を
やり直してみました。
その結果エラーは出ずに、さらに高速に、処理が完走できました。
jasna 0.6.0-alpha5は、やはりベータ版だということですね。勉強になりました。

アルファ版だと思ってたがジワジワきてベータ版の気分になってきた

>>598
jasnaの0.5.x系列のほうが0.6.0-alpha5より早いのはわかったけど同条件での仕上がりはどうなの？
0.6.0-alpha5にしたら良くなったというレスもみかけるんだけど

0.5.x はモザイク破壊した画像をソース画像にはめ込むブレンディング処理にバグがあるから違和感のある画像になる

590です。
モデル強化は全然まだなんすけど、2080Ti→4080Superの効果だけでもjasna的にデカい所と思った所をご報告

両者のベンチマークはググると以下の通り
https://technical.city/ja/video/GeForce-RTX-2080-Ti-vs-GeForce-RTX-4080-SUPER
この数値では2倍までは行ってないのだけど、実際にjasnaを走らせた体感はめっちゃ早くて、
換装前がほぼ動画時間位→換装後は動画時間の半分か40％くらい（ざっくり45％）
つまり、時間当たりの出来高は１÷45％＝2.22倍＝222％→�@
寝る前に仕込んで走らせて、朝起きた時の出来高が2倍以上、これはまあまあビックリする

一方の消費電力は、換装前350W→換装後450Wくらい（ざっくり130％→�A）
つまり、動画1本あたりの処理にかかる電気代は、電気代÷出来高＝�A÷�@＝130÷222＝58％

おそらく、おれんちの電気代のうちjasnaに食わせてるのは9000円くらい
同じ本数の処理に留めれば、節約できる電気代は9000円×58％＝5220円
今回の中古4080Superの落札価格は約160000円、これを節約電気代で割ると 160000÷5200＝30.7か月＝2.6年

・・・・ということで、省エネ投資案件としてはイマイチだけど、時短案件としてはアリかと。(´Д`)

電気代の計算めっちゃ間違えました。電気代節約分は100％-58％＝42％で、節約できる電気代は9000円×42％＝3780円、
投資額÷節電額＝160000÷3780＝48.8か月

というわけで、省エネ投資案件としては全然アカンです。謹んで訂正の上お詫び申し上げます。orz

plを50%にしたら

そもそもエロはエコじゃない

それで、0.5.xと0.6.x-alphaはどちらがえぇんや…

stream機能を使いたかったら0.6.0-alpha5一択
後は処理時間と仕上がりのトレードオフじゃないかな
0.5.xの仕上がりに文句がないなら処理は速いに越した事はないよね

LADA、JASNAアプリ削除しようと思ったら、フォルダーごとゴミ箱ポイで問題ない？

lada-ex+cu130nightly(Ubuntu)が俺環でちゃんと動作する構成に辿り着いた気がしたからlada-exとzelefans+jasna0.5.1(Windows)とVR動画メインで比較検証中。
今のところ、lada-exの復元品質はconf: floatやtrack_buffer他の値を調整してzelefans+jasnaの画質にかなり近付いたけどArtifactが若干多い。しかしtensorrt、vsr、torchcodecなどオプションてんこ盛りでの処理速度は4K60FPSのfisheyeタイプVR動画の場合にlada-exでは41fps、zelefans+jasnaでは17fpsと大差が付いた。
jasnaの処理の部分のみ着目すると片目で95fps位出てるもののfisheye変換で80fpsに復元で40fps位の速度になるからトータルでは遅くなるようだ。
また、8KのVR動画検証はまだ途中なもののlada-exでVRAM24.7GB超えてたから1分位の細切れ動画にしないとVRAM16GBクラスのGPUだとフルオプション処理できないかもしれない。

うちはzelefans jasna０．６がまだうまくいってない
lada-exは動いたけどｖｒは速度の前に質の面でまだまだだな

VRは一つ一つの処理ごとに高解像度のエンコードがあるから
速度が出ないのはどうしようもないかなあ

当然だが、VRは一時ファイルのビットレートを落とせば、作成・読み込み共に高速になるけど、最終結果の品質も落ちることになる
ただ、どうせまたやり直すことになるだろうから、今回の所は落としておいてさっさと済ませるという考え方もできる

あと、個人的には30fpsに落としても全然問題ないと思っていて分割の際に落としているが、これをしておくだけでスピードアップとなる
また、いまだにOculus Goを使っている友人に渡す時は、8KVRだと見ることができないので分割の際に4KVRに落としている
こちらは、面積が1/4になることから、かなりのスピードアップとなるし容量も減る

うろ覚えで間違っている可能性大だが、オ◯ニー1回は50m走と同じエネルギーらしい。そのエネルギーを発電に変換できれば地球温暖化は防げるらしい。どうやって変換するかは別問題だがw

>>619
はいライン越え

30fpsの動画はLosslessScalingで60fps再生したほうがかなり良いと思うから
60fpsの動画を30fps化して平気とか信じられないわ

TVAIで120fpsまで上げてみたことあるけど60fpsと差が良くわからなかった。

>>622
それじゃ、基本24fpsの映画なんで見てられないってこと？

映画やアニメは絶対フレームレート弄らないし
ゲームも最悪30fpsで問題なく遊べるけど
実写のエロだけはフレーム補完してでも60fps以上にしないと気が済まない自分みたいなのもいる

>>623
最近4K180Hzのディスプレイ買ったからTVAIで4K24fps→4K120fpsに変換して再生してみたけどヌルヌルで笑った。

本家Windows版のIntel Arcバージョン使ってる人、調子いいですか？
今Nvidiaバージョン使ってるけど調子良ければIntel Arc買ってみようと思ってます

SFとかマーベルとかの実写ヒーローものを60Fps化すると、途端にコスプレした痛い人達になるのは何でなんだろう？

VR対応についてはばらつきが大きくてまだ当面は過渡期なのでとりあえず３０ｆｐｓでもいいよ　どうせまた同じのをやり直すから

VR物は女優の演技力次第だからなぁ・・・
もうちょっとバリエーションが欲しい。
男優の主観じゃなくてもいいのよ。

まんまと騙されたよ
alpha-5＋rfdetr-v5がいいというから使っていたけど、一瞬モザイクが残ることがあった
理由がわからなかったが、某サイトのサンプルをキャプチャーしたものを使ってみたらはっきりとわかった
たった3分のサンプルで、シーンが切り替わってから終わるまでずっと処理がされないシーンが2か所あった
しかも、画面半分の巨大藻なので閾値などは当然無関係だし、v2/v4/ladaでは問題なく処理される
要するに、rfdetr-v5の顔モザ無視の判断が甘くて、ま〇こを顔だと間違えてるわけだ
顔モザ無視なんてどうでもいいことのために肝心の部分の処理が抜けるなんて、もう絶対にrfdetr-v5は使わん
rfdetr-v5使って処理したのはチェックして藻残りが起きてるやつはやり直しじゃ

俺は逆にlada-yolo-v4使っててモザ残りが頻発してrfdetr-v5に変えた。結局相性なんかな。

>>632
それで、rfdetr-v5に変えて、藻残りは発生しなくなったの？

他の例ではrfdetr-v5でstream再生していると、藻が一瞬出ることが2回あった動画も他の検出モデルでは全く出なかったこともあるし、
どれを使っても一瞬出てしまう動画もあったので、どれを使っても出るやつに顔に勘違いしてのモザ無視が加わってしまうのだと思うが

ナスの動画でははっきりlada-yolo-v4のほうがいいってわかるけどそれじゃダメなんかねｗ？

>>633
オレ環では発生しなくなったよ。

yolo-v4はモザイク検出は良くない、v2_accurateに入れ替えてからは不満ない
rfdetr-v5はv2_accurateで取りこぼすモザイクを検出できる事がある、遅いし常用はしなけど

jasna-guiを使っているけど、検出しきい値を調整すれば、モザ残りって少なくならないですかね…
個人的にはあまり差は感じないので、lada-yolo-v4使って速度重視にしてます。
ただ、処理が早過ぎる為か、時々PCフリーズしてしまうのが…

yolo-v4はボロボロ取りこぼす、>>2の手順でv2_accurateに替えてみればはっきり改善される
検出しきい値いじるのはその後

torchcodec公式がようやくWindows版のCUDA対応wheel(0.13.0)をリリースしたんで
早速Windows版lada-exに組み込んで最速パスを動かしてみたら処理動画に謎のマゼンタアーティファクトが発生する・・・
俺環？と思ったけどGPU違う2台で同じ現象が出たので、どこかに問題がある
せっかく組み込みが楽になったのに、これじゃ使い物にならん

簡単なところからエンコードオプションに-b 0入れてみたらどうかな？

rfdetr-v5がま〇こを顔と認識したということは、逆に言うと顔がま〇こそっくりな人がいるということだろうか
本当にそんな人がいたら、マスクは真の意味での顔パンツということになり、しないと猥褻物陳列でタイーホだな

>>640
サンクス　原因は割と意外だった
--live-preview機能を使って処理映像を見ながら地道に切り分けたらnvvsrとtorchcodecの組み合わせ問題でした
lada-exで使っているnvvsr(cu12系)と今回組み込んだtorchcodec(cu13系)が同名のバージョン違いDLL(nppicc64)をvenvの中に持っていて
torchcodecがcu12のDLLを先に読み込む処理になっていたもんだから不整合が起きて色情報を破壊していたっぽい
RTX VSR側のDLLをtorchcodec側のDLLで上書きする回避策で直った

また学習失敗した
GANの学習で一気に不安定になる

jasnaってGPUスケジューリングONのまま使っても問題ないのだろうか
OFFだとゲームでDLSS FG使えないから切り替えるの面倒なんだよね

>>644
jasna動かしたら処理動画がカクカクします→GPUスケジューリングがONでした
というテンプレやり取りがよくあったけど、おま環でその問題が出ないなら大丈夫じゃね
って、0.5.1と0.6.0-alpha5はSystem CheckでGPUスケジューリングを確認してたっけ

>>645
だめだったわ
ONにすると仰る通りカクカクで解析部分がズレてた
面倒だけど再起動するしかないか

全然アップデートがないな、Jasna
さっさと正式リリース版出してくれねーかな

>>647

作者が転職して忙しみたい。

更新は続けると言ってたから
気長に待て。

jasna使おうとしたらエラー出たが、文字化けしてて、どういうエラーなのか全くわからん。先週やった時は問題なかったのにな。
フォルダごと削除して、プログラムを解凍し直したら動いたけど、何が原因だったのか。

jasna-cliのmodel_weightsフォルダ参照問題を改良するパッチを作った
v0.6.0-alpha5へのパッチとWindows版のビルド手順書を置いたので興味がある人は試してみて
jasnaが組み込んでいるパッケージのライセンス回りが良くわからんので
ビルドしたものを配布するのは止めておく

<注>
Windowsでしか試してないです
わからないところはAIに聞くなりして、基本自分で何とかできる人向けです
パッチや手順書に間違いがあったらゴメン

<今のjasna挙動>
--detection-model-path / --restoration-model-path のデフォルトが jasna-cli.exe と
同じフォルダ内の model_weights\ 相対パス
jasna-cli を PATH に通して任意フォルダから実行すると、コマンドを実行したフォルダの中の
model_weights\ を探して FileNotFoundError

<改良版>
以下優先順でmodel_weights\フォルダを探す
1. 環境変数 JASNA_MODEL_WEIGHTS_DIR で指定したフォルダ
2. jasna-cli.exe と同じフォルダの中の model_weights\
3. コマンドを実行したフォルダの中の model_weights\
4. jasna ソースの親フォルダの中の model_weights\ (uv pip install -e . でソースから動かす人向け)

ttps://13.gigafile.nu/0902-ce3ed12899d6afbe880bd397d559ff2a0
ダウンロードパス：jasn

jasnaのRTX SR UltraとTVAIのiris2をgrid playerで見比べてるけど全く違いが分からん

TVAIが一番効くのはahq12だと思う。GUIでは選択できないが、cliで--tvai-model ahq-12 --tvai-scale 4を指定してみればRSRよりシャープなのが分かる

破解にRSR、破解後の全体仕上げにTVAIの
Starlight Precise2.5を使う俺のようなやつは
少数派なのかな？

そんな使い方してたらGPUはすぐサヨナラされて星になってしまう。

sbsのVRでfisheyeオンしても□が傾く件だが、2つのパターン（またはその複合）を確認した
いずれも、fisheye変換前の片目部分の左右にあるカマボコのサイズを調べる
1.カマボコの左右の横サイズ（厚さ）が異なる場合
　画面左右の中心部分にあるモザは縦がまっすぐになるはずが斜めに傾くことになる
　この場合は、fisheye変換時に視線を横向きに振ってやる必要がある
2.カマボコの画面左右端の縦サイズが普通のものと違う（普通より大きい）
　上下角（v_fov）はデフォルトでは180度だが、モザ処理後hequirectに変換する際にそれを小さくしたと思われる
　この場合は、元の値を探し出し、それを使ってfisheye変換しないと元に戻らない

>>654
今は数分の動画だけの処理が現実的。
NVIDIA3080tiで、1～2時間ものの動画はさすがにやってられない。

h264を100%とすると、hevcなら約50%、av1なら約30%程度のビットレートで同じ程度の画質が得られると聞いてVRの最終ファイルをav1_nvencにしてエンコしてみた
処理時間は、hevc_nvencの時と変わらなかった
しかし、うちのQuest2では、VR再生アプリにはav1対応と書かれていたが、ハードウェアの方が対応していないらしく、8kVRはもちろん4kVRのav1すら再生できなかった

まあav1対応してんのはquest3だからな…3sはどうだっけ

650だがClaude Opus 4.8がリリースされたんでJasnaのLinux版のビルドガイドを頼んだらさくっと作ってくれた
俺環で次まで検証完了:
・vali / PyNvVideoCodec / jasna のソースビルド
・凍結バイナリ生成（dist_linux/jasna/jasna、GUI＋CLI 兼用）
・GUI 全ダイアログ表示、RTX Super Res、lada-yolo / RF-DETR 検出、実動画の復元処理

試したい人がいたら以下からゲットして
ガイド
・ttps://github.com/sh202603/jasna/blob/docs/docs/BUILDING_WINDOWS_ja.md

パッチ (Linux環境固有のパッチが一つ増えた)
・ttps://github.com/sh202603/jasna/blob/docs/patches/build-and-runtime-improvements.patch
・ttps://github.com/sh202603/jasna/blob/docs/patches/fix_linux_gui_and_rtx_vsr.patch

Linux版のガイドはこっちだった
・ttps://github.com/sh202603/jasna/blob/docs/docs/BUILDING_LINUX_ja.md

俺は正式リリース版のLinux版を待つわ

>>661
了解。興味ある人だけチャレンジしてみて

Max 5xのサブスク期限が来る前に勢いで機能追加も頼んだらあっさりやってくれた
さすクロ
BT.601の動画10本位で軽くヒートラン回してWin/Linux両方で動作確認できてます

jasna の出力段を拡張した改造ブランチです
本体の GPU 完結パイプライン（NVDEC→復元→NVENC）はそのまま、エンコード出力の自由度を上げてます
■変更点
　AV1出力対応（--codec av1、ファイル出力のみ）
　8bit(NV12)出力＋ビット深度選択（--bit-depth auto/8/10、既定はソース連動）
　色空間を保持（BT.601 / BT.709 / BT.2020 を入力から維持してタグ付け）
　出力コンテナは拡張子で選択（.mkv / .mp4、AV1-in-MP4も可）
　torch 2.12 / CUDA 13 スタックで再ビルド
■検証
　Win/Linux両方でCLI ＋ GUI 連続処理 ＋ 凍結バイナリ（PyInstaller）動作確認済
　HEVC 8/10bit・BT.601/2020・AV1(8/10bit)・--bit-depth両方向の実機検証済
■公開先
　ttps://github.com/sh202603/jasna （branch: feature/av1-nv12-colorspace）
■詳細
　 docs/CODECS_AND_COLORSPACE_ja.md ／ 変更点: docs/CHANGES_vs_upstream_ja.md

元動画の都度BT.709への変換は面倒だね。

>>663
バッチでバッチリやろ

662です
jasna v0.6.0系で入ったexperimental blendingの性能デグレ原因もわかっちゃったんで
昨日連絡した版(feature/av1-nv12-colorspace)に処理速度の改善を入れときました
クローン済みの人は取り込んどくのがおすすめです

ブレンドマスク生成の畳み込みの計算(2次元blurフィルタ)を素直にK×Kでやっていたのを分離化(一次元フィルタの計算×2回)に変えた
こうすると計算量がO(K^2)→O(2K)に減るのでデグレ分はほぼ解消
実測(同じ1080pのクリップ、31524 フレーム、凍結バイナリ)：処理時間がだいたい3〜4割短縮
- Windows 7:37 → 5:13
- Linux 6:26 → 4:00
出力も変わりません(差はエンコーダの実行ごとのゆらぎ由来) 画質も挙動も変化なしです
対策版コミット：e92dccc

#本家にも報告しておいた

>>662
すみません
これの使用方法を具体的におしえてください

>>666
興味を持ってくれてありがとう
以下リンクにビルドガイドを公開しているからこれを見ながら自分で
jasna-cliとjasna-guiを作るという使い方です
わからないところはAIに聞いて解決するスタイルでお願いします
ttps://github.com/sh202603/jasna/blob/feature/av1-nv12-colorspace/docs/BUILDING_WINDOWS_ja.md

このガイド自体もClaude CodeでOpusに書いてもらってます
各手順の実行→確認はさむとか、途中自分が詰まった所をトラシューとしてまとめるとか
結構くどい位な内容になってます

個人的な実験ブランチなのでバイナリパッケージ公開の予定は無いっす
そのうち本家が対応してくれるかも？

本家のLADAは全然更新されないな

662です
ビルトインのフレーム生成機能をとりあえず追加した (--frame-gen 2x/4x)
中身はRIFE補間で、元の尺・音声はそのままfpsだけ倍にする
(モニタがしょぼいので4xは試してない)
ファイル出力のみ対応
手順とスクリプトは置いといたので重みは自分で用意してね
modiブランチに入れてある

ただ最適化はまだ
1080p(30fps, 31524 フレーム)でざっくり実測（Linux / lada-yolo-v4 + rtx-super-res 4x ultra）:

　frame-gen none (4:00) vs frame-gen 2x (26:40)

全解像度のRIFEをエンコードと同じスレッドで回してるだけなんで
ベースが速いほど補間がモロに効いてガクッと落ちる模様
TRT化とか専用スレッド分離は今後の課題
あと frame-gen 2xにするとrtx-super-res の ultra はVRAM 8GBだと普通にきつい

まあ「とりあえず動く版」です

Jasna の正式リリースまだかよ
夏になっちまうじゃねーか
冬なら暖房機がわりになったのに

GANの学習むずすぎ！何度も失敗してる