Linear workflows with DWAA lossy compression

A digital cloud icon displaying ones and zeros.

For the longest time I've been exporting renders in the EXR format using lossless compression. It always seemed a little weird to me to choose a professional-grade image format and then immediately throw detail away with lossy compression just to save some disk space. Storage is after all plentiful and affordable.

Octane and Redshift both default to using Zip deflate lossless compression when exporting a render and that suited me fine. When using the Zip format, file sizes are smaller than uncompressed images, and still remain fast to read back from apps such as DaVinci Resolve.

Recently though, the RNDR Network have been recommending DWA compression for EXR output when running jobs on their platform.

DreamWorks Animation contributed the DWA codec to the OpenEXR standard and it aims to preserve visual quality without visible compression artifacts. The key benefit of using this format is significantly reduced file size, something that's vital when downloading the often-extensive number of frames that make up any image sequence. On the whole choosing DWAA compression makes sense, I have not noticed any visible difference when comparing DWAA and Zip equivalents.

On the other hand, I have come across a few annoyances. macOS does not appear to be able to open or preview DWAA encoded images, even on the latest beta of Ventura. I have also stumbled across a really odd problem specifically relating to files created on the RNDR Network.

I often use FFmpeg to convert image sequences into videos for verification and easy sharing amongst teams. The standard command that usually works is:

ffmpeg -apply_trc iec61966_2_1 -pattern_type glob -i "*.exr" -c:v libx264 -pix_fmt yuv420p output.mp4

This however results in a black or corrupt video file when using any compressed file out of RNDR.

FFmpeg added DWAA support last year so perhaps there's a small bug in there. Either way ImageMagick can read the file and fix the issue, so this command reprocesses each frame in a folder.

magick mogrify -compress DWAA *.exr

Presumably this additional processing reduces image quality even further, but for quick validation I'm fine with that. Re-running the early FFMmpeg command outputs a viewable video, success!

I'll likely stick with this compressed format going forward, but the lack of previews in Finder is annoying.