Could you possibly replace the read/write node with a gizmo? Inside the gizmo is a regular read set to raw data and a color transform. Promote all the fields and knobs to the gizmo, but change the colorspace knob for the one in the color transform. Turn on postage stamp and you're all set?
Cheers, Elias Ericsson Rydberg 6 jun 2013 kl. 04:01 skrev Andy Jones <[email protected]>: > 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
