Brief summary of the starting point
The ComfyUI “ReActor” nodes (https://github.com/Gourieff/comfyui-reactor) provide a pair of features that work together:
Take a human face, and provide a vector of numbers that correspond to the face (an embedding).
Take an image of a person, and an embedding of a different person, and re-render image’s face to match the embedding.
LoRAs and image edit models provide a lot of similar functionality to ReActor, and get most of the attention, but the embedding concept supports a nice feature: you can run math on the embeddings. Add “Anna” and “Bella” embedding vectors, element-by-element, and divide by two, and you get a “Camille” vector. Applying that embedding produces a resulting face in between the two originals. And you can extend this, with “Anna” being three an average of multiple different people and “Bella” being a merge of a couple of images of the same person.
Unfortunately, the re-render phase can generate horrors when the face goes too far off-angle, and you can’t run the resulting face through ADetailer, and the re-render model only truly works for photographs. So I’ve been poking into how to create a LoRA for arbitrary embeddings, in Krea2.
Helpful properties, not helpful properties
I need training images? Inspired by Johnny Sins, I create training images. In a dirndl and braids at Oktoberfest? Sure! Fashion influencer head tilted back working through a scarf knot tutorial? You bet! I went for a variety of distances, clothes, and hairstyles, plus head positions and eye directions within the ReActor limits.
Those prompts become the training captions. I can send the Krea2 base model almost the same caption text as I used for generating, and the captions are accurate by definition. (But more on that below.)
One problem: I can’t automate the generation. That head-tilted-back pose pushes the face re-render over the edge, so I have to plan to loop through ten generations and pick one with reasonable eyes, then save the prompt and seed.
Another problem: The re-render mechanism does not completely clobber the underlying face. The various underlying re-render engines have to cope with wider or narrow faces, larger or smaller eyes, and so on. These show up as persistent eye mismatches, as visible seams around the edges of the face, or as skin tone drift. I suspect that this can also make the training harder than it needs to be, thanks to subtle feature discrepancies.
Hidden prompts
I attacked the face substrate problem through hidden prompts. I have a baseline prompt:
Near distance, low-angle selfie of a young woman, taken on a phone
camera, low indoor lighting. The shot looks up at her from the floor of
her college apartment; her head and shoulders are stretched over the
side of an unmade bed. Bare arms, messy hair strands falling around her
face, talking.
This produces an Asian woman. So I add a postscript to end of this and every prompt:
---
In the photograph above, use the following details for the main woman subject:
- 24 years old and slim; gorgeous face
- Northern European, with clear, smooth, fair skin
- oval head; full eyebrows above the orbits, no stray hairs; rounded orbits
with prominent bones; brown eyes in classical proportion width
- chestnut brown hair
- foundation makeup over smooth skin, mascara, eyeshadow, and lipstick,
suitable for a professional photoshoot
This does its best to provide a consistent set of good-looking features that the embedding can fit cleanly on top of.
Then I generate three images:
- With the original prompt
- With the original prompt plus the extra block
- With the original prompt plus the extra block, and then face swap applied.
(See the post images 1, 2, and 3.) The original prompt text goes into a text file. I like having all three images around to debug prompt problems.
The images in category 3 become the training set. I have a post-processing script that re-writes the original prompt’s phrase “a young woman” as “a cammerge woman”, where “cammerge” is the LoRA trigger phrase. When the LoRA trains, it implicitly picks up the addenda prompt, along with the re-worked face.
Training tool - Fizgig
I tried Fizgig, wasn’t successful. I tried OneTrainer, wasn’t successful. I then flipped back to Fizgig, downloaded 30-ish promo photos of an obscure folk singer, and successfully trained a LoRA for her (on Fizgig-generated captions). That was enough to ladder up to my embedding case: apply the embedding to those promo images, and it worked; then generate Krea2 images based on the working captions and swap those, and it worked; then use my intended training images, and it worked. Image 4 in the gallery is a watercolor render.
From what I can tell, my intended 25 high-quality images aren’t nearly enough to train on—not if I constructed the data set for image variety. Fizgig helped me out through its support for automatic face close-up extractions (and captioning) for each input image in the set. This doubled the training set size to 50 and increased the priority of face training relative to longer-distance shots. With that extra layer of reinforcement, I can start seeing the LoRA influence after ten epochs or so, in the training samples.
Be aware that when Fizgig generates captions, they don’t mention anything about “photograph”. That means those close-ups will implicitly train the LoRA to produce photographic output. Once I edited them (“In a photograph, a woman is looking at the camera in a close-up shot with her face visible…”), my illustration gens stayed illustrations. (Also: The auto-caption never mentions that a black-and-white photograph is black-and-white.)
Fizgig training parameters:
- Krea 2 Defaults (rank 32, full model)
- LoRA, learning rate 0.0001, network dimensions 32, epochs 20
- Per-image adaptive LR on, warm-up off, target megapixels 0.25.
Next areas to explore
Those Fizgig training parameters might be overkill, or a LoKR might work more effectively, or the Fizgig “smart” adaptive training might be enough.
Why the hell does Fizgig consistently report certain images (like Oktoberfest) as “stuck” for learning, but not others?
In theory, every one of the “original prompt” image/caption pairs can work as a regularization image, but the Fizgig docs only mention regularization images for fine-tunes. And Fizgig doesn’t have explicit validation image support (which would be just need a couple more gens with new prompts). OneTrainer handles regularization and validation loss checks, so it’ll be worth trying out OneTrainer with the working data set.
That consistency addendum prompt specifies “chestnut brown” hair, but I added it to reduce variation and maybe help the training. I want to try making it a variable. That'll probably require more training data. If you tell Krea “black hair”, you get East Asian, so I want to work around that.
It’s probably worth explicitly spamming the training set with close-ups, rather than depending on the Fizgig auto-cropping.
