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 <[email protected]> > *Sent:* Wednesday, June 12, 2013 12:44 PM > *To:* Nuke plug-in development discussion<[email protected]> > *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
