Starter Pack

[fszontagh]

Implementation Options

There are two main approaches to implementing this feature:

1. Install-Time Deployment

• Windows: The NSIS installer can download files or zip archives and extract them into the default models folder.

  • This approach is relatively simple and requires minimal effort.

• Linux (.deb files): A meta-package could be created to download the models based on user preferences (though this is uncommon practice).

• Alternatively, a bash or PowerShell script could handle model downloads, making the process available post-installation as well.

2. Runtime Deployment (First-Run Wizard)

• A new Frame/Window could be introduced, triggered on the first startup.

• The user can select categories such as:

  • Realistic models
  • Anime models
  • SD1.x models
  • SDXL models (SDXL models requires VAE model to fix the image output)
  • VAE models

• The wizard could also allow users to modify default settings, such as:

  • Image format
  • Image quality/compression
  • Output folder
  • Output filename format
  • Other relevant settings

• This wizard could be re-triggered later via the settings window to redownload default models.

Related issue: #37

[iwr-redmond]

Long term, the first run wizard would be ideal, especially because you could look at offering different model options based on the system profile and adjust the default settings accordingly.

For now, however, and in the spirit of #37, I suggest an NSIS option for Windows and a separate Debian package modeled after the famous ttf-mscorefonts-installer (e.g. libstablediffusion-models-installer). These would allow users to decide whether they would like to download the models or not. The only code change to core would then be to support multiple model locations, a new hard-coded system-wide default and the per-user setting already present.

Suggested Linux system-wide location: /opt/libstablediffusion
Suggested Windows system-wide location: C:\ProgramData\StableDiffusionGUI

This approach would also make the Starter Pack usable for the server variant.

[iwr-redmond]

In terms of models:

• Stable Diffusion 1.5
  • Realistic Vision 6.0 B1 because it supports slightly more than 512x768 for its resolutions
  • Fluently LCM v4 for a general purpose model that can be used quickly on lower-end hardware
  • Detail Tweaker LoRA to enhance or diminish details in all types of images
  • LCM-LORA v1.5 to facilitate easier use of the LCM sampler
  • Inpainting ControlNet to facilitate easier inpainting across all models
  • Canny ControlNet and Depth ControlNet, providing the two most frequently used ControlNet types for image-based prompting
  • Wrong Negative Embedding to reduce generation errors (note: needs "in the style of <embedding_name>" in the negative prompt)
  • Bad Hands Negative Embedding v5 to improve hand generation
  • SD 1.5 Default VAE for checkpoints that don't have an internal VAE
• Stable Diffusion XL
  • Juggernaut v9 for vibrant generations, identified by @brayevalerien as particularly high-quality for photorealism
  • SDXL FaeTastic v24 for a general purpose SDXL all-rounder, identified by @DavidDragonsage as being particularly high quality
  • Juggernaut V9 Inpainting to facilitate realistic inpainting on SDXL
  • SDXL Refiner for both enhancing image quality and other types of inpainting tasks
  • SDXL FP16 VAE fix for obvious reasons
  • SDXL Film Photography Style LoRA, used in both Fooocus OG (v0.4) and Fooocus-Lite to enhance photorealism
  • SDXL FaeTastic Detail LoRA for improved FaeTastic generations
  • SDXL Wrong LoRA to improve the quality of generations (note: requires "wrong" in the negative prompt)
  • LCM-LoRA SDXL to facilitate easier use of the LCM sampler
  • SDXL Canny & Depth Control LoRAs, providing the equivalent of ControlNets for SDXL (note: may require testing for compatibility)
• FLUX
  • Flux Dev for obvious reasons
  • Flux Fill Dev for inpainting
  • Flux Anti-Blur LoRA as recently added to FooocusPlus by @DavidDragonsage
  • Flux Canny LoRA and Flux Depth LoRA, providing the equivalent of ControlNets for Flux (note: may require testing for compatibility)
  • Hyper-SD FLUX 8-Step LoRA for an LCM-like generation option for this architecture type (note: may require testing for compatibility)
  • Flux VAE and CLIP-L, required extra components for Flux as noted in the Nexa SDK code
• TODO: Not identified in this list
  • Embeddings for SD1.5 (very important!) and SDXL
  • Detail LoRAs for SD1.5 (very important!), SDXL, and Flux
• TODO: Research/decisions
  • Test the SDXL Inpaint LoRA by @nikgli as a potential replacement for Juggernaut v9 Inpainting checkpoint
  • Decide whether it would be better to include the FLUX Fill LoRA rather than the full checkpoint

If the two third-party inpainting LoRAs and the various Control LoRAs work as advertised, you would have feature parity across all three architectures despite the lack of ControlNet support in SDXL and Flux.

I'm jetlagged to the point of feeling like Bowser’s bone, but hopefully this makes sense!

[fszontagh]

I appreciate the list! 🍺

I've started working on the Runtime Deployment (First-Run Wizard) version - i think it's the easier approach.
Here's a quick screenshot of the initial UI:

I'm planning to add more checkboxes, such as "Select all realistic models", "Select all anime models", etc.

Additionally, I'll improve dependency checks -for example, if a user selects an SDXL model for download, the SDXL Fix VAE will be selected automatically.

One more thing: The model list could be fetched from a REST API, making it dynamic instead of hardcoded into the GUI.

This window will appear on the first run.

[iwr-redmond]

One more thing: The model list could be fetched from a REST API, making it dynamic instead of hardcoded into the GUI.

Great idea!

GPT4All does something similar, hosting a control file on GitHub that is used by its desktop application and Python SDK.

[iwr-redmond]

It looks like Control LoRAs will require stable-diffusion.cpp#692 to be merged first.