Atlas Conditioning EXR 💾

Here's a sentence that tells you whether you need this node: metric depth in metres and optical flow in pixels both leave the range [0, 1], and every 8-bit or half-float hop in between quietly destroys them.

Atlas Conditioning EXR 💾 takes an ATLAS_CONDITIONING bundle and writes it out as float32 EXR sequences with a sidecar manifest. That's the whole job, and the reason it's a separate node from AtlasConditioningBundle is a good one: writing to disk is a side effect that must be opted into, and OpenImageIO is optional while the sockets aren't. If OIIO isn't installed, the node skips rather than failing your graph - nice, but see the traps.

Why float32 and not half

The pack is unusually blunt about this: bit_depth="float" is mandatory and never half. Half's mantissa step is ample for imagery and exactly wrong for data - it quantises tens-of-metres depth to decimetres and loses the sub-pixel flow precision the measurement actually has. Same reasoning behind the split into one EXR per pass per frame rather than one fat multichannel file: the writer names channels positionally, so you'd be inferring which channel is which. Instead the naming is recorded in the manifest - Z, N.*, P.*, FWD.*, BWD.*, CLASS - and a reader never has to guess.

There's no colour conversion anywhere in this path. These are numbers, not colour. That's the same line every compositing doc draws: decode to scene-linear and carry float when output has to survive as an element in a colour-managed shot, and don't colour-manage your measurement data.

The manifest also carries per-frame K and view matrices, and it states plainly that NaN marks a hole in every metric pass. That's the convention you want: a hole that reads as 0.0 metres will silently drag every average you compute downstream.

Inputs and outputs

Required: bundle (from AtlasConditioningBundle) and directory - default atlas_exports/conditioning.

Optional: basename (atlas), write_flow (true), write_position (true), write_normals (true).

Outputs: directory (STRING) and report (STRING, JSON). Output node, so it fires on queue.

Install

Clone and restart:

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

Or ComfyUI Manager → search atlas-camera (ComfyUI Registry). Restart.

If you cloned, that's the end of it - the core nodes need no pip step. If you want this specific node to actually write something, you need OpenImageIO: the [oiio] extra (pip install -e ".[oiio]" from the repo root), or the equivalent install into ComfyUI's Python. The pack reaches for OIIO rather than OpenCV's EXR support on purpose, and the INSTALL notes are worth reading on that point - the opencv-python 5.x wheels don't build the OpenEXR codec at all (cv2.getBuildInformation() reports OpenEXR: NO), so OPENCV_IO_ENABLE_OPENEXR=1 was never going to help. OIIO ships wheels everywhere and carries its own ACES config, so there's nothing to configure.

For the upstream half you'll want a solve with derived projection geometry and a camera path, so numpy is the floor and the [neural] extras are optional.

Traps

The path semantics get people. directory is relative to the ComfyUI process cwd unless it's absolute - not relative to ComfyUI's output/ folder, the way a SaveImage prefix is. If your EXRs aren't where you expected, that's why, and it's also why an absolute path is worth typing on a production job.

Then the silent one: a missing OpenImageIO means this node skips with a message instead of erroring. You'll see a report line and no files, and the graph will look like it succeeded. If the directory is empty, check the report before you check anything else.

And don't feed these EXRs to a colour-managed node expecting plate colour. Depth, flow, position and class maps are data channels; the CLASS map is the ghost classification from AtlasConditioningBundle's ghost output, which is what tells a downstream fill tool which pixels it's allowed to invent.