fix: dpm_solver shouldn't be required to "start" on step 0

[brycedrennan]

Example: img2img pipelines often start somewhere in the middle based on how much of the source image they want to keep.

It wouldn't surprise me that you guys know a better way to allow starting in the "middle" of a diffusion process, but this did get my test suite passing.

[catwell]

Ah thanks, I missed that in my previous PR indeed.

We need a test for this in refiners, ideally one that runs on CPU.

Isn't doing it like this (with a scheduler attribute, like it was the case earlier) also a problem if you run several loops though?

[catwell]

Here is an alternative idea that does not have the problem of keeping a hidden state:

• we add a set_first_step on LatentDiffusionModel (or an extra parameter to set_num_inference_steps);
• we take it into account for init_latents, steps, and pass it to schedulers as an argument.

[brycedrennan]

Isn't doing it like this (with a scheduler attribute, like it was the case earlier) also a problem if you run several loops though?

You mean multiple image generations right? I make a new scheduler instance for each generation. In my mind, the schedulers already store state about the image generation via "num_inference_steps" (which can vary from generation to generation).

[catwell]

@brycedrennan Check out #201 and tell me what you think. I made the first step a 1st class citizen in schedulers and SD, like the number of steps. This way you can just initialize SD and call set_inference_steps when you change the params.

[brycedrennan]

Looks good!