Andy, I'm glad you mentioned the issue of gamut changes. Now that we're all generally working in "linear", this feels like the next thing that needs to be tackled. 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'd like to see the gamut change be part of the color transforms on Read/Write nodes since those are well-defined transforms that we can ship options to handle (aces, srgb, rec709, alexa wide gamut, etc). Neutralisations seem like something where you would need settings to be unique as much as per-plate and I'd rather keep that separate. I think we can handle all of this via OCIO. The transforms can be quite complex and there's support for external slope/offset/power/etc grades via .ccc color correction files.
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... I have to now say the fine print -- I'm not promising any of this by any time! -- but I am actively trying to figure out the right place for us to aim for so as always, opinions and uses cases describing situations you need this stuff to work for are very welcome. Matt On Wed, Jun 12, 2013 at 8:44 PM, Deke Kincaid <[email protected]> wrote: > Nathan: Most of what your asking for is covered by ocio and the > config.ocio file. Can you give examples of where this is lacking? I’m > just confused about why we need another layer on top of the existing ocio. > > > On Wed, Jun 12, 2013 at 12:08 PM, Nathan Rusch > <[email protected]>wrote: > >> 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). >> > > > > ----- > Deke Kincaid > Creative Specialist > The Foundry > Mobile: (310) 883 4313 > Tel: (310) 399 4555 - Fax: (310) 450 4516 > > The Foundry Visionmongers Ltd. > Registered in England and Wales No: 4642027 > > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > > -- Matt Plec Senior Product Designer The Foundry Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027
_______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
