oldshensheep
commented
9 months ago This may not a bug, but a feature
this commit https://github.com/AUTOMATIC1111/stable-diffusion-webui/commit/39ec4f06ffb2c26e1298b2c5d80874dc3fd693ac adds a feature to calculate the hash256 of LoRA models, but it actually not the whole file hash256. This is the code used for hash LoRA, It will skip the metadata of model, that's why the hash is incorrect. https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/4afaaf8a020c1df457bcf7250cb1c7f609699fa7/modules/hashes.py#L66-L80
You may wonder why only the hash of LoRA models is incorrect, not other models. This is because the following code will check the filename whether is end with safetensors while other models will not.
https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/48fae7ccdc2fe2d2ba8e8cfcb17b56028734e570/extensions-builtin/Lora/network.py#L76-L79
if it is, then it will call this function, use_addnet_hash will be set to True and will call the function above.
https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/48fae7ccdc2fe2d2ba8e8cfcb17b56028734e570/modules/hashes.py#L38
workaround
If you change its extension name to something other than safetensors, the hash should be correct.
Is there an existing issue for this?
What happened?
When loading a new LoRA for the first time, the calculated sha256 is incorrect. I've noticed this with multiple LoRAs, the one I've recently used for testing is https://civitai.com/models/153676/colorize-slider-lora .
If a LoRA is loaded for the first time and used to generate an image, there will be a line in the console log reading:
Calculating sha256 for /home/USER/stable-diffusion-webui/models/Lora/LoRAs/colorize.safetensors: 65878cf46ab0d0e68f5658cc3f72869ca61c7b0f6b8a9f33333106d0712efeda.This hash value is incorrect. It does not match the sha256 listed on the civitai page. I also double checked on my own end by running
sha256sum colorize.safetensorsand I got the same hash listed in the civitai page.Checking the "edit metadata" option in the LoRA tab reveals the shortened hash as also being the incorrect first characters of the full hash.
At some point in the past, the correct hash used to be calculated, since I have older LoRAs with the right hash value. I get the wrong hash for every new LoRA I use now.
Steps to reproduce the problem
sha256sum filename. This hash should be different than the one in the webui console logs. If the LoRA was downloaded from civitai, check the hash against the sha256 hash on their website. The one you just generated should match the one on the site.What should have happened?
The hash that is saved in the "edit metadata" window and the hash that appears in the console log should match the hash I calculated myself, and the hash found on the civitai website.
Sysinfo
sysinfo-2023-10-24-17-17.txt
What browsers do you use to access the UI ?
Mozilla Firefox
Console logs
Additional information
I edited my console log and system information to replace all instances of my name with "USER". I also trimmed the console logs of multiple lines of normal image generation. I left one instance in just in case, and every line I removed more or less matched the example I left in.
If this behavior is actually a bug, I'd appreciate if someone could also tell me how to make my webui forget all the incorrect hashes it has saved. Or tell me what file I need to edit to change the hashes myself. It would likely be wherever the LoRA metadata is stored.