[Feature Request]: Add Stable Diffusion 1.5 (SD1.5) Support

[DavidDragonsage]

Is there an existing issue for this?

• I have searched the existing issues and checked the recent builds/commits

What would your feature do?

Fooocus users at the official developer site and at Pure Fooocus have requested SD1.5 support over the years. In my opinion, the Refiner switch option does not produce satisfactory results. SD1.5 support could be introduced using Comfy mode, after we upgrade to the latest version of Comfy.

Proposed workflow

1. Complete the Comfy upgrade scheduled for FooocusPlus 1.1.0

2. Create or adapt Comfy coding to support SD1.5 models

3. Introduce at least one SD1.5 preset, using the realisticVisionV60B1_v51VAE model that is already included as a basic model in the distribution archive. This model is there to support IC-Light.

4. Create a custom Aspect Ratio table that is appropriate to SD1.5 models

Additional information

Before we actually started development on this issue - and before I initialized this item and wrote up our intended workflow - Irmagon (Thomas Goud) developed this solution, Simple presets for SD 1.5 and SDXL which actually works with FooocusPlus 0.9.6 Beta. It consists of a preset and a Comfy workflow.

I have been adapting the preset to my preferences as SD1.5_RealVis.json. I will also initialize a Comfy based SDXL preset as a demonstration.

The next step is to build a custom aspect ratio table.

[Irmagon]

The next step is to build a custom aspect ratio table.

It's not that simple.
The native resolution for SD1.5 is 512x512.
The maximum, at which there are no side effects (“даблёбла” aka “DoubleFucknFaces”) is 768x768.
And it is the width of the image that matters most.

And there are a couple of options here:
Either dynamically substitute another, previously prepared, vorkflow with an upscale node;
or change the json itself before passing it to the API, depending on the resolution.

I'm not an expert in Comfy, maybe there is a workflow where this effect is fixed. At least in A1111 there was a similar module.

[DavidDragonsage]

There is already built-in coding that allows for switching aspect ratio tables and this can be tied into the presets, so that should be a good start. Thank you for the tip about the width mattering more.

Another issue is the lack of LoRA support for SD1.5. LoRA use is very popular for users, and for some folks special LoRAs are a primary reason they want to continue with SD1.5. I am not sure if I want to take the time to deal with LoRAs at the moment, it is easy to become bogged down with distractions that can delay the release of the first production version.

[Irmagon]

There is already built-in coding that allows for switching aspect ratio

I've seen it done, and I can't say I liked it.
When you run the original F - ALL variables are ALWAYS populated in the following priority:
preset -> config.txt -> config.py

When hardcoding aspect ratios in python modules, the logic of filling variables in F+ is broken.
That's why, by the way, you can't set aspects in config.txt in F+.
It just doesn't work.

It doesn't affect the functionality of F+ in general, but...
Maybe you'll have a chance to fix it in the next releases )

LoRA support for SD1.5

As far as I understand it, this is not a priority in the release.
But there might not be anything particularly difficult about it:
make the transfer of LORA and their weights from the F+ interface to the prepared workflow SD1.5. Just like model and resolution parameters are passed. The code for this is quite simple.

[DavidDragonsage]

An aspect ratio table is a standard for the mainline Fooocus interface, and I am not going to abandon that at this point. I have pretty much finished it for SD1.5 and will run a few images through at each value to make sure that the theoretical numbers are working.

Yes, I am familiar with the hierarchy of the Fooocus pseudo-globals. Thank you for bringing this default aspect ratio problem to my attention. Unless you start with a preset that does not have an aspect ratio, the value in config.txt should be irrelevant. But I see that the Default preset is not overriding the value in config.py. Presets selected from the UI do override the aspect ratio, as one would expect. I will add this bug to the Issues list (#98).

Yes, SD1.5 LoRAs can wait until we are working on expanding Flux LoRA support, after the release comes out.

[DavidDragonsage]

*** SD1.5 Aspect Ratio Test ***
'288512', 9:16, 0.5625
'384640', 3:5, 0.6
'320512', 5:8, 0.625
'384576', 2:3, 0.67
'384512', 3:4, 0.75
'512640', 4:5, 0.8
'512512', 1:1, 1.0
'768768', 1:1, 1.0
'640512', 5:4, 1.25
'512384', 4:3, 1.33
'576384', 3:2, 1.5
'512320', 8:5, 1.6
'640384', 5:3, 1.67
'512288', 16:9, 1.78
'448192', 7:3, 2.3
'1024256' 4:1, 4 (Discarded because of subject mirroring with RealVis 6)

Tested with Realistic Vision 6 and Dreamshaper 8. All resolutions tested fine except for 1024*256 which has now been removed from the aspect ratio table.

All done!

[iwr-redmond]

@DavidDragonsage: LoRA support for these presets will require #10 to be completed.

[DavidDragonsage]

@iwr-redmond Yes I agree, that is what I was thinking of.