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
