OpenEXR file size

[marco]

When rendering an 1920x1080 animation with VRay 1.5 SP1 into an OpenEXR sequence, the OpenEXR file size is approx. 20 Mb per frame (RGBA and zip compression).
Some parts of this animation have to be rendered from videopost because of a glow effect.
File size of the frames rendered from videopost are 11Mb each, with exactly the same OpenEXR settings !

This behaviour can also be replicated with a simple scene with only a sphere.
filesize of exr 8.9 Mb, filesize of exr from videopost 4.6 Mb
Repeat this same test with the 3dsmax scanline renderer instead of VRay and filesizes are always the same...so it's definitely not caused by different EXR-settings in videopost.
Both OpenEXR files seem to be containing exactly the same information, no visual differences.

Someone any idea what could be causing this huge difference in file size when rendering with VRay from videopost ? (Vista x64, 3dsmax 9 SP2 x64 and Vray 1.5 SP1 x64)

[vlado]

This depends on the precision of the EXR file (32- or 16-bits) and the compression.

Best regards,
Vlado

[marco]

as I said before , all Open EXR settings are exactly the same....
So both OpenExr output settings in "normal" 3dsmax file-output dialog and in Videopost are: Zip(16 scanline blocks)-compression Format: Float 32 bit per channel RGBA premultiplied alpha.

what is the reason that -when rendered with VRay- the EXR filesize from 3dsmax-output is 20 Mb and exactly the same frame with exactly the same EXR-output settings from videopst is 11 Mb ?
With the default 3dsmax scanline renderer both filesizes are exactly the same. So again, EXR-output settings are equal.....

[simmsimaging]

I have noticed this too - I can save a file here as 32bit EXR and get a 140MB file, and then save it as a 32bit HDR and it's 29MB. If I just open and resave the same EXR file out of Photoshop it's down to 28MB. Does that imply that Photoshop is automatically cutting it down to 1/2 float, or is something else going on?

For now I have just gone back to using the HDR format.

b

[vlado]

Are you saving the file from the V-Ray VFB raw file settings (simply .exr instead of .vrimg) or through the regular options in the common tab of the render scene dialog?

If you are saving from the V-Ray VFB, then the 3ds Max OpenEXR settings are completely ignored, as V-Ray does the saving itself. They are considered if saving in the normal way though.

Also keep in mind that neither the scanline renderer nor Video post write full floating-point colors - everything is clamped to 1.0, and the color precision is always 16 bits, regardless of how the colors are finally stored in the .exr file.

Best regards,
Vlado

[simmsimaging]

I'm saving from the VFB, but using the "save" button once the render is done, and that gives me the same basic Max saving options. I don't use Video Post or the scanline renderer. Isn't .hdr format a full float format? The same image saved the same way out of the VFB as .hdr is considerably smaller.

b

[vlado]

HDR is a floating point format, but it has very limited precision. While it can store high-dynamic range colors, it has only 8 bits of precision for any color channel. 16-bit EXR files have 10 bits of precision (the other 6 are for the sign and the exponent), while 32-bit EXR files store the full floating point information from the renderer.

To demonstrate this, imagine that the red component of some pixel in the image is something like 2.546785 as calculated by the renderer. In the HDR file, it will be stored as something like 2.55. In a 16-bit EXR it will be stored as something like 2.547. The 32-bit EXR file will store the precise value.

So while all these formats can store floating-point colors in the sense that they are not limited to 0-1 (or 0-255), they do store the colors with different precision. That's why HDR and 16-bit EXR files are smaller than the full ones.

Best regards,
Vlado

[simmsimaging]

That explains a lot - thanks for taking the time.

b

[marco]

@Vlado: thank you for the in depth explanation of the EXR an HDR formats, but the question I started this thread with was related to the stage before.

-I'm saving from regular options in the common tab of the render scene dialog, not VFB.


Ignoring of what happens with the renderer information after saving to EXR or HDR, why is it that if I render a non-videopost VRay rendered frame to EXR filesize is 18 MB, and rendering the same frame videopost-rendered gives a filesize of 11MB ? (of course both with the same EXR-ouput settings)

please create an empty scene with just a sphere fully framed in it and render on for example 1920x1080 resolution to magnify filesize differences
1) renderer=VRay, render from the 3dsmax render scene dialog, set savefile/file output to EXR.
2) renderer=VRay, render from the 3dsmax videopost (create add scene-event and file output-event), file output= EXR
3) repeat step 1+2 with default 3dsmax scanline renderer

you'll notice that:
1)-EXR filesize from step 1 is aproxx. 9 Mb and rendertime= 8 sec !!
2)-EXR filesizes from step 2 is aproxx. 4 Mb and rendertime= 6 sec !!
3)-both EXR filesizes are exactly the same



Why is it that VRay creates a smaller filesize from videopost compared to normal renderscene output dialog ?

Why is there a rendertime difference of +/- 30% when rendering with VRay from videopost compared to rendering from the regular 3dsmax render-scene file ouput dialog ?

[vlado]

For the file sizes, it is what I explained already - the frame buffer produced by the scanline renderer and Video post is NOT a full floating-point frame buffer. Therefore a lot less information is stored in the EXR file in that case, and the default EXR compression is able to pick this up and produce a smaller file.

For the time difference I will check it out, but 2 seconds is not too indicative of anything, I'll have to make a test with a slower scene.

Best regards,
Vlado

[vlado]

So I did a few tests; like I guessed, the difference is entirely because of the different frame buffers. If you right-click on the frame buffer produced by a normal V-Ray rendering, you will see that it says "Type: 32 bits per channel Floating point (RGBA)" while the Video Post frame buffer says "Type: 64 bits (RGBA)".

Further on, if you set the OpenEXR options to write 16-bit (half-float) data, you'll get the exact same file sizes in the end - since the data from both the regular frame buffer and the video post one will be truncated to the same precision.

The time difference seems to be also because the floating-point frame buffer is a little slower than the regular one.

Best regards,
Vlado

[marco]

thank you Vlado for testing this !

So the regular framebuffer writes 32-bit float EXR and the videopost framebuffer writes 16-bit half-float EXR, hence the smaller filesize from videopost. correct ?

What worries me -and is the reason for starting this thread- is that when I render the main part of an animation with the regular framebuffer and small parts through the videopost framebuffer, I end up with an mixed float/half-float precision EXR-sequence...
Processing this EXR-sequence in AfterEffects (small exposure correction) does not reveal any visual differences, but I could imagine that applying filters like extreme exposure corrections could result in visual differences ?


I also expected the regular framebuffer and the videopost framebuffer to handle pixel data from the renderer exactly the same... Why is it that the videopost framebuffer only does 16-bit data, maybe something to do with the available videopost effects being not able to process full-float pixel data ?

Marco

[vlado]

They both write 32-bit float EXR, but there is a difference in the information that is written. For example, if the regular frame buffer writes something like the following sequence of numbers:
2.567832, 2.557832, 1.764329

but the video post buffer will write something like
2.568000, 2.558000, 1.764000

and the zip compression of the EXR file will be able to compress those zeroes to produce a smaller file size.

Normally 16-bit EXR files are enough for post-processing purposes, even at the extremes.

As for why the video post frame buffer is 16-bit, I don't know, but it has not been updated since a long time... probably reworking it to support floating-point frame buffers would have been too much work.

Best regards,
Vlado

[marco]

thank you for the explanation !

Marco