Atlas Output Desk 🎛

The Atlas viewport (AtlasBlockoutViewport) is the most button-dense node in the pack - primitives, project mode, camera path authoring, render passes, lights, exposure, the lot. When you're actively orbiting and scrubbing, all of that is great. When you want a clean, perspective-render-only node in the middle of your graph, it's a wall of chrome. AtlasViewportControls - the one ComfyUI labels Atlas Output Desk 🎛 - is the pack's answer: pull every one of those controls off the viewport node and park them in a node of their own, and use the spare real estate to carry a color pipeline description alongside.

Think of it as the editor's desk next to the monitor. The viewport stays a screen; this node holds the knobs.

How it works

Two jobs, two outputs, zero heavy lifting. The controls output (type ATLAS_VIEWPORT_LINK) carries no data at all - the docs are blunt about that: it's a plumbing link. When you wire it into AtlasBlockoutViewport's controls input, the viewport's entire toolbar and panels relocate into this node, leaving the viewport perspective-render-only. There's no Python computation behind it; it's a noop() that returns a placeholder so the graph has something to pass around.

The second job is the genuinely useful one. The output_profile output builds an ATLAS_OUTPUT_PROFILE - an OCIO-flavoured description of how this project's color is meant to flow: working space, output space, display, view, and a trim. The Atlas pack is aggressively color-managed (plates tracked in ACEScg, float-safe EXR handoffs), and this node is where you declare that pipeline in one place. Wire the profile into the exporters - AtlasExportNuke takes it directly - and your Nuke/Maya handoff carries the color intent instead of you re-typing "ACEScg" in three different places.

The inputs that matter

None are required - the node is happy with pure defaults, which are sensible ACES values. The ones a beginner actually touches:

• working_colorspace (default ACEScg) and output_colorspace (default ACES - ACEScg) - what your plate lives in and what you hand off in. Leave them unless your project is on a different standard.
• display / view (defaults sRGB - Display, ACES 2.0 SDR-video) - describe the monitor you're grading on. These are metadata; they describe the intended transform, they don't apply one.
• display_trim (default 1.0, range 0–4) - a display trim value the profile records.
• config_label and config_path - a human-readable label and, if you're pointing at a real OCIO config, its path.

One honest caveat from the author's own docs: the ComfyUI browser preview is a display-inferred proxy. Final color fidelity belongs to OCIO Write, Nuke, Maya, or Resolve - this node describes the target, it doesn't magically make the little preview grade-true.

Install & gotchas

The pack installs like any other custom node:

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

Then restart ComfyUI. This node needs nothing extra - no [vision], no [neural], no GPU. It's a pure metadata and UI-move node, so it works even in the dependency-free core tier of the pack.

The one thing that confuses people: a node with no required inputs that you wire a control link into. If you just drop it in and expect something to appear, nothing does - that's correct. Connect controls to a viewport's controls input, or output_profile to an exporter, and only then does it earn its keep. And since it's a companion node, grabbing it without an AtlasBlockoutViewport in the graph is like buying a TV remote with no TV.