No module named 'kornia' in ComfyUI

If ComfyUI logs ModuleNotFoundError: No module named 'kornia', the server may still start, but some built-in extra nodes can fail to load.

In the tested portable repair lab, this error did not crash the whole server. Instead, it broke several built-in comfy_extras modules until kornia was installed in the same Python environment.

.\python_embeded\python.exe -s -m pip show kornia
.\python_embeded\python.exe -s -m pip install "kornia>=0.7.1"
.\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build

What The Real Log Looked Like

In the repaired lab, these built-in files failed to import:

Cannot import ...\ComfyUI\comfy_extras\nodes_post_processing.py module for custom nodes: No module named 'kornia'
Cannot import ...\ComfyUI\comfy_extras\nodes_canny.py module for custom nodes: No module named 'kornia'
Cannot import ...\ComfyUI\comfy_extras\nodes_morphology.py module for custom nodes: No module named 'kornia'

The important detail is the path. These were not third-party custom nodes. They were built-in extra nodes shipped with ComfyUI.

Quick Diagnosis

Step 1: Check The Local Requirement Line

In the tested lab, ComfyUI\requirements.txt included:

kornia>=0.7.1

Check your local file:

Get-Content ComfyUI\requirements.txt | Select-String "kornia"

That confirms whether current ComfyUI code expects it as a runtime package.

Step 2: Install In The Python That Launches ComfyUI

For Windows portable:

.\python_embeded\python.exe -s -m pip install "kornia>=0.7.1"

For a manual venv:

python -m pip install "kornia>=0.7.1"

In the lab, this also installed kornia_rs, which is normal.

Step 3: Restart And Verify The Failed Nodes Came Back

Relaunch ComfyUI and read the startup log again:

.\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build

In the tested lab:

• before kornia, /object_info reported 657 nodes
• after kornia, /object_info reported 685 nodes

The kornia-related IMPORT FAILED lines disappeared after that install.

Step 4: Understand Why This Is Not Always A Full Startup Failure

kornia problems often look scarier than they are because the log prints Cannot import ... module for custom nodes, even though the server may still start.

That means:

• the browser UI may open
• core generation may still work
• but built-in image-processing nodes can be unavailable

If your workflow needs canny, morphology, or post-processing nodes, it is still a real problem. It is just not the same class of blocker as sqlalchemy, torch, or comfyui-frontend-package.

What Not To Do

• do not assume kornia missing means the whole environment must be reinstalled
• do not install kornia into a random Python when ComfyUI runs elsewhere
• do not stop at "the server started" if your expected nodes are still missing
• do not mix plugin-specific fixes with core environment fixes until you confirm the built-in extras are restored

How Wonderful Launcher Helps

This is the kind of issue where node availability matters more than a single browser success check. Wonderful Launcher makes it easier to see whether the runtime is merely alive or whether the expected built-in node surface actually came back.

Related Guides

• ComfyUI 便携版依赖损坏后，按一个报错一个包修启动
• Plugin Missing Module Warning: When It Is Safe to Ignore
• ComfyUI Startup Failed
• ComfyUI Dependency Conflicts
• OpenGL dependencies not available in ComfyUI

Source References

• Windows portable repair lab, May 18, 2026: No module named 'kornia' blocked nodes_post_processing.py, nodes_canny.py, and nodes_morphology.py
• Same lab ComfyUI\requirements.txt: kornia>=0.7.1
• Same lab verification: /object_info node count rose from 657 to 685 after installing kornia