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
