Atlas Define Shot Cam 🎬

Atlas Camera's whole trick is that it solves a metric pinhole camera from a photo, then projects that photo onto derived geometry. But the camera that took the photo isn't necessarily the camera you want to deliver. AtlasDefineShotCam is the node that decides the delivery - it's the Nuke/Resolve "project format" setting, turned into a socket.

The confusion hits everyone once: you solve a 35mm-looking plate, orbit in the viewport, and the final export keeps inheriting the source photo's own lens and aspect. That's usually wrong. A matte-painting plate is often shot wider (or narrower) than the move you actually want to render, and the shot's aspect ratio is a creative decision, not an accident of the source. This node separates those two cameras so the render/export stops being chained to the photograph.

What it actually does

AtlasDefineShotCam takes no image and does no math on pixels. It emits a shot_cam (an ATLAS_SHOT_CAM), which is intrinsics-only: sensor size, focal length, and resolution. No position, no orientation - it's a format, not a camera placement. Think of it as "here's the lens and frame the final output is supposed to use."

You wire that shot_cam one of two ways. Into AtlasMergeGeometry (which attaches it onto the merged solve so it flows downstream), or directly into AtlasBlockoutViewport - a direct wire always wins over an inherited one. Either way, the viewport renders and the exports conform to your format, and the projection of the photo onto geometry is untouched. That separation is load-bearing in this pack: the photo keeps being projected through its own recovered camera, while the view and export run through your delivery camera.

The inputs that matter

There are only four, all optional, all floats/ints:

• sensor_width_mm (default 36) and sensor_height_mm (default 24). Together they define the output aspect ratio - 36×24 is 3:2, 36×20.25 is 16:9. If you know your delivery format, this is where it lives.
• focal_length_mm (default 35). The final render/export camera's lens. The tooltip hammers the point: it's independent of any individual source photo's solved lens.
• resolution (default 1920, step 8). The long-edge output resolution, up to 8192. The short edge follows the sensor aspect above - same long-edge convention as the viewport's own resolution widget.

That's it. One output, shot_cam, and you're done.

Why you'd bother

If you're rendering a 2K 16:9 plate for a client, you type 16:9 numbers once, wire it to the viewport, and every orbit, bake, and export comes out in that frame. Change your mind later and you edit one node instead of rebuilding the graph. It's a small node with an outsize effect on consistency, which is why it sits in the Atlas/05 Geometry menu - it's part of the scene's definition, not its rendering.

Install

Same as every Atlas node - it's in the atlas-camera pack:

cd <ComfyUI>/custom_nodes
git clone https://github.com/mikejamesvfx/atlas-camera.git

Restart ComfyUI, or grab it from ComfyUI Manager by searching "atlas-camera". This specific node needs zero dependencies - it's pure schema, part of the dependency-free core tier. If it registers, you're done.

Where people get tripped up

The one recurring confusion is expecting it to place a camera in space. It doesn't, and it can't - there's no position input. If what you actually want is a camera move, that's the viewport's Camera Path mode or the camera-path export nodes, not this. Treat shot_cam as the format definition and everything else slots in around it.

This is also a very new pack (registered mid-2026), so there are no battle-tested community war stories about this node yet - the docs and the changelog are the ground truth. The good news: its job is so simple that it mostly just works.