Using the PBR workflow, the safe range for the darkest values is between sRGB 30 and 50, and for the brightest nothing above sRGB 240. Now, I am confused about how those sRGB values would translate into ACES. Do I convert the sRGB values to ACEScg RGB? Is there any document that covers PBR workflow in ACES?
Many thanks in advance
Hey Ciro welcome,
If you need to type in values rather than loading a texture I believe the easiest way would be to have the software automatically convert
sRGB - Texture values into
ACEScg with their color pickers. Some can use the OCIO config’s color picking role for this. Some can perhaps be manually be configured. If your software doesn’t support this you’d have to manually do the conversion which you could do here.
Hello @cirocardoso and welcome,
this is the topic that has been discussed a couple of times on this forum. I think I even did an ACEScg albedo chart somewhere…
What is tricky about albedo is that it can include both difffuse_albedo and specular_albedo, sometimes weighted by the SSS weight (like in Arnold). It depends on the render engine.
But overall, in scene-linear, I generally use charcoal as a low limit (around 0.02/0.04) and snow as a high limit (around 0.8/0.9). I thought those achromatic values to be good reference for PBR range.
Then, it comes the issue of ACEScg primaries that can be tricky to deal with. But that can be discussed at a later time.
thank you for your answers.
The reason why I ask this is because when you do texturing in Substance Painter, there is no way to know which values are safe to use in PBR. The PBR validator tool doesn’t work correctly. If I give a value of 0.02 or 0.04, like you mentioned Chris, the PBR will be super red telling me is wrong.
Now, I can create a new filter to use in Substance Painter and share with the community, but for that, I need to know which values are safe for the albedo. But then I also need the values for metals as the safe range is different (I think in sRGB is between 170 and 240).
But so far, I haven’t found any kind of information to help me and although we have a tool in the studio to check the albedo, I just feel isn’t practical to check this right on Substance Painter.
So, I am kind of lost. I assume that each studio is defining which values that are comfortable to work with.
Hello, before creating a new filter, could you share some screenshots about the PBR validator ? I am curious to see which range it expects.
Here is the darkest value accepted at the moment
for sRGB is 0.250 but in ACES sRGB is 0.113. I believe we can go even lower than this for ACES.
for the brightest values
for sRGB is 0.800 but in ACES sRGB is 0.936.
What do you think? Currently, we are working with the lowest value of around 0.032 and the highest
value of 0.88.
As a new user, I can’t post images on the replies.
The range that you indicated seems safe to me for low and high values.
Again, here we are only talkiing about “luminance” values. Things get tricky when we introduce saturation in our values. You probably do not want to end up with a laser-like primary in an albedo (except for some kind of alien planet I guess ?)
Hi Chris, sorry for the delay, but this week has been super busy.
Yes, I am talking about luminance values and the PBR tool in Substance Painter only checks that. However, I think due to the fact ACES gives a wider range of work, can’t we work with darker values and brighter values? The value of 0.250 is the darkest value the PBR Validator tool allows, however in ACES that is basically gray. I wish I could upload a couple of screenshots to show you the difference.
Great, I can upload the pictures now.
Ok, so on the left is the normal sRGB and you can see on the base color how dark you can go and be under the safe range.
On the right side, we have the ACES workflow, and I am using the darkest value allowed by the same PBR validator. Which is almost gray. Below I am showing the darkest value we use in our studio.
I’m not in front of Substance Painter right now but there is something not working properly. When @ChrisBrejon mentions 0.02 or 0.04, he is talking about a scene-referred linear colour. Put another way, this is the colour before it has been encoded for display rendering.
Now if you convert some sRGB colour to ACEScg, the luminance should not change, it is the same colour after all, just encoded (expressed) in a different colourspace.
It can be verified by many means, e.g. Nuke and OCIO, or Python:
sRGB = [[0.02, 0.02, 0.02], [0.04, 0.04, 0.04]]
print(colour.RGB_to_RGB(sRGB, "sRGB", "ACEScg"))
[[ 0.02000174 0.0199994 0.01999895]
[ 0.04000349 0.0399988 0.0399979 ]]
My assumption here is that the PBR validation tool in Substance is not working correctly and not performing the correct colour conversions in your current setup.
that is exactly what I think is happening. The tool isn’t prepared to work in ACES. That is no issue at all as I can create a new tool.
If I understood you correctly, all I have to do is convert sRGB (linear) values to ACES, is that right?
So sRGB 30 ( in 0-1 is 0.12) is in linear sRGB 0.013. Converting this value to ACES - ACEScg it will be 0.049. Is that right? For some reason, the Python code isn’t working for me, so I am using this tool
A big thanks for your patience
I’m not sure what is that tool, can you share a link please?
If you consider Luminance, it is the same value between sRGB and ACEScg and any other RGB space so
[0.04, 0.04, 0.04] in Linear sRGB equals to
[0.04, 0.04, 0.04] in ACEScg (discounting precision issues).This is what the Python code was showing above.
I will try to take a look at Substance next week at work if I have time. It could be coming from anywhere between the channel bit depth causing unexpected computations, to incorrect scene setup, to a bug or some misunderstanding but without access to your setup it is hard to diagnose.
Hello Ciro !
From your screen you are not picking “scene-referred” value like Thomas mentioned.
If you look a bit under you can actually see the value you pick is
0.1127 in ACEScg
If that can help I explain the sp’s colorpicker on my blog and give some tips for ACES.
thanks for the time in explaining things and good to see you here Liam.
@Thomas_Mansencal the tool is the one mentioned by Shebbe. Sorry, it seems I can’t post links for now.
These are the settings I am using in Substance Painter
@MrLixm I am having a look at your stuff. I will do a couple of tests and get back to report.
Thanks again for the help.
Ok, I think I understand now.
The luminance value for 30 sRGB is 0.118 (I think this is what the PBR Validator tool takes into account).
The linear value is 0.0130.
The luminance value for 30 ACES sRGB is 0.020, but the linear value is still 0.0130 as you mentioned.
Now, I am able to create the tool to work correctly in ACES. Going to give it a go today and share it with the community.
One thing to look out for is that the “V” in HSV is not luminance, unless you have a monochromatic color, as Thomas already mentioned. The difference you’re seeing in Substance is because the HSV values are not linear.
To calculate luminance from a Linear sRGB color you should use the following formula:
You can read more here: Relative luminance - Wikipedia
You can also use the color space converter here, as it calculates the luminance value for you: physicallybased.info/tools
Adding to the confusion is the fact that the Substance Painter color picker doesn’t update the Working Color Space values until you type in a new value, so sometimes the values you see there are wrong.
The reason you’re seeing the wrong results in the ACES converter is that you should set your source color space to Utility - sRGB - Texture instead of Output - sRGB
Hope this helps!
That is super useful information and thank you for sharing it. I have the tool almost done and this new info brings up a good question. Is the 30 RGB a way to say what the luminance value is supposed to be overall? I will investigate this further, but thanks again for your insight.
Does anyone want to give it a go with this new PBR validator? Doing some testing before releasing it to the wider community, but it seems to be working fine now.