As requested, here is the collection of "boop"-related merges I've been using over the past few months. I'll list them out here and then for each version, I'll put its description there, as well as well as each model's example images.
~boop
merge of analogMadness_v60, and aZovyaPhotoreal_v2
The first attempt at a photorealistic merged checkpoint and, honestly, it works pretty well.
It handles prompts fairly well, and like later versions, I use mainly "Euler a" or "DPM++ 2M SDE - Kerras."
For guidance, I generally use between 4 and 6, and sampling steps from 20 to 29.
I almost always use Beyondv4-neg and bad-hands-5 in the negative prompts.
It will produce SFW & NSFW images and does people pretty well and handles a fairly large number of descriptors and/or loras before image quality suffers.
~boopV2-inpainting
merge of pornmasterPro_fullV5-inpainting, and ~boop
This is included mostly for completeness. In a mad scientist kind of scenario, I tried to incorporate an inpainting model into a standard SD15 model.
While it will produce images, they always are a bit muted, color-wise, and usually generate with a weird red border.
There are reasons I don't use this one. Unless you're looking for muted colors and odd borders, I would use any of the other models.
It handles prompts fairly well, and like later versions, I use mainly "Euler a" or "DPM++ 2M SDE - Kerras."
For guidance, I generally use between 4 and 6, and sampling steps from 20 to 29.
I almost always use Beyondv4-neg and bad-hands-5 in the negative prompts.
It will produce SFW & NSFW images and does people pretty well and handles a fairly small number of descriptors and/or loras before image quality suffers.
~boopv3
merge of serenity_v10Safetensors, and ~boop
The 3rd attempt at a merge with which I was happy, this is one that I have used for a while, now, right up until I decided PhotoBoopV4 worked in a satisfactory manner.
It handles prompts pretty well, and like later versions, I use mainly "Euler a" or "DPM++ 2M SDE - Kerras."
For guidance, I generally use between 4 and 6, and sampling steps from 20 to 29.
I almost always use Beyondv4-neg and bad-hands-5 in the negative prompts.
It will produce SFW & NSFW images and does people pretty well and handles a fairly large number of descriptors and/or loras before image quality suffers.
boopXL
merge of photoMovie_photoMovieSXL, Photo Movie SX.fp16, and ~boopv3
Another "mad scientist" attempt, this time to shove SDXL and SD15 into the same mold as sort of a "do everything" merge.
However, like a lot of mad scientist experiments, this has flaws.
The main flaw, however, is a biggie, to me. It doesn't really pay a lot of attention to the prompt.
You will get a lot of "the spirit of the prompt" rather than "the letter of the prompt." I haven't found one that really gives me what I prompted for.
PhotoBoopV4
merge of ~boopv3, and photon_v1
The 4th iteration, or attempt, at a merged checkpoint that was more what I was looking for.
Prompt processing is mixed. "Euler a" is usually the closest to the prompt, though I generally like the output using "DPM++ 2M SDE - Kerras" better.
For guidance, I generally use between 4 and 6, and sampling steps from 20 to 29.
I almost always use Beyondv4-neg and bad-hands-5 in the negative prompts.
It will produce SFW & NSFW images.
BoopV4.fp16
merge of ~boopv3, and photon_v1
A fp16 version of PhotoBoopV4.
It behaves much like PhotoBoopV4, so, as stated below, prompt processing is mixed. "Euler a" is usually the closest to the prompt, though I generally like the output using "DPM++ 2M SDE - Kerras" better.
For guidance, I generally use between 4 and 6, and sampling steps from 20 to 29.
I almost always use Beyondv4-neg and bad-hands-5 in the negative prompts.
It will produce SFW & NSFW images.
Description
I've changed this over to "other" as it's not strictly speaking a Flux model, though I've been using it as such for 6 months now. Problematically, the merge was done through SD processing, which is interesting but, again, alters the model's output veracity.
While technically not named boop-ishly, the lineage is similar enough that it can be an honorary member, and not just because it makes it easier to keep track of.
So, this is what I've been using for my flux generations for several months, now, and have had really good results, especially when using the ae , clip_l, and either t5xxl_fp16 or t5xxl_fp8_e4m3fn VAE/Text encoders.
I use the Euler and DEIS sampler types the most, though it handles a variety of others, just not as well. Under schedule types, I stick to Simple/Normal/KL Optimal/SGM Uniform for the majority of generations.
For sampling steps, I use 23 most often, and under the distilled cfg scale, I leave it at 3.5.
I rarely use the HiRes Fix, but instead, send it to Extras and use the 4x_foolhardy_remacri at 4x to get consistent results.
I don't remember why I decided to merge a couple of the flux checkpoints, but problematically, I don't remember which I merged, and I did it under Auto1111 but have been using Forge or ComfyUI for close to 6 months, now.
FAQ
Comments (6)
Not a flux model.
What should it be called then -- what am I missing?
I ask because it doesn't process without the proper VAE/clip/text encoders. It produces flux output. It was merged in Forge which currently only supports Flux models.
{\"name\": \"flux1DevFlux1Schnell_devNF4UNET.safetensors\", \"legacy_hash\": \"d9cb14c6\", \"sd_merge_recipe\": null}, \"83024b81665f1ee9d323cba43ca3ea4012741e5bd9b804902199b0868d8530b9\": {\"name\": \"FluxFusionDS_v0_Q4_K_S.gguf\", \"legacy_hash\": \"c0fb15cd\", \"sd_merge_recipe\": null}}"}
merging in forge supports other models too, so i'd say the SD recipe ain't the right one
@snotty First -- thank you for giving me some knowledge I can work with. I appreciate it. As an aside -- what did you use to view the innards/metadata for the model?
OK. Interesting. So...and this is me thinking "out loud," so read it in a slow cadence with some brow furrowing.
It looks like there are a couple of things going on, so I ask for a little patience as I work this out.
So, when it says "Ready to save ... (Currently only support saving Flux models)" that is referring to only the Unet and Checkpoint saving and does not apply to the model merge button further down on the page. If this is the case, side note to developers -- if it doesn't have to do with the title of the tab, it shouldn't be on the tab. Simple solution -- rename the tab to "Checkpoint Functions." Anyhoo...
Logic then dictates that everything under that subsection is what actually has to do with the merging. That makes sense, though, as it did seem silly that it would only support flux, but that's my misinterpretation, therefore makes sense, then, that the produced merge would be whatever it uses, like you said, for a recipe..
This raises a question or two:
When one clicks "Checkpoint Save," then what is on the main generator UI -- the model in use and its associated settings -- is poured into the checkpoint.
The resultant checkpoint, then, is a Flux one, can I assume? If, as in this example, Fluxzilla is the model in use and all the settings that go with it -- since Fluxzilla is of questionable model-y-ness, what is it actually producing, structurally/model-typey?
Again, thanks for info.
@Soulbliterator open the model in any text editor, the header is plaintext.
the Ready to save ... (Currently only support saving Flux models) text refers to Save Current Checkpoint only.
the model merge section is beneath that, and, as you noted, TOTALLY UNCONNECTED to the above,
if you actually use Forge for generation, do yourself a favor and try SwarmUI, which is way way better than all the A1111 clones.
And the ComfyUI backend included in SwarmUI has an actual Flux Merge node.
Whoa. @Soulbliterator I learned something from this thread too. Thank you!