I would consider EXR ZIPS vs DPX the EXR will be smaller and still be same
fijle quality as DPX.
Randy S. Little
http://www.rslittle.com/
http://www.imdb.com/name/nm2325729/
On Thu, Sep 18, 2014 at 8:26 PM, Deke Kincaid d...@thefoundry.co.uk wrote:
We updated the the newest Red SDK in Nuke
Nuke can read R3D but I find them to be much slower to work with than
just regular old dpx's or exr's. If you have a Hiero - Nuke
workflow, I'd recommend just making dpx files from your R3D's.
On Thu, Sep 18, 2014 at 6:01 PM, John Coldrick john.coldr...@gmail.com wrote:
In the past we had
R3D's are going to be slow because they need to be debayered. You're also
looking at more room for error by exposing all of the debayer settings to the
artist, and more room for instability by getting third-party libraries involved.
I would stick with DPXs.
-Nathan
From: John Coldrick
Cool, thanks for the feedback guys. The speed hit seems like a no-fly...
Cheers,
J.C.
On Thu, Sep 18, 2014 at 6:41 PM, Nathan Rusch nathan_ru...@hotmail.com
wrote:
R3D's are going to be slow because they need to be debayered. You're
also looking at more room for error by exposing all of
Too much room for error when reading R3d in directly, not to mention the
speed hit due to de-bayering and full resolution as mentioned before.
I totally agree that transcoding everything to dpx files is the way to
go. This will give you:
1. full control over how the transcode happens across
We updated the the newest Red SDK in Nuke 8.0v6, so there shouldn't be any
problems with reading newer camera files even if it is just for
conversion. Also the newest Red SDK adds the ability for us to GPU
debayer. We may or may not have time to get this into Nuke 9.0v1 but we
will see. This