Thanks for the reply Matt! I think my expectations for what an OCIO replacement of Nuke's lut color management are pretty straightforward. I would like to be able to use it as a drop-in replacement for all of Nuke's current colorspace operations. It seems like a good way to do this would be to keep the legacy functionality as-is, and add OCIO read and write nodes. Project and/or user preferences would then control which nodes get created through the menus and shortcuts.
The timing you're describing certainly could be worse. It sounds like it's coming soon enough that I wouldn't want to bother sinking significant development time into anything for a company our size. A few things that might be worth considering, if we're touching on the topic of read and write nodes. I think a lot of studios are making customizations/wrappers of those nodes, in order to tighter pipeline integration. I think it could be worthwhile to invest some time in making Read and Write nodes more "gizmo-friendly." For example, it's pretty unfortunate that we can't easily wrap up OCIO functionality with a gizmo in the current Nuke release, as that's exactly the sort of things I'd expect facilities to use gizmos for. I'm sure there are guys on this list who could elaborate more, but a things like knobs getting created on the fly are difficult to handle at a gizmo or group level. It would also be good to have ways to easily give a gizmo some of the special behaviors that read and write nodes have. For example, when a new read node is created, a browser pops up. In order to give users a seamless experience with a read node replacement, I'd want my gizmo to do the same thing. There are probably ways to do that now, but if there are, I think some examples in the documentation would be really helpful. Ideally we could do something like copy the callbacks from a node out to the parent group, or make use of prepackaged callback routines for read and write nodes (not unlike object inheritance, but for specific UI behaviors at a scripting level). When I did attempt to prototype an OCIO read gizmo, one thing I noticed is that Nuke does not currently "track" colorspace through the comp. So, for example, if I do a conversion from linear to a "neutralized" linear, there isn't a built-in way to keep track of this. Prior to OCIO, Nuke essentially assumed that all arriving rgb is in linear space, and changes in gamut were left to the user. It would be really cool if we could track the rgb colorspace of each channel via metadata, so that incoming data streams could be interpreted automatically by being set to "read metadata." So, if I were to use two "neutralizing" color transforms, metadata would prevent me from getting a double transform. I.e., the output colorspace would fully determine the output colorspace. Without this, I imagine users will quickly lose track of things like gamut changes that are a lot more subtle than, say, a change from log to lin. It would also provide a reliable way to do conversions in the viewer. So if my viewer lut expects non-neutralized data, it would always get converted correctly regardless of whether the incoming data is neutralized. In order to do this correctly, we probably need both an input and output colorspace on the OCIO read and write nodes. I'm now getting off topic, as I'd consider this a completely separate feature, but a way to read and write channels/AOVs as separate exr files would be great as well. For example, I've built gizmos/groups in the past that use simple search and replace functions to turn a single path into a series of paths for multiple read nodes. It would be _really_ nice to have some functionality like that built into Nuke. I know OpenEXR 2.0 is supposed to help with some of the issues associated with using multi-channel exr files, but I think there is still something to be said for creating the same functionality within a directory tree. - Andy _______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
