* fix GFPGAN to work with visibility < 1
* fix codeformer to work with visibility < 1
* try harder to download GFPGAN model. Old method would download only if there were no .pth models in the GFPGAN directory. If codeformer was used before GFPGAN, the supporting models are already downloaded into the GFPGAN directory.
The previous change to the width of the input box, to prevent overlap between long checkpoint names and the dropdown arrow, also reduced the clickable region of the input box - showing up the arrow as the purely visual element that it is.
This PR restores width, tweaks position of the arrow, and makes the arrow background solid to avoid inference with text. The latter two changes also affect the vae/te and diffusion in low bits menus.
* Fix Checkpoint Merging #1359,#1095
- checkpoint_list[] contains the CheckpointInfo.title which is "checkpointname.safetensor [hash]"
when a checkpoint is selected to be loaded during merge, we try to match it with just "checkpointname.safetensor".
-> use checkpoint_aliases[] which already contains the checkpoint key in all possible variants.
- replaced removed sd_models.read_state_dict() with sd_models.load_torch_file()
- replaced removed sd_vae.load_vae_dict() with sd_vae.load_torch_file()
- uncommented create_config() for now, since it calls a removed method: sd_models_config.find_checkpoint_config_near_filename()
* Follow up merge fix for #1359#1095
- read_state_dict() does nothing, replaced 2 occurrences with load_torch_file()
- now merging actually merges again
hide the color/opacity/softness controls on the inpaint tab:
consistent with high contrast option +
they don't offer real control anyway (color irrelevant to mask, mask gets thresholded to binary)
- 100% reproduce all author results and demos
- 0.3b/0.6b/1b/2b models, all pass 2GB VRAM (powered by Forge backend memory system
- perfect memory management for quick shifting between other spaces or forge main UI
1. fix several problems related to layerdiffuse not unloaded
2. fix several problems related to Fooocus inpaint
3. Slightly speed up on-the-fly LoRAs by precomputing them to computation dtype
... based on 3 evidences:
1. torch.Tensor.view on one big tensor is slightly faster than calling torch.Tensor.to on multiple small tensors.
2. but torch.Tensor.to with dtype change is significantly slower than torch.Tensor.view
3. “baking” model on GPU is significantly faster than computing on CPU when model load.
mainly influence inference of Q8_0, Q4_0/1/K and loading of all quants