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

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

>>8と>>18は女より男が好きらしい。

>>2だった

そんな必死に否定せんでもええがな

きっしょ

flashvsrの4倍めちゃめちゃ時間かかるね
4fpsぐらいしか出ないから5分の動画の処理に30分以上かかりそう

>>14
13700＋4070の環境で
・一次basicVSR＋二次FlashVSRX2(タイル分割処理なし)＋inline設定(一時修復プロセスのブロックごとに即実行、でいいのよね？)
　Maxクリップサイズ=512程度なら、1080Pソースの処理にVRAM消費11GB前後で行ける
・これまでよりすげー速くなった、もうJasna本家に導入されてもいいくらいでは…
・修復部位の色合いの違和感が消失
・FlashVSRX4はタイル4分割なら実行可能だった、X2との仕上がりの違いは試した範囲だとあまりわからなかった

2次修復の精細度はJasnaの画像修復に近い精細度を動画でやれてるくらいな感じ
毛のディティールが過剰になりがちなのはFlashVSRの癖っぽい？
一つ気になったのは2次修復まで終わってエンコードに入っても、VRAM消費が高止まりなままだった事

次の更新いつくるんだろ

復元モデルもアップデートして欲しい
でも重くなりそうだな

>>24
VRAM消費が高止まりのままだったのはoffline指定で動かした時の挙動？
jasnaの処理が終わってもVRAMを開放せずに残っていたとかだったらまずいんで
もし不具合っぽい動作があったらgithubのissueで報告してもらえると助かります

>>27
inlineのほう
短すぎない動画で実行すると、修復とエンコードがある程度同時？交互？進行していてVRAMを保持しているのは分かるんだけど
修復が100％終了して、エンコードのみ残ってる状態でもVRAMは修復実行中と同じく、11G前後使ってるままで最後まで進む
エンコードも終われば解放される(複数動画をまとめて登録して実行した場合も大丈夫)
offlineでの起動はまだあまり試してないので判りません

>>28 なるほど
進捗バーの100%は「修復完了」じゃなくて「デコードと検出が終わった」時点で到達するんだわ
なので100%になった後もキューに残ってる分をFlashVSRがまだ修復中
VRAMがつかみっぱなしに見えるのはそのためで、裏でまだ働いてる状態
解放はパイプライン全体が終わってモデルを捨てるタイミングなので、残りの修復が片付くまで保持
inline版はモデルを常駐させる作りなのでこうなってます (offline版は別経路)

あと、クリップサイズ512だと1クリップが閉じるまでが長いので、100%の後に残る処理もその分長くなって余計目立つと思う
ちなみにinline版はクリップを小分けにして流す作りで、その小分けの単位はクリップサイズとは別にFlashVSR側で固定されてる
クリップサイズを大きくしても小分けの数が増えるだけでサイズは変わらないので、FlashVSR側のVRAM常駐量はほぼ一定だったりする

>>29
じゃあ心配しないでこのまま使いますね
二次修復の出来は個人的にはladaが登場した時レベルの衝撃、素晴らしいお仕事

>>13
thx
012の app/Contents/Resources に runtime 以下が含まれていなかったので
010から拝借したらモデルのcoreai変換できた

>>31

報告ありがとうございます。
同梱するようにしました。

もしよかったら環境とfpsどれくらいでてるか？教えてください。

>>29
ちょっと質問
>inline版はクリップを小分けにして流す作りで、その小分けの単位はクリップサイズとは別にFlashVSR側で固定されてる
この「FlashVSR側で固定されてる」クリップサイズって数値はいくつ？
これに合わせて・あるいは等倍で設定しておいたほうが能率よかったりする？

>>33
FlashVSR側で固定なのは「サイズ」じゃなくて刻み
クリップを8k+5フレーム(最低21)に切り上げて、先頭21→あと8ずつ回す作り
合わせるなら8k+5の値(93、125、181)が候補
効率に効くのはクリップを長くするほう(既定(--temporal-overlap 8)だと境界ごとにoverlap 16フレームを二重処理してるので)
実測で90→93が−4%、90→181が−10%、240で頭打ち、VRAMは181で+0.2〜0.4GB

目安: VRAMに余裕があれば181、16GBでscale 4の1080pみたいにギリギリなら93
(既定の90のままでも損失は4%程度)

>>32
早速の対応ありがとうございます
今後も期待
Mac mini M4 16Gですが、fpsは元素材によって変わってしまうので何とも。

>>35

FHDだとして等倍ぐらいの速度は出てます？

>>34
把握、感謝

>>36
coreaiを使うと並列数1でもswapが20〜30GBくらい発生して途中でやたら遅くなってしまいます
008でcoreml使用では問題ないレベルで完了

>>38

とりあえず、私のおすすめ設定


https://jpeg.men/1Kf0dJrJnpu.jpg
https://jpeg.men/1Kf0dJrJnpv.jpg
https://jpeg.men/1Kf0dJrJnpw.jpg

>>39

一時ファイルは全部外部に

mac版のmioh興味がありますがどこで入手可能？

>>41
https://github.com/mioh-labs/mioh

ありがとうございます

>>24
これ以上のSeedVR2+LoRAのディテール改善は自分には無理っぽいので諦め、FlashVSR二次復元の方をさらに改良した
--flashvsr-accel: FP8でFlashVSRを高速化(すまんがRTX40系以降とfork版sh202603/FlashVSR_plusが必要)
・FlashVSR単体だと3〜4割速くなってる(対応してなきゃフォールバックして従来通りの挙動になる)
・RTX5080で1080pを二次復元scale x2指定して通しで回すと162秒→127秒で、VRAM消費も1.4GB減った

--flashvsr-lora: 毛の過剰ディテールはFlashVSRの癖なので、それを多少緩和するLoRAを作った
・inline専用でaccelと併用できる
・LoRAを使っても5%くらいしか遅くならない

詳細はドキュメント参照してください

必要なリソースが見つかりません: Swift native detection model: v4-fast-coreml
と出てエラーが出てしまいますが、何か対策はありますか？

>>45

モデルをダウンロードして、mac専用に変換しないといけません。
同梱している.zshファイルを実行してください。
osは27にしてね。

>>46　
ありがとうございます。起動はできたのですが20%らへんのところで
Swiftネイティブプレビューを開始できませんでした: Cannot Decode
mioh-native-coreai-preview: Cannot Decode
と出てエラーになってしまいました。
ネイティブプレビューというのは何なのでしょうね？

>>47

動画が壊れてません？

一応ladaとかだと問題なかったんですよね・・・
比較しようと思って実行したので。
他の動画で試してみますね

あ、もしかしたらOSアップデートしてから動画とか開いてなかったのが原因かも？

ありがとうございます。無事解決しました。

>>51

よかったら、環境とか、報告いただけるとありがたいです。

>>52
mac book pro AppleM4 16GBです
大体30分くらいの動画で３０〜１時間で処理が完了しました。

>>53

おすすめ設定で、ですかね？

ネイティブ並列数を最大にしたら、速くなるかも。

M1 Mac mini 16GBでほぼ等倍です。

>>53

あと、３つの一時フォルダは可能な限り外部で。

>>54　
ありがとうございます。試してみますね。

>>55
あ、おすすめ設定にしてました。
外部というのは、外付けHDとかって意味でしょうか？

>>57


はい、外付けです。

>>58
ありがとうございます。HDはなぜかアクセス権が与えられなかったのですがSSDだとできました。
確かに、速度が全然違いますね

>>59

ログを見るとfpsがわかるので、
また知らせてください。

>>60
60~180fpsと結構差がありました

>>61

大体

180fpsはモザイクの無いところ
60fpsはモザイクのあるところです。

30fpsの動画を復元すると2倍速ですから、
lada環境から比べると雲泥の差です。

>>62
すごい速度ですね
こちらの方が顔モザイク検出機能もありますしね

>>63

顔モザイクは動くかどうかわかりません笑

mioh

ネイティブ並列数を10まで増やしました。

M5 maxやultraなら400とか500とかfps出るような気がします。

どなたか試してもらえませんか？

魚眼VRでzelefans-vr-yolo-v2を使って「SBS+魚眼」すると下方左右でモザ残りが発生するし、rfdetr-vr-v1でも結果はいまいち
で、色々試してみた結果、最初にデュアルフィッシュアイに変換してからzelefans-vr-yolo-v2で「SBS-左右別処理」するのが最も良い結果となった
もちろん、元の柱状投影に戻さなくても、デュアルフィッシュアイのままで再生できる
【デュアルフィッシュアイへの変換コマンド例】

ffmpeg -i input.mp4 -vf "v360=hequirect:fisheye:in_stereo=sbs:out_stereo=sbs" -c:v hevc_nvenc -cq 22 -c:a copy output.mp4

デュアルフィッシュアイは周辺部分の歪みが少なくなるので、普通に2Dとして再生した時に結果の確認もやりやすいし、なんなら、2D再生して楽しむこともできる

魚眼はv8に比べて9、10は認識が悪くなってしまったからv8を使ってる
映像全体の魚眼変換をやると
映像全体の画質がモヤっとしていると感じたのでもうやらないな

Jasna modi作者様


swiftVRというプロジェクトはご存知ですか？

https://github.com/H-oliday/SwiftVR

macでやってみたら試験段階ですが、めちゃ良好。

FlashVSRを動かしてないので比較はできませんが、
面白いと思います。

ご存知でしたら、忘れてください笑

>>68
「SBS-左右別処理」も「SBS+魚眼」も中央部分は良いが、上下端に近づくと横に拡大された映像に対して復元を行うので2Dの時と比べると品質はかなり落ちる
それに対して、魚眼VRをデュアルフィッシュアイに変換した状態で復元を行うと、映像に歪みが少ないので2Dの時に近い品質が得られる
ということで、破壊部分に限って言えばこれがベストだと思われるが、変換したことで動画全体の画質が低下するというのなら、非常に時間はかかるが以下の方法はどうだろう

1. 元の魚眼VR動画（動画1）をデュアルフィッシュアイに変換して動画2を作成する
2. jasnaで動画2を「SBS-左右別処理」して動画3を作成する（zelefans-vr-yolo-v2推奨）
3. 動画2と動画3で、各ピクセルのRGB値の差の絶対値の合計がしきい値以上の部分だけを抜き出し、さらにfisheye⇒hequirectに戻した動画4を作成する（ffmpegで1回で可能）
4. 動画1に対して、動画4の画像がある部分（black以外の部分）を置き換える（ffmpegで可能、非常に複雑になるが3と4も1回でできるかも？）
（動画2〜動画4は全て一時ファイルになるので、品質は上げていい）

なお、デュアルフィッシュアイに変換した時、丸い映像の外の部分が気になるなら、このようにすれば黒くなる
ffmpeg -i input.mp4 -vf "drawbox=0:0:iw/2:ih:black,drawbox=iw/2:0:iw/2:ih:black,v360=hequirect:fisheye:in_stereo=sbs:out_stereo=sbs" -c:v hevc_nvenc -cq 22 -c:a copy output.mp4

もちろん、blackの部分をwhiteに変えれば白くなるし、redに変えれば赤とかもできる
左右の色を変えて紅白も可能だけど、ヘッドセット被って片目ずつ瞑って見ると映像の切れ目の色が違ってしまう

この方法だと、元の動画1から最終動画への再エンコードも4で行う1回だけとなる

mioh Universal 0.14.3-014
M6 32GB 設定はデフォのまま
動画情報: 1920x1080 / 29.969fps / 13:52

処理統計: 24929フレーム / 検出対象22101フレーム / 復元321クリップ / 76.2fps / 経過 05:27
並列構成: 時間バッチ1レーン

処理統計: 24929フレーム / 検出対象22101フレーム / 復元321クリップ / 89.9fps / 経過 04:37
並列構成: 時間バッチ2レーン

処理統計: 24929フレーム / 検出対象22101フレーム / 復元321クリップ / 91.6fps / 経過 04:32
並列構成: 時間バッチ3レーン

処理統計: 24929フレーム / 検出対象22101フレーム / 復元321クリップ / 81.4fps / 経過 05:06
並列構成: 時間バッチ4レーン

処理統計: 24929フレーム / 検出対象22101フレーム / 復元321クリップ / 50.2fps / 経過 08:17
並列構成: 時間バッチ5レーン

処理統計: 24929フレーム / 検出対象22101フレーム / 復元321クリップ / 29.6fps / 経過 14:02
並列構成: 時間バッチ6レーン

M5 maxやultraなら400とか500とか出るの？

>>69
情報サンクスです SwiftVRは知らなかったです
調べてみたら重たいモデルだけどMPSで動かす想定になっているのでMacに向いている作りのようですね
自分の環境に落としてトライしてみたところ、素の構成だとOOMが出てダメだったけど
コミュニティ版(LightX2V)の内容とFlashVSRでやった高速化手法を取り込んだら
素のFlashVSR_plusより7倍位速くなったｗ (要RTX40系以降のグラボ)

RTX5080でscale 2倍(640x480→1280x960)を試したら48〜50fps(VRAM使用量 8〜8.4GiB)で処理できてる
マジでリアルタイム級の速さ
まだちょっとしか試してないけどFlashVSR x2の結果と比べてアプスケ品質は同等、過鮮鋭は抑え気味でより自然な絵になる印象です
二次復元をこっちに乗り換えるのはアリだな・・・

>>72

M5 pro 18CPU 20GPU 48GBで
2時間作品一本通すと大体160fpsぐらい
設定はちょっと前に出したおすすめ設定にして
検出モデルはv4-fast-coremlで

>>73

Macは行き詰まってます

>コミュニティ版(LightX2V)の内容とFlashVSRでやった高速化手法を取り込んだら

教えてください

>>75
SwiftVRのローカル版でやった最適化はデバイスに依存しないメモリ削減と、CUDAを前提とする高速化
MPSで使えるのは前者だけの見込みだけどMac持ってないので試せないっす
(1) デバイスに依存しないメモリ削減
次の4つはPyTorchの標準的な演算だけで書かれており、CUDA専用のAPIを使っていない
・ReAEのフレームバッチ処理（出典：LightX2V）
　状態を持たない層を数フレームずつ処理し、出力は1つの確保済みテンソルに書き込む
・decoderの分割（出典：LightX2V）
　最後のTGrowまでの状態を持つ部分を先に実行し、捨てるフレームを除いてから、フル解像度の後半を実行
・TGrowとUpsampleの順序入れ替え（出典：独自）
　TGrowは空間方向に点ごとの演算なので、nearestのUpsampleと順序を交換でき、4分の1の画素数で実行できる
・QKV融合後の元の重みの解放（出典：独自）
　融合前のQ、K、Vの投影を解放（約2.6GiB）

つづき
(2) CUDAを前提とする部分
以下の4つの施策は、いずれもCUDAでしか効果がない
・cuDNN attention：名前からわかる通りNVIDA GPU専用
・FP8 DiT：torch._scaled_mm はCUDAとROCm専用で、TritonはMetalに対応してない
・DiTのfusion（torch.compile）：WindowsとLinuxでは、InductorがTritonのカーネルを生成
・ReAE fusion：torch.cudnn_convolution_relu と torch.cudnn_convolution_add_relu はCUDA専用

>>76

ありがとうございます

今まで4KVRしか試してなかったのでデュアルフィッシュアイに変換した時の画質についてはよくわからなかったけど、8K匠で試してみることにした
8K匠はhevc59.94fpsで出力も同じなので、元動画の映像ビットレートを1.5倍（ハードエンコによる画質低下等も考慮）したビットレートを指定した
映像最大ビットレートは取得できなかったが、先ほどのビットレートをさらに1.5倍したものを最大ビットレートとして指定した（これに伴い-cqの指定はやめた）
なお、丸い映像の外の部分を黒にしたのは、そこに映像があるとその部分に無駄にビットレートを割いてしまうのでそれを避けるため

ffmpeg -i input.mp4 -vf "drawbox=0:0:iw/2:ih:black,drawbox=iw/2:0:iw/2:ih:black,v360=hequirect:fisheye:in_stereo=sbs:out_stereo=sbs" -c:v hevc_nvenc -rc vbr -b:v 174000k -maxrate:v 261000k -c:a copy output.mp4

ファイルサイズは、元の動画の約1.47倍になったのでだいたい計算通り
とりあえず、jasnaで「SBS-左右別処理」にかける前にQuest2で見比べたが、画質の劣化は感じられなかった
ちなみに、jasnaで「SBS-左右別処理」（cq22）すると、映像ビットレートは56.8Mbps、映像最大ビットレートは220Mbpsに落ちたのでもっとcqの値を下げた方がよさそうだ
いずれにせよ、適正なビットレートを指定すればデュアルフィッシュアイで十分な画質が得られるので >>70 の処理までは必要ないと思った

Jasna有料の静止画をSD1.5で変換するのって、アニメCGとかでも
元の構図を維持したままモザイク下だけ修正してくれますか？
あまり大きく変わるようならStable Diffusion Web UIでi2iにかけた方が良いんだろうけど
Discordの入り方がよく分からないから投稿サンプルとか見てみたいです・・・

>>80
やってる事自体はi2iのinpaintと同じ
モザイク検出してマスクするのを自動でやるってだけ
ただSD1.5なんで除去後の品質はそれなり

swiftVRすごいな。

現状のMacではチラツキが残ってちょっと目障りだけど、
解像度はめちゃ上がる。
チラツキ対応中。

2xで6fpsぐらいまで落ちるのは仕方ないか。

試しにJasna modi版でSwiftVR二次復元作ってみたけど二次復元目的だと微妙なことがわかった
Scale 2xは速くて、テストに使った1080p動画では一次復元だけの時間に比べて2.5倍位の所まできた
ただしSwiftVRの場合、256px→512pxの2倍拡大ケースで時間安定性が下がる性質があった
(タイルサイズ×スケールが1024より大きくないとダメ)
2xの結果は目視ではっきりわかるくらいにチラつくので実用する場合はscale 4x指定が必要
4x常用だと少ないVRAMのGPUには不利だし、FlashVSRで2xの運用でいいかなと思った

＜参考：RTX5080+Linuxでの実験結果 入力は1080p動画(4203フレーム)＞
　Reference：22.2s (一次復元だけ)
　SwiftVR 2x：53.7s
　SwiftVR 4x：136.4s
　FlashVSR 2x：129.6s (--flashvsr-accel 指定)

>>83

windowsでも同じなんですね。

2xの揺らぎが収まれば、と思って色々試しています。

>>84

Linuxって書いてあったwww

ごめんなさい

>>84
このScale 2xの特性はOSによらないと思うよ
何かいい方法が見つかったら教えてください

>>81
やっぱりinpaintでやった方が無難ですかねぇ　XLに対応してくれれば良さそうですけど


アニメ動画の方だとJasnaとladaでは誤差程度の仕上がりになるけど、だいたい20作に1作くらいの割合で
Jasnaの方がチラつきとモザイク取りこぼしが抑えられて少し綺麗ってのはできますね
ただ全体的に違いがはっきり分かるほど劇的に綺麗ってレベルではない
2Dに関しては後で改善されたverが出た時、確実にやり直すハメになるだろうから
一番好きな作品にだけJasnaかけた方が良いかも

>>86

フリッカー取れたよ。

https://uu.getuploader.com/douzinsi12/download/241

PASS:0143

素朴な疑問なんだけどアニメの場合破解したらこうだったパターンってないのかな
https://pbs.twimg.com/media/EtNwDTMVcAArvt-?format=webp&name=large

>>88
サンクス！
テストで使ってる1080p動画で測ったら、Scale 2xの揺れがScale 4xとほぼ同じレベルまで落ちた
ボケだけ揃えた比較基準用の結果じゃここまで下がらないから、安定化の効果で間違いない
素のSwiftVRが枠の跳びに半分くらいしかついてきてないのも確認できた
「輪郭が太く細く」の正体はたぶんこれだと思う
教えてもらった方法をJasna modiに組み込む方向でやってみる

>>90
利用者です
VRAM 12GBなのでオフラインモードの追加を待ってます

>>90

よかった。

しかし、
SwiftVRこれ凄いよね。
正直感動してる。

二次復元今までうまくいかなかったから。

mioh for mac

swiftVR採用のROIエンハンサー搭載バージョン公開しました。
試してみてください。
モデルは全部構築し直しで面倒臭いと思うけどよろしくです。

ko-fiも待ってます。

https://github.com/mioh-labs/mioh

すごいことに気づいてしまったかもしれん
モザが斜めっていて魚眼であることは間違いないけど、処理すると下方左右のモザが残ってしまうやつあるけど、その対処方法
デュアルフィッシュアイに変換すると、左右の〇の横が短くなるVR動画があった（見分け方は左右の黒い部分が縦に長いVR動画）
縦はそのままで横を長くするにはどうすればいいかというとh_fovの値をデフォルトの180よりも小さくすればいいが、この動画の場合162で横ピッタリになった
モザを掛けているのはこの横ピッタリの画面の時のはずなので、要するにこの時モザは□になっている（つまり、h_fov=180では□にならない）
さて、この162という数字は何だろうと思ったが、これも色々と考えたらわかった
ヘッドセットで魚眼のVRを再生する時、SKYBOXでも4XVRでもなにやら 180°190°200°220°とあるじゃないすか？
結論だけ言うと、h_fov=180×180÷[魚眼角度] で横ピッタリになるので、162になるのは200°ということになる（どうしてこうなるかは考えてみてね）
当然180°は180°（デフォルトなので省略可）、190°は171°（170.5°）、200°は162°、220°は147°ということになる
具体的にはデュアルフィッシュアイ変換時にフィルターの記述にh_fovの設定を挟めばいい

-vf "drawbox=0:0:iw/2:ih:black,drawbox=iw/2:0:iw/2:ih:black,v360=hequirect:fisheye:h_fov=162:in_stereo=sbs:out_stereo=sbs"

>>92
今回教えてもらった切り出しview平滑化対策をJasna modi版に組み込みました(まずはインライン版)
処理コストは測定誤差の範囲だったのでScale 2x/4xいずれの場合も既定で使うことにしました

RTX系でやってきた者として、SwiftVRで凄いと思ったのはその処理速度
素のアプスケ処理では速いと言われてるFlashVSRの約7倍をたたき出したし
jasnaの処理パイプラインでもScale 4xで約4倍、Scale 2xで約2倍それぞれFlashVSR版より速くなった

>>91
オフライン版検討中なのでちょっと待ってね
ピークVRAM量を落とすにはSwiftVR側も改善必要だった
ところで使っているGPUはRTX 4070 or 5070でOK?
今回処理高速化で使ているFP8はRTX40系以降のハードじゃないと動かないので注意が必要

>>95
ご対応感謝
4070tiです
さっきReadmeを拝見しましたら480pなら12GBでinlineいけそうなのでやってみますね

>>96
ついさっきSwiftVR fork版に入れた更新を取り込んでもらうと1080pでもScale 2xなら行けるかもしれないです
Load the FP8 DiT block by block to avoid a bf16 + FP8 load peak

>>95

MacはPython系を使うとメモリー官権で使い物にならないので、全部swiftに移植です。coreMLやcoreAIというAPIが整理されてきて、メモリー管理がとても優秀な様なので、そこそこ負荷を掛けてもswapに溢れることがありません。claudeとcodex頼みだけど、PCに追いつけているのはなかなか良い笑

>>97
SwiftVSR inline 無事動作しました
処理時間はjasnax2ぐらいなので満足度です
スモークテストで動画全体をscale x 2しましたがアップスケーラーとしても魅力的ですね
古いTOPAZモデルよりよっぽど好みです

>>97
自分も試してみた、グラボは4070で、720Pソースの動画に二次修復をX2で実行して25〜27フレーム/秒程度の処理速度
FlashVSR2Xの二次修復より若干モジャ毛を増やす傾向はあるかも？くらいでディティールはほぼ同等な感じで速度は素晴らしい

新モデルリリースの進捗をずーっと濁してたKrukも「数か月以内には出す」と明言したし、この二次修復と合わせたらスゲーことになりそう

>>99
>>100
インライン版動作確認乙です オフライン版も先ほどpushしました

出来はSeedVR2/FlashVSR並みに見えるのにSwiftVRはあまり話題になっていない気がしたので
何でかAIに聞いてみたら「速さは本物、画質の評価はまだ固まっていない」とのことでした
Redditにもそんな感じのスレがあったよ
RTX5090やH100使って高解像度動画をリアルタイム処理するのに特化とか尖ってるのは嫌いじゃないけどｗ
もったいないなー

>>100
仮に新モデルとこの二次復元をつなげてインラインで処理したらVRAMが最低でも24GB必要になるコースと思たｗ

>>93
macbook pro M1 32GB に入れました
Release版をアプリフォルダに入れて同梱のマニュアル通りに設定したらあっさりSwiftVSRも動きました
リアルタイム再生機能も入っていてMac版jasnaという感じですね
ありがとうございます

リアルタイム再生の方は二次復元はされていないのかな

>>102

リアルタイム再生はROIエンハンサーはできないと思ってください。
合成の項目の各エレメントは使えると思います。

HLS再生いいですよw

質問です。

PCのシステムでは、多数のモザイクが混在している場面で、復元の品質が落ちる現象はありますか？

動画によるとしか答えようがないと思う

>>104
「復元の品質が落ちる現象」って具体的にはなんだ？ (検知漏れ、取りこぼし、復元の絵がボケる、etc.)
ふわっとした質問だとふわっとした回答になっちゃうよ

最近のJasnaのモザイク検知モデル・検知処理にはあんまり不満ないな
miohで問題になっている動画をJasnaのSegment Editorで見て検知がどうなっているのか比べるのが手っ取り早い気がする

ありがとうございます。

ladaの実装を見ていると、
複数のモザイクが重なり合うような場面で、
復元対象の枠が急に大きくなったり小さくなったりする可能性があって、
それに引きずられて復元画質が極端に悪くなるという現象があります。

jasnaは使えないので、
ladaとは違う実装のようですが、
jasnaでは同様の現象があるのかな？と思ってお伺いした次第です。

ぶっちゃけて言えば、
「顔の周りが多くの竿でモザイクだらけ」
みたいな場面ですw

>>107
画面内にモザ多めの動画でjasnaとlada-exとで残モザイク量を比較したことがあるけど
その時使ったデータだとjasnaの方が取りこぼし少ない結果でした
#jasnaはシーン切り替わり検出やモザのトラッキングなど独自処理あり

書いてある現象はlada-exに出したPR#28が参考になりそうな気がする
lada-exの方も作者さんが改良しているので、まだ調べてなかったらソース読み込むと良いことあるかも

お前らの言ってる事の1割も理解できない

>>109

それでも楽しめ！！w

>>108

ありがとうございます。

行ってみますね。

jasna本家に大量のコミットがあったのでそろそろ新しいリリースが出そうだが、使い勝手改善、リファクタやバグ修正がメインっぽい
新モデルや復元処理が何か新しくなるような変更は今のところ入って無さそうなんだよな・・・

jasnaに課金しようと思うんだけど、UNex-4xってどんな感じですか？
3Dアニメーションのモザ消し試してみたけど、rfdetr-v6は取りこぼすし、v1は時間かかるし、lada yoloはその中間な立ち位置だと思ってやってるんですけど違ったらすみません。
使ってるかた教えてください〜

V6でそんな取りこぼす？

>>113
基本設定の検出しきい値を下げたらええんでないの？
モデルによってデフォだと0.25～0.45になってるはずだけど
極端な話、0にしてやってみるとかさ

>>113
取りこぼしの話とUNex-4xは別件ですよね。UNex-4xは２次修復なので検出とは関係ないので
個人的にはRTX Super Resと大きな違は無いと感じた

>>116
× UNex-4x
〇 UNet 4x

LTX-2.5ベースの新復元モデル「ltx」がmainに追加されたので次バージョンで新モデル来る
以下、調べた結果
- LightricksのLTX-2.5(22B 動画拡散モデル)をモザイク復元用にfine-tuneしたもの
- BasicVSR++より大幅に遅いが画質最高、という位置づけ、NVIDIA専用
- 非対応： ストリーミング、セグメント、unet-4x等の二次復元、denoise、VR SBS
- 重みはINT8で約22GB、VRAMに入らない分はメインメモリからストリーミングするので
　VRAM 16GBでも動く設計(ただし激遅、メインメモリ32GB 以上が推奨になりそう)
- 重みはsupporter専用の暗号化配布で、既存キーでは開かず「LTX 対応のアップグレードキー」が必要とREADMEに明記されてる
- 重み自体もまだ未配布、0.11.0リリース＋キー販売開始まで誰も動かせない