sRGB → Linear

This is the opposite direction of its sibling: display-referred sRGB values in, scene-linear out. It's the node that answers "why does my AI render look wrong when I comp it over the plate?" - because an sRGB-encoded image has been through a gamma curve, and adding it to linear light as if the numbers were light over-brightens everything and blows out the midtones. The values are right; the encoding is wrong.

You reach for it in three situations:

• The render came from somewhere that isn't the EXR loader - a Save Image output you're re-ingesting, a plate out of another tool, a preview PNG, a VAE decode you want to treat as display-referred. Now you want linear values to hand into the comp.
• You need to do linear-domain work mid-graph. Exposure in stops, physically-plausible blending, a linear-light multiply - the math only means anything if the numbers are linear first.
• Your loader is set to keep linear but something upstream in the graph produced sRGB. Conversion should happen exactly where the encoding changes, and mid-graph is sometimes that place.

How it works

It's the exact sRGB EOTF inverted, per pixel in float32: below 0.04045 it's the linear segment (x / 12.92), above it's ((x + 0.055) / 1.055)^2.4. Same curve as Nuke's sRGB colorspace, so a roundtrip with Linear → sRGB lands back where you started.

The number to internalise: sRGB 0.46 is linear 0.18 - that's mid-grey, and it's a good sanity check on any conversion you're unsure about. Half-grey 0.5 in sRGB is about 0.214 linear, which is why a correctly converted image feels "dark" if you're looking at raw values in a viewer that doesn't transform them.

One asymmetry with the forward node worth knowing: this direction doesn't clamp. Values above 1 stay above 1 (the math just keeps going - 1.5 in sRGB comes out around 2.27 linear), so a superwhite in your source survives the conversion. The forward node, by contrast, clips to 0–1. Which means the two are only exact inverses while everything stays inside 0–1.

Like its sibling it's a CPU-side numpy round trip: fine at stills and short sequences, a sync point in a big video graph.

Wiring it

images in, IMAGE out, no widgets to set. The usual pipeline shape is anything sRGB → sRGB → Linear → Save Plate with the saver's colorspace left at keep linear, writing an EXR your comp can merge directly. The alternative is one node shorter: skip this and set Save Plate's own colorspace to sRGB -> linear - which is its default, and the reason you usually won't need this node in a straight Nuke roundtrip at all.

Where the standalone node earns its keep is when the linear data has to exist before other nodes, not just before the write.

Installing it

Same pack - ComfyUI Manager → search EXR Plate (Samuelsujan's EXR Plate) → Install, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Samuelsujan/comfyui-exr-plate
python -m pip install -r comfyui-exr-plate/requirements.txt   # opencv-python>=4.6, numpy

Restart and hard-refresh the browser. Both converters appear under Add Node → EXR Plate.

Where people get burned

• Stacking it with the saver's default. Save Plate already defaults to sRGB -> linear. Add this node in front without changing the saver and you've decoded twice - the plate gets contrast-crushed and dark, and it looks like the comp is broken.
• Applying it to already-linear data. Same failure in the other direction, and it's the most common one, because nothing in the graph tells you which convention a tensor is in. If a Preview Image after this node looks nearly black, you were probably already linear.
• Expecting recovery. This can't undo an 8-bit encode or a clamped HDR range; it only re-encodes what's in the tensor. If your highlights got clipped upstream, converting to linear doesn't bring them back.
• Not a full color-management solution. It's a fixed sRGB curve. In an OCIO/ACES-managed shot you still need the working space handled by the OCIO node packs - this gets your element into the right encoding, not the right config.