RFC Discussion: More Core Nodes

[github-actions[bot]]

This is the discussion thread for RFC PR #22.

Please provide feedback and discuss the RFC here rather than in the PR comments.

PR Link: #22

[Amorano]

Add Tuple2, 3 and 4 support for int and float.

[PrometheusDante]

Checking the github star rating in case of pseudo-duplicate node implementations from different packs is something I do too, to minimize inconvenience for new users of my workflows.

But the actual differences are important to note as well. A simple example would be the ImpactPack's ImpactInt node, which provides only positive integer values and is thus better suited for cases requiring just that.
Using for instance the ComfyUI-essential's Simple Math Int node might require an additional min-max clamp via some math node.

The step-distance is another point to consider, especially with float values. Using 0.1 or 0.5 steps for the CFG is fine, but not so much for the denoise value, where I rather want 0.01 steps instead.

So when it comes to implementing a core solution for those general cases, a means of configuration, possibly handled within the node's properties, seems necessary to account for all those nuanced differences.
If all (reasonable/common) use-cases can be accounted for, I for one would always prefer the Comfy core version to avoid further dependencies. I would very much welcome not having to build in fail-safes for all sorts of values into group nodes, just to clamp down to the accepted value ranges 😅

[PrometheusDante]

An example where this is handled nicely would be the Slider node of the ComfyUI-mxToolkit pack

[PrometheusDante]

I would also argue that some basic functional nodes like the lazy switch, loop and accumulation nodes from the execution-inversion-demo-comfyui pack are highly valuable.

My workflows all use lazy switches where possible, leading to users having to jump through the hoops of setting their custom node channel to "dev" only to even find that pack.

A group node I built for an img2img pass uses a lazy switch to allow users to decide between using regular sampling, tiled diffusion or the ultimate sd upscaler. Any regular switch would be unfeasibly inefficient and result in the generation of all paths before deciding which output is actually needed.

To me lazy switches and loops were the main highlight of the execution inversion update and would represent part of Comfy's core functionality as well, warranting them a place, despite their potentially more niche use-cases.

[doctorpangloss]

see

https://github.com/hiddenswitch/ComfyUI/blob/master/comfy_extras/nodes/nodes_arithmetic.py
https://github.com/hiddenswitch/ComfyUI/blob/master/comfy_extras/nodes/nodes_generators.py
https://github.com/hiddenswitch/ComfyUI/blob/master/comfy_extras/nodes/nodes_regexp.py
https://github.com/hiddenswitch/ComfyUI/blob/master/comfy_extras/nodes/nodes_strings.py
https://github.com/hiddenswitch/ComfyUI/blob/a4a9e4b59f96a3e82ea3ae3ffcbc1606530eefe7/comfy_extras/nodes/nodes_images.py#L246

[christian-byrne]

Marking this RFC as active, as the process of upstreaming popular nodes has begun with:

• upstream MaskPreview from ComfyUI_essentials comfyanonymous/ComfyUI#7719
• upstream Preview Any from rgthree-comfy comfyanonymous/ComfyUI#7815
• Add nodes for basic string operations comfyanonymous/ComfyUI#7952
• Add nodes for basic logic and math operation comfyanonymous/ComfyUI#8024

The reception so far on this process has been really great and thanks to jtydhr88 for making the PRs.

I think we should keep the disccusion going -- any other suggestions for nodes that would be good to upstream into core ComfyUI?

Also, I think PRs to upstream nodes would be welcomed by any contributor, they can use jtydhr88's PRs as reference if e.g. they want to PR their own custom nodes or nodes they use a lot.

[Amorano]

Marking this RFC as active, as the process of upstreaming popular nodes has begun with:

* [upstream MaskPreview from ComfyUI_essentials comfyanonymous/ComfyUI#7719](https://github.com/comfyanonymous/ComfyUI/pull/7719)

* [upstream Preview Any from rgthree-comfy comfyanonymous/ComfyUI#7815](https://github.com/comfyanonymous/ComfyUI/pull/7815)

* [Add nodes for basic string operations comfyanonymous/ComfyUI#7952](https://github.com/comfyanonymous/ComfyUI/pull/7952)

* [Add nodes for basic logic operation comfyanonymous/ComfyUI#8024](https://github.com/comfyanonymous/ComfyUI/pull/8024)

The reception so far on this process has been really great and thanks to jtydhr88 for making the PRs.

I think we should keep the disccusion going -- any other suggestions for nodes that would be good to upstream into core ComfyUI?

Also, I think PRs to upstream nodes would be welcomed by any contributor, they can use jtydhr88's PRs as reference if e.g. they want to PR their own custom nodes or nodes they use a lot.

Pardon my ignorance here, but I am curious why you dont want to use this as a cleaner design moment?

I literally started making nodes because I wanted to do Maths one day and ran into the ComfyMath pack which had a node for EVERY. SINGLE. TYPE.

You dont want to consolidate all these nodes into a single node that can simply change context with a dropdown?

This was recently done in another PR.

I dont think (most of us) want to see a hundred+ new nodes that all do the same thing(s) just for a different type input.

That is just a future maintenance problem when you need to change something. I would also think you would want it condensed into "type switching" nodes so you could support future types, like vectors/tuples/lists or whatever else comes along, rather than having to make X * Y new nodes?

Just a thought, as this is how I designed all my nodes, more specifically, the ones you have listed to include in the core:

Even with dynamic inputs where it makes sense.

I am not saying "only take and use Jovi's nodes!!!" I am saying spend a little more time in the design part of what this means and how it actually impacts use, rather than just grab a bunch of existing nodes/concepts and jam them in the system.

Cheers.

[PrometheusDante]

Some would probably appreciate the simplicity of having very basic nodes, especially beginners.
But I agree that more complex functionality regarding a specific case, like math or string operations, would be nice to see realized within a single node with a dropdown menu rather than having a dozen nodes for all different cases.

I personally wouldn't want the Jovimetrix design taken as reference for core Comfy though, as I found it a bit over-stylized adding more visual noise than necessary, especially now that no intact group node solution is in place to manually hide what's not needed.

[Amorano]

I personally wouldn't want the Jovimetrix design taken as reference for core Comfy though, as I found it a bit over-stylized adding more visual noise than necessary, especially now that no intact group node solution is in place to manually hide what's not needed.

I dont want to chunk up the thread with personal questions, but I am curious what you mean "visual noise". If there is something I can clean up, I am interested in what you are seeing and how I can clean up anything that feels noisy during use. If you are on discord, please feel free to ping me (@Joviex) (if you are interested in explaining it further), or even a github thread on the Jovimetrix repo -- I would appreciate the feedback to make it better.

[Bocian-1]

I really like what pythongosssss's ComfyUI-Custom-Scripts does with their Math Expression node that lets you type in any expression manually. This makes it easy and compact even with large and complex expressions and can support functions like rounding functions or ternary if() statements all in a single node. It even accepts image inputs that can be referred with syntax like a.width and a.height. It can also handle
Some examples from my own workflows:

This has been the only math node I use aside from input nodes ever since I found it, I like it far more than the alternative of having multiple nodes for a single operation each that clutter the workflow. This isn't much of an issue for a workflow user since they can be hidden in group nodes or the future subgraphs, but are much more pleasant for me as a workflow designer to work with than having to place multiple nodes that only can do a single operation each.

[PrometheusDante]

I never knew that iif(condition, true, false) was a thing and worked around that by using sums of huge functions multiplied with simple condition statements 🤣
So thank you very much for that first of all!

I would also second the suggestion to have a universal math node like that, as I use those all the time as well and never bothered stringing together singular operations.
The only addition I would find useful would be to have a dedicated boolean output as well.

[henrikvilhelmberglund]

Seed (rgthree)

This does everything I want, randomize, fixed (that also gives a new randomized seed on click) and Use Last Queued Seed which is very useful when you liked the previous result but already queued a new prompt. The native behavior is a lot more clunky, you have to open the generated image to get the previous seed. Also having buttons for these makes for imo better UX than a dropdown.

---

Bookmark (rgthree)

Press the key to jump to the node, simple and useful.

---

Resize image (and mask)

Already mentioned I guess but resizing images should probably be a core node. It feels like every extension has a node like this because it's not a core node. In fact if you want examples of what could be added, just look through the popular extensions and see what the similar nodes are in each extension and pick the best designed one (or make it even better).

---

Load image with metadata

I know I can open a workflow by dragging an image into ComfyUI but sometimes I just want a list of everything, prompt, sampler settings etc etc. Should probably have some split metadata node too or another way to get the data you want.

---

Lazy switches

Mentioned above but lazy switches should definitely be a core feature, or anything that allows for stuff like "disable upscaler pass but pass through image to the end".

---

The "bigger than string manipulation/math stuff but I would love to see them in core" nodes

IPAdapter nodes

There is the great https://github.com/cubiq/ComfyUI_IPAdapter_plus which now however is in maintenance mode. It has a few bugs with PRs to fix them but the PRs haven't been merged, so a core version could be interesting.

---

Skimmed CFG nodes

From https://github.com/Extraltodeus/Skimmed_CFG/, I saw Mahiro in the CFG section so maybe skimmed CFG could be in core too. Great for avoiding issues when raising CFG.

Anyway I think these nodes are not what the RFC is about so I'll stop here. I will probably edit this with more "basic" nodes when I find something that should probably just be a core node.

[comfyui-wiki]

Get Image Size

We need a Get Image Size node. Currently, a lot of templates require manually setting the image size among nodes. The template will be more user-friendly if we have a Get Image Size node.

Better Get Video Componets node

It would be great if we could get the video size and frame count in the Get Video Components node. It just needs some modifications, not a new node.

[MNeMoNiCuZ]

Preview Values

https://github.com/yolain/ComfyUI-Easy-Use

I love this universal "Show" node. It's a good go-to for debugging or displaying any value.

Getting and Setting

SETTING and GETTING variables would also be good core functionality.

Save image with metadata (automatic data extraction)

https://github.com/nkchocoai/ComfyUI-SaveImageWithMetaData
Pretty please? And make it super fast :)

Image Size

As mentioned above, extracting width and height from images is a good foundational node

Latent size presets

A universal size preset selector with good defaults, and a custom user selection would be great.
https://github.com/MNeMoNiCuZ/ComfyUI-mnemic-nodes/blob/main/README/resolution_selector.md
I made one that works like this, but it's much too bloated as I can't control it well. It should also be able to output both image and video latents. Ideally you would choose an architecture from the list, and the presets would adapt and show you only what's needed. I combined this with latent output, as well as resolution outputs.

Multi-line string input

Updated multi-line string input. It should be easier to get this. Double-clicking a string input should default to multi-line string editor in my opinion. Ideally this would be modern and easy to use with UNDO functionality etc. and normal hotkeys like CTRL + UP to raise weights etc.

It could also support {wildcard|formats|like|this}, or like __thisToLoadFromFiles__.

LoRA load from tags

A node that supports lora:weight and loads it from the LoRA folder.

The two above could be combined into some kind of universal "Prompt" node, where we have a lot of luxury features for prompts, like loading LoRAs, wildcard handling and other luxury features.