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
