Estimate FOV
Estimate FOV — the node whose author says don't trust it
- image
- h_fov_deg
- pitch_deg
- status
- debug
Here's an honest take from the source code itself: the author marks this node DEPRECATED and says in the docstring to "prefer typing the FOV into the warp node by hand." Before you bounce, that's useful information, not a reason to skip the page. This is a vanishing-point FOV estimator that works far better than it has any right to - it's just that "estimate my camera's field of view from a single photo" is a genuinely underdetermined problem, and for most real photos typing the number is faster and more reliable.
Why it exists
The Warp node needs h_fov_deg and pitch_deg to place your photo on the 360° canvas, and photos don't store their focal length in any way a normal person can read. If you don't know your camera's spec, this node estimates both from the image's geometry - no EXIF needed.
How it works
It's classical computer vision, not ML. The node detects straight line segments (OpenCV LSD, with a Hough fallback), extracts up to three dominant vanishing points via a length-weighted RANSAC, then recovers focal length from an orthogonal pair of finite vanishing points using the standard right-angle constraint: f² = -(v1 − c)·(v2 − c) where c is the image center. Horizontal FOV follows as 2·atan(W/2f). Pitch is read from the vertical (zenith/nadir) vanishing point. When a scene is near one-point perspective - a path running straight away, all strong lines sharing a single vanishing point - focal length is mathematically underdetermined, and it says so in status and returns your fallback_fov instead of inventing a number. That honesty is worth a lot.
Inputs and outputs
Just two inputs: image and fallback_fov (default 65°, used when the geometry can't pin the focal length down - ~65 suits a 16:9 phone frame). Outputs are h_fov_deg, pitch_deg, a human-readable status string, and a debug overlay image showing the detected lines and the two vanishing-point circles it used.
Wire h_fov_deg and pitch_deg into the Warp node and you're off.
The catch, measured
The docstring reports real accuracy numbers from testing against pinhole views cut from known panos: pitch is reliable (mean error ~4°), but hFOV is only a starting estimate - mean error ~18°, and it can go badly wrong (a true 60° came back as 121°) when the orthogonal vanishing-point pair is poorly conditioned. So treat the estimate as a sanity check, not ground truth. Check the debug overlay, compare against your camera (phone main ~70, wide ~90), and if it looks off, just type the number into the warp.
Install
Same as every node in this pack - it's part of Mickmumpitz-Nodes, no models, deps are numpy/Pillow/opencv-python. ComfyUI Manager (search "Mickmumpitz") or:
cd ComfyUI/custom_nodes && git clone https://github.com/mickmumpitz/ComfyUI-Mickmumpitz-Nodes.git
Restart, and it's under Mickmumpitz/Panorama as "Estimate FOV". My take: keep it in a corner of the graph for when you're handed a photo with unknown provenance, and otherwise do what the author recommends - type your FOV and skip the estimation round trip.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| fallback_fov | FLOAT | 6520–170 | Returned when the geometry can't pin down the focal length (degenerate / 1-point perspective). ~65 suits a 16:9 phone frame. |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| h_fov_deg | FLOAT | — |
| pitch_deg | FLOAT | — |
| status | STRING | — |
| debug | IMAGE | — |