I'll put my own discoveries on those utilities here.
They might be worthless, but having an option is better than having nothing.

Samplers

//TODO
I'll update when needed and focus on how samplers can be used rather than what each of them are.

Limitations

Here are the boundaries I've observed so far, tested with KSampler.

I won't guarantee authenticity at 100 percent.

Errors in names are made for convenience.

doughnut (🍩) is noise, water drop (💧) is heat cooler;
warning sign (⚠️) is the risky, roadblock (🚧) is the bad, prohibition sign (🚫) is the worst.
Samplers with their name colored is prone to saturation. Increasing step is less likely to help.

Steps

Most of the time, giving the model more steps for generation is beneficial to vibrancy suppression when cfg is set too high (for SDXL), and I want to show you some notable cases:

• dpm_adaptive doesn't need adjusting steps, it will fly by itself if not set to 1.

• lcm doesn't help stabilizing colors, but it tries to find the 'right' shape.

• dpmpp_2s_ancestral_cfg_pp doesn't help either, modification on color is negligible.

• dpm_2_a, dpmpp_2s_a, dpmpp_sde and res_multistep_a need lots of steps for cooling.

• dpmpp_2m_sde_gpu, dpmpp_3m_sde, dpmpp_3m_sde_gpu and ddpm take more steps for reasonable cooling.

Similarity

These samplers can be classified with euler on similarity:

• euler, ddim, deis, res_multistep, dpmpp_2m, lms, ipndm_v, ipndm, heun_pp_2, heun, gradient_estimation, uni_pc, uni_pc_bh2.

If you've read popular articles about samplers you should already know those with 'ancestral' or 'sde' in their names provide more diverse outputs, which means they share less similarities with euler. The following samplers also meet this condition:

• lcm

  • With or without LCM LoRA, it all looks unique.

• ddpm / dpm_fast / dpm_adaptive

• euler_cfg_pp / dpmpp_2m_cfg_pp / res_multistep_cfg_pp / gradient_estimation_cfg_pp

• euler_a / ddpm / seeds_2 / seeds_3

In addition to these, there are also pairs that look generally the same:

• dpmpp_2m_sde - dpmpp_3m_sde

• dpmpp_2m_sde_gpu - dpmpp_3m_sde_gpu

Schedulers

kl optimal

Lots of detail and rich content, sacrificing other metrics.
This matter of divergence is derived from align your step.

Distant walk noticeably banishes bad noises, but it can't cool down those flammable samplers.

linear quadratic

linear schedule followed by quadratic one.

By observing the preview, you can see the canvas forms its content and fixing itself smoothly. To be brief, it gives less body horror.

Put on SDXL, linear part only works well on the sampler with cfg++ indicated on its name.
Others waste time during the linear phase, leaving heavy work to the quadratic schedule:

• euler_cfg_pp (clearer than euler_a_cfg_pp)

• euler_ancestral_cfg_pp

• dpmpp_2s_ancestral_cfg_pp (the most de-saturated)

• dpmpp_2m_cfg_pp (looks like euler_cfg_pp)

• res_multistep_cfg_pp (looks like euler_cfg_pp)

• res_multistep_ancestral_cfg_pp (the most saturated)

in flux those are the samplers to avoid.
Cfg++ samplers burns twice as easily as normal ones, and linear quadratic makes it worse.
Both raising cfg scale and number of steps lead to further over-saturation.
It either gives you blurs or clear shapes like distilled flux, but the outcome will always get saturated anyway (unless you are using flux or sd3 models).

GITS (Geometry-Inspired Time Scheduling)

Simplified introduction here, arxiv source link here.
Available at built-in native GITScheduler node and Inspire Pack KSampler.
Has a coefficient; the default(1.2) value is suggestion, which is locked in KSampler;
The higher it gets, the more it is biased towards 0 sigma.

Sigmas and NotTODO

From this article you will know sigmas is de-noise strength of steps.

When KSampler is used for img2img, it keeps the scheduler's sigmas value relatively low to help preserve many elements from the original input image in the output.
By comparing the difference in output between the empty latent input and the img2img input when denoise is set to 1, you'll observe that the latter may still retain some of its original content, all of this thanks to what is happening with sigmas behind the scene.

Easily said, txt2img is a denoising process with a high sigma schedule, while img2img has a low sigma schedule.

By setting sigmas very high, extremely saturated horror will appear in the latent preview, which means the model can't de-noise properly at this strength during the process. Not giving it enough steps in the right sigmas may destroy the output, just like what the linear quadratic scheduler does when not combined with cfg++ sampler.

RES4LYF has a few scheduler nodes and sigma nodes for you to experiment with. ComfyUI also ships with schedulers that feature many recondite sliders. If you prioritize image generation efficiency over experimentation, I suggest staying away from it.