> But I think we need to be careful to differentiate between > getting images into the same whitepoint/primaries color space because they > came from different sources -- like alexa wide gamut vs. an sRGB gamut image > from a DSLR -- and a neutralisation (as in a grade) that I'm doing to make > my plates match from shot to shot due to differences in shooting conditions, > lighting, etc on set.
I agree with you on principle, but I feel like there is already room to make those distinctions in OCIO itself. Whatever neutralization has been done needs to be done in a specific colorspace, so if we tried to decouple things, it would get confusing. I'd rather simply let OCIO fully take care of these things and leave it up to the studio to define how to differentiate them conceptually. In terms of the factory profile, it probably makes sense to leave context-sensitive neutralized colorspaces out entirely, since a studio making use of that probably needs to define their own OCIO structure anyway. I do think it would be good to have some more control over which colorspaces get exposed to certain nodes in Nuke. Right now, everything always shows up, but if we had control over this a studio would be able to keep neutralization out of their write nodes and confined to separate nodes, for example. A common example of where neutralization would be needed as an input colorspace would be on a precomp if work is being done on neutralized footage and written to disk that way. This is also a clear example of where it would be good to be able to remove the neutralized space on the read and write nodes if a studio is specifically trying to prevent that from happening. > I think this starts to get to what Nathan is saying about some sort of mini > dynamic color transform pipelines that you can assemble and apply anywhere. > I've had some thoughts about what the OCIO analog is to our current 1D LUTs. > I don't want to lose the convenience of being able to define a "LUT" on the > fly right in the project like we can now with the 1D LUTs. Maybe instead of > a curve editor the next gen UI for this is a little stack of operations from > a fixed list of what OCIO can do. Much of what we ship could be just 1D > shaper LUT + 3D LUT, but why couldn't you bung a matrix + power + 1D LUT > stack in on your root LUTs tab and pick it anywhere you get a "color space" > knob... This is a great idea, especially thinking about Nuke as an off-the-shelf application, and not just a studio tool. This stuff worries me a little, though, as I feel like ad-hoc colorspace transforms can already be implemented really well with nodes in Nuke, and OCIO already lets you do most of what I can imagine ever wanting to do via group transforms. So while I can see the benefit of doing something like defining an on-the-fly colorspace within a Nuke script, I worry it could lead to redundant functionality, or over-complicate the existing 1D luts setups. One idea would be to provide some sort of intuitive interface for designing OCIO colorspaces, and make use of the OCIO API to drop them into the OCIO profile, so that the existing OCIO integration can do all the heavy lifting, and the existing colorspace nodes can basically stay the way they are. Imagine, for example, something like the lut generator that can turn any node sequence into a 3D lut as a named colorspace in OCIO, and which does so on the fly when Nuke starts up. Or, an even smarter colorspace generator that can take any sequence of OCIO-savvy transform nodes and concatenate them as a group transform for another colorspace in OCIO. Basically, you'd need an OCIO Nuke node for each of the possible color transforms available in OCIO profile definitions, and some way to define the metadata for the colorspace. It would also be great if this same toolset could spit out text definitions (and whatever luts are needed) for proper OCIO definitions. I like the syntax well enough, but it's certainly too complicated for a lot of compositors. _______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
