Aces

[vlado]

See here for some discussion of using ACES in production enviroments:
https://zenodo.org/record/345624#.WMFWy_KWlUV

Highly saturated blue or magenta emitters such as LED, Neon, and other spectrally sharp light sources can create artifacts when processed through ACES [Mor16]. Scott Dyer (2016) has provided a standalone workaround [Dye16], but a built-in comprehensive solution is preferable especially since the current solution affects the image globally. In the meantime, the current interim workaround could be officially documented and shipped as an LMT with the CTL codebase due to its high prevalence. Gamut compression or mapping based on IPT or ICtCp color spaces would be a fruitful research axes to overcome these issues. Additionally, narrow band light sources present issues in post-production and DI, when the grade is performed in a space other than ACES AP0 itself. When converting an image to ACEScc or ACEScct for grading, or shaping linear data into a display LUT, negative values may result from the highly saturated colors outside the AP1 primaries. Software or pipelines that are intolerant of negative numbers may clamp them causing real image detail to be lost. It becomes visually apparent when an image is transformed back to ACES AP0, and the RRT and respective ODT are applied. A common example of this includes the flattening of LED-based lights captured in-camera, such as car tail lights, light bars on emergency response vehicles, and miscellaneous lighting accents and decorations on set.

Best regards,
Vlado

[sharktacos]

wow, March 2017. That's what I call an "up to date" citation! Thanks for the link.

[im.thatoneguy]

colorspace affects what the material colors do when the lights get really bright

Colorspace mostly affects what the colors do when the colors get really *saturated*, colorspace doesn't necessarily affect brightness very much (although I'll contradict myself in a moment). It's helpful to think in HSV (Hue-Saturation-Value) when talking about colorspaces not RGB since RGB metaphors work poorly when dealing with color gamut issues. ACES only increases your maximum value for Saturation not Hue or Value. You are correct that your gamut *should* affect how materials react to lights, but being limited to RGB it's kind of like the difference between Phong and Blinn, both are wrong... just wrong differently. The classic case is the color Yellow. There are two "true" ways to have yellow. 1) The first and most correctest way to have pure yellow is the light frequency 575nm. 2) The alternative approach is to have a pure green and pure red light mixed together RGB[1,1,0].

Here is the problem with RGB, which ACES and gamut doesn't "fix". Let's say you have a pure yellow flower. Now let's say you shine a pure red light on it. RGB[1,0,0]. With yellow #2 you get RGB[1,1,0] flower * RGB[1,0,0] light = RGB[1,0,0] aka pure red. But that's "wrong" if your material is actually spectrally speaking yellow. So let's add some primaries: RedYellowGreenCyanBlueMagenta yellow flower RYGCBM[0,1,0,0,0,0] * red light RYGCBM[1,0,0,0,0,0] = RYGCBM[0,0,0,0,0,0]... black. The correct "rendering" of a yellow flower under red light is actually black not red. Real world cameras don't have this problem because all of these effects take place in the real world of photons and quantum effects.

[ACES] has nothing to do with how lights interact with your scene.

Now here Vlado is where I would argue you are actually wrong. Wide gamut does affect materials and how they react to light! We just ran into this on our last project. Let's take a color like Yellow, let's say you're rendering a banana and that it's not purely 575nm. Under Rec709/sRGB our color is RGB[1,1,0]. And we are rendering under a red light [1,0,0]. Our resulting color is [1,0,0] aka Red. But that yellow isn't a pure saturated color in ACES it's RGB[0.8,0.9,0.12] now if we blast it with the same red light ACES_RGB[0.43,0.08,0.01] our resulting render color in ACES is [0.35,0.07,0.002] which translated into rec709/sRGB gamut is = [0.8,0.01,0.0]. Again, both of those are "wrong" without more primaries in your spectral information but arguably, performing the color multiplication in ACES gamut gave us a more "natural" result which is lower saturation. To expand on this example let's say you have instead of "YELLOW" you "yellow" rec709_RGB[1.0,0.5,0.0] * red light [1.0,0.0,0.0] = Still Red!! [1.0,0.0,0.0]. In ACES mixing it works out to rec709 RGB[0.63,0,0]. So it's still the same hue but the reduction in green more accurately modeled the real world effect of a color darkening based on its saturation. In this case it should still be "black" if it's "correct" but it is affecting the intensity of the color. The closer you get to dealing with purely saturated colors the more "wrong" RGB becomes in most situations. Since you reach full saturation in rec709 gamut very quickly, you are far more frequently encountering what should be edge cases near relatively unnatural pure wavelength materials and lights.

[im.thatoneguy]

Here I did a quick comparison of rendering in an ACES gamut vs rendering in sRGB gamut. It should also be noted that you can compress saturation smoothly if you render in ACES. If you render in rec709 it's like rendering in 8bit color where clipping is clipping. All the major camera manufacturers capture in wider than sRGB and then apply a saturation compression to remap values into rec709. And it's much easier to match these idiosyncracies if you start with something like ACES and then apply that saturation compression LUT all at once. RED has a good example on their website right now with their latest color science and how it handles out-of-gamut images. The rec709 rendering is arguably "too bright" since most materials are more like pure yellow than a spikey green and red color.




Here is a good example of how gamut remapping can avoid one form of clipping without actually affecting luminence. We have this exact same situation right now trying to render in rec709/srgb colorspace in Vray. We can tonemap a bright cyan so that it's not clipping, but the only reason we drove the intensity up was to try and get that nuanced saturation. If we switch to ACES or P3 we won't have this issue and it'll be more physically similar to a real optical camera.

[^Lele^]

Gavyn, you said it best: "Arguably".
I'd invite you to go through a whole project where you mess up with the scene-to-screen linearity, and we should share experiences then.

Thought experiment: take two single wavelength lasers, one red and one blue, and cast them on a single-wavelength reflecting sphere, green.
What you get is a perfectly black sphere (as neither of the lasers' wavelengths got reflected.).
Then try than under ACES wider gamut, and show me the results.

The forced input transforms on colors, well before ACEScg, were the main reason i refused to use them on Oblivion (and Got!) at Pixo in Stuttgart: besides the silly amount of handywork, ram wastage, and potential for gruesome mistakes it'd force on the 3d pipeline, the results back then would be energy-preservation breaking, without a way arround it (if a 1.0f white becomes 1.03 and pinkish, good luck with your 100th GI bounce colors and intensities...).

ACEScg supposedly fixed the transform issues, and yet it keeps pushing this idea of an "arguably prettier" gamut.
Language matters to me, just as much as numbers.
They still, in my short-sighted opinion, fall short on both.

[vlado]

Wide gamut does affect materials and how they react to light!

This is only true if you go through the trouble of specifying all your lights and materials and textures in a wide gamut color space - then the numbers involved in the rendering will obviously be different and the results will be different. But just slapping an ACES transform on an otherwise sRGB render won't achieve anything meaningful (although it might look prettier to someone).

Best regards,
Vlado

[dgruwier]

It might be beneficial if you all clarified whether you're all talking about luts/ocios/colorspaces being used actively inside the render engine, or luts/ocios/colorspaces being applied as a "post effect" in the frame buffer / compositing, after the render is said and done. Only one affects the light calculations inside the render engine, but both of them in some way change what you see on your monitor, and it seems like that's where some of the confusion lies?

[^Lele^]

We covered only the one which deals with changing the color mapping of the engine (and hence needs the back-transform of all color inputs.).
Post can do what they want with the linear CG output.

[dgruwier]

Right, and I think the two have been tangled up in the course of the discussion. I hesitate to put words in their mouth, but im.thatoneguy seems to be talking about how the already-rendered linear output is interpreted in the frame buffer / post (ACES vs rec709/sRGB), not what actually goes on internally in the renderer, and when they and sharktaco say "how materials react to lights", they probably mean "how the camera reacts to materials and light", 'camera' being an analogy for how the raw linear input is treated post render.


I might be wrong. I don't quite understand how or why aces can be involved in rendering and light calculations (Is that a thing that happens?), but in any case, the discussion looks to me to be a bit muddled by confusion about which part of the pipeline is being discussed.

[sharktacos]

It might be beneficial if you all clarified whether you're all talking about luts/ocios/colorspaces being used actively inside the render engine, or luts/ocios/colorspaces being applied as a "post effect" in the frame buffer / compositing, after the render is said and done. Only one affects the light calculations inside the render engine, but both of them in some way change what you see on your monitor, and it seems like that's where some of the confusion lies?

Yes, that's a helpful clarification. So to get the results shown in the video from Animal Logic, one would need to have an ACES IDT on the textures, colors, and lights. We do have theVrayTexOCIO... would that work in this case with an ACES OCIO config (at least for texture maps), or would we need to have the "ACES button" that Vlado mentioned earlier?

The behavior that I am most interested in is how saturated material colors become gradually desaturated as the exposure is raised on a render, which emulates the behavior in cameras. You can see this on the video from Animal Logic (about 10 minutes in). It's interesting to me that in the video, Alex Fry says that this behavior is achieved in ACES, but not in spi-anim.

[sharktacos]

Here's something odd that I ran into with ACES. Note how the highlight on the blue sphere gets unusually large as the light intensity is increased:




Does anyone know a fix for this? I realize that this is likely a problem with ACES, and not with Vray.

Save

[^Lele^]

You need every input color back-transformed, including the lights (meaning an OCIO texture map with the color in it.).
If not, some primaries may not align (hence the blue reacting oddly.).
Mind you, it's a hunch, as i flatly refused aces (albeit 1.0) to touch my CG in production when i had to make the call as TD, and whatever look i gave to the spec and proposed workflows later on had me shake my head in disbelief (office of overcomplication of simple affairs.), so i can't really call myself an expert and stand well ready to be corrected.

[vlado]

You need every input color back-transformed, including the lights

I don't think so Lele; in the real world, the lights don't automatically adjust themselves according to the film response of your camera...

Best regards,
Vlado

[^Lele^]

I don't think so Lele; in the real world, the lights don't automatically adjust themselves according to the film response of your camera...

Best regards,
Vlado

Uh, maybe i misunderstood.
I was referring to what's needed to render with ACES: one needs an ACES descriptor for the colors on both lights and shaders, or the shading maths would go askew.
At least it well did in v1.0, when i tested it, and the need to "describe" also every light colour was one of the factors which had me (well, us as a studio) drop it (it was due to the fact that the out-transformed 1.0f white wouldn't be 1.0f anymore, but a pinkish 1.04 or something of the order.).

Said differently, i meant it in the same vein one needs to gamma the colors of the lights as well as the color of the shaders to sRGB standard to then get a linear output under sRGB viewing conditions.
In the case above, because the ACES descriptor isn't (well, wasn't.) linear across the RGB primaries viewing under sRGB, i guessed the blue was skewed in its multiplier curve (notice it also sharpens the terminator. it looks blown out.), something more visible when the values get bigger.

I'd be interested anyway to play with the scene setup, and get a clue. ^^

[sharktacos]

I can post the scene here. In the meantime, I did a little experiment with just a single sphere where I applied different texture colors. In the image below I have raised the exposure up to 5 to demonstrate the behavior.

Notice for example how you get a big white :"highlight" around teal and magenta, and then yellow in the big "highlights" for the green and red (on either side of yellow). None of that happens in spi-anim (or in sRGB 2.2 gamma). So it seems to me that something odd is going on with ACES. Just trying to figure out what that may be.