PNG frames vs FFV1 video for intermediate render

Support Compositing and Post Processing
1

I’ve got a big project I’m working on, and right now I’m using storing intermediate renders as a sequence of PNG frames. Predictably, this takes up quite a bit of space. I figured I’d try rendering the frames into a lossless video and see how the size compares.

The PNG frames take up 42GB.

The FFV1 video (H.264 container, AVI format) takes up 8GB

This particular render doesn’t use alpha, I’m rendering at the same resolution, and FFV1 is supposed to be lossless, so no information should be lost. At the same time, less than 25% of the original size seems to be too good to be true.

Does anyone have an explanation for this? Could bit-depth be a factor?

EDIT: I checked a few frames from the video and the frames using “subtract” blending, and there seems to be a slight difference. I’d still like to pinpoint what’s causing it, if anyone knows.

2

Did you check your .png settings? .png files can use either 8bpc or 24bpc color depth.
I don’t believe for even one second that there is any such thing as a lossless codec. The whole point of a codec is to be lossy so that file sizes are tamed. 32bpc openexr is not lossy. Everything else is.
Don’t wory about some codec being lossy anyway. As long as you don’t see artifacts in your render then it’s all good because there are no imaging devices available that are capable of displaying anywhere near the full, super high dynamic range of a 32bpc lossless image file. Even if there were…your eyes aren’t capable of seeing such amazing color depth.

3

My PNGs show as 64bit in Windows detail dialog, which I’m assuming is 16bpc X 4. I guess I must have exported as RGBA even though the frames don’t use alpha.

There absolutely are lossless video codecs. They’re often used for archival. Blender includes HuffYUV and FFV1, both of which are lossless.

A codec doesn’t have to be lossy to provide compression.

As for the argument that such a high color depth is unnecessary, that’s wrong too. It’s useful to have a high color depth when you’re doing editing that affects color even if you export to a lower bit depth later.

4

Why are you worried about how much disk space the file takes up unless it’s being written to DVD? Gigabytes are nothing and Terabytes are CHEAP:

5

I recently upgraded my GPU to a 1060 from a 650Ti, which required a new PSU and case as well. I also grabbed a bigger SSD, so my wallet hurts right now. Besides, if I could shrink my intermediate render sizes at no cost, why wouldn’t I?

This project specifically is only four minutes long, so in this case I had room for the PNGs. However a longer project, or one at a higher resolution, could easily become a problem.

6

I understand your desire to have the best of both worlds. It’s like having your cake and eating it too. We both know that life does not work that way though. I do not foresee there being any resolution to this problem either…unless or until we all have quantum computers at our fingertips. At that point we’ll all be watching interactive, hologram movies that are being rendered in real time. Untill then…

7

You can compare your png-s to half float exr files with different compression algorithms. PIZ lossless compression should be the smallest for most use cases but it depends on image content a bit. For very graphic content (large plain color areas) some form of ZIP could be more efficient.

PNG format has no advantage over half float (16bit) exrs and it is unlikely that you get better compression with png-s on rendered images.

Smaller file sizes in lossless video formats can be result of chroma subsampling, watch out for this as it can ruin your color detail.

8

So how is it lossless if color is lost?

9

How is 8bit png lossless if precision is lost?

There are different concepts of lossless, depending on which end you look at it. Float vs int is also a question of losing some precision and as blender internally works on 32bit floats one can argue that everything besides 32vit exr is lossy.

1 Like
10

For all “intermediate” purposes, I have only two recommendations: either OpenEXR, or, more likely MultiLayer OpenEXR.

Both of these formats are “expressly designed for the purpose” of “capturing render results.” These files are not meant to be viewed, and they’re also not meant to be small. Instead, they’re designed to be “loss-less,” and numerically accurate.

“OpenEXR” is the original format that was created by Industrial Light & Magic (ILM), and “MultiLayer” is an extension to that format (which was actually pioneered by … the Blender Foundation). “MultiLayer” allows multiple “layers” of related information to be captured in a single file. (It was a Very Good Idea™, and The Industry adopted it.)

In every rendering or image-manipulation stage within your pipeline, no matter how many stages there might be, except for the actual production of “delivery files” (such as .MOV), the most-important thing that you require is “loss-less accuracy.” You want the inputs to stage “n+1” to be "exactly ‘the outputs of stage n.’ Which is exactly what these file-formats, in particular, undertake to do.

I suggest that “the ‘final-final version’ of your movie” ought to be: a directory full of OpenEXR files, one per frame." All of these have been laboriously generated at a visual resolution equal-to or greater-than that of any deliverable which your project may require. (Likewise, each-and-every intermediate stage used the MultiLayer OpenEXR format.)

If you follow this strategy, you know that this “final version” has never yet been “compressed.” It has never yet been “encoded.” Data has never been “lost,” and you have “directories full of humongous(!) files” to prove it! :slight_smile:

From this, you can now (separately) generate “movie files” in whatever format and image-size may be required, knowing that each one of these is a separate reduction from “T-H-E Master.” Knowing, also, that this is the one-and-only stage in which “actual data” was encoded and/or thrown-away and/or compressed. (And, knowing that the original sources remain unchanged, so you’ve actually ‘lost’ nothing.)

And, “disk space b’damned…” These days, disk drives (and SSD drives) are cheap, gargantuan(!), and external.

1 Like
11

Video codecs are often labeled “visually LOSSLESS”. Note the little word at the start? Just because the human eye can’t see the discrepancy doesn’t mean it isn’t there. Biggest issue is noise where you don’t want it and can’t see it. No such thing as a free lunch.

12

I was just asking about you guys in another post. Thanks for the help guys. I was just gonna let em keep on drinking the kool-aid.

13

Some regard FFv1 as a suitable intermediate format for video production:

FFV1 useful as a preservation or intermediate video format.

Source: https://www.potaroo.net/ietf/html/ids-wg-cellar.html

I have done a test and rendered a sequence to FFv1 plus a single frame to EXR, I’ve calculated a difference and inspected that - there is a tiny residual noise-like difference.

I am not sure where it comes from - the FFv1 encoded file shows as 32bpp, and honestly for footage that’s not going to be very heavily processed, I wouldn’t mind this negligible difference, as it’s not perceptible, but I agree that the only truly lossless storage format is an EXR sequence.