People have asked him what wall paint value he used, and he responded 180 RGB.
This answer has then turned into another questing. What does he mean about 180 RGB, does it mean sRGB or does it actually mean RGB.
180 sRGB is 46.5% reflectance and 180 RGB is 70.6%.
So he is talking about real linear RGB values. 70.6% is still dark for white values, but this is the common average value for white paint.
Well despite his amazing renders, BB is more of an eyeballing kind of guy (and he has an insane eye), he can can pretty much nail any materials just by looking at them. That leaves me speechless every time! But after reviewing some of his scenes (some older ones, don't know is it still the case), I just noticed he is not using "strict PBR rules". So I guess that's just the expression of his artistic vision. That said, his approach is not devoid of foundation and we can clearly identify some technical background behind all of this. Overall reflectance values of the scene are indeed extremely important as it will greatly influence how light propagates through it and thus affect the dynamic range of the final render. That's just a pain in the ass to get it right for every single material in the scene (for me at least).
I've been lurking around on different forums and articles in that regard. Without a "state of the art" material scanner, it's hard to guess these values. Anyway, Some studios are relying on this sensor:
https://www.nixsensor.com/. For sure, it is not as smart as being able to split it into diffuse and spec or anything nice like that but you'll get an accurate overall brightness and hue for your material for cheap. What's more, it can give you ACEScg values (the pro one), so linear data. I'm considering buying one of them atm.
And here we come, talking ACES workflow. I had some time to kill so I decided to give ACES a spin. I used Vray and OCIO config to see what it gets.
lin sRGB + 2.2 gama curve
lin ACEScg + sRGB viewtransform
lin sRGB +5EV + 2.2 gama curve
lin ACEScg +5EV + sRGB viewtransform
We can clearly see the advantages of the ACES tone mapping. The way blown highlights are handled is way closer to what a real camera would produce. We can feel the "Fstorm look" there uh? The only drawback is that "ACES bug" with bright saturated values professor Dubcat was referring earlier this topic. At this point, I'm not that sure it is a bug rather than a "workflow issue".
That color 'bug" literally freaked me out! Why the fuck is this happening? So I tried to figure out what was the issue and here what I found :
To understand that we need to be pragmatical.
The issue: I'm increasing EVs and my primaries are not fading to white in sRGB. It does in ACES but colors seem shifted. Why?
According to the definition of EV (Wikipedia), the Exposure value is used to indicate an interval on the photographic exposure scale, with a difference of 1 EV corresponding to a standard power-of-2 exposure step, commonly referred to as a stop. So basically, it's a multiply operation. The colors used for the lights are pure sRGB primaries (1,0,0 ; 0,1,0 ; 0,0,1). I guess you understand what's happening at this point. Let's sample our blue: At current exposure value we have (0,0,3.391 float 32). So multiply that by whatever you want to, you'll always see a blue primary (the blue being clipped to be displayed and the other two components being 0 -> REMINDER: 0*x=0 😉).
Now let's change that blue color to (0.1,0.1,1)
sRGB - start to see fading even at current exposure
sRGB +5EV - totally faded to white while the other two primaries remain the same.
OK, that's just math so shouldn't ACES behave the same way as we were using the same pure primaries? In fact, it does...
What's defining a color ? Well it's a balance between R, G and B values (thanks captain obvious). What I mean here is that your color won't be more blue by increasing the blue component (that's actually luminance), it will be more blue by removing more red and green.
ACEScg gamut is wider than sRGB gamut which means colors can be more saturated.
So when we are using ACEScg to grade, we are converting from lin sRGB to lin ACEScg. Since the gamut is expanded, my sRGB(0,0,1) is not translated to ACEScg(0,0,1) as it's less saturated. Less saturation brings back a bit of red green to my color in ACEScg colorspace ! and that's why colors fade out! If you try to grade a pure blue primary in ACEScg, it will behave the same way as in sRGB, 100% saturation is reached, 0 red and 0 green, blue is clipped -> no fade out.
But we are actually converting to ACEScg after rendering which introduce some bias in the solution and it is especially visible near extreme values. To avoid that it's better to convert anything that contributes to the color information in the final rendering. So basically all lights and textures that are not supposed to be shades of gray.