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
