[Discussion] Resolution mismatch of I2I bagel training

[yuxiaooye]

Hi author,
As we hard-coded the resolution as 512 in the I2I bagel config, it causes a resolution mismatch because the reference image's resolution is higher than this setting.

As a result, the output collapsed (as observed in WandB. At that time, no training happened):

I also tested the original BAGEL inference with same config, and that result is correct:

I think the critical part is that the resolution of generated image should follow the resolution of reference image. But I am not sure. Could you check this issue? Looking forward to your reply. Thanks very much!

[Jayce-Ping]

First I want to confirm if that image is from training or evaluations?

If it is from training, it is normal since the num_inference_steps is smaller for training. As the training goes on, the reward like pickscore will guidance the model to generate better images.

If it is from evaluation, I believe something wrong here. Since I got images like:

Which are all look good. And its corresponding training images are like:

which are normal as I explained above. After traing using DiffusionNFT after 100 steps, we got:

Additionally, I don't think the resolution of generated image should exact follow the resolution of the reference images. For Bagel, it hardcoded a transformation to resize input images to (1024, 512).

For some other cases, you may have multiple reference images with different sizes, official Qwen-Image-Edit pipeline chooses tha last reference image for the output size. And Flux2, things are slightly different. But theoritically you should always be able to choose the resolution you want.

From my experience, it is a good choice to sample & train on images with lower resolution, which significantly speed up the training and the gains can be transferred to higher resolution. For more detailes, please refer to:

Flow-Factory/guidance/algorithms.md

Lines 100 to 114 in 816c9fb

	#### Decoupled Training and Inference Resolution
	Flow-GRPO demonstrates that *lower-quality images, generated via fewer denoising steps, are often sufficient for reward computation and GRPO optimization*. PaCo-RL[[6]](#ref6) validates this insight from the perspective of **resolution**.
	Research indicates that training on moderately low-resolution images yields sufficient reward signals to guide optimization effectively. Furthermore, *performance gains achieved at lower resolutions successfully transfer to high-resolution outputs*. Given that the computational complexity of modern Diffusion Transformers grows quadratically with image resolution, this decoupling significantly reduces training costs.
	You can configure a smaller resolution for the sampling and optimization loop while maintaining the target resolution for inference and evaluation:
	```yaml
	train:
	resolution: 256 # Reduced resolution (int or [height, width]) for faster RL loops
	eval:
	resolution: 1024 # Full resolution for validation and inference
	```

For Bagel, the condition_image_size doesn't work since, as I said, it hardcoded the vae_transform for (1024, 512).

After you got a group of hyperparameters that works fine on lower resolution, and further if you are worried about the reward hacking or something, you can just switch the resolution seamlessly.

[yuxiaooye]

First I want to confirm if that image is from training or evaluations?

It is from training.

Yeah I got your point. I also agree with you that the resolution of the output image doesn't need to be the same as the input image.
It seems like BAGEL doesn't have a lot of good pre-training for the cross-resolution editing, because the output image is severely collapsed. However it is not a big deal, as I also observed the quality increase through NFT training.
Thanks a lot!