Hey all,
I've been following this discussion with interest, and this seems like as
good a time as any to throw in a couple of wishlist items.
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).
I also like the idea of at least giving operators an idea of their current
colorspace/gamut information, but I would go one step further than a
metadata representation and possibly attach the data to the IopInfo class
(or maybe as another data structure that could be requested separately if
necessary). While I definitely wouldn't want any part of Nuke to require
this information to be accurate, the general idea of being able to set a
color transform's source to "from input" is very appealing (not to mention
being able to examine the information and make decisions on the fly).
Anyway, just wanted to toss those thoughts out there.
-Nathan
_______________________________________________
Nuke-dev mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
