Salut Hugo.
For playback, the B44 and B44A are much better suited. They are lossy,
but for most playback uses it will be negligible. Any other compression
method will be very taxing on the cpu for 4k content.
B44 and B44A, of course, are only a valid option if you want to export
your images just for playback.
Also, it pays to tweak the formats preferences in RV. We've had big
performance improvements from exr and dpx by playing with these
settings. The RV user manual gives some hints as to where to start.
www.openexr.com/TechnicalIntroduction.pdf
B44 (lossy)
Channels of type HALF are split into blocks of four by four pixels or 32
bytes. Each block is then packed into 14 bytes, reducing the data to 44
percent of their uncompressed size. When B44 compression is applied to
RGB images in combination with luminance/chroma encoding (see below),
the size of the compressed pixels is about 22 percent of the size of the
original RGB data. Channels of type UINT or FLOAT are not compressed.
Decoding is fast enough to allow real-time playback of B44-compressed
OpenEXR image sequences on commodity hardware.
The size of a B44-compressed file depends on the number of pixels in the
image, but not on the data in the pixels. All images with the same
resolution and the same set of channels have the same size. This can be
advantageous for systems that support real-time playback of image
sequences; the predictable file size makes it easier to allocate space
on storage media efficiently.
B44 compression is only supported for flat images.
B44A (lossy)
Like B44, except for blocks of four by four pixels where all pixels have
the same value, which are packed into 3 instead of 14 bytes. For images
with large uniform areas, B44A produces smaller files than B44 compression.
B44A compression is only supported for flat images.
Cheers!
F
On 2015-11-18 20:29, Hugo Léveillé wrote:
Hey guys
Anyone of you ever tested 4k 16 bits exr in zip1 in RV for realtime playback?
We have a 1.4 gigabytes raid so the bandwidth is not the problem as we need
something like 900MB.
But the CPU is dying when decompressing the frames. Before trying something
else, anyone successfully played this in realtime in RV?
DPX is playing fine be we are trying to make a exr only workflow.
Thanks
Sent from my iPhone_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
