In the past we had experimented using quicktime files directly in Nuke as
source plates and it was pretty much a disaster, unstable, inexplicitly
slow at times, and checking around that was a concession from a number of
shops. Fine in theory, seemed OK, but inevitably when you got to a real
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
