Thanks for the input, Blake!
On Wed, Jun 5, 2013 at 4:55 PM, Blake Sloan<[email protected]> wrote:
Also working toward full OCIO color management. But a OCIO colorspace menu
in Read/Write nodes is not a high priority. We typically set 'colorspace' to
'raw data' on Nuke Read/Write nodes for non-linear formats and use explicit
color transformations in the script body.
This is a pretty good option 4. It just requires more of a training
component, which can sometimes be hard to stay on top of in our
commercials context -- for freelancers in particular. Definitely a
viable option, though.
Seems bundling color transforms other than the standard 1D display encoding
into Read and Write nodes might create more problems than it solves.
A big problem I have is that the standard encodings are not what I
want, and actually are doing more harm than good. The rec.709 curve,
in particular, is pretty irrelevant and causes a lot of confusion, as
almost nothing is encoded as scene-linear Rec.709. Rather, footage
from video tends to arrive as display-referred gamma 2.4.
If I decide to force people to use the OCIO colorspace nodes, I might
actually consider just doing away with the default luts entirely. I
just hate deviating too far from vanilla.
For Jpeg's to be correctly interpreted by browsers, consumer apps, they must
be sRGB encoded, which is the default for Read and Write nodes. We often
bake grades and viewer LUTs into jpeg dailies, but in our experience,
there's more danger overloading the Write node than just creating an
upstream color transformation.
Applying luts/looks explicitly with upstream nodes makes sense to me,
since looks aren't really encodings, and read/write operations should
be all about encodings, be they scene-referred or display-referred.
Lately, DPX plates from vendors are rarely Cineon log encoded (the default
DPX encoding by Nuke Read nodes). They tend to use the camera vendor's own
log encoding (Arri, SLog, etc). So the default is usually wrong. But giving
the artist control over which input transform to use is probably fraught.
This is where I feel OCIO would be really handy, as it would let us
define defaults based on roles, so as to have a fighting chance of
getting the right value without a cumbersome amount of communication.
For example, I could define a colorspace as "Main Camera (SLog2)" for
a show and compositors would know I had set the main camera to be
SLog2. That kind of streamlining tends to be a non-issue for a
feature, but can be handy for short projects.
Internally, VFX trafficks in scene-linear EXR with no transform applied on
read or write. So the major concerns are that that the CG uses the same
color primaries as the camera-captured media it is intended to integrate
with, and that the color rendering predicts the theater experience.
Yes, one thought I had was just to avoid the issue by insisting that
all media coming into the pipeline be pre-transcoded as linear exr.
Not the worst option, but it's more of a workaround than a solution.
It's a sad day when Nuke needs a workaround for dealing with color.
_______________________________________________
Nuke-dev mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
