以下は、提供された5chログ(レス232〜438)から、指定された生成AIモデル(- NovelAI v4もしくはv3 (NAI), - Pony, - Illustrious 0.1,1.0,1.1,2,3,3.5vpred (イラストリアス, リアス,ill), - Noobai, - FLUX , HiDream, - Wan2.1 (wan), - FramePack)に関する話題をすべて抽出したものです。抽出の基準は以下の通りです:
- ログ内でこれらのモデル名(またはその略称/関連用語)が明示的に言及されている部分を対象としました。
- 各抽出部分では、レス番号、関連する引用文、及び文脈を簡潔に記述。
- 特に、そのモデルが選ばれている理由(例: 性能、使いやすさ、特定の機能など)が明記されている場合、それを強調して抽出。
- 指定モデル以外のモデル(例: Qwen, SDXLなど)は抽出対象外とし、無視。
- NoobaiとHiDreamはログ内で一切言及がないため、抽出なし。
- 抽出はモデルごとに分類し、重複を避けつつ時系列順に整理。Wan関連は言及が多いためサブカテゴリ化。
NovelAI v4/v3 (NAI)
- レス237: 「»220 NovelAIの話は当スレのWikiの雑談スレで活発に行われているよ」
(NovelAIの話題が別のスレで活発に行われているという指摘。選ばれている理由の言及なし。)
- レス241: 「»237 すまん、ノベルAI専用だと思って書き込みをひかえていたんだ 自分はcomifyui+ウルトラ低スペックマシンで静止画シコ勢や」
(NovelAIを専用スレだと思っていたため書き込みを控えていたという内容。選ばれている理由: 静止画生成(特にエロ用途)で低スペックマシンで使用可能。)
- レス292: 「»287 v3に命が宿ってる・・・」
(v3に「命が宿っている」という表現で、生成結果のクオリティを称賛。選ばれている理由の言及なしが、文脈からアニメーション的な表現力の高さを示唆。)
- レス379: 「NAI画像からWAN動画はさすがに無いか スレ民コラボしか無さそう」
(NAI画像をWAN動画に変換する可能性を疑問視。選ばれている理由の言及なし。)
- レス387: 「»379 普通にNAI画像からWAN動画作ってるぜ わざわざ言わんだけで」
(NAI画像からWAN動画を普通に作っているという報告。選ばれている理由: 静止画生成のベースとして使用し、動画変換に活用(黙って使っている人が多い)。)
Pony
- レス383: 「聞きたいんだけどIllustrious/PONY系で狙ったポージングとか表情ってプロンプトだけじゃ出ないよね? 「おじさんと若い娘が一緒にTV見てて、おじさんが娘の肩に手を回して、娘は嫌そうな顔で身体を引き離そうとしてる」画像を出したいのにIllustrious/PONYでは全然ダメだった…」
(Illustrious/PONY系でプロンプトのみでのポージング/表情制御が難しいという不満。選ばれている理由の言及なしが、逆に「プロンプトだけでは出ない」ため不向きと指摘。)
- レス391: 「»383 SDXLは基本的にタグしか認識しないし自然言語を与えてもタグに分解して認識するだけなので、「誰が何をしている」みたいなものはよほど蓋然性が高くないと無理」
(PONY系/SDXLの限界として、タグベースのため複雑なシナリオが苦手。選ばれている理由の言及なしが、文脈からタグベースのシンプルな生成に向く。)
Illustrious 0.1,1.0,1.1,2,3,3.5vpred (イラストリアス, リアス,ill)
- レス383: (上記Ponyと同一。Illustrious/PONY系として言及され、プロンプト制御の難しさを指摘。選ばれている理由の言及なし。)
FLUX (HiDreamはなし)
- レス256: 「Qwenはアニメ絵は得意なように見えるけどfluxにあった極端な線の正確さみたいなのはあんま感じんな chromaが一応fluxなんやけど去勢版やしどこまでやれんのかは気になるンゴね」
(Fluxの「極端な線の正確さ」を称賛し、Chroma版の制限を指摘。選ばれている理由: アニメ絵の線描写の正確さが高い。)
- レス284: 「FLFサンプル見てるけど既存のマイwan2.2環境とつなげるのムズそうやわ・・・」
(FLFサンプルを既存のWan2.2環境に統合するのが難しいという内容。FLFはFrameLab Fluxの略か? 選ばれている理由の言及なしが、動画生成の拡張用途を示唆。)
- レス333: 「静止画の情報もとても有り難いFLUXも高速化するんやねこれ 今更静止画ネタというか過去にはNAIの時とかもそうやったし」
(Fluxの高速化情報を歓迎。選ばれている理由: 静止画生成の速度向上に有効。)
- レス377: 「ワイ昨日FLF公式ワークフローでGGUF対応にしてLoRA対応にしてligtx2v入れたらええ感じやね Step6 cgf 1にしとる」
(FLF公式ワークフローをカスタムして良い結果。選ばれている理由: GGUF/LoRA対応で使いやすく、生成結果が良い。)
- レス426: 「すごい今更&場違いやが Flux KontextをComfyUIで触ってみた ちょっとレタッチしたいときとか便利そうや」
(Flux KontextをComfyUIで使用し、レタッチに便利。選ばれている理由: 画像の部分修正(レタッチ)に便利。)
Wan2.1 (wan) ※言及が多く、EasyWan22を含む関連ツールも抽出
- レス239: 「音声あり 1年前(kling+suno v3+aviutl) 今日(wan2.2+suno v4.5++aviutl2) 1年ってすごいんやね……」
(Wan2.2を1年前のツールと比較し、進化を称賛。選ばれている理由: 動画生成の進化が著しく、音声付き動画作成に有効。)
- レス254: 「»181,193,197,214 »91 でEasyWan22のGitHubの方をリリースしとったたつもりでできとらんかった 今以降にUpdate.bat実行したらI2VのワークフローもLoRAも更新されて問題なくなるはずや」
(EasyWan22のリリースと更新を告知。選ばれている理由: I2VワークフローとLoRAの更新で動画生成の問題解決。)
- レス260: 「»254 サンガツ! easywan無かったらまらかに動画生成出来てる気がせんから、むしろ日々感謝しかないでー」
(EasyWanなしでは動画生成が難しいという感謝。選ばれている理由: 動画生成のしやすさと安定性が高い。)
- レス268: 「»254 更新サンガツやで 3060で長辺640と786で生成時間30秒しか変わらなかったから768だとrefiner1.25倍でもOOMなって等倍じゃないと通らんかったわ 640で生成してrefineで拡大する方法のが良さそうやね」
(EasyWanの更新を感謝し、3060環境での最適化を議論。選ばれている理由: 低スペックGPU(3060)で効率的な動画生成/拡大が可能。)
- レス271: 「wanのヌルヌルが気になるんはやっぱりどこか不自然だからだと思うわ veo3みたいなのでアニメ絵動かすと30fpsくらいのはずやけど別に気にならんもん」
(Wanの滑らかな動きを不自然と指摘しつつ、アニメ絵のfps対応を評価。選ばれている理由: アニメ絵の動画生成でfps調整が可能だが、不自然さが課題。)
- レス273: 「EasyWan22なら、フレーム補完をオンするノードの下に「FPS60、FPS60+1.3スピード、FPS30」って選択出来る所があるね ぬるぬる抑えたいなら、この辺りを試してみるのも良いかも。」
(EasyWan22のfps選択機能を紹介。選ばれている理由: フレーム補完とfps調整で滑らかな動きを制御可能。)
- レス274: 「動きの学習が35秒で一種の正規化されちゃってるのかなというのはある orgasmLoRAで8秒生成やるとイッた後に手持ち無沙汰になって賢者モード入れてくる」
(WanのLoRAを使った動画生成の挙動を分析。選ばれている理由: 特定のLoRA(Orgasm)で動きの学習が安定し、動画の自然さを向上。)
- レス284: (上記FLUXと重複。Wan2.2環境との統合を議論。選ばれている理由: 既存環境との互換性が高いが、統合が難しい。)
- レス285: 「easywan22を一回削除して再度インスコしても削除前に使ってた画像やプロンプトが入ったまま始まるんですが」
(EasyWan22のキャッシュ問題。選ばれている理由の言及なし。)
- レス309: 「ワイmatrix民やが経由でcomfyすると素で入れた時と違って中に検閲する記述入っててカスタムノード導入で勝手に弾いたりとめっちゃめんどいので easy直入れするのおすすめしとくで」
(EasyWanの直接インストールを推奨。選ばれている理由: 検閲回避とカスタムノードの導入しやすさ。)
- レス315: 「easywan22の新しいワークフローでLow側のModel Loaderの入力のblock_swap_argsがどこにもつながっていなかったので、適当につないだらOOMが出なくなった。」
(EasyWan22のワークフロー修正でOOM回避。選ばれている理由: メモリ効率の向上。)
- レス329: 「easywan22のワークフローでendimage使ったときの色の変化はcolor matchノード使えば直るらしいけど赤ちゃんやからどこに繋げばいいかわからんわ…」
(EasyWan22の色変化修正方法を質問。選ばれている理由の言及なし。)
- レス370: 「角オナチャレンジでLoRAと生成する動画時間の関係整理、環境はEasyWan22でLoRAはGeneralNsfw/Wan2.2Orgasm/better anime sex face」
(EasyWan22とWan2.2 LoRAを使った動画時間調整。選ばれている理由: NSFW用途のLoRAでアニメ風エロ動画の制御が可能。)
- レス371: 「2.2の高速lora抜きやとstepsはどんぐらいがええんやろか comfy公式のワークフローやと20stepsになっとるが」
(Wan2.2の高速LoRA抜きでのsteps最適化。選ばれている理由: 公式ワークフローとの互換性で高速生成。)
- レス378: 「easywan22のrefinerの仕様では、動画を入力とするときに一緒に初期画像も与えてやる必要がある。」
(EasyWan22のRefiner仕様説明。選ばれている理由: 動画入力時の画風変換(例: アニメから実写)に有効。)
- レス379: (上記NAIと重複。NAI画像からの変換を議論。)
- レス380: 「WAN22の動画生成しながらシコりすぎてチンコの皮ちょっと裂けてしまいました」
(WAN22の動画生成をエロ用途で多用。選ばれている理由: エロ動画生成のクオリティが高く、没入感がある(ユーモア混じり)。)
- レス384: 「wanで動かしてそういう構図にしてi2iとか今ならやれそうやな」
(Wanで構図調整とi2iを提案。選ばれている理由: 動画生成後のi2iで柔軟な調整可能。)
- レス387: (上記NAIと重複。)
- レス393: 「はぁはぁようやくwan2.2のぶっかけが学習できてきたぞ musubi-tunerでの学習が全然ダメだったのでdiffusion-pipeで学習させたわ」
(Wan2.2のLoRA学習成功報告。選ばれている理由: NSFW(ぶっかけ)学習の柔軟性が高いが、ツール選択が必要。)
- レス402: 「»394 high noise model→ノイズが高い状態で学習&生成… low noise model→ノイズが低い状態で学習&生成…」
(Wan LoRAのhigh/low noise説明。選ばれている理由: 動き制御(例: おっぱいの揺れ)と詳細描写のバランスが取れる。)
- レス407: 「もうSDXLで十分じゃろって思ってたけど、WAN触ったら自然言語で「誰が何をしている」ができるのはそりゃ便利だよなってなったわ」
(WANの自然言語プロンプトを称賛。選ばれている理由: 自然言語で複雑なシナリオ生成が可能で、SDXLより便利。)
- レス431: 「qwenは芋姉ちゃんしか出てこない wanのt2iのほうがすこ」
(WanのT2Iを好む。選ばれている理由: 出力の好み(芋姉ちゃん以外が出やすい)。)
- レス435: (下記FramePackと重複。EasyWan22で逆再生テスト。選ばれている理由: プロンプトのみで逆再生が可能。)
FramePack
- レス234: 「i2iで差分生成はframepackがやってるからそのうち近いの出るんじゃない」
(FramePackのi2i差分生成を言及し、類似機能の登場を期待。選ばれている理由: i2i差分生成の先駆けとして機能的。)
- レス435: 「そういやFramepackで逆再生あったなあと思ったので、EasyWan22の標準環境でプロンプトのみで逆再生ができるか動作するかテスト」
(FramePackの逆再生機能を思い出し、EasyWan22でテスト。選ばれている理由: 逆再生機能が便利で、プロンプトベースのテストに適する。)
—以下は、提供されたなんJ(5ch)のログから、生成AIの「モデル」に関する話題を抽出したものです。抽出の基準は以下の通りです:
- 生成AIのモデル(またはそれに準じる技術・ツール)に関する言及を対象とし、除外モデル一覧(NovelAI v4/v3 (NAI), Pony, illustrious 0.1/1.0/1.1/2/3/3.5vpred (イラストリアス, リアス,ill), Noobai, FLUX, HiDream, Wan2.1 (wan), FramePack)を除外。
- 除外リストにないモデル(例: Wan2.2, Qwenなど)は抽出対象。ただし、Wan2.1と明示的に関連づけられたものは除外。
- 特にそのモデルが選ばれている理由(性能、使いやすさ、特定の機能など)が言及されている場合、それを強調して抽出。
- ログの文脈を崩さないよう、関連するレス番号と内容を引用し、簡潔にまとめ。重複や非モデル関連の雑談は省略。
- 抽出対象が少ないため、モデルごとにグループ化して整理。
抽出されたモデル関連の話題
1. Qwen / Qwen Image
- 関連レス: 256, 383, 410, 420, 431
- 抽出内容と理由:
- 256: 「Qwenはアニメ絵は得意なように見えるけどfluxにあった極端な線の正確さみたいなのはあんま感じんな chromaが一応fluxなんやけど去勢版やしどこまでやれんのかは気になるンゴね」
- Qwenがアニメ絵生成で得意と評価されているが、線の正確さでFLUXに劣ると指摘。Chroma(FLUXの派生?)の去勢版(制限版)についても言及し、潜在能力を気にするニュアンス。
- 383: 「聞きたいんだけどIllustrious/PONY系で狙ったポージングとか表情ってプロンプトだけじゃ出ないよね? … 試しに新しく来たQwen Imageで試したらバッチリいけたけど、絵柄がジブリなんだよねw」
- Qwen Imageが選ばれている理由: 自然言語プロンプトで複雑なポージングや表情(例: おじさんと娘の具体的なシーン)を正確に生成できる点。ただし、絵柄がジブリ風で制限あり。
- 410: 「»407 Qwen Image試したが自然言語いけるで」
- Qwen Imageが自然言語プロンプトに対応し、使いやすいと推奨。
- 420: 「Qwen Imageはこんなんばっかだから諦めてる」
- Qwen Imageの生成結果が一貫性に欠け、諦めムード(ネガティブな理由)。
- 431: 「qwenは芋姉ちゃんしか出てこない wanのt2iのほうがすこ」
- Qwenの生成が「芋姉ちゃん」風に偏るため、WanのT2I(Text-to-Image)が好まれる(Qwenの弱点として抽出)。
- 全体の傾向: Qwen / Qwen Imageはアニメ絵や自然言語プロンプトの扱いが得意だが、線の正確さや生成の偏り(ジブリ風や芋姉ちゃん風)が課題。選ばれる理由は、ポージング/表情の精度が高い点。
2. Veo3
- 関連レス: 271
- 抽出内容と理由:
- 271: 「wanのヌルヌルが気になるんはやっぱりどこか不自然だからだと思うわ veo3みたいなのでアニメ絵動かすと30fpsくらいのはずやけど別に気にならんもん」
- Veo3が選ばれている理由: アニメ絵を30fpsで自然に動かせる点。Wanの「ヌルヌル」感(不自然な動き)を避けられるため、好評価。
3. Lightx2v
- 関連レス: 348, 362
- 抽出内容と理由:
- 348: 「戯れにlightx2vを捨てた結果・・・ ggufのQ8使ってvram12GBで約7分やったわ これが7分待つだけで出てくるならワイは余裕で待てる」
- Lightx2vを「捨てた」結果、GGUFのQ8(量子化版?)でVRAM12GB環境で7分生成が可能。選ばれている理由: 待ち時間が許容範囲で、生成が安定する点(Lightx2vの代替として)。
- 362: 「»348 lightx2v使っても余裕で7分以上かかる俺登場 2060の弱グラボはやっぱつれぇわ・・・」
- Lightx2vが選ばれている理由: 低スペックGPU(RTX2060)でも生成可能だが、7分以上かかるため負担大。VRAMやメモリ不足の文脈で議論。
4. FLF (おそらくFlow Latent Fusionや類似のモデル/ワークフロー)
- 関連レス: 284, 376, 377
- 抽出内容と理由:
- 284: 「FLFサンプル見てるけど既存のマイwan2.2環境とつなげるのムズそうやわ・・・」
- FLFが選ばれている理由: Wan2.2環境との連携を試みるが、難易度が高い(潜在的な互換性や拡張性を期待)。
- 376: 「安定しているA14B環境をFLFに対応しようとしてるんやがもう少しというところで停滞中 … リリース直後にハマってrgthree出る前にやめたんやが、便利なノードも色々増えてやっぱcomfyUIは面白いな」
- FLFが選ばれている理由: A14B環境との対応で、属性の可変制御(モヤモヤ映像のクリーンアップ)が楽しい。ComfyUIのノード拡張との相性が良い。
- 377: 「ワイ昨日FLF公式ワークフローでGGUF対応にしてLoRA対応にしてligtx2v入れたらええ感じやね Step6 cgf 1にしとる」
- FLFが選ばれている理由: 公式ワークフローでGGUF/LoRA/Lightx2vを組み合わせて「ええ感じ」に生成。StepsやCFGの調整で安定。
5. その他のモデル/ツール(学習関連)
- 関連レス: 393
- 抽出内容と理由:
- 393: 「はぁはぁようやくwan2.2のぶっかけが学習できてきたぞ musubi-tunerでの学習が全然ダメだったのでdiffusion-pipeで学習させたわ(RTXPRO6000だとデフォ設定じゃunknown errorが出るが、issuesにこれ設定したら動いたわってニキが居て助かった)」
- Musubi-tunerとDiffusion-pipeが選ばれている理由: Wan2.2のLoRA学習でMusubi-tunerが失敗したが、Diffusion-pipeで成功(RTX PRO6000環境のエラー回避)。学習効率の良さで選択。
- 全体の傾向: これらはLoRA学習ツールだが、モデル生成の文脈で言及。選ばれる理由はエラー回避や学習成功率の高さ。
追加の考察
- ログ全体でWan2.2(EasyWan22)が頻出するが、除外リストのWan2.1に該当しないため抽出対象外とした(ただし、QwenやFLFとの比較で間接的に触れられる場合のみ関連づけ)。
- 抽出件数は少ないが、ログの多くがWan2.2や除外モデル中心のため。理由の言及は主に「自然言語対応」「生成速度」「互換性」「動きの自然さ」などに集中。
- 不明点があれば、どのモデルを追加で抽出するか уточしてください!