I’m starting to look into the ACES work flow, I was wondering if there are any plans to add any native LUT support from VRay? It does appear that ACES might be the new ‘accepted’ standard…
V-Ray does support LUT files natively in it’s VFB and through the VRayLUT texture. I don’t think you need anything else from us for the time being, as far as LUTs are concerned.
We do plan to add a switch for the internal spectral color space though, because stuff like light color temperature, sun&sky, dispersion etc. must be transformed into ACEScg if you plan to use ACES.
Best regards,
Vlado
Yeah I was wondering about a dedicated ACES button or drop-down button to switch from sRGB-to-ACES in the VRayVFB if this is the ‘new standard’.
For the time being, it’s best to just use a suitable OCIO configuration.
Best regards,
Vlado
Would this be the correct .ocio file to load into the VFB?
https://github.com/imageworks/OpenColorIO-Configs/tree/master/aces\_1.0.1
We do plan to add a switch for the internal spectral color space though, because stuff like light color temperature, sun&sky, dispersion etc. must be transformed into ACEScg if you plan to use ACES.
Any change this will be in Vray 3.5?
Yes, it will work fine.
Any change this will be in Vray 3.5?No, as 3.5 is already out. Hopefully for 3.6
Best regards,
Vlado
This video shows how colors under bright lights react correctly with ACES and incorrectly with sRGB. This is the main reason I’m interested in using it in Vray. When you say things like “light color temperature” wont work properly with OCIO in the VFB, does that mean that the stuff in this video will not work (bright lights reacting correctly with material color)?
I think you are slightly confused as to what ACES is and why it is used… it has nothing to do with how lights interact with your scene.
That’s not entirely correct to say. They react differently, that’s true. But unless you work with actual spectra (in which case color space is meaningless) instead of RGB images, there is always going to be some error in the result. The very concept of RGB implies that some spectral information is already lost, and just changing to a different color space will not recover it.
This is the main reason I’m interested in using it in Vray. When you say things like “light color temperature” wont work properly with OCIO in the VFB, does that mean that the stuff in this video will not work (bright lights reacting correctly with material color)?No, that’s not what I said at all. Lights will work just fine no matter how bright they are. However when you specify the light color as a blackbody temperature value, it is necessary to know the wavelengths for the red, green and blue components of the resulting image, so that the blackbody spectrum can be converted correctly.
Best regards,
Vlado
Okay, would it be correct to say that colors under bright lights with ACES react in a way that is closer to how a camera reacts? What I am ultimately interested in is avoiding the problem of an artist setting the lights too dim in order to avoid clipping in the whites, and instead emulating more what a camera does. I was hoping ACES might help with that, at least in regard to what colors do when they get overexposed.
No.
What I am ultimately interested in is avoiding the problem of an artist setting the lights too dim in order to avoid clipping in the whites, and instead emulating more what a camera does.It doesn’t sound like you need what a real world camera does. I don’t know where this misconception comes from, that real-world cameras are somehow perfect, with no burnouts whatsoever and you can point them at any scene with any exposure and always get a perfect result. This is just not true.
I was hoping ACES might help with that, at least in regard to what colors do when they get overexposed.ACES will most definitely not help you with that. See my reply here for a discussion of this topic:
- Chaos Forums
Best regards,
Vlado
Hi Vlado,
I think we may be talking past each other here. In the post you link to you discuss tonemapping and lights getting blownout (or burnout as you call it). That’s not what I am referring to. After all, the Animal Logic renders do get burnout in the video. The point made in the video is about how the colorspace affects what the material colors do when the lights get really bright. I don’t expect ACES to have any effect on lights getting burnout. I do expect the colors to respond differently when the lights get bright, as shown in the video.
Lights just emit light. They don’t “respond” to anything.
You did mention that your artists specifically make lights dimmer in order to prevent burnouts?
Best regards,
Vlado
Yes, but that is not because of the color space. The colorspace would only affect how it looks as it blows out (the color), but not whether it blows out (which it will, and should). Lights don’t respond to anything, but material color responds to light.
Using ACES will simply move the problem from one set of colors to another. It will not remove it completely.
Best regards,
Vlado
To clarify, when you say “the problem” are you referring to burnout or something else?
See here for some discussion of using ACES in production enviroments:
Highly saturated blue or magenta emitters such as LED, Neon, and other spectrally sharp light sources can create artifacts when processed through ACES . Scott Dyer (2016) has provided a standalone workaround , 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
wow, March 2017. That’s what I call an “up to date” citation! Thanks for the link.
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.
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.
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.
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.