> Sure, that's a good point. I can see how exposing that much > fine-grained control as the default interface would be a serious > overload. However, for people who are interested in having finer-grained > control over conversions, having the *ability* to get at the complete set > of options in a way that provided reusable interfaces could be quite handy.
I agree 100%. My preference would be to just keep the nodes that are in there now for this -- Colorspace, etc. There's of course some room for improvement there, but I feel it's a pretty good way to approach the problem. Beyond that, I feel like what we'd want is some "building block" OCIO nodes that can be published together as GroupTransforms to define additional colorspaces through the GUI. Those nodes might re-implement some of the general purpose functionality of the existing color transforms, but I think they might actually be harder to use in practice, since they'd be representing granular operations like matrix transforms. They'd be really useful for testing OCIO definitions, though. What did you have in mind in terms of extending the ability to get at the complete set of options? On Fri, Jun 14, 2013 at 9:19 AM, Nathan Rusch <[email protected]> wrote: >> One of the great things about OCIO is that it avoids the pitfalls of >> having to manage an N-dimensional grid of possible colorspaces. > > > Sure, that's a good point. I can see how exposing that much fine-grained > control as the default interface would be a serious overload. However, for > people who are interested in having finer-grained control over conversions, > having the *ability* to get at the complete set of options in a way that > provided reusable interfaces could be quite handy. > > >>> I see nothing but cool ideas that are impractical in real world >>> solutions. > > > Well, the current LUT controls on the Read/Write nodes are impractical as > well, so I don't see the harm in brainstorming some other ideas. In any > pipeline where any sort of standardization or control is required, I can > almost guarantee that both nodes are in 'raw data' mode the whole time. > > > -Nathan > > > > 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 > > > _______________________________________________ > 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
