What is the difference between BASE and text encoder value? They generate different images.

[diodiogod]

I'm really grateful for this extension and supermerger. Analyzing my SDXL Lora I get the BEST results reducing the effect of the trained lora text encoder and chopping some Unet blocks. With these settings: <lora:NAME:0.25:1:lbw=0.25,0,0,0,0,0,1,1,1,0,0.15,1> I get really great results. I really wish I could merge my lora to fix or adjust the Text Encoder value TE and Unet value to these ones above. But I don't know if it is possible.

From your other responses here https://github.com/hako-mikan/sd-webui-supermerger/issues/281#issuecomment-1805428022 https://github.com/hako-mikan/sd-webui-lora-block-weight/issues/110#issuecomment-1708282404

You said that the BASE value is the same as this FIRST TE value on the LoRA. As if in

the X is the same as BASE. But it doesn't look like it when testing it. I'll use this tank shirt Lora as an examples (this is not the one I want to merge though): This is the normal I understand there is some kind of multiplication going on from the "first TE" to the "BASE". If I set zero on the first value like this: `````` it doesn't affect the generation and is the same as both with zero `````` `````` it does affect the generation and generate noise because of the high value, so its not a simple multiplication of the first TE to the BASE or else it would be the same as zero. Now with 0.8 on the "first TE" (different seed and prompt): `````` BASE 0: TE 1 affect the generation and crate image "N" `````` BASE 0.5: it affect the generation and create a slightly altered image "Na" `````` BASE 0.8: it affect the generation and create a slightly altered image "Nb" but NOT "Na" `````` BASE 0.5 and TE 0.5: it affect the generation and create a slightly altered image "Na" but NOT "Na" or "Nb" So any positive value on any side will affect the generation and they are not interchangeable. So my questions are: 1- how are they different? Are they adjusting the same thing? 2- Is it possible to create/adjust a Lora in supermerger to get a 0.25 on the "First TE" value and also adjust the rest of the Unet values? This should be on supermerger github I guess, but you are also the author so, using supermerger with these options (only one LoRA): ```NAME:0.25:1:0.25,0,0,0,0,0,1,1,1,0,0.15,1``` doesn't work, it uses 0.25 to all blocks. > ERROR:Number of Blocks must be 12,17,20,26 ```NAME:0.25:0.25,0,0,0,0,0,1,1,1,0,0.15,1``` It works but it doesn't look like the 0.25 meters at all. This is the same as using this ```NAME:1:0.25,0,0,0,0,0,1,1,1,0,0.15,1``` or this with weight 99 ```NAME:99:0.25,0,0,0,0,0,1,1,1,0,0.15,1``` Looks like it ignores the strength. the best way I could think of was adjusting using "lora block weight" (this is all on generation not after merging, I could not make it work with supermerger) the Unet in a way that I could just use the LoRA as 0.25 both for TE and UNET Like this: `````` is very similar to this `````` i multiplied everything by 4 and the BASE is a really low value, close to be divided by 4. It's the best I could do to get close to the Lora:0.25:1 with the blocks I wanted the same way: `````` is very similar to this `````` that is very similar to `````` But using on supermerger (NAME:0.25:1,4,4,4,4,4,4,4,4,4,4,4) don't work and has side effects because of such high values. They look similar on the generation but not after merge. If I merge this I get the lora to work if I use the merged lora in a very very small value like ``````

[hako-mikan]

Yes. The values for BASE and Te are the same. This means that the results you tested should originally be the same. In fact, the results I tested were the same for the following three outcomes:

Generated using lbw for `<lora:NAME:0.5:1:lbw=1,1,1,1,1,1,1,1,1,1,1,1>`
Generated using lbw for `<lora:NAME:1:1:lbw=0.5,1,1,1,1,1,1,1,1,1,1,1>`
Generated by merged model using ratio `lora:NAME:1:0.5,1,1,1,1,1,1,1,1,1,1,1`

This could be due to differences in the environment you are using. The handling of LoRA can vary significantly depending on the version of the web-ui and its settings, etc.

[diodiogod]

Oh my... I've just tested on my forge installation and you are correct. <lora:NAME:1000:1:lbw=0,1,1,1,1,1,1,1,1,1,1,1> did not make noise.

BUT I kept testing and now I think it's about SDXL. On Sd15 you are correct <lora:NAME:99:1:lbw=0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1> wont generate noise. It acts as Te:0 But with SDXL loras <lora:SDXLloraNAME:99:1:lbw=0,1,1,1,1,1,1,1,1,1,1,1> will generate noise. Would you try it? It happens both on Forge and on my automatic1111.

Anyway, thanks for the response. You extension is probably the most needed and amazing of all SD ones I use!

[hako-mikan]

Ah, you were right. Looks like the thing you mentioned did happen with XL. When I checked it out, it seems like it hadn't dealt with the second text encoder that was added to XL. Seems like the problem got missed initially because the XL LoRA's Text Encoder wasn't trained at the start. It's been sorted now. Thanks.