chaiNNer icon indicating copy to clipboard operation
chaiNNer copied to clipboard

Node disable/passthrough

Open theflyingzamboni opened this issue 3 years ago • 3 comments

Allow individual nodes to be disabled and permit upstream inputs to be passed through if possible, else disable downstream nodes as well. One way this could potentially work at a high level is to check if the "primary" input type (e.g. an image being modified) matches the output type, then the input is just passed to the next node. If the "primary" input type does not match the output type, or there is some other factor that would prevent a sensible input/output connection, then all downstream nodes are disabled as well.

theflyingzamboni avatar May 28 '22 18:05 theflyingzamboni

I have some more thoughts on how this could be implemented. I am basing this on how I tend to think about most of the nodes (*with some notable exceptions), and how I think other users likely think about chaiNNer as well.

*(Split/Merge Channels are probably the most notable exceptions)

The way I tend to think about nodes* is that you have an initial image that is loaded into the chain. This image then "flows" through the nodes from beginning to end, where it is outputted with whatever modifications that were made to it along the way. We sadly don't have those user polls going, but this is a very layperson's understanding of how chains work that I suspect is how "average" end users conceptualize it.

Given this, when it comes to disabling/passing through nodes, I believe users will expect it to work such that what they think of as their "main" image (or other input type) will go through a disabled node unmodified by whatever other inputs/calculations the node uses.

My suggestion is that we define this ourselves explicitly, based on what makes the most "common sense" of how the average layperson will see it (and regardless of whether someone thinks that is how a given node should work, they will know it's how that node does work).

This input would be defined as the "passthrough input", and would need to meet the following conditions:

  1. There can only be one output.
  2. The passthrough input type and output type must match.
  3. a. There is only one input of the same type as output. b. There are multiple inputs of the same type as output, but one modifies the other and is not an expected output (e.g. Color Transfer has a primary image and a reference image, where the reference image exists only to modify the primary image). There is obviously some disagreement over which nodes qualify under this condition, but we can make the behavior clear to users to resolve potential confusion.

Any nodes that do not meet these conditions would be disabled and disable all downstream nodes that relied on their output. Those that do would send the passthrough input on to the following node(s), if it/they exist(s).

If a node has an input that matches these conditions, we can use markdown or some other visual indicator to express to the user what value they should expect to pass through. If a node does not meet these conditions, none of the inputs will be indicated as passthrough. A node can only have one passthrough input at most.

theflyingzamboni avatar Jun 11 '22 20:06 theflyingzamboni

Regarding pass through: Instead of imposing the idea of a primary input and assuming that users think in a certain way about nodes and chains, why don't we just let users choose which input gets passed through?

We could just say that pass through doesn't happen on the node level but on the edge/input level. I think of it as users right-clicking a specific edge/input and enabling pass through for that specific edge/input. This would allow users to freely choose which input gets passed through. This is not only more useful, it's also always clear which input gets passed through, because we don't have to define some arbitrary primary input.

Of course, even with this, there must some restrictions on which inputs can be passed through to make them compatible with the outputs (as explained by @theflyingzamboni above). Additionally, only one edge/input can be passed through per node at once.

RunDevelopment avatar Jun 12 '22 08:06 RunDevelopment

I'll have to think about it more, but at first blush I think I like that idea. I have some concern about people not understanding what can and can't be passed through and why, but disabling the option when invalid is probably enough to settle that confusion, even if users don't always understand the why. I feel like this could be done quite easily by having a little single-select radio button for each input or something that can be toggled (as in you have only one or zero selected at a time on a node).

theflyingzamboni avatar Jun 13 '22 02:06 theflyingzamboni