Further improvements to FLUX image-to-image

[RyanJDick]

Summary

This PR improves the behaviour of FLUX image-to-image. It eliminates/simplifies much of the logic from #6900 while preserving the benefits and extending support to image-to-image in addition to inpainting workflows.

Changes:

• Adjusts the denoise_strength scale in the Linear frontend for FLUX to improve usability (the amount of image change now varies more gradually with denoise_strength).
• Adds support for fractional denoise_start / denoise_end steps. This results in smoother transitions as denoise_start is varied for a particular image/seed.
• Update "Optimized Image-to-Image" toggle to apply to all image-to-image workflows - not just inpainting.
• Remove trajectory_guidance_strength from FLUX Denoise node. The benefits of this feature are largely captured by the other (simpler) features in this PR.

Example - Image-to-Image

Image-to-image example with denoise_strength (in the linear UI) varied from 0.0 to 1.0 in increments of 0.1:

Example - Inpainting

Inpainting example with denoise_strength varied from 0.3 to 1.0 in increments of 0.1:

Related Issues / Discussions

Recent related PR that originally added Trajectory Guidance: #6900

QA Instructions

• Image-to-image
  • optimized=True
  • optimized=False
• Inpainting
  • optimized=True
  • optimized=False
• Outpainting
  • optimized=True
  • optimized=False
• Progress images are correct
• Default FLUX workflows load without errors

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• Documentation added / updated (if applicable)

[skunkworxdark]

I don't pretend to understand the whole flux timestep thing as most of it is way over my head. However, I did cobble together some tests to improve the denoise start and stop accuracy, which were mildly successful. That I shared in the discorde garbage bin https://discord.com/channels/1020123559063990373/1083864753543331981/1280944995569897494.

Do you think, in the clip_timestep_schedule_fractional function, it would be worth scaling all of the timesteps to the new extents rather than replacing only the first and last ones after clipping them?

This should maintain the shape of the timestep curve rather than having a jump at either end. I know we are probably only talking about small fractions in the changes but I wasn't sure if this would have much of an impact or not.

[RyanJDick]

I don't pretend to understand the whole flux timestep thing as most of it is way over my head. However, I did cobble together some tests to improve the denoise start and stop accuracy, which were mildly successful. That I shared in the discorde garbage bin https://discord.com/channels/1020123559063990373/1083864753543331981/1280944995569897494.

Do you think, in the clip_timestep_schedule_fractional function, it would be worth scaling all of the timesteps to the new extents rather than replacing only the first and last ones after clipping them?

This should maintain the shape of the timestep curve rather than having a jump at either end. I know we are probably only talking about small fractions in the changes but I wasn't sure if this would have much of an impact or not.

I experimented with another version like what you've described. The results were pretty similar. The main advantages I see of the current approach is that you get to save a little time by running fewer steps if the denoise strength is low. I'm definitely open to changing it if you have convincing results to show that another timestep schedule is better though.

[skunkworxdark]

I experimented with another version like what you've described. The results were pretty similar. The main advantages I see of the current approach is that you get to save a little time by running fewer steps if the denoise strength is low. I'm definitely open to changing it if you have convincing results to show that another timestep schedule is better though.

I wasn't suggesting changing the number of timesteps, just the existing clipped timestep range might be better if it was scaled to the new values rather than just replacing the first and last ones. As this might better maintain the shape of the timestep curve.

However, the same as you, I have gathered no empirical evidence at all that it would improve the image. My previous experiments didn't show any meaningful differences other than being easier to choose that fine line of Denoise start that shifts from doing i2i and not doing it.

I see this has been merged into main now, so I might run some tests to satisfy my own curiosity about it. I am not expecting any big differences with it but I am curious.