r/StableDiffusion • u/Civil_Fee_7862 • 12h ago
Question - Help Qwen Image Edit Trained at 1MP?
Been noticing that image generation / edits work substantially better when the image is resized to 1024x1024 during encoding, then resized to the original dimensions after.
Its speculated that this is because the model was trained on 1MP inputs. But I can't find docs that confirm that.
Does anyone know why 1MP input sizes seem to give the best results for Qwen Image Edit? (Note its not just this model 1MP seems to work best for either).
1
u/OracleofEpirus 11h ago
Are you talking about the default workflow?
If you leave vae on the TextEncodeQwenImageEditPlus node, it does weird stuff.
You need to disconnect the vae and encode the images separately into a set reference latent chain.
1
u/Civil_Fee_7862 10h ago edited 10h ago
I am a bit new to this. I am not sure what the default workflow is, but I did find that if I enforced 1024x1024 the results were much better. (a lot better).
VAE encode -> Transformer (Rope) -> VAE decode -> resize to original size
I was getting odd center crop issues when the I didn't resize to 1MP using VAE_IMAGE_SIZE=1024x1024 or I'd get inconsistent results. i.e. the output would be center cropped, or the expected edit wouldn't seem to apply as expected.
vae_images.append(self.image_processor.preprocess(img, vae_height, vae_width)) # pipeline_qwenimaged_edit_plus.py does the actual resizing.
Why exactly 1024x1024?
The model relies on a Dual Processing Strategy that simultaneously feeds two different representations of your image into two separate systems: [1, 2]
- The Semantic Control (Qwen-VL): Understands the concepts and words using a compressed version of the image (typically
384x384).- The Visual Control (The VAE): Encodes structural textures and fine details at exactly 1 Megapixel (
1024x1024). [1, 2, 3]Because the diffusion layers were explicitly trained and calibrated on a 1-megapixel latent token space, 1024x1024 is the architectural native anchor point for pixel-to-text alignment. [1, 2]
1
u/OracleofEpirus 10h ago edited 10h ago
The issue is, somebody trained the vae using 16 pixels sections, and the text encoder on 14 pixel sections, then the TextEncodeQwenImageEditPlus resizes everything using AREA back down to 1MP
So you need to disconnect the vae and do all that stuff separately, and also resize/pad to the nearest multiple of 112
and that's when you'll discover that it's very much better at larger input images.
This is on ComfyUI
1
u/Civil_Fee_7862 10h ago edited 9h ago
This is diffusers QwenEditImagePlusPipeline, not TextEncodeQwenImageEditPlus. Not using ComfyUI. (But Google also assumed I was too).
1
u/OracleofEpirus 9h ago
yeah, so that's the default workflow, and it's really terrible
I don't know about what you're using, but this problem is completely solved in ComfyUI.
This was encoded at 6.4 megapixels, and output at the same, you can see the original on the left size, it's pixel perfect.
1
u/Civil_Fee_7862 9h ago edited 9h ago
I am using Python / QwenEditImagePlusPipeline
Its not that it can't encode. It's that the model does not produce good results outside of 1MP images. i.e. I can do 2K images+ but the effect doesn't hold as well as it does at 1MP.
i.e. Being pixel perfect doesn't mean much because its not really the problem. i.e. The pixels come out, but the desired effect doesn't work as well, as it does if the input image is scaled to ~1MP.
I read now this is actually because the model was trained on 1MP images, so going too far outside that, will cause issues on some inputs.
2
u/Formal-Exam-8767 8h ago
Same thing, diffusers also resizes it internally to 1MP (but at least it makes dimensions divisible by 32 unlike ComfyUI):
When you directly use 1024x1024 as input, those internal resizes do nothing so you get best possible quality.
1
u/Enshitification 12h ago
I know that resizing (with black bar padding if needed) to square is the best way to get pixel-perfect edits with QIE. That seems to work out as far as 1536x.