qwen-image-edit について
自然言語の指示で Qwen Image Edit を使って画像を編集する ComfyUI 向けスキルガイドです。モデルやノードの選択、潜在表現と解像度の扱い、サンプラー設定、ワークフロー例を説明します。
主な機能
- 01モデルと条件付けノードのガイド
- 02潜在表現と元画像の整合
- 03サンプラープリセットと Lightning LoRA
- 04画像編集プロンプトのパターン
- 05ComfyUI ワークフロー例
活用シーン
- 01自然言語による画像編集グラフの構築
- 02高速な Lightning サンプリング設定の選択
- 03参照画像と出力潜在表現の不一致の調査
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ artokun/ comfyui-mcp --skill qwen-image-editインストール後、Claude Code で/qwen-image-editを入力して読み込まれたか確認します。
詳細
Qwen Image Edit ワークフロー
概要
Qwen Image Edit は、自然言語の指示に基づいて画像を編集するために、ビジョン言語モデル(Qwen2.5-VL)を使用します。モデルは CLIP コンディショニングを通じて元画像を「認識」し、編集後の画像を生成します。
モデル
必須コンポーネント
| コンポーネント | ノード | モデル名 | 備考 |
|---|---|---|---|
| UNET | UNETLoader | qwen_image_edit_2511_bf16.safetensors | 公式の 2511 編集モデル(bf16) |
| CLIP | CLIPLoader (type=qwen_image) | qwen_2.5_vl_7b_fp8_scaled.safetensors | すべての Qwen モデルで共用 |
| VAE | VAELoader | qwen_image_vae.safetensors | Qwen 専用 VAE |
代替 UNET モデル
| モデル | パス | 用途 |
|---|---|---|
qwenImageEditRemix_v10 | qwenImageEditRemix_v10.safetensors | コミュニティによるリミックス、汎用的な編集 |
qwenUltimateRealism_v11 | Qwen/imageized/qwenUltimateRealism_v11.safetensors | 商品写真、超リアルな描写 |
copaxTimeless | Qwen/realistic/copaxTimeless_qwenUltraRealistic.safetensors | 超リアルなポートレート |
qwnImageEdit_v16Bf16 | Qwen/abliterated/qwnImageEdit_v16Bf16.safetensors | Abliterated(検閲なし) |
コンディショニングノード
TextEncodeQwenImageEditPlusAdvance_lrzjason(推奨)
qweneditutils カスタムノードパックに含まれています。以下の理由から、Advanced 版が推奨されます。
- LATENT を直接出力するため、別途 EmptyLatentImage を用意する必要がありません
- 細かく制御できる、VL リサイズとリサイズなしの画像スロットが分かれています
- 出力解像度をtarget_sizeで制御できます
- pad_info 出力を備えた、pad/center/disabled crop方式が含まれています
Required Inputs:
- clip: CLIP
- prompt: STRING — natural language edit instruction
Optional Inputs:
- vae: VAE — needed for image encoding and latent output
- vl_resize_image1-3: IMAGE — images that get VL-resized (downscaled for vision encoder)
- not_resize_image1-3: IMAGE — images kept at full resolution
- target_size: [1024, 1344, 1536, 2048, 768, 512] (default 1024)
- target_vl_size: [392, 384] (default 384)
- upscale_method: [lanczos, bicubic, area]
- crop_method: [pad, center, disabled]
- instruction: STRING — system instruction template (has sensible default)
Outputs (10):
[0] conditioning_with_full_ref: CONDITIONING — use as positive conditioning
[1] latent: LATENT — auto-scaled latent, feed directly to KSampler
[2] target_image1: IMAGE — processed target-size image
[3] target_image2: IMAGE
[4] target_image3: IMAGE
[5] vl_resized_image1: IMAGE — VL-resized version
[6] vl_resized_image2: IMAGE
[7] vl_resized_image3: IMAGE
[8] conditioning_with_first_ref: CONDITIONING — conditioning with only first ref
[9] pad_info: ANY — padding info for later unpadding
主な利点:出力 [1](latent)により、別途 EmptyLatentImage または VAEEncode ノードを用意する必要がありません。Advanced ノードは、適切な解像度で潜在表現を内部的に生成します。
その他のコンディショニングのバリエーション
- TextEncodeQwenImageEditPlus(Phr00t v2、組み込み)は、よりシンプルです。画像入力は 4 つで、CONDITIONING のみを出力します。別途 EmptyLatentImage が必要です。手早く編集する場合に適しています。
- TextEncodeQwenImageEditPlus_lrzjason:画像入力は 5 つで、リサイズのオン/オフを切り替えられますが、Advance より制御性は低くなります
- TextEncodeQwenImageEditPlusPro_lrzjason:
vl_resize_indexs文字列で画像ごとの VL リサイズを選択でき、main_image_indexを制御できます
Lightning LoRA(高速生成)
4 ステップ Lightning(2511 Edit)
{
"class_type": "LoraLoaderModelOnly",
"inputs": {
"model": ["<unet_node>", 0],
"lora_name": "Qwen-Image-Edit-2511-Lightning-4steps-V1.0-bf16.safetensors",
"strength_model": 1.0
}
}
設定:steps=4、cfg=1.0、sampler=euler、scheduler=simple、denoise=1.0
4 ステップ Lightning(一般的な Qwen)
編集以外のモデル(txt2img、2512)向け:
Qwen-Image-Lightning-4steps-V1.0.safetensors(strength 1.0)
8 ステップ Lightning
Qwen-Image-Lightning-8steps-V1.0.safetensors。4 ステップより詳細に描写されます
サンプラー設定
| プリセット | ステップ数 | CFG | サンプラー | スケジューラー | デノイズ | LoRA |
|---|---|---|---|---|---|---|
| Lightning 4-step(2511 edit) | 4 | 1.0 | euler | simple | 1.0 | 2511-Lightning-4steps |
| Lightning 8-step | 8 | 1.0 | euler | simple | 1.0 | Lightning-8steps |
| 標準編集 | 40 | 4.0 | euler | simple | 0.75 | なし |
| 高品質編集 | 50 | 4.0 | euler | simple | 0.5-0.8 | なし |
デノイズ値が1.0未満の行では、
VAEEncodeの潜在表現が必須です。 サンプリングスケジュールを短縮するほど低いデノイズ値(0.5-0.8は確実に該当します)では、入力された潜在表現の一部が保持されるため、その潜在表現は元画像のものでなければなりません。latent_imageを、元画像をVAEEncodeしたもの(またはTextEncodeQwenImageEditPlusAdvance_lrzjasonの出力 [1] のような、元画像由来の潜在表現を出力するノード)に接続してください。これらの行をEmptyLatentImageと組み合わせてもエラーなく実行されますが、平坦でほぼ均一な場が返されます。空の潜在表現には保持すべき元画像の内容がないためです。参照画像をTextEncodeQwenImageEditPlus経由で入力しても解決にはなりません。その画像は CONDITIONING に渡され、デノイズを制御しますが、サンプラーの初期状態のシードにはなりません。
編集時のデノイズ:デノイズ値が低いほど元画像に近くなります。ただし、潜在表現が元画像であることが条件です。VAEEncode の潜在表現を使う標準的な編集では、0.5-0.8の範囲にしてください。Lightning では1.0を使用します(モデルが内部で忠実度を処理します)。
解像度
この表は Qwen-Image のテキストから画像への生成用です。編集グラフの出力サイズをこの表から選ばないでください。 編集グラフの画像サイズは、指定するのではなく、元画像によって決まります。詳しくは下記の「編集グラフでの解像度」を参照してください。編集にここから1104x1472を選ぶのは #2681 でした。
Qwen-Image は、ネイティブで約1.6メガピクセルで動作します。
| アスペクト比 | 解像度 | 用途 |
|---|---|---|
| 正方形 | 1328x1328 | 一般用途 |
| 縦長 3:4 | 1104x1472 | ポートレート |
| 縦長 9:16 | 928x1664 | スマートフォン向け |
| 横長 4:3 | 1472x1104 | 風景シーン |
| 横長 16:9 | 1664x928 | ワイドスクリーン |
| 動画向け | 832x480 | WAN 2.2 FLF パイプライン用 |
動画パイプラインの場合:WAN 2.2 のデフォルト解像度に合わせて832x480を使用してください。
編集グラフでの解像度
TextEncodeQwenImageEdit と TextEncodeQwenImageEditPlus はサイズを受け取りません。すべての参照画像をハードコードされた int(1024 * 1024) px(約1.05 MP、元画像と同じアスペクト比)にスケーリングし、VAEでエンコードして、参照潜在表現としてモデルに渡します(comfy_extras/nodes_qwen.py)。
次にモデルは、参照トークンと生成中のトークンを同じ中央揃えの座標グリッド上に配置します(comfy/ldm/qwen_image/model.py の process_img)。そのため、参照位置 (i, j) と出力位置 (i, j) が同じ場所を意味するのは、2つのグリッドが同じサイズの場合だけです。公式テンプレートで1枚の画像を FluxKontextImageScale に通し、そのスケーリング済み画像を VAEEncode でエンコードしてサンプラーに渡すのは、これが唯一の理由です。両方の分岐で同じピクセル、同じ約1 MPのスケール、同じアスペクト比を使うことになります。PREFERRED_KONTEXT_RESOLUTIONS のすべての項目が約1.05 MPなのも、同じ理由です。
これはエンコーダーの8単位への丸め誤差の範囲内での一致であり、厳密な一致ではありません。この違いは正確に知っておく価値があります。FluxKontextImageScale は推奨されるペアにスナップし、エンコーダーはそれを独自の1,048,576 pxの予算に合わせて再正規化します。18個の推奨ペアのうち12個では、どちらも同じ潜在グリッドになります。残りの6個(688x1504、800x1328、832x1248、およびそれぞれの横向き)は、参照側が潜在グリッドで1行または1列ずれます。800x1328では、サンプラーのグリッドは100x166、参照側は99x165です。ComfyUIに同梱されている2511テンプレートでもまさにこの状態になるため、実際にはパッチ未満のずれで問題ないようです。このページで扱う失敗はスケールの問題であり、丸めの問題ではありません。1104x1472の空の潜在表現は、線形寸法で1.24倍も離れており、1行のずれではありません。
つまり、編集グラフでは解像度を選ぶのではなく、引き継ぎます。
- 正しい例:
LoadImage->FluxKontextImageScale-> (TextEncodeQwenImageEditPlusとVAEEncode)-> KSampler のlatent_image。 - 誤った例: 上の表にあるサイズの
EmptyLatentImage。その寸法は固定値ですが、参照画像の寸法はグラフの実行時に元画像から計算されます。1.05 MPの参照画像に対して1104x1472(1.63 MP)を指定すると、グリッドは線形寸法で1.24倍離れています。モデルは両者の間でディテールをコピーできず、代わりに被写体を再合成します。その結果、素材はプラスチックやCGIのような見た目になり、印刷されたディテールは汎用的な形状に戻ります(#2681)。エラーは発生しませんが、画像は依頼した編集結果になりません。
create_workflow (action:"validate") は、この組み合わせに edit_reference_empty_latent のフラグを付けるようになりました。
プロンプトのパターン
編集指示(自然言語)
"Change the black cat into a cute girl with a black bodysuit and jeans"
"Make the sky a dramatic sunset with orange and purple clouds"
"Add a red sports car parked in front of the house"
"Remove the person on the left and fill with the background"
マルチアングルLoRA(qwen-image-edit-2511-multiple-angles-lora)
構造化された角度・距離プロンプトで <sks> トークンを使用します。
<sks> front view eye-level shot close-up
<sks> front-right quarter view low-angle shot medium shot
<sks> back view elevated shot wide shot
テンプレート: <sks> {direction} view {angle} shot {distance}
方向:正面、右斜め前、右側面、右斜め後ろ、背面、左斜め後ろ、左側面、左斜め前 角度:ローアングル、目線の高さ、やや上から、ハイアングル 距離:クローズアップ、ミディアムショット、ワイドショット
ネガティブコンディショニング
Qwen editでネガティブコンディショニングを行う場合は、必ず ConditioningZeroOut を使用してください。
{
"class_type": "ConditioningZeroOut",
"inputs": { "conditioning": ["<positive_cond_node>", 0] }
}
完全なワークフロー:Lightning Edit(高度なノード)
TextEncodeQwenImageEditPlusAdvance_lrzjason を使用します。このノードは潜在表現を直接出力するため、EmptyLatentImage は不要です。
{
"1": { "class_type": "UNETLoader", "inputs": { "unet_name": "qwen_image_edit_2511_bf16.safetensors", "weight_dtype": "default" }},
"2": { "class_type": "LoraLoaderModelOnly", "inputs": { "model": ["1", 0], "lora_name": "Qwen-Image-Edit-2511-Lightning-4steps-V1.0-bf16.safetensors", "strength_model": 1 }},
"3": { "class_type": "CLIPLoader", "inputs": { "clip_name": "qwen_2.5_vl_7b_fp8_scaled.safetensors", "type": "qwen_image" }},
"4": { "class_type": "VAELoader", "inputs": { "vae_name": "qwen_image_vae.safetensors" }},
"5": { "class_type": "LoadImage", "inputs": { "image": "<source_image.png>" }},
"6": { "class_type": "TextEncodeQwenImageEditPlusAdvance_lrzjason", "inputs": {
"clip": ["3", 0], "prompt": "<edit instruction>", "vae": ["4", 0],
"vl_resize_image1": ["5", 0],
"target_size": 1024, "target_vl_size": 384,
"upscale_method": "lanczos", "crop_method": "pad"
}},
"7": { "class_type": "ConditioningZeroOut", "inputs": { "conditioning": ["6", 0] }},
"8": { "class_type": "KSampler", "inputs": {
"model": ["2", 0],
"positive": ["6", 0],
"negative": ["7", 0],
"latent_image": ["6", 1],
"seed": 42, "steps": 4, "cfg": 1, "sampler_name": "euler", "scheduler": "simple", "denoise": 1
}},
"9": { "class_type": "VAEDecode", "inputs": { "samples": ["8", 0], "vae": ["4", 0] }},
"10": { "class_type": "SaveImage", "inputs": { "images": ["9", 0], "filename_prefix": "qwen_edit" }}
}
主な接続:
"latent_image": ["6", 1]:KSamplerは潜在表現をAdvancedノードの出力[1]から直接受け取ります"positive": ["6", 0]:出力[0]のconditioning_with_full_ref"vl_resize_image1": ["5", 0]:ソース画像をVLリサイズ用スロットに入力します(ビジョンエンコーダー用に縮小)
よりシンプルな代替方法(Phr00t v2)
qweneditutils のカスタムノードが利用できない場合は、組み込みの TextEncodeQwenImageEditPlus と、別の EmptyLatentImage を使用します。
{
"6": { "class_type": "TextEncodeQwenImageEditPlus", "inputs": {
"clip": ["3", 0], "prompt": "<edit instruction>", "vae": ["4", 0], "image1": ["5", 0]
}},
"8": { "class_type": "EmptyLatentImage", "inputs": { "width": 1024, "height": 1024, "batch_size": 1 }}
}
ノード 6 を置き換え、ノード 8 を追加します。KSampler の latent_image は ["6", 1] ではなく ["8", 0] に接続します。
その EmptyLatentImage をサンプラーに接続したままにしないでください。 上に示したのは、Plus エンコーダー自体のシグネチャのために必要になるものだからです。また、denoise 1.0 の上下で、それぞれ異なる問題が発生します。
- 1.0 未満では、常に平坦でほぼ均一な画像が生成されます。エンコーダーは CONDITIONING のみを出力するため、潜在画像は実際に空です。また、入力された潜在画像を保持するための切り詰められたシグマスケジュールが存在しますが、ここには保持すべきものがありません(#2678)。
- 1.0 では、元画像ではない、もっともらしい画像が生成されます。ただし、幅と高さがエンコーダーが導き出した形状(元画像と同じアスペクト比で約 1.05 MP)と一致する場合は除きます。完全な正方形の元画像に対して 1024x1024 の空の潜在画像を使う場合は一致するため問題ありません。同じ元画像に対して 1104x1472 を使うと一致しません。モデルは参照画像と出力を同じグリッド上で位置合わせするため、グリッドが大きく離れているとコピーできず、代わりに再生成します(#2681)。「編集グラフの解像度」を参照してください。
2 つ目のケースが落とし穴です。確認していない元画像に左右されるうえ、エラーが表面化しません。VAEEncode を使えば、この偶然の一致はなくなります。エンコーダーが認識したものと同じピクセルから導出されるため、サイズが誤ることはありません。
エンコーダーに渡した画像と同じ画像を VAEEncode で潜在画像に変換し、事前に一度だけ拡大して、両方の分岐に同じスケールの同じピクセルが渡されるようにします。
{
"5b": { "class_type": "FluxKontextImageScale", "inputs": { "image": ["5", 0] }},
"6": { "class_type": "TextEncodeQwenImageEditPlus", "inputs": {
"clip": ["3", 0], "prompt": "<edit instruction>", "vae": ["4", 0], "image1": ["5b", 0]
}},
"8": { "class_type": "VAEEncode", "inputs": { "pixels": ["5b", 0], "vae": ["4", 0] }}
}
KSampler の latent_image は ["8", 0] に接続します。これで、どの denoise 値にも意味があります。全面的に編集する場合は 1.0、元画像に近づける場合は 1.0 未満にします。
基本バリエーション(ComfyUI 公式の例)
公式の「Qwen 2511 Edit Simple」では、モデルのパッチ適用と画像のスケーリングに新しい組み込みノードを使用しています。
公式パイプラインの追加ノード:
ModelSamplingAuraFlow(shift=3.1):UNET に適用されるフローマッチングのシフトです。ModelSamplingSD3の代わりに使用します。CFGNorm(strength=1):CFG ガイダンスを正規化し、生成をより安定させます。ModelSamplingAuraFlowの後に適用します。FluxKontextImageScale:入力画像を Qwen に適した解像度に自動スケーリングします。サイズを手動で指定する必要はありません。FluxKontextMultiReferenceLatentMethod(method=index_timestep_zero):ポジティブおよびネガティブの両方のコンディショニングに適用します。複数参照潜在画像のインデックス付けを処理します。VAEEncode:スケーリングした画像を潜在画像にエンコードします(EmptyLatentImageの代わりに使用)。
公式パイプラインの流れ:
UNETLoader → [LoraLoaderModelOnly] → ModelSamplingAuraFlow (shift=3.1) → CFGNorm (strength=1) → MODEL
CLIPLoader (qwen_image) → CLIP
VAELoader → VAE
LoadImage → FluxKontextImageScale → scaled_image
├─ TextEncodeQwenImageEditPlus (positive) → FluxKontextMultiReferenceLatentMethod → positive CONDITIONING
├─ TextEncodeQwenImageEditPlus (negative, empty) → FluxKontextMultiReferenceLatentMethod → negative CONDITIONING
└─ VAEEncode → LATENT
KSampler → VAEDecode → SaveImage
公式サンプラーの設定:
| バリエーション | ステップ数 | CFG | サンプラー | スケジューラー | Denoise | LoRA |
|---|---|---|---|---|---|---|
| 標準 | 40 | 4.0 | euler | simple | 1.0 | なし |
| Lightning | 4 | 1.0 | euler | simple | 1.0 | 2511-Lightning-4steps |
注:Comfy の公式モデルファイルを直接使用する場合、FluxKontextMultiReferenceLatentMethod と FluxKontextImageScale ノードは不要な場合がありますが、コミュニティによって再パッケージされたモデルでは必要になることがあります。
XY Plot の手法(Widgets.json より)
複数の編集バリエーションをまとめてテストするには、Easy Nodes の XY Plot システムを使用します。
- Text Multiline ノードでパラメーターのリスト(例:方向、角度)を定義します
- Split String でリストをインデックス付きの選択肢に分割します
- easy textIndexSwitch で選択肢を一度に 1 つずつ選びます
- easy promptReplace で、ベースプロンプト内の
{X}、{Y}、{Z}プレースホルダーを置き換えます - easy XYPlotAdvanced と easy XYInputs: PromptSR でスイープを実行します
- easy pipeIn で model/clip/vae/latent をパイプラインにまとめます
これにより、すべての組み合わせを示すグリッド画像が生成され、対象に適した角度、距離、スタイルを見つけるのに役立ちます。
VRAM に関する考慮事項
- Qwen 2511 edit bf16:約10GB の VRAM
- CLIP(fp8):約7GB の VRAM
- VAE:約200MB
- 合計:約17~18GB。24GB の GPU で余裕をもって動作します
- 別のモデルファミリーから切り替える場合は、ロード前に必ず
clear_vramを実行してください
ヒント
- ワークフローを作成する前に、
upload_image (action:"image")でソース画像をアップロードしてください - 出力解像度は次のパイプラインのステップに合わせてください(例:WAN FLF では 832x480)。ただし、これは生成グラフの場合に限ります。編集グラフではソースのサイズが使われます。希望するサイズでサンプリングするのではなく、あとから RESULT のサイズを変更してください
- Lightning LoRA + denoise 1.0 はうまく機能します。モデルはコンディショニングを通じて構造を保持します
- 編集グラフの
latent_imageは、EmptyLatentImageではなく、ソースをVAEEncodeしたものから取得してください。denoise が 1.0 未満の場合、空の latent は平坦でほぼ均一なフィールドにデコードされます(#2678)。denoise が 1.0 の場合に正しくなるのは、そのサイズがエンコーダーによってソースから導出されたジオメトリと偶然一致する場合だけです。これはまさにVAEEncodeを使えば避けられる偶然です(#2681)。どちらの問題もエラーにはなりません。create_workflow (action:"validate")は、どちらの組み合わせにもフラグを立てます(partial_denoise_empty_latent、edit_reference_empty_latent) - lrzjason Pro variant は、どの画像を VL リサイズするかを細かく制御する必要がある複数画像の合成に最適です
- 保存済みの Qwen 編集ワークフローを変更または実行する前に、
get_workflow (action:"analyze")を使って内容を把握してください。生の JSON ではなく、構造化された概要が返されます。enqueue_workflowまたはcreate_workflow (action:"modify")で実際の JSON が必要な場合に限り、get_workflowを使ってください
情報源
- 公式: 見つかりませんでした。
- 実証情報:
packs/内の動作するグラフから得られたサンプラー値、配線、プロンプトに関するメモ、および確認済みの生成結果です。ベンダーによるプロンプトガイドではありません。