> One more *shortish* note on converting to a baseline set of primaries on > ingest. We've learned from experience that converting everything ingested to > monitor display primaries (709/sRGB) -- though it allows plates to appear > "in-the-ballpark" without a 3D LUT -- is generally bad for preserving data: > going from a wider (camera) set of primaries to a narrower (display) set > causes some saturated values to go negative and clamp.
Yeah, that's a tricky one here, as our workflow is still more output-oriented than I'd like (another issue on the roadmap). Since we're doing mostly commercials, it's not a huge problem, but I'd rather have an abstracted notion of a working gamut and independent display gamuts. I'd ideally like to be rendering/comping in Wide gamut, storing image data in ACES, and viewing on a display-by-display basis. I think OpenColorIO is the best hope I have to get there but I need things to be simple until we have tools to manage the complexity. Sidenote: negative values are something that's handled pretty badly in general, especially since they're necessary in order to record true black without a floor bias. I think a pretty good workflow is to denoise and clamp, and re-apply the noise after compositing. I believe IIF talks about this a little bit, but I feel it's something our industry has a tendency to ignore. > Though you would still have this problem in a mixed camera environment > either way since all these new camera manufacturer specific log > colorspaces do not exist in the dpx metadata spec (rec709 is the > “newest” one). To get around this though, many places add the > colorspace to the file name so they can automate linearizing the > file properly in Nuke. Yes, I'm a big fan of this convention for the most part. Dpx headers are particularly untrustworthy when Flame is involved, as it seems to hard-code the value as rec709. This is actually an area where OCIO Read/Write would be great, as OpenColorIO integrates the ability to recognize a default colorspace based on filename. _______________________________________________ Nuke-dev mailing list Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
