Bing-su / adetailer

Auto detecting, masking and inpainting with detection model.
GNU Affero General Public License v3.0
4.09k stars 318 forks source link

[Feature Request]: Persistent Storage / Modify the Installation Path #706

Open GlamoramaAttack opened 1 week ago

GlamoramaAttack commented 1 week ago
          This looks normal to me. Please be more specific about what you are reporting as an issue.

Originally posted by @Bing-su in https://github.com/Bing-su/adetailer/issues/650#issuecomment-2206114584

For Automatic/Stable Diffusion WEBUI

[Feature Request]: Persistent Storage / Modify the Installation Path

Symlinked files in the CACHE can't be moved or copied (not on Windows, don't know about other OS). Users cannot influence the chosen Huggingsface path which is harddrive C: (except they edit a script?).

Most of the yolov-models are already in my ULTRALYTICS or GFPGAN folders. The extension scans the folders as set in the settings for Adetailer ("Extra paths to scan adetailer models separated by vertical bars") but it's only for use inside the Adetailer in WEBUI, yes it works, they can be used. But it should scan while launching WEBUI to avoid downloading again into the .CACHE folder on C: because WEBUI is supposed to work offline too. Other extensions accept that and download to where the WEBUI is located, to make it easier for portable use.

My wish?

An option for COMMANDLINE_ARGS, for example (using the ad_extra_models_dir name as called in config.json) to use it like that:

--ad-extra-models-dir "D:\stable-diffusion-webui\models\adetailer" --ad-extra-models-dir "D:\stable-diffusion-webui\models\ultralytics"

Or maybe direct everything coming from Yolov into a Yolov folder in the WEBUI?

In Stable Diffusion FORGE however I use the same settings for Adetailer (Extra paths) and it's recognizing them obviously on launch, if I delete the cache folder it doesn't reload the yolov files and Adetailer works correct.

But why? The main difference in my settings between those two WEBUIs is that in FORGE I can use a COMMANDLINE_ARGS called --text-encoder-dir (I use it to direct to the 'diffusers' folder, where FORGE stores Bingsu and some other content), that would be also an alternative to the current setup with HF's cache. If Automatic1111/SD-WEBUI could add --text-encoder-dir to the COMMANDLINE_ARGS options at start.

GlamoramaAttack commented 1 week ago

I have now changed the Windows system variables (for the environment), the lower part, added three entries HF_HOME, HUGGINGFACE_HUB_CACHE, TRANSFORMERS_CACHE with the value leading to my shared diffusers folder (D:\models\diffusers). That's a workaround to use my D: drive offline.

Bing-su commented 1 week ago

You can disable huggingface connections by setting the --ad-no-huggingface command line argument, or by setting the HF_HUB_OFFLINE environment variable to 1.

GlamoramaAttack commented 1 week ago

You can disable huggingface connections by setting the --ad-no-huggingface command line argument, or by setting the HF_HUB_OFFLINE environment variable to 1.

--ad-no-huggingface = I did that, but you can't use it offline because Automatic1111 doesn't start then, you can delete the command of course but it doesn't change the problem: the files should be stored persistent within a webui runtime. Adetailer and Controlnet are the only two extensions who try to plant something in that .cache folder specifically on C: in Automatic1111 - while in FORGE it accepts the path into the diffusers folder per commandline_args. The difference is Forge accepts --text-encoder-dir (for Controlnet's text encoder and Adetailer's Yolov files where the cached files can be found in the 'diffusers' folder) and Automatic1111 doesn't recognize 'text-encoder-dir' . So I hope you and Automatic1111 could change that (to my comfort :-) )

HF_HUB_OFFLINE = I'm not doing it because that would prevent other single downloads from HF. I put it instead in the environment variable to link it to my other harddrive, the one I use offline.