I agree with wanting things to be simple. One of the great things about OCIO is that it avoids the pitfalls of having to manage an N-dimensional grid of possible colorspaces. I.e., instead of having every possible 1D encoding, along with every possible gamut, along with every possible white point, along with every possible color model, you can boil it all down to a single 1-dimensional list of colorspaces that regular users have a fighting chance of not completely borking.
The only problem with OCIO is that it's a pretty deep rabbit hole to go down if you're not used to setting up config files and don't happen to be the one guy at a company who knows about color. So the gist of what I'm in favor of is: 1) A drop-in OCIO-based replacement of the read and write nodes (i.e., the colorspaces come from OCIO, not the luts knob). 2) Colorspace info being tracked through the graph under the hood, giving users an optional "automatic" setting for input colorspaces of nodes doing transformations. In order to do this, you either need to be able to define what Nuke's global working space is, or add an output colorspace to the read node. To me, an output colorspace makes as much sense as anything, as I don't like the idea of changing it at the scene level and having my whole comp start doing something different. If we went down that road, ideally the creator of the OCIO profile could configure what Nuke will display as a possible output colorspace choice, and if there's only one choice, will hide or disable the knob. 3) As a much lower priority request, the ability to "design" and "inject" on-the-fly additional colorspaces into the OCIO config from Nuke. I don't need this for myself, but I think it would be a good feature for individual users outside of a studio. This would probably be relatively tucked away for power users, kind of like input processes and adding 1D luts. There shouldn't be any direct impact on users' workflow. All the stuff about read and write gizmos is really separate from OCIO integration. On Thu, Jun 13, 2013 at 2:47 PM, Nathan Dunsworth <[email protected]> wrote: > Pretty much this... > > I see nothing but cool ideas that are impractical in real world solutions. > > This topic reminds me of everyone that went nuts for a roto/paint all in one > swiss army knives and look what that resulted in. I still hit "x" and type > Bezier. > > > On Thu, Jun 13, 2013 at 2:13 PM, Jonathan Egstad <[email protected]> > wrote: >> >> fwiw as a general recommendation avoid embedding too much automatic color >> management stuff into nodes - Reads especially. >> >> Reads tend to get copy/pasted around and artists often forget to check the >> settings beyond making sure the file path's set, so if a Read has anything >> more complex than a simple colorspace pulldown (like grading or gamut >> controls for example) those controls can often cause far more trouble than >> they're worth. >> >> For example, the first nuke3.beta Read node back in 1999 had cineon >> black/gamma/white rgb controls and they were constantly tripping up artists >> who copy/pasted Reads around. Those rgb controls were ripped out in favor >> of the simple 1D lut selection and all grading/balancing done in separate >> nodes for clarity. >> >> How often have you dropped down a Colorspace node, set it up for one >> direction, added a Grade node, then copy/paste the previous Colorspace node >> and ended up having to reverse all its controls when simply creating a new >> Colorspace node would have been faster? >> >> Not saying I'm against more colorspace automation, just saying to tread >> carefully... >> >> -jonathan >> >> >> On Jun 13, 2013, at 12:29 PM, Nathan Rusch wrote: >> >> Hey Deke, >> >> I’m not so much suggesting there should be another layer on top of OCIO, >> but rather that it would be nice if Nuke’s support framework for >> color-management be expanded. >> >> The main thing I can see being beneficial here would be one or more new >> knob types that would be populated from the available colorspace/gamut >> transforms. This would function somewhat similarly to the Format knob, in >> that values added to the current Nuke environment would be available to any >> knob instances. These knobs would probably require one or more new data >> structures, both for backend storage and to provide entry point(s) to >> actually perform transforms. The knobs could then be used in place of the >> mix of hard-coded and dynamically-populated Enumeration knobs, etc. >> currently used across different types of Nuke nodes. >> >> In theory, all of this would provide an easy way for OCIO to integrate >> itself more deeply into Nuke’s color pipeline (as opposed to requiring a >> separate set of nodes), but continue to use its own libraries directly to >> perform conversions within the context of these new transform objects. In >> other words, rather than trying to supersede OCIO, it would be more of an >> effort to provide better unification within Nuke, as there is a pretty clear >> divide between OCIO and "the rest" of the color management functionality at >> the moment. I guess in a way, this is actually along the lines of bringing >> Nuke to be more in line with OCIO in more than just a conceptual way. >> >> Anyway, sorry that this is kind of a brain-dump, but I’m on a bit of a >> deadline at work. >> >> >> -Nathan >> >> >> From: Deke Kincaid >> Sent: Wednesday, June 12, 2013 12:44 PM >> To: Nuke plug-in development discussion >> Subject: Re: [Nuke-dev] OpenColorIO and Nuke's Read and Write nodes >> >> Nathan: Most of what your asking for is covered by ocio and the >> config.ocio file. Can you give examples of where this is lacking? I’m just >> confused about why we need another layer on top of the existing ocio. >> >> >> On Wed, Jun 12, 2013 at 12:08 PM, Nathan Rusch <[email protected]> >> wrote: >>> >>> While I think the current system for trying to intelligently apply file >>> transforms can be useful, it almost invariably becomes more prohibitive than >>> helpful beyond a certain scale. Based on Andy's general thoughts, I think it >>> would be great if color transforms in Nuke were built out and given a more >>> robust API, both at the NDK and Python levels. I'm imagining something that >>> either draws parallels with, or is even built on top of, the Op system, with >>> a set of available transforms built out dynamically and available in any >>> context (file transforms, color operators, viewers, etc). These would >>> obviously not be limited to OCIO/Nuke-native transforms, and would make it >>> possible for facilities to remove or replace certain transforms in all >>> contexts (dropping in a custom Alexa curve, for example). >> >> >> >> >> ----- >> 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 >> >> ________________________________ >> _______________________________________________ >> 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 >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
