Repository navigation
Why does calculate_dimensions in qwen-image-edit require image height/width to be multiples of 32? #12997
Description
Hi, thanks for the great work!
I have a question regarding the logic in calculate_dimensions.
Currently, the image height and width are constrained to be multiples of 32.
From my understanding:
The VAE has a downsampling factor of 8, so the latent spatial size should require the input dimensions to be multiples of 8.
Before entering the DiT, the latent is passed through a Patch Embedding layer with patch_size = 2.
That would further imply a total factor of 8 × 2 = 16.
Based on this, it seems that constraining the image dimensions to be multiples of 16 should already be sufficient.
Could you clarify why a multiple of 32 is required here?
Is there an additional downsampling stage, architectural constraint, or implementation detail that I might be missing?
Thanks in advance for the clarification!
Activity
chinmayirm commentedon Sep 22, 2026
Hi @lucky-liuzhihong, the factor of 16 you derived is the architectural minimum. The 32 in
calculate_dimensionsis the size this pipeline actually resizes to.Root cause
vae_scale_factoris 8, and the transformer packs latents in 2×2 patches, sovae_scale_factor * 2is 16.__call__checks that multiple, andVaeImageProcessoris built with it. A side of 16 is enough for the VAE and the patch embedding.calculate_dimensionsthen doesround(x / 32) * 32anyway. There is no third downsample. The Qwen-Image-Edit release resizes condition images on that 32 grid (area1024 * 1024for the VAE image,384 * 384for the vision-language image). The helper matches that preprocessing, so a local run hits the same height and width as the published pipeline.Proposed approach
Keep the rounding at 32. Changing it to 16 would load and decode sizes the release pipeline never uses. A one-line comment on
calculate_dimensionsis enough: 16 is the model constraint, 32 is the release grid.I would be glad to open a PR for that comment if it would help.