On Apr 4, 2014 8:07 AM, "Tom Wilshaw" <[email protected]> wrote: > This can be done on scene linear data with a 3x3 > matrix, but doing so causes those RGB values which fall outside the sRGB gamut > to be represented with one or more negative RGB values; this can present > problems for some compositing operations. The ACES gamut can accommodate all > current and likely future gamuts without negative values because it encompasses > the entire visible spectrum. Of course, sRGB material will fit into this gamut > fine, so no compatibility issues should arise due to using existing sRGB material.
Wider gamuts typically will require the clamp not only at the zero luminance level, but also at the upper end for values that have been pushed beyond their sRGB domain. > If Blender's native working space > were ACES, then we could create a camera to ACES matrix from the Macbeth chart, > mix with other sources including CG renders with a wide gamut, and output to > any display type we wanted. All of this without having to contend with > compositing images with negative RGB values. Or XYZ. As stated above, the conversion also yields invalid colors at the upper end as well I believe. The only method that I am aware of to maintain in-gamut values is to: A) Linearize your space's data. B) Scale data to 0-1.0 domain. C) Matrix convert to smaller gamut via the aforementioned RGB to XYZ and XYZ to RGB. D) Clip out of gamut beyond 0-1.0. E) Scale back to display referred values via the value from B. > ACES also allows the creation of > trim passes for output displays other that the mastering display without > additional colour correction by employing a variety of ODTs, although Blender's > current implementation addresses this. However, for wider gamut releases, such > as DCPs, it would be better to have a wider gamut source than sRGB, to better > fill the range of available colours and give a richer and more realistic > result. This is one instance where a move to ACES would be beneficial to > content created entirely within Blender, rather than live action footage only. The current issue with ACES is that there was an aesthetic / design choice baked in for film compatibility. This makes it difficult to ingest say, sRGB and get 1:1 back via the RRTs. Using only the primaries of course would deviate significantly from the ACES spec, and probably lead to problems. Within the Blender community, I believe this would cause more confusion than desired. Something like XYZ is likely a better fit, and is the 100% compatible with the existing Blender paradigm. Trim passes are already possible via OCIO. > Could a move to ACES be affected > simply by changing the OCIO config, or would the tools in the compositor > require some recalibration? You can obtain the official ACES OCIO configuration and use it. The issue is that there are still some critical areas that are not color managed, such as the color picker / wheel. Having the picker broken affects even sRGB of course, but is much more obvious in wider gamuts. Hopefully the picker / wheel and remaining pieces will be addressed in the near future. > We sent this to Ton, who advised us > to send it to the mailing list. He raised the point that "filmers prefer Aces, > but animation/vfx pipelines (apparently) not. Blender is about the latter". With specific attention to the Blender community, it remains problematic due to the RRTs. Many animators within the Blender community expect a perfect 1:1 input to output chain, and this is currently impossible without the aesthetic choices ACES had baked into the RRTs. ACES by default would cause legacy problems here. XYZ however, would not. > As an aside, but whilst discussing > colour management, we have often thought that the addition of an OCIO node > would be a very helpful feature. Some operations, such as green screen keying, > work better on low dynamic range sources, and the ability to convert to log. Agreed. In theory, this is already somewhat possible by crafting custom OCIO configs, but hopefully an OCIO node is soon on the horizon. It has been needed for a while. So the TL; DR is that ACES or any other space can be partially implemented in Blender by changing the OCIO configs. The downside is that some areas are still not color managed, with particular attention to the color wheel / picker, which requires a perceptual curve change (to log for example) and a primaries change. With respect, TJS _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
