cheald / sd-webui-loractl

An Automatic1111 extension for dynamically controlling the weights of LoRAs during image generation
MIT License
239 stars 10 forks source link

`hr=0` not being set correctly #5

Closed catboxanon closed 1 year ago

catboxanon commented 1 year ago

Thanks for the follow up in #4! However, I think that may have introduced a new issue (or perhaps I didn't notice before).

When I enter a LoRA as the following <lora:name:0.8@0.15,0@0.3:hr=0>, I would expect in the hires fix pass for it to remain at 0. That doesn't seem to be the case though, and it will instead reuse the schedule specified. tmpe1h7qwla

Indeed, adding a test for this results in a failure case.

self.assert_params("loraname:0.8@0.15,0@0.3:hr=0", {
                              'hrte': 0.0,
                              'hrunet': 0.0,
                              'te': [[0.8, 0.0], [0.15, 0.3]],
                              'unet': [[0.8, 0.0], [0.15, 0.3]]
                            })
AssertionError: {'unet': [[0.8, 0.0], [0.15, 0.3]], 'te': [[92 chars].3]]} != {'hrte': 0.0, 'hrunet': 0.0, 'te': [[0.8, 0[48 chars].3]]}
- {'hrte': [[0.8, 0.0], [0.15, 0.3]],
-  'hrunet': [[0.8, 0.0], [0.15, 0.3]],
+ {'hrte': 0.0,
+  'hrunet': 0.0,
   'te': [[0.8, 0.0], [0.15, 0.3]],
   'unet': [[0.8, 0.0], [0.15, 0.3]]}

A temporary workaround is to instead specify explicitly hr=0@0.

cheald commented 1 year ago

Whoops. Thanks for the test. I'll fix it up.

cheald commented 1 year ago

Indeed, I forgot that Python considers 0 to be falsey, so 0 or <default> results in the default being used. 8a42bf45b2ab5d2f43ceb774b9eceb5cdb0a94d7 fixes it up.