Why you should not use PNG files for image sequences
A (Fairly) Comprehensive Compression Comparison between PNG, TIF, and EXR
TL;DR: If you’re working in 8 Bit use TIFs (if you need smaller files but can take the slight performance hit turn on LZW compression), if you’re working in 16 or 32 Bit use EXRs with Piz compression.
I’ve recently posted a little PSA on Twitter that ended up being shared quite a lot within the industry:
It said that you should never use the PNG image format if you’re working with image sequences. The reason being that it’s computationally expensive (read: slow) to compress and decompress it. What that means in the real world is, if you’re for example loading in an image sequence into Adobe After Effects it’ll take much longer until the bar above your timeline is green if you use PNGs instead of EXRs/TIFs. And if you’re done working on your project and you’re rendering it out as a PNG sequence (e.g. if you want a lossless version of your work before you convert it into h.264) you’ll wait much, much longer than if you rendered it as EXR/TIF files.
On that tweet I have also attached a screenshot from an article on provideocoalition.com that beautifully explains what you can do to make After Effects run a lot faster (and that you should definitely read, especially if you think you need to upgrade your PC because AE is sluggish)
https://www.provideocoalition.com/after-effects-performance-part-14-make-it-faster-for-free/
I mean what the f**k, 20 times longer? That’s crazy, right? Yes it is!
“Fair enough”, you might say, “but I’m not made out of money! I need to save disk space, TIFs and EXRs? They’re massive! And I also need my files to have transparency! I’ll rather have a coffee while the computer is doing all the hard work, but at least I don’t have to buy a new drive for every job!”
I’ve actually had quite a few people comment on the file size issue with TIF and EXR files and I can only assume they must’ve used them in another software in the past, that didn’t compress them by default. Because, as we’ll see, the file size is similar between the formats if you use them with the right compression settings (which are set by default in Cinema 4D and After Effects) and often even smaller.
Some people also commented on some more “exotic” compression variants of the EXR format that would yield even better results in terms of file size, but I have never used them so was curious to whether I could improve my workflow even more. However I ended up not including them in the final charts (you can find an explanation why below).
My workflow for the last couple of years consisted of Maxon Cinema 4D as my main 3D software and Adobe After Effects for compositing and 2D animation work. I don’t currently have access to a Blackmagic Fusion license otherwise I’d have looked into the behaviour there as well as I suspect there must be something wrong with how Adobe handles PNG files.
The Methodology
I’ve tried to make this as reproducable as possible and exclude all the factors that could mess with my results.
All files were written and read from the same Samsung 950 Pro NVMe with 2,500MB/s read and 1,500MB/s advertised write speeds to eliminate this hardware bottleneck as much as possible.
I shut down all other programs while performing the tests and had no backups running, so nothing would interfere from the software side either.
I’ve run the tests on an Intel i7 6900K with 3.2GHz running Windows 10 2004 and used C4D R23 and AE CC 2020.
As image compression’s efficiency is depending on the actual content of the image I have decided to run the same test on five different images. That way I’d get a good average for different scenarios.
- a typical 3D rendering from a never-finished project, it’s 32bit color and has a high dynamic range and contains a modest amount of noise
2. another 3D rendering, also 32bits, this time I’ve upped the exposure so there are lots of values outside the 8bit range (I am aware it looks like crap)
3. A picture I’ve taken with my phone, it’s an 8 bit image with some JPG artefacts
4. Something you’d see in a typical 2D animation (well minus the looking-shit part), mostly flat colors, no gradients, this should be easy to compress. This could probably go as my LinkedIn banner #hireme
5. A compression nightmare, a 32bit gradient with heavy noise applied. Show me what you’ve got!
I’ve put every image into the Luminance channel onto a Plane in Cinema 4D and rendered 21 frames in 1080p and 4k in different file types, I have also rendered sequences without saving them so I could subtract the raw render time to get the actual time spent just for saving of the files.
The reason for it being 21 frames is that I have entered 0–20 without thinking.
I have then imported the image sequences into After Effects and timed the time each of them needed to fill the green bar above the timeline upon pressing space using the stopwatch on my phone (I’ve rounded to 0.5 seconds which I hope is exact enough for that step)
This was technically the time it took to load in 20 frames as the first frame was already loaded into RAM as soon as I opened the sequence inside a composition.
After that I have exported the sequences out from AE using different compression methods (leaving out a couple that by that time I felt were obsolete or not supported by AE)
I have entered everything into a spreadsheet and calculated the averages across the 5 image sequences to get somewhat representative results for a wider variety of scenarios.
One thing to note is that I did the same test with the Pixar, B44a and DWAA compression within the EXR files but decided not to publish them as this might lead people to use them in a professional pipeline as they’re faster/smaller but they’re also lossy compressions (and therefore in my opinion not suitable for an intermediary file format and should under no circumstances be used for info passes as they’ll yield wrong results when using e.g. a Z-Pass to add DOF in post). I didn’t want someone to see the results out of context and assume these are the winners in this competition when they’re actually just a JPG in an EXR wrapper or “secretly” max out at 16 bits.
The Results
This is what you’ve come here for. The raw numbers. The bar charts you can show your friends.
First off exporting from Cinema 4D, PNG is already significantly slower to save. Hopefully you’re asleep or at lunch while this is happening but especially the export times for 32 bit images can accumulate quite quickly. Interesting to keep that in mind for when you’re deciding if you should order desert or not.
I feel this might be a good time to reiterate that these are just the times for saving 21 frames, I have subtracted the actual render time.
Now let’s load those files into After Effects, the difference in read speeds is by far not as significant, but 16 bit PNG is about 60% slower to load than my new personal favourite EXR Piz.
Writing out from After Effects is where the real issues start. PNGs are consistently up to 30x slower to write than the other file formats (don’t even think about going 8k). Only TIF LZW is also fairly slow to write but still miles away from PNGs. I skipped TIF Packed Bits as AE doesn’t seem to support that compression method.
And last but not least let’s compare the file sizes. For 8 bit images PNG keeps producing on average slightly smaller files but as soon as we go 16 bit the EXR compressions is actually smaller than the PNG while EXR Piz is also blazing fast to compress.
Conclusion
Do not use PNGs.
If not for yourself, then for the sake of everyone after you in the pipeline.
If you’re looking for ways to increase the speed of After Effects I cannot stress enough that you should read the article below, it’s brilliant covers a lot of ground (I am not affiliated with them in any way, even though I’ve mentioned this article 100 times)
Should you for whatever reason want to recreate my “benchmarks” you can download the C4D files here (just click “Render selected Takes to Picture Viewer”. The renders from C4D will take up about 130GB of disk space), I’m afraid you’ll have to do the manual labour inside AE yourself. But I’d be interested if the same issues persist on different processor architectures or super duper multi-threaded systems. If someone with a Threadripper or an Apple M1 wants to recreate the tests get in touch and I’ll be happy to append the findings to this article.
If you have any feedback or comments feel free to @ me on Twitter. You can also follow me there for more occasional workflow tips and some other CG related rambling.
Thank you very much for your attention, and happy rendering!
Bonus Content For Nerds 🤓
Enough about the fancy bar charts.
For those of you who aren’t interested in some mean averages but want to know how the individual images were compressed (nerds!) here are the true numbers from my spreadsheets, including those evil lossy formats. As you can see the “2D graphics” compressed significantly faster (even as a PNG), yet still a lot slower than the other formats. I’ll let you draw your own conclusions as I don’t know enough about the compression algorithms to give more than a guess about what causes it to be more efficient and what doesn’t.
