“Genealogy” trees for merged models

[eadnams22]

Would be really interesting if we could follow a genealogy tree, of sorts, for merge based models. So when there’s merges of merges of merges, we can trace that back easily. Would let us easily see the trigger words or phrases/prompts that have been added into the new merge, and let’s the authors easily do their merge lists. By adding just what they merged, it automatically integrates to show what those pervious merges included too.

would make for interesting analytics stats too!

[JustMaier]

I've been thinking about this one for a while. It seems especially important now that there are some special modified licenses out in the wild that require derivatives to include their special terms.

[eadnams22]

Totally, It feels ambitious (I'm not much of a developer, otherwise r I'd try to make a pull), but could really help users, help bandwidth usage (less redundancy possibly), and be impressive to show what makes civitai special.

[JustMaier]

We're beginning to work on this. Here's a quick preview of the recipe input:

[aolko]

please make a better component AUTOMATIC1111/stable-diffusion-webui#5786

[hassan-sd]

To add to this, there's other methods of merging than simply the singular weight, many of us are using a block weighted merge approach such as this: https://github.com/bbc-mc/sdweb-merge-block-weighted-gui

It might be worth adding an enhancement request to the Automatic1111 UI so when a merge is complete ,a log is saved with the variables used regardless of the method. They save a new settings.json logfile when you train an embedding so something similar for merging would be handy, then Civitai could import it. It would be a more standardized way than having the option for a users to paste in a recipe all over again here

[eadnams22]

My thought at the time of the suggestion isn’t so much to know the exact type of merge, just what the “genealogy” is, what went into it, and easily navigate that tree, to those models (if they’re on the site) to see trigger words that might’ve been buried. Licensing stuff too, I suppose.

Also to see what merges have come from a particular model, that might improve various parts of them.

Fun and interesting data, and a point of pride for the creators, I’d hope. ❤️

The description can still go deeper in to the specific types of merges.

[JustMaier]

We've discussed something like this in our discord thread on this matter. I'd bet that if we put together a PR that adds JSON metadata alongside models when merges are done that it'd get accepted.

Hard part is that I'm not really sure how to even properly track or account for the block-weighted merges you're talking about.

[aolko]

there are also https://github.com/bbc-mc/sdweb-merge-board recipes