Gender Handling in ReActor, with problems and a wish

[wknudsen]

I just saw that you closed the original issue since I started writing this, so I repeat it in this new issue to be sure that you see it.

It's very nice that you have added the gender handling, thank you so much. I have updated the node and tested it, and it worked as expected.

I initially had a problem: After git pull updating, the node (in an existing workflow) had the new gender fields, but the two inputs kept their original legends but had their new positions which caused my wiring to fail. It was very confusing and I didn't understand it until I deleted the node and replaced it with a new one.

The new nomenclature - source for the source faces and input for the image to be changed - is very confusing, at least to me. Source and input are two concepts rather close to each other. Much better to call them what you do in A1111: Source for the source faces, target for the image that is to be changed. You actually do that in the ComfyUI log.

If you don't know ReActor from A1111, it's not clear that you can specify a list of indexes, not just one index.

A question: Do you count the detected faces from left to right, or is top to bottom also involved?

A wish: Do you have (or know of) a way of showing the analysis of an image: The number of faces found and a sequence of gender M and F's? If the information is readily available, you could output the information as text or - ideally - the original target image with face number and gender marked on top of its detected faces. This would be nice for A1111 too. Not everyone has access to logs so some output would be preferable, although log output could be a first step.

[Gourieff]

A wish: Do you have (or know of) a way of showing the analysis of an image: The number of faces found and a sequence of gender M and F's? If the information is readily available, you could output the information as text or - ideally - the original target image with face number and gender marked on top of its detected faces. This would be nice for A1111 too. Not everyone has access to logs so some output would be preferable, although log output could be a first step.

Very good idea, I will implement it in SD WebUI ReActor and then here, I'm going to add an age detection option and after that I'll add a txt output with an info of detection values

I just saw that you closed the original issue since I started writing this, so I repeat it in this new issue to be sure that you see it.

It's very nice that you have added the gender handling, thank you so much. I have updated the node and tested it, and it worked as expected.

I initially had a problem: After git pull updating, the node (in an existing workflow) had the new gender fields, but the two inputs kept their original legends but had their new positions which caused my wiring to fail. It was very confusing and I didn't understand it until I deleted the node and replaced it with a new one.

The new nomenclature - source for the source faces and input for the image to be changed - is very confusing, at least to me. Source and input are two concepts rather close to each other. Much better to call them what you do in A1111: Source for the source faces, target for the image that is to be changed. You actually do that in the ComfyUI log.

A source image renamed to "source" to match the same logic as sd-webui-reactor has
But as for the image to be processed - I think the "input image" is much more logical (for a Node's system) than the "target image"

If you don't know ReActor from A1111, it's not clear that you can specify a list of indexes, not just one index.

A question: Do you count the detected faces from left to right, or is top to bottom also involved?

Yeah, you're right, I will spot it in the Readme with future updates

[drdancm]

I'm afraid I have to agree with knudsen about the terminology. Target image makes more sense for users who don't know anything about the underlying mechanism (Nodes).

It's a matter of perspective, the logic for users is not the same as for the people doing the programing and analysis. Source is the face you want to put into the scene, and Target is the face you wish to swap with the Source.

This is totally logical and crystal clear from a strictly user perspective. What makes sense for the coding, is an entirely different matter and, in this case, is confusing to the naive user. The word input could easily apply to the Source and the face you are replacing. If you want things to be less confusing to total naive, brand new users, you have to try to put yourself in their shoes.

This is not easy, and sometimes for many people it is impossible, because you would have to put aside things that you know. Hence the need for good teachers, they know how to wear beginner's shoes. I'm speaking not only as a somewhat new user, but also as a Psychologist.

[Gourieff]

Source is the image with a reference face
Target is the image to swap
This naming also goes in SD WebUI
So, input_image - is the image to swap (target image)
It's very simple I think and it also follows with the ComfyUI logic of inputs in pipes
From 0.4.0 input_image is the main input of the Node, the input providing the image to be processed
To process how? With a source face image or with a pre-ready face model
Very simple and logical
And even if someone doesn't understand which input is for what (and doesn’t want to look at the README for some reason) - it’s not at all difficult to run the query once and figure things out

[wknudsen]

Thanks, looking forward to the detection enhancement.

To fight a bit for the naming: In a node based system all input connections are that, inputs. So calling it "Input image" adds no information of what it is used for. This particular input image is the target image to be changed by ReActor. Same as the Source image is an input image used as the source for the transformation. You help your users' understanding much more that way. The naming-for-function principle is also common in ComfyUI, eg. the two prompt inputs in kSampler that are called positive and negative to make it clear what they are used for.

[Gourieff]

To fight a bit for the naming: In a node based system all input connections are that, inputs. So calling it "Input image" adds no information of what it is used for. This particular input image is the target image to be changed by ReActor. Same as the Source image is an input image used as the source for the transformation. You help your users' understanding much more that way. The naming-for-function principle is also common in ComfyUI, eg. the two prompt inputs in kSampler that are called positive and negative to make it clear what they are used for.

In any case, we can rename inputs and outputs the way we like inside ComfyUI

[drdancm]

Please read my input above.
Thanks !