LCM Scheduler isn't perfect in uniformly spreading the timesteps across the full range

[aifartist]

Describe the bug

Timesteps for nSteps=26 using the current scheduler

[999, 979, 959, 939, 919, 899, 879, 859, 839, 819, 799, 779, 759,
739, 719, 699, 679, 659, 639, 619, 599, 579, 559, 539, 519, 499]

Notice that it comes up short of coming near zero.
My modification is still linear but across the full range and still keeping the individual timesteps as multiples of 20 away from 999:

[999, 959, 919, 879, 839, 799, 759, 739, 699, 659, 619, 579, 539,
499, 459, 419, 379, 339, 299, 259, 239, 199, 159, 119, 79, 39]

Note that at 25 steps and at a few other step values both schedules result in the same timesteps and same image. In the "Asian woman with fancy bikini" image below with the old scheduler it loses the sky, clouds and sand/sea edge when going from 25 steps to 26 steps. Perhaps due to the lopsided schedule???

Reproduction

For a hack to test my modified scheduler I took:

diffusers/schedulers/scheduling_lcm.py:set_timesteps()
and after the old scheduler created the self.timesteps tensor I just overrode it with:

    nSteps = len(self.timesteps)
    delta = 999. / nSteps
    for i in range(nSteps):
        self.timesteps[i] = 999 - 20 * int((i * delta + 10) / 20)

Obviously this is hard coded for the 20 increment delta requirement Simian told me of when I reported this to him.

Logs

No response

System Info

This is the diffusers version with LCM now integrated fully.

Who can help?

No response

[luosiallen]

The origin LCM scheduling is indeed flawed.

[patrickvonplaten]

Should we open a PR to fix it? :-)

[luosiallen]

Sure, we can. @aifartist how about you open a PR? It's your discovery.

[dg845]

I have opened a PR for this issue at #5836. (@aifartist sorry if I sniped you 😅).