Depth Anything is not working in A1111 Version: v1.9.4 - Always errors with TypeError: Expected state_dict to be dict-like, got <class 'NoneType'>

[LVNSDCAPE]

Depth Anything is not working in A1111 Version: v1.9.4 - on my side.

It always errors with TypeError: Expected state_dict to be dict-like, got <class 'NoneType'

I reinstalled the Plugin two times and it is same behavior. Also used pip install -r requirements.txt and there have been no errors during this.

Final info here is: Successfully installed depth-anything-2024.1.22.0 timm-0.9.16

My Specs:

Windows 10 64 Bit RTX 3080

A1111: version: [v1.9.4]•  python: 3.10.9  •  torch: 2.1.2+cu121  •  xformers: 0.0.23.post1  •  gradio: 3.41.2  •

Settings to replicate

[DrSniffy]

Same here, and the tabs has also gone. I'm using Forge, and seems like an update Forge did killed Depth maybe...

[semjon00]

@DrSniffy Could you please provide the stacktrace (the full error message which is very long)?

[hutje]

I got the same problem. I use SD Forge and it seems the ui_tab_callback gives an error.

Details of the whole start up log

Python 3.10.6 (tags/v3.10.6:9c7b4bd, Aug 1 2022, 21:53:49) [MSC v.1932 64 bit (AMD64)] Version: f1.0.2v1.10.1-previous-151-gb7878058 Commit hash: b7878058f9144201924cf983e64d08174cf1756e Launching Web UI with arguments: Total VRAM 8188 MB, total RAM 97925 MB pytorch version: 2.1.2+cu121 Set vram state to: NORMAL_VRAM Device: cuda:0 NVIDIA GeForce RTX 4070 Laptop GPU : native Hint: your device supports --pin-shared-memory for potential speed improvements. Hint: your device supports --cuda-malloc for potential speed improvements. Hint: your device supports --cuda-stream for potential speed improvements. VAE dtype preferences: [torch.bfloat16, torch.float32] -> torch.bfloat16 CUDA Stream Activated: False Using pytorch cross attention Using pytorch attention for VAE ControlNet preprocessor location: C:\AI\SD Forge\webui_forge_cu121_torch21\webui\models\ControlNetPreprocessor WARNING:dinov2:xFormers not available WARNING:dinov2:xFormers not available Loading weights [15012c538f] from C:\AI\SD Forge\webui_forge_cu121_torch21\webui\models\Stable-diffusion\realisticVisionV51_v51VAE.safetensors StateDict Keys: {'unet': 686, 'vae': 248, 'text_encoder': 197, 'ignore': 0} 2024-08-06 17:15:26,043 - ControlNet - INFO - ControlNet UI callback registered. Working with z of shape (1, 4, 32, 32) = 4096 dimensions. *** Error executing callback ui_tabs_callback for C:\AI\SD Forge\webui_forge_cu121_torch21\webui\extensions\stable-diffusion-webui-depthmap-script\scripts\depthmap.py Traceback (most recent call last): File "C:\AI\SD Forge\webui_forge_cu121_torch21\webui\modules\script_callbacks.py", line 283, in ui_tabs_callback res += c.callback() or [] File "C:\AI\SD Forge\webui_forge_cu121_torch21\webui\extensions\stable-diffusion-webui-depthmap-script\scripts\depthmap.py", line 104, in script_callbacks.on_ui_tabs(lambda: [(common_ui.on_ui_tabs(), "Depth", "depthmap_interface")]) File "C:\AI\SD Forge\webui_forge_cu121_torch21\webui\extensions\stable-diffusion-webui-depthmap-script\src\common_ui.py", line 289, in on_ui_tabs inp += gr.File(label="Custom DepthMap", file_count="single", interactive=True, File "C:\AI\SD Forge\webui_forge_cu121_torch21\webui\modules\gradio_extensions.py", line 126, in __repaired_init__ original(self, *args, **fixed_kwargs) File "C:\AI\SD Forge\webui_forge_cu121_torch21\system\python\lib\site-packages\gradio\component_meta.py", line 163, in wrapper return fn(self, **kwargs) File "C:\AI\SD Forge\webui_forge_cu121_torch21\system\python\lib\site-packages\gradio\components\file.py", line 98, in __init__ raise ValueError( ValueError: Invalid value for parameter `type`: file. Please choose from one of: ['filepath', 'binary']

[graemeniedermayer]

We might want to make a separate branch for sd forge or newer versions.

Anywhere were we use gr.File the parameter type='file' needs to be replaced with type='binary' but I'm pretty sure this will be a breaking change for people using older versions.

Also we are going to need to do a bunch of other work to make the UI work. The API still works somehow haha.

flux only works on newer versions so I expect this to be a more common problem.

edit: So it seems that the model unload/reload needs edits, but that seems to be the only other issue.

[semjon00]

Uh-oh... This indeed may be a challenge. But I still hope that we could work around it without making a new branch. Basically we will need to detect which variant it is and then use the correct string. I feel that somehow it should be possible, but who knows.

[tommcg]

We might want to make a separate branch for sd forge or newer versions.

Anywhere were we use gr.File the parameter type='file' needs to be replaced with type='binary' but I'm pretty sure this will be a breaking change for people using older versions.

Also we are going to need to do a bunch of other work to make the UI work. The API still works somehow haha.

flux only works on newer versions so I expect this to be a more common problem.

edit: So it seems that the model unload/reload needs edits, but that seems to be the only other issue.

Is this a matter of a find and replace for the 'type' in order for it to work in Forge?

[graemeniedermayer]

I think it partially fixes some of the extension, but the memory loading and unloading also needs to be modified. If you have a bigger gpu you might just be able to remove the unloading part.

I'll try put some time into a forge branch this week.

[graemeniedermayer]

Okay after looking into this.

The main issue is forge is using Gradio 4.xx vs auto1111 using Gradio 3.xx.

So it's going to be a fairly significant rewrite of common_ui.py.

[graemeniedermayer]

Here's my first go at forge compatibility if you'd like to test out, https://github.com/thygate/stable-diffusion-webui-depthmap-script/pull/467

[tommcg]

Here's my first go at forge compatibility if you'd like to test out, #467

This is on the edge of my understanding of how to implement this update. Do I go to your commit and then copy and replace the 4 files over the default forge and extension scripts?

[semjon00]

@tommcg This is one way to fo it, yes, but this will be fixed in the next update, so another way would be to update the extension once it is out (soon).