前スレ
【超解像】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スケジューリング>オフ
・最新グラフィックスドライバに更新
【超解像】Lada part6
1名無しさん@お腹いっぱい。
2026/09/18(金) 07:09:22.98ID:HcSsDWfJ02026/09/18(金) 15:08:39.30ID:xq6PmOUq0
破壊を極めるという事はモザイクのチンコを鮮明に映すという事
潜在的なゲイと愉快なオカマ達のハッテンバはここですか?
潜在的なゲイと愉快なオカマ達のハッテンバはここですか?
3名無しさん@お腹いっぱい。
2026/09/18(金) 19:09:21.30ID:05iddI0i0 みんなチンコが大好きなんだよ。
某ショートスリーパーの無修正ちんこも男女問わず話題になったくらいだし。
某ショートスリーパーの無修正ちんこも男女問わず話題になったくらいだし。
4名無しさん@お腹いっぱい。
2026/09/18(金) 19:12:37.85ID:L8EDLSni0 みんなデカくてハリのあるガチガちんぽが好きってだけなんだよ
短小やフニャチンや汚れが目立つちんぽは嫌われる
短小やフニャチンや汚れが目立つちんぽは嫌われる
2026/09/19(土) 05:17:51.96ID:JqRZ2/NA0
石器時代や縄文時代のはるか昔から
生殖器崇拝はしっかりあったからな
太古から人類のDNAに刻まれてるんだよ
みんなチンコとマンコが大好きなんだ
生殖器崇拝はしっかりあったからな
太古から人類のDNAに刻まれてるんだよ
みんなチンコとマンコが大好きなんだ
6名無しさん@お腹いっぱい。
2026/09/19(土) 06:12:12.86ID:1oEiBs/P0 やっぱゲイじゃん
2026/09/19(土) 09:41:01.92ID:PxhAEmoL0
女子目線の印象によると、結局男は女性器よりちんこの方が好きなように見えるらしい。
性的な意味ではなく。
性的な意味ではなく。
2026/09/19(土) 11:48:49.79ID:aC16gVpo0
>>2
フェラッチョも挿入も興味ないの?w
フェラッチョも挿入も興味ないの?w
2026/09/19(土) 11:52:15.11ID:j3JCnkD/0
mac版のmiohが404
10名無しさん@お腹いっぱい。
2026/09/19(土) 13:13:03.81ID:slvu8hyc0 mac book proユーザーだからlanaのGUI版使ってるけどすごく時間かかるね。
40分の動画でも10時間くらい?
window買ってもいいけど、どのくらいのスペックあれば快適なんだろう・・・
40分の動画でも10時間くらい?
window買ってもいいけど、どのくらいのスペックあれば快適なんだろう・・・
11名無しさん@お腹いっぱい。
2026/09/19(土) 15:33:06.84ID:J2a6E2rk012名無しさん@お腹いっぱい。
2026/09/19(土) 15:34:14.90ID:J2a6E2rk013名無しさん@お腹いっぱい。
2026/09/19(土) 18:12:25.76ID:J2a6E2rk02026/09/19(土) 21:21:26.06ID:8Iii9wLj0
SeedVR2+LoRA一次復元の改善が行き詰まり気味なので気分転換にJasna modi版のFlashVSR二次復元をメンテした
・scale 2倍を追加(inline/offline両対応):512px処理なのでinlineで約4〜5倍速くVRAM 3.5GB減、offlineだと約2.5倍速くVRAM 5GB減
・色補正を常時適用:復元領域だけ色味がずれていたのを、BasicVSR++ 一次復元の色調に合わせるようにした
・clip 32上限撤廃:inlineは通常の --max-clip-size(既定90)がそのまま効き、offlineは --flashvsr-max-clip-frames の既定を32→90にした
これでFlashVSRの処理時間がほぼ半分になる
VRAM 16GB でscale 4を使う人は --flashvsr-tiles 2 を付けてくれ (scale 2はtiles無しでOK)
・scale 2倍を追加(inline/offline両対応):512px処理なのでinlineで約4〜5倍速くVRAM 3.5GB減、offlineだと約2.5倍速くVRAM 5GB減
・色補正を常時適用:復元領域だけ色味がずれていたのを、BasicVSR++ 一次復元の色調に合わせるようにした
・clip 32上限撤廃:inlineは通常の --max-clip-size(既定90)がそのまま効き、offlineは --flashvsr-max-clip-frames の既定を32→90にした
これでFlashVSRの処理時間がほぼ半分になる
VRAM 16GB でscale 4を使う人は --flashvsr-tiles 2 を付けてくれ (scale 2はtiles無しでOK)
2026/09/19(土) 22:49:01.63ID:rgWCnz2D0
>>14
今日アップデートされてた
flashvsr_inline_secondary_restorer.py
flashvsr_inline_worker.py
flashvsr_offline.py
flashvsr_phase2_driver.py
この4つを書き換えればおkって事?
今日アップデートされてた
flashvsr_inline_secondary_restorer.py
flashvsr_inline_worker.py
flashvsr_offline.py
flashvsr_phase2_driver.py
この4つを書き換えればおkって事?
2026/09/19(土) 23:13:41.58ID:8Iii9wLj0
2026/09/19(土) 23:19:18.62ID:rgWCnz2D0
>>16
実はこのへんのファイルを既にいじってる(offline処理でFlashVSRX4&クリップサイズ512で実行に設定して、最大でVRAM消費が11G弱)ので
とりあえずバックアップをまるごと取ってからアプデしてみるね
色目は確かにズレた違和感あったので合わせられるとありがたそう
実はこのへんのファイルを既にいじってる(offline処理でFlashVSRX4&クリップサイズ512で実行に設定して、最大でVRAM消費が11G弱)ので
とりあえずバックアップをまるごと取ってからアプデしてみるね
色目は確かにズレた違和感あったので合わせられるとありがたそう
2026/09/19(土) 23:34:27.04ID:2XmgMMio0
>>8
フェラシーンが好きなやつはホモの素質があると言われてる ネタではなく
フェラシーンが好きなやつはホモの素質があると言われてる ネタではなく
2026/09/20(日) 04:11:25.25ID:Trbil+Wn0
2026/09/20(日) 04:12:00.92ID:Trbil+Wn0
>>2だった
2026/09/20(日) 04:13:43.59ID:gZSUy2ar0
そんな必死に否定せんでもええがな
2026/09/20(日) 06:41:24.69ID:yvjCDugU0
きっしょ
2026/09/20(日) 09:07:19.25ID:gQDWSjCl0
flashvsrの4倍めちゃめちゃ時間かかるね
4fpsぐらいしか出ないから5分の動画の処理に30分以上かかりそう
4fpsぐらいしか出ないから5分の動画の処理に30分以上かかりそう
2026/09/20(日) 12:37:27.64ID:jOiFY7Vt0
>>14
13700+4070の環境で
・一次basicVSR+二次FlashVSRX2(タイル分割処理なし)+inline設定(一時修復プロセスのブロックごとに即実行、でいいのよね?)
Maxクリップサイズ=512程度なら、1080Pソースの処理にVRAM消費11GB前後で行ける
・これまでよりすげー速くなった、もうJasna本家に導入されてもいいくらいでは…
・修復部位の色合いの違和感が消失
・FlashVSRX4はタイル4分割なら実行可能だった、X2との仕上がりの違いは試した範囲だとあまりわからなかった
2次修復の精細度はJasnaの画像修復に近い精細度を動画でやれてるくらいな感じ
毛のディティールが過剰になりがちなのはFlashVSRの癖っぽい?
一つ気になったのは2次修復まで終わってエンコードに入っても、VRAM消費が高止まりなままだった事
13700+4070の環境で
・一次basicVSR+二次FlashVSRX2(タイル分割処理なし)+inline設定(一時修復プロセスのブロックごとに即実行、でいいのよね?)
Maxクリップサイズ=512程度なら、1080Pソースの処理にVRAM消費11GB前後で行ける
・これまでよりすげー速くなった、もうJasna本家に導入されてもいいくらいでは…
・修復部位の色合いの違和感が消失
・FlashVSRX4はタイル4分割なら実行可能だった、X2との仕上がりの違いは試した範囲だとあまりわからなかった
2次修復の精細度はJasnaの画像修復に近い精細度を動画でやれてるくらいな感じ
毛のディティールが過剰になりがちなのはFlashVSRの癖っぽい?
一つ気になったのは2次修復まで終わってエンコードに入っても、VRAM消費が高止まりなままだった事
25名無しさん@お腹いっぱい。
2026/09/20(日) 14:23:54.27ID:ZQLJUimI0 次の更新いつくるんだろ
2026/09/20(日) 17:35:15.99ID:gSv8tOZm0
復元モデルもアップデートして欲しい
でも重くなりそうだな
でも重くなりそうだな
2026/09/20(日) 18:28:07.63ID:R+fmWSs50
>>24
VRAM消費が高止まりのままだったのはoffline指定で動かした時の挙動?
jasnaの処理が終わってもVRAMを開放せずに残っていたとかだったらまずいんで
もし不具合っぽい動作があったらgithubのissueで報告してもらえると助かります
VRAM消費が高止まりのままだったのはoffline指定で動かした時の挙動?
jasnaの処理が終わってもVRAMを開放せずに残っていたとかだったらまずいんで
もし不具合っぽい動作があったらgithubのissueで報告してもらえると助かります
2026/09/20(日) 20:22:31.81ID:jOiFY7Vt0
>>27
inlineのほう
短すぎない動画で実行すると、修復とエンコードがある程度同時?交互?進行していてVRAMを保持しているのは分かるんだけど
修復が100%終了して、エンコードのみ残ってる状態でもVRAMは修復実行中と同じく、11G前後使ってるままで最後まで進む
エンコードも終われば解放される(複数動画をまとめて登録して実行した場合も大丈夫)
offlineでの起動はまだあまり試してないので判りません
inlineのほう
短すぎない動画で実行すると、修復とエンコードがある程度同時?交互?進行していてVRAMを保持しているのは分かるんだけど
修復が100%終了して、エンコードのみ残ってる状態でもVRAMは修復実行中と同じく、11G前後使ってるままで最後まで進む
エンコードも終われば解放される(複数動画をまとめて登録して実行した場合も大丈夫)
offlineでの起動はまだあまり試してないので判りません
2026/09/20(日) 22:07:20.40ID:R+fmWSs50
>>28 なるほど
進捗バーの100%は「修復完了」じゃなくて「デコードと検出が終わった」時点で到達するんだわ
なので100%になった後もキューに残ってる分をFlashVSRがまだ修復中
VRAMがつかみっぱなしに見えるのはそのためで、裏でまだ働いてる状態
解放はパイプライン全体が終わってモデルを捨てるタイミングなので、残りの修復が片付くまで保持
inline版はモデルを常駐させる作りなのでこうなってます (offline版は別経路)
あと、クリップサイズ512だと1クリップが閉じるまでが長いので、100%の後に残る処理もその分長くなって余計目立つと思う
ちなみにinline版はクリップを小分けにして流す作りで、その小分けの単位はクリップサイズとは別にFlashVSR側で固定されてる
クリップサイズを大きくしても小分けの数が増えるだけでサイズは変わらないので、FlashVSR側のVRAM常駐量はほぼ一定だったりする
進捗バーの100%は「修復完了」じゃなくて「デコードと検出が終わった」時点で到達するんだわ
なので100%になった後もキューに残ってる分をFlashVSRがまだ修復中
VRAMがつかみっぱなしに見えるのはそのためで、裏でまだ働いてる状態
解放はパイプライン全体が終わってモデルを捨てるタイミングなので、残りの修復が片付くまで保持
inline版はモデルを常駐させる作りなのでこうなってます (offline版は別経路)
あと、クリップサイズ512だと1クリップが閉じるまでが長いので、100%の後に残る処理もその分長くなって余計目立つと思う
ちなみにinline版はクリップを小分けにして流す作りで、その小分けの単位はクリップサイズとは別にFlashVSR側で固定されてる
クリップサイズを大きくしても小分けの数が増えるだけでサイズは変わらないので、FlashVSR側のVRAM常駐量はほぼ一定だったりする
2026/09/20(日) 22:57:46.30ID:jOiFY7Vt0
2026/09/21(月) 07:37:52.29ID:bL9bWtDu0
32名無しさん@お腹いっぱい。
2026/09/21(月) 08:42:58.05ID:5GxyiuNR02026/09/22(火) 01:29:47.36ID:H3rjrp5u0
>>29
ちょっと質問
>inline版はクリップを小分けにして流す作りで、その小分けの単位はクリップサイズとは別にFlashVSR側で固定されてる
この「FlashVSR側で固定されてる」クリップサイズって数値はいくつ?
これに合わせて・あるいは等倍で設定しておいたほうが能率よかったりする?
ちょっと質問
>inline版はクリップを小分けにして流す作りで、その小分けの単位はクリップサイズとは別にFlashVSR側で固定されてる
この「FlashVSR側で固定されてる」クリップサイズって数値はいくつ?
これに合わせて・あるいは等倍で設定しておいたほうが能率よかったりする?
2026/09/22(火) 06:25:03.11ID:jl+xMxcZ0
>>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%程度)
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%程度)
2026/09/22(火) 11:25:10.69ID:reVix/Nj0
36名無しさん@お腹いっぱい。
2026/09/22(火) 12:36:05.98ID:MscSnSw402026/09/22(火) 20:22:52.76ID:H3rjrp5u0
>>34
把握、感謝
把握、感謝
2026/09/23(水) 10:44:42.79ID:wZKocGsu0
39名無しさん@お腹いっぱい。
2026/09/23(水) 13:26:38.34ID:lhkZwm2U040名無しさん@お腹いっぱい。
2026/09/23(水) 13:28:13.91ID:lhkZwm2U041名無しさん@お腹いっぱい。
2026/09/23(水) 19:34:27.24ID:FVneTMc+0 mac版のmioh興味がありますがどこで入手可能?
42名無しさん@お腹いっぱい。
2026/09/23(水) 20:17:26.01ID:WVwO1yNk043名無しさん@お腹いっぱい。
2026/09/23(水) 20:35:38.82ID:FVneTMc+0 ありがとうございます
2026/09/23(水) 21:58:41.60ID:0btST1hE0
>>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%くらいしか遅くならない
詳細はドキュメント参照してください
これ以上の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%くらいしか遅くならない
詳細はドキュメント参照してください
45名無しさん@お腹いっぱい。
2026/09/23(水) 22:20:02.82ID:FVneTMc+0 必要なリソースが見つかりません: Swift native detection model: v4-fast-coreml
と出てエラーが出てしまいますが、何か対策はありますか?
と出てエラーが出てしまいますが、何か対策はありますか?
46名無しさん@お腹いっぱい。
2026/09/23(水) 22:30:22.15ID:WVwO1yNk047名無しさん@お腹いっぱい。
2026/09/24(木) 08:31:55.40ID:wZJvhzBI0 >>46
ありがとうございます。起動はできたのですが20%らへんのところで
Swiftネイティブプレビューを開始できませんでした: Cannot Decode
mioh-native-coreai-preview: Cannot Decode
と出てエラーになってしまいました。
ネイティブプレビューというのは何なのでしょうね?
ありがとうございます。起動はできたのですが20%らへんのところで
Swiftネイティブプレビューを開始できませんでした: Cannot Decode
mioh-native-coreai-preview: Cannot Decode
と出てエラーになってしまいました。
ネイティブプレビューというのは何なのでしょうね?
48名無しさん@お腹いっぱい。
2026/09/24(木) 09:05:02.97ID:Sa4EMlXh049名無しさん@お腹いっぱい。
2026/09/24(木) 09:20:15.71ID:wZJvhzBI0 一応ladaとかだと問題なかったんですよね・・・
比較しようと思って実行したので。
他の動画で試してみますね
比較しようと思って実行したので。
他の動画で試してみますね
50名無しさん@お腹いっぱい。
2026/09/24(木) 09:21:46.27ID:wZJvhzBI0 あ、もしかしたらOSアップデートしてから動画とか開いてなかったのが原因かも?
51名無しさん@お腹いっぱい。
2026/09/24(木) 15:21:34.30ID:wZJvhzBI0 ありがとうございます。無事解決しました。
52名無しさん@お腹いっぱい。
2026/09/24(木) 16:39:25.12ID:Sa4EMlXh053名無しさん@お腹いっぱい。
2026/09/24(木) 16:48:33.00ID:wZJvhzBI054名無しさん@お腹いっぱい。
2026/09/24(木) 17:11:21.94ID:Sa4EMlXh055名無しさん@お腹いっぱい。
2026/09/24(木) 17:13:40.61ID:Sa4EMlXh056名無しさん@お腹いっぱい。
2026/09/24(木) 17:13:54.29ID:wZJvhzBI0 >>54
ありがとうございます。試してみますね。
ありがとうございます。試してみますね。
57名無しさん@お腹いっぱい。
2026/09/24(木) 17:14:41.56ID:wZJvhzBI058名無しさん@お腹いっぱい。
2026/09/24(木) 17:35:09.36ID:Sa4EMlXh059名無しさん@お腹いっぱい。
2026/09/24(木) 18:07:27.22ID:wZJvhzBI060名無しさん@お腹いっぱい。
2026/09/24(木) 18:10:46.97ID:Sa4EMlXh061名無しさん@お腹いっぱい。
2026/09/24(木) 18:18:32.24ID:wZJvhzBI0 >>60
60~180fpsと結構差がありました
60~180fpsと結構差がありました
62名無しさん@お腹いっぱい。
2026/09/24(木) 18:26:50.29ID:Sa4EMlXh063名無しさん@お腹いっぱい。
2026/09/24(木) 18:28:26.50ID:wZJvhzBI064名無しさん@お腹いっぱい。
2026/09/24(木) 18:31:45.22ID:Sa4EMlXh065名無しさん@お腹いっぱい。
2026/09/24(木) 21:49:46.19ID:WD6kqzGy0 mioh
ネイティブ並列数を10まで増やしました。
M5 maxやultraなら400とか500とかfps出るような気がします。
どなたか試してもらえませんか?
ネイティブ並列数を10まで増やしました。
M5 maxやultraなら400とか500とかfps出るような気がします。
どなたか試してもらえませんか?
66名無しさん@お腹いっぱい。
2026/09/25(金) 03:22:38.48ID:AHkPOcwf0 魚眼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
で、色々試してみた結果、最初にデュアルフィッシュアイに変換してから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
67名無しさん@お腹いっぱい。
2026/09/25(金) 03:30:13.06ID:AHkPOcwf0 デュアルフィッシュアイは周辺部分の歪みが少なくなるので、普通に2Dとして再生した時に結果の確認もやりやすいし、なんなら、2D再生して楽しむこともできる
2026/09/25(金) 08:30:13.85ID:5Rs+d2Mo0
魚眼はv8に比べて9、10は認識が悪くなってしまったからv8を使ってる
映像全体の魚眼変換をやると
映像全体の画質がモヤっとしていると感じたのでもうやらないな
映像全体の魚眼変換をやると
映像全体の画質がモヤっとしていると感じたのでもうやらないな
69名無しさん@お腹いっぱい。
2026/09/25(金) 10:04:39.98ID:mRzb+kUn0 Jasna modi作者様
swiftVRというプロジェクトはご存知ですか?
https://github.com/H-oliday/SwiftVR
macでやってみたら試験段階ですが、めちゃ良好。
FlashVSRを動かしてないので比較はできませんが、
面白いと思います。
ご存知でしたら、忘れてください笑
swiftVRというプロジェクトはご存知ですか?
https://github.com/H-oliday/SwiftVR
macでやってみたら試験段階ですが、めちゃ良好。
FlashVSRを動かしてないので比較はできませんが、
面白いと思います。
ご存知でしたら、忘れてください笑
70名無しさん@お腹いっぱい。
2026/09/25(金) 10:27:32.80ID:AHkPOcwf0 >>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に変えれば赤とかもできる
左右の色を変えて紅白も可能だけど、ヘッドセット被って片目ずつ瞑って見ると映像の切れ目の色が違ってしまう
「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に変えれば赤とかもできる
左右の色を変えて紅白も可能だけど、ヘッドセット被って片目ずつ瞑って見ると映像の切れ目の色が違ってしまう
71名無しさん@お腹いっぱい。
2026/09/25(金) 10:34:16.60ID:AHkPOcwf0 この方法だと、元の動画1から最終動画への再エンコードも4で行う1回だけとなる
2026/09/25(金) 18:11:36.97ID:aEWAA+E+0
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とか出るの?
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とか出るの?
2026/09/25(金) 18:22:09.11ID:OF0xc8aw0
>>69
情報サンクスです SwiftVRは知らなかったです
調べてみたら重たいモデルだけどMPSで動かす想定になっているのでMacに向いている作りのようですね
自分の環境に落としてトライしてみたところ、素の構成だとOOMが出てダメだったけど
コミュニティ版(LightX2V)の内容とFlashVSRでやった高速化手法を取り込んだら
素のFlashVSR_plusより7倍位速くなったw (要RTX40系以降のグラボ)
RTX5080でscale 2倍(640x480→1280x960)を試したら48〜50fps(VRAM使用量 8〜8.4GiB)で処理できてる
マジでリアルタイム級の速さ
まだちょっとしか試してないけどFlashVSR x2の結果と比べてアプスケ品質は同等、過鮮鋭は抑え気味でより自然な絵になる印象です
二次復元をこっちに乗り換えるのはアリだな・・・
情報サンクスです SwiftVRは知らなかったです
調べてみたら重たいモデルだけどMPSで動かす想定になっているのでMacに向いている作りのようですね
自分の環境に落としてトライしてみたところ、素の構成だとOOMが出てダメだったけど
コミュニティ版(LightX2V)の内容とFlashVSRでやった高速化手法を取り込んだら
素のFlashVSR_plusより7倍位速くなったw (要RTX40系以降のグラボ)
RTX5080でscale 2倍(640x480→1280x960)を試したら48〜50fps(VRAM使用量 8〜8.4GiB)で処理できてる
マジでリアルタイム級の速さ
まだちょっとしか試してないけどFlashVSR x2の結果と比べてアプスケ品質は同等、過鮮鋭は抑え気味でより自然な絵になる印象です
二次復元をこっちに乗り換えるのはアリだな・・・
74名無しさん@お腹いっぱい。
2026/09/25(金) 19:02:27.87ID:mRzb+kUn075名無しさん@お腹いっぱい。
2026/09/25(金) 19:03:44.38ID:mRzb+kUn02026/09/25(金) 20:14:02.39ID:OF0xc8aw0
>>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)
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)
レスを投稿する
ニュース
- 高市総理「日米は非常に強い絆で結ばれた同盟国」 トランプ大統領の“中国は同盟国だった”発言受け [首都圏の虎★]
- 「暗い未来に子供を産みたくない…」それでも左派よりも右派の方が「たくさん子供を産む」のはなぜか【米研究】 [首都圏の虎★]
- 【野球】広島東洋カープの矢野雅哉・前川誠太選手を書類送検 ゾンビたばこを巡る容疑 広島県警 [Ailuropoda melanoleuca★]
- 【速報】 高市首相 「円の過小評価は問題だ」 ★4 [お断り★]
- 【東京】ウズベキスタン国籍のフードデリバリー配達員を逮捕 配達先の女子小学生にキスや体を触るなどわいせつ行為か ★2 [煮卵★]
- 【テレビ】サッカー日本代表-ウルグアイ戦の視聴率は4.1%→9.1%、アジア大会の卓球団体戦男女は8.4%→9.9% [鉄チーズ烏★]
- 自分たちでvipつまらなくしといて、「vipつまらん」とか言い出すのってだいたいこういう奴なんだよな
- 【HanaE.sys】night
- 駅伝大好き日本人に捧げる感動ドラマ「俺たちの箱根駅伝」 10月10日より日テレで 選手の苦悩と感動、そして中継の熱き裏側 [737440712]
- ハッタショって人から「ハッタショ」と指摘されるのはめちゃくちゃ嫌がるよな
- 先走り汁も愛液も乾くと臭いじゃん
- 高市早苗「日本とアメリカは戦争後に和解して関係を深めて非常に強い絆で結ばれている」 [931948549]