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.
Seems bundling color transforms other than the standard 1D display encoding into Read and Write nodes might create more problems than it solves. 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. 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. 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. On Wed, Jun 5, 2013 at 3:45 PM, Andy Jones <[email protected]> wrote: > I've been trying to make a push to integrate OpenColorIO heavily into > our pipeline, and I'm at a bit of a crossroads with regard to how to > proceed dealing with Read and Write nodes in Nuke, and I'm curious > what people think, and what other studios are doing. My issue is that > the colorspaces in the Read/Write nodes only show luts from Nuke's > list of 1D luts. I'd like a single place to control my input > colorspaces. I see three options available: > > 1) Script the creation of a new set of Nuke 1D luts on startup, based > on the OCIO config. > > 2) Develop a fancy Read and Write node that incorporate an > OCIOColorspace node, either as a gizmo or some sort of C++ inheritance > thing that I'd rather not deal with. > > 3) Wait for Nuke to release a version that lets us opt into native > OCIO support for the Read and Write nodes. > > Option #3 seems particularly compelling, and seems like it should be > coming soon, given that Hiero already relies entirely on OCIO for its > colorspaces, and it would obviously behoove The Foundry to have their > color management consistent across their own apps. > > If option 3 is going to happen, but not right away, I suppose I'd opt > for option 1, just to avoid complexity and proprietary nodes that get > deprecated within the year. > > But if it's going to be a long time or maybe never happen, option 2 > would make sense. I'm kind of assuming some people have already done > option 2, so if anyone has tips from that angle, or could point me in > a good direction, I'd be curious to hear them. I know how to make a > basic gizmo, but getting all the nuanced behavior of a read and write > node seems harder. > > A big disadvantage of option 1 is that it's completely limited to 1D > luts. I could sort of live with that, as we're mostly working on > commercials, but it's far from ideal. Especially since gamut is the > thing that confuses people the most. > > Any thoughts? Thanks! > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > -- *B*l*a*k*e* S*l*o*a*n *S*o*f*t*w*a*r*e, *C*o*l*o*r* *D*i*g*i*t*a*l* D*o*m*a*i*n*
_______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
