Choose EXR when a CGI render still needs compositing, grading, AOVs or recoverable HDR highlights. Choose PNG for a finished web, presentation or transparent product image that must open easily in common software. Choose TIFF for a high-quality flattened still intended for retouching, layout or print production.
In many projects, the best answer is not a single format: retain an EXR as the production master, then create a color-managed PNG or TIFF for the client. This guide compares EXR vs PNG vs TIFF for CGI based on dynamic range, bit depth, color management, alpha handling, compression and software compatibility. It also explains how to configure a Houdini-based workflow without clipping highlights, losing AOVs or introducing transparency and color errors.
EXR vs PNG vs TIFF: the quick answer
| Requirement | Recommended format | Reason |
|---|---|---|
| Scene-linear production master | EXR | Preserves floating-point HDR data and can carry multiple render channels. |
| Compositing, grading or AOV handoff | EXR | Supports linear workflows, multilayer files and extensive channel data. |
| Transparent product image for web or presentation | PNG | Provides lossless RGBA delivery with broad software support. |
| Simple approval or review image | PNG | Easy to view when exported with the correct display transform. |
| High-quality retouching or layout handoff | TIFF | Well suited to high-bit-depth, flattened images in professional imaging software. |
| Print-oriented still | TIFF | Supports established profile-managed print and layout workflows. |
| Uncertain future revisions | EXR master plus PNG or TIFF export | Protects production data while giving the client an immediately usable file. |
The format is only one part of the specification. Resolution, color space, bit depth, RGB or RGBA output, alpha convention and required render passes should ideally be established in the product CGI brief before rendering begins.
Separate the production master from the client export
A production master preserves the image data that may be needed during post-production. It can contain scene-linear values, highlights brighter than display white, alpha, masks and render passes or AOVs. In a typical Houdini pipeline, this is an EXR written before a display transform is baked into the pixels.
A compositing file may be the same master or a more focused EXR containing only the beauty render and channels required by the compositor. Supplying every available AOV is rarely useful. Unnecessary channels increase storage and make the handoff harder to interpret.
A client-ready export is usually simpler: a flattened, display-referred image with an agreed resolution, color profile and background treatment. It should open correctly in the software used for review, layout, retouching or publication.
Keeping these files separate avoids destructive compromises. A PNG may be ideal for approval but unsuitable for recovering a clipped reflection. A layered EXR may preserve the complete render but be impractical in presentation software. The client can receive both when future editing and immediate usability matter.
What determines the right CGI render format?
Dynamic range and numeric type
Physically based renders can contain values above the range of a conventional display image. Bright reflections, light sources and specular highlights may all exceed display white before a view transform maps them to the monitor.
Floating-point EXR channels can retain those values for later exposure changes, glare and grading. Integer PNG and common integer TIFF exports have a bounded range. Once an HDR highlight has been clipped during conversion, increasing the export bit depth will not restore it.
Bit depth
Bit depth controls tonal precision, but the distinction between integer and floating-point data matters as much as the number itself:
- 8-bit integer is generally appropriate for finished display images but can reveal banding under significant tonal adjustment.
- 16-bit integer provides more precision for gradients, retouching and print-oriented work.
- 16-bit half-float is widely used for rendered EXR image channels because it combines HDR range with manageable storage.
- 32-bit full-float may be justified for particular technical passes, extreme values or workflows requiring additional precision, but it is not automatically necessary for every beauty render.
Higher precision cannot compensate for clipped lighting, inadequate sampling or an incorrect color conversion earlier in the pipeline.
Color space and display transforms
A scene-linear render is not ready for ordinary viewing merely because it has been saved successfully. The renderer produces linear values, while an OCIO view or display transform maps those values to a monitor. Confusing the two stages can make an image appear washed out, too dark or excessively contrasty.
For the production master, preserve the expected scene-linear data unless the pipeline specifies otherwise. For a client export, apply the agreed output transform and embed an appropriate ICC profile where the destination workflow expects one. Untagged files are more likely to display differently across applications.
Channels and AOVs
An opaque finished image needs RGB. A transparent product normally needs RGBA. Compositing may also require diffuse, specular, emission, depth, normal, motion-vector, cryptomatte or other utility channels.
EXR is designed for this kind of multichannel data. PNG is normally a simple RGB or RGBA delivery. TIFF can contain additional channels in some workflows, but support varies between applications and should not be assumed. A format cannot preserve a pass that was never enabled in the render settings.
Compression and compatibility
All three formats offer lossless compression options, but file size and application support vary. EXR also offers compression modes intended for different image and data types; some are lossless, while others trade a controlled amount of data for smaller files. Test the selected mode with representative beauty and utility channels.
Compatibility is a delivery requirement, not an afterthought. A technically rich file is still the wrong choice if the recipient’s software cannot decode its compression, float channels, layers, profile or alpha correctly.
When EXR is the right choice
OpenEXR is generally the strongest format while a render remains part of production. Use it when the image requires HDR retention, linear compositing, substantial grading, separate render passes or uncertain future revisions.
HDR and linear compositing
EXR commonly stores image channels as 16-bit half-float or 32-bit full-float values. This allows reflections and light sources to remain above display white rather than being clipped into an integer delivery range. A compositor can adjust exposure, generate glare and apply the viewing transform while the original highlight relationships remain available.
EXR does not create dynamic range that the render lacks. It preserves values generated by a correctly configured renderer and pipeline. If values were clipped, clamped or transformed before writing the EXR, the file extension cannot recover them.
Multilayer files and AOVs
A multilayer or multichannel EXR can keep the beauty image, lighting components, masks and utility data in one file. This reduces sequence-management overhead and helps maintain alignment between passes. However, channel naming and layer interpretation should be tested in the receiving compositor.
Use a flattened EXR when the recipient needs a high-quality scene-linear image for grading or simple compositing but not individual lighting passes. Use a layered EXR when another artist must isolate objects, rebuild components or make AOV-based adjustments.
EXR limitations
EXR is not a universally convenient client format. Presentation tools, browsers and lightweight asset managers may not support it, and an unconfigured viewer may display scene-linear pixels incorrectly. Multilayer files can also become large and difficult to navigate when they contain redundant AOVs.
Keep EXR as the master when its production capabilities are needed, but accompany it with a display-ready PNG or TIFF if the recipient also needs an easy reference image.
When PNG is the right choice
PNG is best for finished, display-ready images that need broad compatibility. Its lossless compression makes it suitable for product edges, gradients, text and graphics without the block artifacts associated with lossy delivery formats.
Web, presentation and approval images
An RGB PNG works well for a finished image with a solid background. An RGBA PNG is practical for an isolated product that will be placed over different backgrounds in a website, presentation, catalog or interface.
Eight-bit PNG is often sufficient for final viewing. A 16-bit PNG provides greater tonal precision where compatible software will perform modest additional editing. It remains an integer, display-oriented delivery, however; it is not equivalent to a scene-linear half-float EXR.
PNG limitations
PNG is not designed to carry a complete AOV workflow or general floating-point HDR render data. It should normally be exported after compositing, grading and the intended color transform have been completed.
A frequent mistake is writing scene-linear values directly to PNG and opening the result in a standard viewer. The image then looks wrong because the viewer expects display-referred values. Another is using a finished PNG as the only archive, leaving no HDR or render-pass data for revisions.
Use PNG when convenience and transparency matter more than production flexibility. Keep the EXR master whenever the image may need significant exposure changes, compositing or regrading.
When TIFF is the right choice
TIFF is well suited to high-quality flattened stills for retouching, page layout, archiving and print-oriented production. It is especially useful when the receiving application expects a conventional image file with greater tonal precision than a typical 8-bit delivery.
High-bit-depth retouching and print
A 16-bit TIFF gives a retoucher more room to adjust subtle product gradients, shadows and reflections than an 8-bit file. TIFF also supports profile-managed workflows commonly used by professional image-editing and layout applications.
For CGI, it is usually safer to complete rendering and scene-linear compositing first, then create the TIFF with the required output transform and profile. If a printer or layout team requests a specific color space or CMYK conversion, confirm who is responsible for that conversion rather than assuming that the renderer should produce it directly.
TIFF limitations
TIFF is a flexible container, which also means that support is inconsistent. Bit depth, floating-point data, alpha, extra channels, layers and compression options may be interpreted differently by different applications. Confirm the exact requested variant and test it in the recipient’s software.
A feature-rich TIFF should not be treated as a universal substitute for EXR. When the project needs scene-linear HDR values, multilayer AOVs or deep post-production, preserve an EXR master and use TIFF as a deliberate downstream export.
Alpha channels: straight, premultiplied and edge artifacts
Transparency problems often appear to be rendering defects but are actually interpretation errors. With straight or unassociated alpha, RGB remains independent of opacity. With premultiplied or associated alpha, RGB has already been multiplied by alpha.
EXR and TIFF workflows may use either convention, and the convention is not always communicated reliably by the file itself. PNG defines unassociated alpha in the file, although software may premultiply it internally while processing. Problems arise when an application applies the wrong interpretation or when RGB edge pixels have already been contaminated by a background color.
Typical symptoms include:
- Black fringes: RGB was multiplied by black and then treated as straight, or premultiplication was applied twice.
- Light fringes: straight RGB was interpreted as premultiplied, or edge pixels contain a light matte color.
- Colored halos: the product was rendered or matted against a colored background before being placed over another one.
- Broken glass or fine edges: partial coverage and transmission were flattened without preserving the intended RGB and alpha relationship.
Test every transparent export over both light and dark backgrounds. Record the alpha convention in the handoff notes, particularly for EXR and TIFF files, and confirm the compositor’s import settings rather than relying on automatic detection.
Building a reliable Houdini delivery workflow
The renderer’s output settings determine more than the filename extension. If you are building the shot in Karma, establish the render quality and image outputs together; Artivoxa’s guide to setting up Karma for product visualization covers the broader rendering configuration.
1. Define the delivery specification
Confirm the resolution, frame range, background, RGB or RGBA requirement, post-production scope, color space, bit depth and target software. Ask whether the recipient needs a finished image, editable render data or both.
2. Render the production master
For compositing-heavy work, write a scene-linear EXR with the required beauty channels and AOVs. Half-float is often appropriate for rendered image data, while full-float should be reserved for channels or value ranges that justify it.
Use a consistent OCIO configuration in Houdini, the renderer and the compositor. A display transform may be active in the viewer without being baked into the underlying EXR; verify this distinction rather than judging the file from its appearance in one application.
3. Composite and grade from the master
Perform exposure changes, AOV adjustments, background replacement and finishing while the HDR data remains available. Preserve the original master instead of flattening or overwriting the only production copy.
4. Create the client export
Apply the agreed output transform and export:
- PNG for web, presentations, approvals and straightforward transparent products.
- TIFF for high-quality retouching, layout or print-oriented delivery.
- EXR when the recipient genuinely needs scene-linear pixels, AOVs or compositing flexibility.
For projects covering a wider range of assets and outputs, the complete product visualization guide places this delivery stage within the broader production pipeline.
5. Validate outside the originating application
Open the actual export in the client’s target software whenever possible. Check:
- dimensions, crop, orientation and sequence numbering;
- highlight detail, shadows and gradient banding;
- color appearance under the expected profile or display transform;
- RGB versus RGBA channel count;
- transparent edges over light and dark backgrounds;
- the promised AOVs, layers or flattened structure;
- compression and file readability; and
- filename, version and folder conventions.
Common delivery failures and how to fix them
Clipped highlights
The render was converted to a bounded integer image or clamped too early. Return to the scene-linear EXR if it retains the original values, then apply exposure and the output transform before exporting again. If the source was already clipped, rerendering may be necessary.
Washed-out or overly dark output
The file is being interpreted in the wrong color space, or a view transform has been omitted or applied twice. Check the render space, OCIO configuration, export transform and embedded profile separately.
Banding in studio gradients
The image was reduced to insufficient precision before grading, or later processing amplified quantization. Work from a float EXR or higher-bit-depth intermediate and make the final bit-depth reduction only after the look is approved.
Black or bright transparency edges
The alpha convention is being interpreted incorrectly, premultiplication has been applied twice, or edge RGB contains a matte color. Correct the straight/premultiplied handling and inspect the RGB beneath transparent pixels.
Missing AOVs
The passes were not enabled, were excluded during export or were written to channels the receiving application does not expose as expected. Verify the renderer’s image planes and test the EXR channel structure before the final render.
The client cannot open the file
The application may not support the selected EXR compression, TIFF variant, bit depth or layer structure. Supply a simpler flattened export for immediate use, then agree on a compatible production format before resending editable data.
Recommended delivery by product-visualization scenario
| Scenario | Deliver | Retain internally |
|---|---|---|
| Compositing-heavy hero image | EXR with agreed AOVs, plus a viewing reference if needed | Original EXR master |
| Transparent product cutout | RGBA PNG for simple placement; TIFF if the retouching workflow requests it | EXR master with alpha |
| Web or presentation asset | Display-ready PNG | EXR master where future revisions are likely |
| Print or page-layout still | Profiled 16-bit TIFF when requested | Scene-linear EXR and final compositing project |
| Approval frame | Display-ready PNG | Current production render |
| Animation sequence for grading or compositing | Consistent EXR sequence | Render outputs and project files |
When the destination is uncertain, the safest delivery is usually an EXR production master accompanied by a correctly color-managed PNG or TIFF. Label each file clearly as a compositing master, transparent asset or final display export, and document its bit depth, color-space expectation, alpha convention and channel structure. That preserves the render’s production value without forcing the client to use a complex format for an otherwise simple image.