Merci Francois Thanks Nathan Will definitely have a look at this
On Fri, Nov 20, 2015, at 10:49, Francois Lord wrote: > 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 _______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
