Here’s the short version: EXR keeps every value your renderer calculated. PNG keeps only what fits on a normal screen. Anything brighter than pure white gets crushed flat. If you ever want to dim a blown-out sky, recover the sun reflection on a car, or change the look of the image after the render is done, EXR still has the data to work with. PNG threw it away the moment it saved.
The expensive mistake
If the only file you saved is a PNG, every pixel that was brighter than your monitor can show is already gone. Flattened to pure white before you ever open the compositor.
Live signal
Same highlight, two very different outcomes.
EXR is your working master. PNG is the delivery copy.
A delivery copy needs to look correct on a normal screen right now. The job is done. Once you’ve handed it off, you don’t need to touch it again.
A working master is the file you keep around because the job might not actually be done. You might want to change the grade, recover a highlight, swap the view transform, or pull a pass into the compositor. The working master has to still have the data to do any of that.
PNG works fine as a delivery copy. As a working master, it’s useless. It can’t store the values your renderer actually computed. Real light isn’t an RGB number capped at 255. The renderer calculates actual brightness, and a bright window or sun reflection can be many times what a screen calls “white.”
Why a PNG can look fine and still be the wrong file to keep
Here’s the trap: a PNG can look perfect on your monitor. If you’re delivering the still, posting it, or showing a client, you’d never know anything was missing.
The PNG breaks down the moment you stop looking at it and start working on it. Drop the exposure to recover a sky. Try a different view transform. Composite a diffuse pass back in. Suddenly the PNG isn’t a render anymore. It’s a photograph of one, with whatever look you had at save time baked in for good.
The print and the negative
Think of PNG as a print. Think of EXR as the negative or digital raw. Both can look good. Only one is still designed for heavy reinterpretation.
How a render actually becomes a file
There are three separate things happening when you save a Blender render, and they get tangled up all the time:
- The renderer computes light values. Those numbers can go way above what a monitor can display.
- The view transform (AgX, Filmic, Raw) decides how to map those numbers onto your screen so you can see the image.
- The file format you save to (PNG, EXR, JPEG, whatever) decides what to actually keep.
Three steps. Three different decisions.
Pipeline map
EXR keeps your options. PNG bakes them in.
Source data
What you renderedCycles produced light values. HDR. Values can go far above what your monitor can display.
EXR file
Working masterWhat's in the file
- Raw render numbers
- Full HDR range, values above 1.0 preserved
- View transform NOT applied yet
PNG file
Delivery copyWhat's in the file
- Pixels capped at the format ceiling (0-255 for 8-bit PNG)
- View transform baked into the pixels
- Raw HDR numbers gone
View transform
Applied at displayView transforms are like Instagram filters for your render. Same data, different look. Pick one.
AgX. Modern Blender default. Soft highlight rolloff and clean color in bright regions.
For the EXR
Viewing through AgX's soft highlight rolloff. The data underneath is intact, so you can swap to Filmic or Raw and the file stays the same.
For the PNG
Baked at AgX. The file just holds AgX-interpreted pixels. Applying a different transform later won't get you back to the raw render. It'd just recolor what's already baked.
AgX, Filmic, and Raw are ways of viewing the render. EXR and PNG are ways of storing it. PNG bakes the view transform into the file at save time. EXR keeps the raw render data, which means you can change the view transform later without re-rendering.
See what clipping looks like
“Blown out” can mean two different things. Either the highlight is bright but the data’s still there to pull back, or the file already threw it away. Big difference, depending on which one you’re looking at.
Interactive demo
Pull the exposure down and watch what survives.
The useful test is recovery. If the bright area comes back when you lower exposure, the data survived. If it stays flat white, it was clipped on save.
Scene-referred vs display-referred
These are the two terms that explain why EXR and PNG behave so differently.
Scene-referred values represent actual light. The renderer doesn’t care what your monitor can display. It just records how bright everything in the scene actually is. A diffuse white surface might be 1.0. A bright window catching sun might be 12.0. A direct sun reflection on chrome might be 80.0 or higher. There is no upper bound. Cycles produces scene-referred data.
Display-referred values represent what your monitor can show. A monitor maxes out at 1.0 (or 255 in 8-bit). Anything above that just clips to white. PNG stores display-referred pixels.
The view transform is the function that translates scene-referred numbers into display-referred pixels. AgX, Filmic, and Raw are all ways to do that translation.
EXR preserves the scene-referred data. PNG bakes in a display-referred copy.
The red marker is where PNG runs out of room. Everything to the right still exists in EXR.
Why this matters in compositing
Once you save as PNG, you’re not just losing highlight detail. You’re losing a kind of math.
In scene-referred space, doubling a value means doubling the light. Adding two passes together behaves the way light actually behaves. Exposure changes are predictable. Color corrections before the final view transform produce the result you’d expect.
Once the image has been baked into PNG, those operations don’t behave the same way anymore. You can still grade and adjust, but you’re working on already- flattened pixels, not on data that represents real light. That’s why comp on a baked image often feels fragile: small adjustments produce results that look “off” in ways that are hard to articulate but very obvious to look at.
Compositing math
Adding render passes only behaves like light in linear space.
Inputs
Correct linear path
Add the pass values first, then tone map for display.
Baked display path
Tone map each pass first, then add the already-baked values together.
The baked path is starting to drift. The error grows with brightness.
Knowledge check
Why can an EXR often recover highlight shape when you lower exposure, but a PNG cannot?
+
Why can an EXR often recover highlight shape when you lower exposure, but a PNG cannot?
+Because the EXR still stores light values above 1.0, while the PNG has already clipped those brighter values down to the same flat ceiling.
Try this in Blender
5 minRender the same frame once as PNG and once as EXR. In the compositor or another grading tool, lower the exposure hard. The EXR should reveal more shape and highlight detail. The PNG will stay flatter because the brightest values were already clipped away.
Half-float EXR is not “basically a 16-bit PNG”
The “16-bit” label fools people. Both formats can use 16 bits per channel. The similarity ends there.
PNG uses 16-bit integers in a fixed range (0 to 65535). Doubling the bit depth just gets you finer steps inside the same 0-to-1 ceiling. You still can’t store a value of 5.0.
Half-float EXR uses 16-bit floating-point numbers. Same number of bits, but they’re spent on a much wider range and concentrated where ordinary image values live. You can store values way above 1.0 and they don’t quietly clip on save.
Fixed integer steps. Everything above 1.0 is white. Banding shows up fast in gradients.
Floating-point. Huge highlight range with non-uniform precision, strongest where ordinary image values usually live, and no forced clipping.
Practical rule: Use half-float EXR for beauty and color work. Reach for full 32-bit float when you are storing data passes like Z-depth, motion vectors, or world position.
Quick format cheat sheet
The 30-second version:
| Format | Keeps values above 1.0? | Best use | Main limitation |
|---|---|---|---|
8-bit PNG / JPG | No | delivery, previews, approvals, social posts | clipped highlights and a baked display look |
16-bit PNG | No | smoother gradients in a display-ready still | still not HDR scene data |
16-bit Half EXR | Yes | most beauty renders, comp, animation masters | larger files than delivery formats |
32-bit Float EXR | Yes | data-heavy passes like Z-depth, position, or vectors | heavier than most beauty work needs |
For most Blender work, Half EXR is the default sweet spot. Full HDR range, half the storage of 32-bit float. Reach for full float only when you need the extra precision for data passes (depth, normals, motion vectors).
View transforms are interpretation, not source data
A lot of people first feel the value of EXR when they realize they are not stuck with one baked-in display look.
Filmic, AgX, or a custom LUT are ways of viewing the render data. They are not the raw render data itself. That separation is what makes late-stage look changes possible without a re-render.
Display transform
The file stays the same. The display interpretation changes.
Better highlight behavior and cleaner color in bright regions.
What to take from this
Two things stick:
- EXR keeps the render data. PNG bakes it into pixels.
- Save EXR when you might still need to grade, recover, or recomp the shot. Save PNG when you’re handing off the deliverable.
Use the wrong one and you’re throwing render time away. Use the right one and the rest sorts itself out.
For the actual settings to enable, see How do I set up EXR output in Blender?.