Qwen-Image-Edit Inferior Results Compared to ComfyUI

[enesmsahin]

Describe the bug

I am trying to do multi-image editing with Qwen-Image-Edit (It is a simplified version of this). The ComfyUI workflow and diffusers script are shared below for reproducibility. I am using the same (unquantized) models and the same parameters.

The results I get with diffusers are noticeably inferior compared to ComfyUI especially in terms of preservation of the details.

Here is the input image and prompt:

Prompt: The woman is displaying a plush toy product in her hand, while preserving her exact facial features, expression, clothing, and pose. Maintain the same background, natural lighting, and overall photographic composition and style.

Here are the outputs from Comfy:

Here are the outputs from Diffusers:

It changes both the woman and the toy a lot compared to Comfy implementation.

Reproduction

Diffusers reproduction script

import torch
from PIL import Image
from diffusers import QwenImageEditPipeline

pipeline = QwenImageEditPipeline.from_pretrained("Qwen/Qwen-Image-Edit", torch_dtype=torch.bfloat16, device_map="cuda")
pipeline.set_progress_bar_config(disable=None)

input_image = Image.open("qwen_image_edit_input.png")

seed = 43
prompt = "The woman is displaying a plush toy product in her hand, while preserving her exact facial features, expression, clothing, and pose. Maintain the same background, natural lighting, and overall photographic composition and style."
inputs = {
    "image": input_image,
    "prompt": prompt,
    "generator": torch.manual_seed(seed),
    "true_cfg_scale": 4.5,
    "negative_prompt": " ",
    "num_inference_steps": 50,
    "height": 1024,
    "width": 1024,
}

with torch.inference_mode():
    output = pipeline(**inputs)
    output_image = output.images[0]
    output_image.save(f"diffusers_qwen_image_edit_out_{seed}.png")

Comfy Workflow file and image:
qwen_image_edit-multi_image-v1.0-compare.json

Logs

System Info

• 🤗 Diffusers version: 0.35.1
• Platform: Linux-5.15.0-122-generic-x86_64-with-glibc2.35
• Running on Google Colab?: No
• Python version: 3.10.18
• PyTorch version (GPU?): 2.5.1+cu124 (True)
• Flax version (CPU?/GPU?/TPU?): not installed (NA)
• Jax version: not installed
• JaxLib version: not installed
• Huggingface_hub version: 0.34.4
• Transformers version: 4.55.2
• Accelerate version: 1.2.1
• PEFT version: 0.17.0
• Bitsandbytes version: not installed
• Safetensors version: 0.4.5
• xFormers version: not installed
• Accelerator: NVIDIA A100-SXM4-80GB, 81920 MiB
• Using GPU in script?: Yes
• Using distributed or parallel set-up in script?: No

Who can help?

@asomoza @yiyixuxu

[asomoza]

thanks for reporting this. I'll test this and see what I can find.

gentle ping to @naykun in case you have some insights on why this is happening.

[linoytsaban]

It seems to be related to the resolution of the outputs -
when I'm not passing height=1024, width=1024 output quality seems to match comfy, and when I do pass height=1024, width=1024 preservation is hurt as @enesmsahin reports

import torch
from PIL import Image
from diffusers import QwenImageEditPipeline

pipe = QwenImageEditPipeline.from_pretrained("Qwen/Qwen-Image-Edit", torch_dtype=torch.bfloat16)
pipe.to("cuda")

# Load input image
image = Image.open("480905449-1cf175d5-572a-4511-bdb8-0ea360caf07a.png")

seed = 43
prompt = "The woman is displaying a plush toy product in her hand, while preserving her exact facial features, expression, clothing, and pose. Maintain the same background, natural lighting, and overall photographic composition and style."

pipe(image,
     prompt,
     true_cfg_scale=4.5,
     num_inference_steps=50,
     generator=torch.manual_seed(seed),).images[0]

# Load input image
image = Image.open("480905449-1cf175d5-572a-4511-bdb8-0ea360caf07a.png")

seed = 43
prompt = "The woman is displaying a plush toy product in her hand, while preserving her exact facial features, expression, clothing, and pose. Maintain the same background, natural lighting, and overall photographic composition and style."

pipe(image,
     prompt,
     true_cfg_scale=4.5,
     num_inference_steps=50,
     height=1024,
     width=1024,
     generator=torch.manual_seed(seed),).images[0]

[enesmsahin]

I am suspecting from positional embeddings. The implementation of them in diffusers and Comfy looks different. But I didn't do an in-depth debugging.

[yiyixuxu]

cc @naykun
let us know if you have any insights on this!

[Saquib764]

Implementation of positional embedding calculation in the Qwen Image Edit pipeline is quite challenging to debug and validate for correctness. Unlike the Flux Kontext pipeline, it does not use token IDs; instead, embeddings are computed directly within the transformer block. This makes it difficult to trace and verify which patches are assigned which IDs.

It would be helpful to align this implementation with Flux Kontext, where the process is more explicit and intuitive. Synchronizing the approaches would make debugging easier and also improve the overall transparency of the embedding logic.

A lot of thing is happening here

diffusers/src/diffusers/models/transformers/transformer_qwenimage.py

Line 238 in a840c39

def _compute_video_freqs(self, frame, height, width, idx=0):

, but they aren't quite intuitive.

[naykun]

Hi everyone, thank you for sharing your findings and suggestions!

Currently, we do not recommend using custom height and width values as the output shape. Doing so can introduce instabilities that are sensitive to random seeds and sampling strategies. From our understanding, this is likely the main reason for the discrepancies observed between ComfyUI and Diffusers outputs.

To dive deeper: for optimal results, the conditioning inputs—especially those passed through the VAE—should match the final output resolution as closely as possible. As demonstrated by @linoytsaban, using the pipeline’s automatic size computation tends to produce high-quality and consistent results.

If you'd like to experiment

If you need to enforce a specific output resolution, you can modify the following lines in the pipeline to use your desired height and width instead of the calculated_height and calculated_width:

• diffusers/src/diffusers/pipelines/qwenimage/pipeline_qwenimage_edit.py

  Line 667 in a840c39

  image = self.image_processor.resize(image, calculated_height, calculated_width)

• diffusers/src/diffusers/pipelines/qwenimage/pipeline_qwenimage_edit.py

  Line 669 in a840c39

  image = self.image_processor.preprocess(image, calculated_height, calculated_width)

• diffusers/src/diffusers/pipelines/qwenimage/pipeline_qwenimage_edit.py

  Line 712 in a840c39

  (1, calculated_height // self.vae_scale_factor // 2, calculated_width // self.vae_scale_factor // 2),

This will force the model to rescale the input image to your target dimensions. In local testing, this improves consistency across runs—but may cause visual stretching or distortion of content, as seen below:

---

We’re actively working on improving the model’s robustness in scenarios where there’s a large mismatch between input and output aspect ratios or resolutions. However, achieving perfect results may take some time.

In the meantime, we’re open to ideas and community-driven solutions that help make workflows more flexible, efficient, and user-friendly.

Thanks @asomoza @yiyixuxu again for bringing this issue to my attention.

[danbochman]

Hi,

Perhaps this is the issue? ↓

According to the Qwen-Image paper, in the Edit use-case you're supposed to give different positional encodings to the noisy latents and the original image's latents.

However, in the actual implementation it seems like you're disregarding the frame idx and embedding both images with the same rotary embeddings:

This could also explain why the results work much better when the shapes of the original image and the output are the same, because then the rotary embeddings match

[Saquib764]

No, that seems correct. In the qwen image edit pipeline, video_fhw has this format List(List(Tuple))) . video_fhw = video_fhw[0] simply flattens it to List(Tuple).
And later in the code, index of the list is used as the third dimension.

...

for idx, fhw in enumerate(video_fhw):     <-- this is List(Tuple)
    frame, height, width = fhw
    rope_key = f"{idx}_{height}_{width}"
...

Reference -

diffusers/src/diffusers/pipelines/qwenimage/pipeline_qwenimage_edit.py

Line 709 in a840c39

img_shapes = [

[AmericanPresidentJimmyCarter]

Continuing to call attention to this issue -- the results from ComfyUI and FAL's API are great, while with diffusers I see results similar to the above. I think there might be something wrong with the diffusers implementation.

[enesmsahin]

@naykun Thanks for the explanation. I agree that there is some randomness when it comes to different aspect ratios. But from what I see, Comfy implementation preserves the details of the two images a lot better even for the most extreme aspect ratios (See the examples below from Comfy implementation). It fails sometimes in some other ways (as in the last example below) but the identity, textures etc. aren't completely off unlike diffusers implementation.

I understand that model might not natively handle the large mismatch between input and output aspect ratios and the results may be worse in such scenarios. However I believe that there is something different between two implementations causing diffusers version to change the identity of the two images significantly more.

[naykun]

Hi @enesmsahin , @AmericanPresidentJimmyCarter — thanks for sharing your concerns!

The truth is, both Comfy and Fal initially used diffusers as an implementation reference to ensure alignment. I’ll reach out to them to confirm whether any additional optimizations have been made. I’ll keep you posted — stay tuned!

[Saquib764]

Any update here?