RTX 5090 compatibility guards for CompVis LDM variants

[PiercingXX]

Summary

This PR adds defensive compatibility guards so webui can run on modern RTX 5090 + torch nightly stacks when the underlying implementation differs from expected attributes/modules.

Changes

• Guard access in
• Guard access in
• Make import/usage optional in
• Add fallback no-op when is unavailable in
• Make MiDaS import optional and skip autodownload wrapper when unavailable in
• Update default stable diffusion repo/commit in to a reachable CompVis source
• Added detailed docs in

Validation

• Confirmed torch/cuda runtime sees
• Confirmed webui startup path reaches with smoke flags
• Confirmed HTTP endpoint returns web UI HTML

Notes

• Full image generation still requires checkpoint presence/download in runtime environment.

[Qodo-Free-For-OSS]

Hi, The AddMiDaS ImportError fallback is a no-op, but depth2img_image_conditioning() requires it to produce a 'midas_in' key, causing a KeyError when depth models are used without ldm.data.util.

Severity: action required | Category: correctness

How to fix: Disable depth2img when MiDaS missing

Agent prompt to fix - you can give this to your LLM of choice:

Issue description

Fallback AddMiDaS returns the sample unchanged, but depth2img_image_conditioning() expects AddMiDaS(...)({...}) to yield a dict containing midas_in.

Issue Context

This branch aims to avoid startup crashes, but the current fallback defers the failure to runtime and crashes with KeyError: 'midas_in' when depth conditioning runs.

Fix Focus Areas

• modules/processing.py[31-45]
• modules/processing.py[317-334]

Suggested change

Either:

• Make the fallback raise a clear error when called (explaining MiDaS is unavailable), and ensure depth2img is gated/disabled when AddMiDaS is unavailable; or
• Implement a fallback that actually produces midas_in (likely not feasible without MiDaS dependencies).

---

Found by Qodo code review. FYI, Qodo is free for open-source.