Skip to content

More Samplers/Schedulers, e.g. Euler #277

Closed

Description

@dblunk88

Thank you guys for throwing in the documentation. Segregating this from the other Issue.

Is there any possibility to include more of the k-diffusion samplers? https://github.com/crowsonkb/k-diffusion/blob/master/k_diffusion/sampling.py

Heuler for example would be nice

Activity

  1. ElleSimpsonEdin commented on Aug 30, 2022

    @ElleSimpsonEdin

    Seconded!

  2. changed the title [-]More Samplers[/-] [+]More Samplers/Schedulers, e.g. Euler[/+] on Sep 1, 2022
  3. mja commented on Sep 2, 2022

    @mja

    Looking at the code and the equations referenced, sample_euler in k_diffusion is the same or very similar to KarrasVeScheduler in diffusers. So that would be a good starting point for implementing the other samplers (sample_huen, sample_dpm_2) that take the same parameters (s_churn, s_tmin, s_tmax, s_noise).

  4. exo-pla-net commented on Sep 8, 2022

    @exo-pla-net
    Contributor

    TLDR: Now that we have optimized VRAM usage, I'd argue that the next feature to expand is samplers. Devs are attached to certain samplers, and their absence here is tempting devs to develop outside of huggingface. Given that a lot of devs are attached to k_euler_a in particular, I think adding it to Hugging Face should be a high priority.


    Below is my overview of where we are with samplers, and what's important.

    Currently, our diffusers project has these samplers available:
    DDIM, LMS, or PNDM.

    It appears the gameplan is to make separate files for each sampler we implement.

    What other samplers exist? Where can you try them out and see how they're implemented? I'd suggest the hlky Colab here.

    Their samplers: "DDIM", "PLMS", 'k_dpm_2_a', 'k_dpm_2', 'k_euler_a', 'k_euler', 'k_heun', 'k_lms'.
    (Our PNDM ~= their PLMS. Our LMS ~= their k_lms.)

    But wait, you might ask, do samplers even matter? Is choosing the correct sampler important for making a great image? I have looked at several comparisons between samplers. Here are three of the best: one , two, and three. My conclusions:

    • Given low CFG and >=25 steps, all samplers are fairly interchangeable.
    • Accommodating high CFG, however, is very important for defining the look of an image.
      -- Low CFG = washed out, greater intricacy.
      -- High CFG == more defined, higher saturation.
    • Given high CFG, some schedulers require 50 or more steps to get rid of a seed's rainbow artifacts.
    • Steps are different speeds in different samplers. Some samplers are much quicker.

    So which is the best sampler? I think the following reasoning is a solid foundation for making that choice:

    • For any given prompt+CFG, there exists a "steady state" number of inference steps, where an additional step is equally likely to make the image better or worse.
    • Steady state for many excellent images is achieved in merely 25 steps.
    • Some samplers, however, do not reliably eliminate the rainbow noise in 25 steps.

    And thus, the best scheduler is the one that resolves high-CFG rainbow noise in 25 inference steps the fastest. For that purpose, these samplers are all equivalent: DDIM, k_euler, k_euler_a. Using any of those, you'll be able to explore seed+CFG space the fastest, and thereby create a great image the fastest.

    However, I and other devs have developed a superstition about k_euler_a. There's just something to it. k_euler_a is a contrarian sampler that refuses to resolve, no matter how many steps you throw at it. It seems to often spit out higher quality images than other samplers. (I think k_euler_a is possibly just chaotic, and you'd find an equal number of great images in equal time, simply by exploring different seeds with another sampler, instead of pounding on the same seed with the chaotic k_euler_a. But then again, maybe not -- maybe k_euler_a truly is special. Can anybody math me and say something definitive?)

    We want developers to feel like Hugging Face's diffusers is all they need to make state-of-the-art apps. Whether or not it's merely superstition that makes devs want to use other samplers, we should try to include those samplers, because great devs are not immune to superstition, and we want them building with Hugging Face.

    (Plus, you never know, k_euler_a might add some extra spice to our incantations /~*~~ )

  5. Inkorak commented on Sep 9, 2022

    @Inkorak

    Yeah, k_euler_a has some popularity. It is really worth implementing, at least as a selling point.

  6. sidthekidder commented on Sep 16, 2022

    @sidthekidder
    Contributor

    Thanks for the context above @exo-pla-net! I'm planning to try and implement the sample_euler_ancestral sampler in a new scheduler. I read the schedulers/scheduling_karras_ve.py implementation that's similar to sample_euler so I'll structure my code similarly.

    A question - since the Algorithm 2 euler implementation is also spread across the pipelines/stochatic_karras_ve/pipeline_stochastic_karras_ve.py file, does that mean sample_euler_ancestral would require a new pipeline as well? Or should I try to modify the existing pipeline_stochastic_karras_ve.py, since it's similar apart from adding ancestral sampling?

  7. Arkitecc commented on Sep 23, 2022

    @Arkitecc

    I'm very much looking forward to this, if anyone is able to get this down definitely tag me.

  8. Suhail commented on Oct 10, 2022

    @Suhail

    it would be useful to implement as many of the samplers that DreamStudio does: https://github.com/Stability-AI/stability-sdk

    Users are becoming used to using them.

  9. patrickvonplaten commented on Oct 11, 2022

    @patrickvonplaten
    Contributor

    @patil-suraj @anton-l - plans/ideas on how to move forward here?

  10. crowsonkb commented on Oct 14, 2022

    @crowsonkb

    k-diffusion's Euler and Euler Ancestral samplers are just the VE versions of DDIM and the original DDPM sampling method though, they should actually produce the same outputs as their VP counterparts if you convert a VP diffusion process to VE...

  11. patrickvonplaten commented on Oct 27, 2022

    @patrickvonplaten
    Contributor

    @anton-l any updates here?

  12. 8 remaining items

  13. keturn commented on Jan 4, 2023

    @keturn
    Contributor

    I think

    • k_dpm_2: DPMSolverMultistepScheduler(algorithm_type='dpmsolver')
    • k_dpmpp_2: DPMSolverMultistepScheduler(algorithm_type='dpmsolver++') [default]

    not sure about the _ancestral variants, whether that corresponds to one of the many configuration options for DPMSolverMultistepScheduler, or if that's a crowsonkb special addition that wasn't in Cheng Lu's implementation for diffusers.

  14. patrickvonplaten commented on Jan 4, 2023

    @patrickvonplaten
    Contributor

    Actually sorry I think there is some confusion because the names are so similar 😅

    Here the conversion k-diffusion<>diffusers:

    Hope this helps a bit :-)

  15. patrickvonplaten commented on Jan 4, 2023

    @patrickvonplaten
    Contributor
  16. Suhail commented on Jan 4, 2023

    @Suhail

    Very helpful - thank you

  17. usamaehsan commented on Jan 14, 2023

    @usamaehsan

    Do you guys support DPM adaptive?
    I am only getting good results with this scheduler

  18. added a commit that references this issue on Jan 15, 2023
  19. patrickvonplaten commented on Jan 16, 2023

    @patrickvonplaten
    Contributor

    Hey @usamaehsan,

    Can you send a link to DPM adaptive? Where is it from?

  20. usamaehsan commented on Jan 16, 2023

    @usamaehsan

    Hey @usamaehsan,

    Can you send a link to DPM adaptive? Where is it from?

    It's from k-diffusion:
    https://github.com/crowsonkb/k-diffusion/blob/686dbad0f39640ea25c8a8c6a6e56bb40eacefa2/k_diffusion/sampling.py

    I am using it with automatic 1111, stable diffusion web ui

  21. pete-finesse commented on Mar 23, 2023

    @pete-finesse

    This scheduler k_dpmpp_2s_a (or k_dpmpp_2 generally) is mentioned in this thread before but I can't figure out how it maps to the diffusers schedulers. Does it exist and I'm just missing something? This is the method for reference

  22. sayakpaul commented on Nov 21, 2024

    @sayakpaul
    Member

    I think we now support a comprehensive list of schedulers and also overhauling its inter-pipeline support (like using a non-flow matching scheduler in a flow-matching model like Flux). So, closing this. Cc: @yiyixuxu

    See: #9607

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions