Element_ListGraph

Every sampler you run is already following a curve. Karras, beta57, sgm_uniform - those are names for particular shapes of "how much denoising happens at step 1, step 2, step 3…". Element_ListGraph (class Element_listGraph_Curve) lets you draw that shape yourself and ship it out as a plain list of numbers, so any node taking a per-step value can be fed a curve instead of a typed-out comma string.

It's the sibling of the pack's Element_SigmaGraph, and the README is honest about the lineage: same curve editor, minus the three rules that make something a sigma schedule. Sigmas have to fall monotonically and land on zero at the end, because they're noise levels. A generic per-step parameter has no such obligation - it can rise, fall, flatline or wobble. That's the whole reason this node exists.

How it works

The canvas is normalized: x 0 → 1 left to right, y 0 → 1 bottom to top, whatever your real values are. Click to drop a point, drag it, right-click to remove it. In the default curve mode the backend fits a natural cubic spline through your points - a tridiagonal solve, so the curve passes exactly through every point you placed and stays smooth between them. Hit the small mode button and it flips to straight: piecewise linear, no smoothing, which is what you want when you mean "hold 0.9 for the first half, then drop".

Then it samples at steps evenly spaced positions, x_i = i/(steps-1). The first and last sample land exactly on your endpoints, and the output has steps entries - not steps + 1. That's deliberate, and it's the difference from the sigma node, which emits one extra boundary value. Here steps=8 means eight numbers, one per sampling step.

Finally each value gets multiplied by max_value, so the canvas stays a clean 0–1 shape and max_value is your unit.

Inputs and outputs

Three inputs:

• steps (default 20) - how many numbers the list contains. This is the resolution of the schedule, not the sampler's step count. It should match whatever consumes the list.
• graph_data - the curve itself, stored as JSON with points and mode. You never type this by hand; the canvas writes it. It lives in the workflow, so your curve travels with the file.
• max_value (default 1) - the multiplier described above. Minimum is 0.0001, so you can't zero out the whole output here.

Two outputs:

• float_list - a list of steps floats, on one socket.
• string_list - the same numbers joined with commas (1, 0.93, 0.85, …), 6-significant-digit formatting, no trailing junk.

The string output has a known customer: supElement's companion pack, ComfyUI-Element_TileUpscale, takes reference_strength as a comma-separated string - "control the image reference strength for each step sampling", per the README. The pack ships an example workflow (workflow/ElementTiledUpscale_Krea2_area_repair.json) where steps=8 feeds a decaying curve into exactly that input. Which is the honest use case: reference-guided passes lean on the reference hard early and taper off as the latent gains its own detail, and that taper is much easier to see than to type.

Whether float_list helps you depends entirely on the receiving node accepting a list of floats. Don't assume a plain FLOAT widget will do something sensible with it - check the target's input type first.

Installing it

The node ships inside ComfyUI_Element_easy, along with ~25 other nodes. Via Manager, search ComfyUI_Element_easy and install. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/supElement/ComfyUI_Element_easy.git
cd ComfyUI_Element_easy
pip install -r requirements.txt

That requirements file is pack-wide, and it's heavier than this node implies: kornia, opencv-python, av (PyAV) and scenedetect all come along for the video and smart-merge nodes. The README's optional ffmpeg on PATH is only for exporting video with audio - nothing to do with a curve node. The README also warns the pack wants a reasonably current ComfyUI (Multi REF uses a newer node API), so on an old build that's what breaks, not this node. You'll find it under the Element_easy category.

Where people get burned

The steps mismatch is the real one. Set this to 20 while your tile pass runs 8 steps and you've handed eight-step sampling a twenty-entry schedule - the consumer decides how to reconcile that, and probably not in a way you like. Keep the two numbers equal, the way the bundled workflow does.

Second: presets saved with the numbered slot buttons live in presets/List_Curve_presets.json inside the pack folder on your machine, served over a small HTTP route. They don't travel inside a workflow the way graph_data does - sharing a workflow shares the curve, sharing a preset is a manual file copy.

Third, a bit of tolerance worth knowing: if graph_data isn't valid JSON, the node scrapes numbers out of the text and spreads them evenly across x. Pasting 1, 0.9, 0.8, 0.6, 0.4 gives you those as y-values, and a single number becomes a flat line. Handy for turning an old comma string into an editable curve.

Credit where it's due: the editor descends from Element_SigmaGraph_Curve, which credits Temult's TWanSigmaGraph (MIT). The spline work and point-insert logic are supElement's rewrite on top.