> > 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.
Though you would still have this problem in a mixed camera environment either way since all these new camera manufacturer specific log colorspaces do not exist in the dpx metadata spec (rec709 is the “newest” one). To get around this though, many places add the colorspace to the file name so they can automate linearizing the file properly in Nuke. ----- Deke Kincaid Creative Specialist The Foundry Mobile: (310) 883 4313 Tel: (310) 399 4555 - Fax: (310) 450 4516 The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 On Wed, Jun 5, 2013 at 7:01 PM, Andy Jones <[email protected]> wrote: > 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 >
_______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
