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.
Indeed, adding a test for this results in a failure case.
Indeed, I forgot that Python considers 0 to be falsey, so 0 or <default> results in the default being used. 8a42bf45b2ab5d2f43ceb774b9eceb5cdb0a94d7 fixes it up.
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![tmpe1h7qwla](https://github.com/cheald/sd-webui-loractl/assets/122327233/10df8d9b-939b-4af2-a7c1-70e7b954ba7c)
<lora:name:0.8@0.15,0@0.3:hr=0>
, I would expect in the hires fix pass for it to remain at0
. That doesn't seem to be the case though, and it will instead reuse the schedule specified.Indeed, adding a test for this results in a failure case.
A temporary workaround is to instead specify explicitly
hr=0@0
.