New SD window recovers the wrong lora on using reload parameters button

[derpina-ai]

Each time you open a new SD window, pressing blue arrow to recover last used parameters loads everything fine except the name of the lora used. In my case it loads the last lora available in the last subfolder of my lora folder every time, regardless of what lora I had actually used in the generation. The prompt is otherwise correct, only the name of lora loaded is wrong. Maybe has to do with having subfolders?

[ali0une]

Yes, i think this issue is related https://github.com/lllyasviel/stable-diffusion-webui-forge/issues/1342

Looks like Forge stopped calculating LoRAs hash they are all the same for me for about a week or so i would say.

[derpina-ai]

Yes seems correct, thank you for the reference.On 26 Aug 2024, at 18:51, i @. @.> wrote: Yes, i think this issue is related #1342 Looks like Forge stopped calculating LoRAs hash they are all the same for me for about a week or so i would say.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[ali0une]

OK ... i've checked my own trained LoRAs with Ai-Toolkit, all do have the same hash. Other LoRAs i downloaded from HF or Civitai all seem to have different hashes except those trained with Ai-Toolkit.

So i'm pretty sure this is not a Forge issue but a Ai-Toolkit issue related to this https://github.com/ostris/ai-toolkit/issues/130

So like explained in the issue i cloned https://github.com/Xypher7/lora-metadata-viewer and opened /whatever/lora-metadata-viewer/index.html in my Firefox, uploaded one of my trained LoRAs let's call it file_.safetensors (you can try here) and at the bottom in "Metadata Editor" i deleted the hash value for "sshs_model_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", so it looked like "sshs_model_hash": ""

Then clicked "Update and download" and got a file_edited.safetensors without the boring sha256sum.

Once you use the updated LoRA in Forge or A1111 the hash will be calculated and the problem should solve itself with future image generations.

For previously generated images i guess we would have to calculate the proper sha256sum (eg with the Linux command sha256sum) edit the Lora hashes in images metadatas with this sha256sum value, but i'm not sure how to do that right now and if it's safe regarding reproducibility of those edited images, it'll need some testing.

@lllyasviel, @DenOfEquity, @Panchovix, i think this issue and the related #1342 linked above one can be closed if you don't mind.

[diodiogod]

OK ... i've checked my own trained LoRAs with Ai-Toolkit, all do have the same hash. Other LoRAs i downloaded from HF or Civitai all seem to have different hashes except those trained with Ai-Toolkit.

So i'm pretty sure this is not a Forge issue but a Ai-Toolkit issue related to this ostris/ai-toolkit#130

So like explained in the issue i cloned https://github.com/Xypher7/lora-metadata-viewer and opened /whatever/lora-metadata-viewer/index.html in my Firefox, uploaded one of my trained LoRAs let's call it file_.safetensors (you can try here) and at the bottom in "Metadata Editor" i deleted the hash value for "sshs_model_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", so it looked like "sshs_model_hash": ""

Then clicked "Update and download" and got a file_edited.safetensors without the boring sha256sum.

Once you use the updated LoRA in Forge or A1111 the hash will be calculated and the problem should solve itself with future image generations.

For previously generated images i guess we would have to calculate the proper sha256sum (eg with the Linux command sha256sum) edit the Lora hashes in images metadatas with this sha256sum value, but i'm not sure how to do that right now and if it's safe regarding reproducibility of those edited images, it'll need some testing.

@lllyasviel, @DenOfEquity, @Panchovix, i think this issue and the related #1342 linked above one can be closed if you don't mind.

Also, please remember. Forge should calculate the file hash (if there is none in the header) without taking the metadata header in account. That is how Civitai does and make sense. Because If I go and change the header, let's say like @ali0une explained, and erased the "sshs_model_hash". The file hash calculated by any normal program like 7zip for example will be different because you modified the file. But the LoRA content is still the same. Civitai will still show the same Hash it calculated before and the generated images will have another third Hash on it because Forge will (I might be wrong here, I don't have the coding skills to read this in the code) calculate the file hash and it will be different from civitai, causing mismatch problems and the lora not being recognized for cross posting.

[ali0une]

once the LoRA metadata hash has been modified Forge calculate the hash, problem exists only when the ai-toolkit generated metadata same hash is present.

Maybe should check for this bogus LoRA hash metadata and if present ignore it and recalculate.

[derpina-ai]

The problem remains that you need a way to get a proper hash as soon as the lora is created, otherwise you are applying bandaids.

The issue I raised is all my loras aren’t loaded properly in Forge. Not all of them are trained with toolkit, i have a few dozen Loras.

Either the toolkit loras mess with Forge or this is more complex than I see atm.

[DenOfEquity]

I've not been able to replicate the problem you describe @derpina-ai . Starting from an empty prompt, the blue arrow loads from a file called params.txt in the webui directory which should be overwritten after each generation. First thing to do is to check that file and see if it has correctly saved the last-used prompt.

[derpina-ai]

You have to have loras loaded first of all in the params of the last generation. Params.txt are ok otherwise my files would not save generation params correctly in the png. The hashes are not read correctly. Please contribute to the discussion coherently, read the replies above from the others.On 27 Aug 2024, at 12:25, DenOfEquity @.***> wrote: I've not been able to replicate the problem you describe @derpina-ai . Starting from an empty prompt, the blue arrow loads from a file called params.txt in the webui directory which should be overwritten after each generation. First thing to do is to check that file and see if it has correctly saved the last-used prompt.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>