Thanks for your reply @MrLixm!
EDIT: I see that you have two LUTS, one from sRGB-linear to Output, and another from ACEScg to Output.
Hello, Substance Painter, as part of their latest 7.4 update now supports OCIO.
I made a full review of it on my blog (with a section on the ACES workflow):
Hope this can be of any utility.
Cheers.
2 Likes
Very nice write up Liam!
I see you’ve tried an OCIOv2 config in Substance. I’m noticing that when using an OCIOv2 config I get the following error in the SP logs:
[ColorManagement] Error while creating OpenColorIO colorspace transform: Color space '<USE_DISPLAY_NAME>' could not be found.
Are you getting the same error when using your v2 config?
Yes getting the same, but the displays all seems to work fine.
True that.
For scalar channels, sp will not apply any color-transformation and consider them using the colorspace
raw(no matter the config).
This is very interesting. Do you know it this is true for masks (which are not output with the Export Textures dialog, but with right-click “export mask to file” since the Blending Mask channel was depreciated.
We doesn’t have any options to apply a color-transformation at export time in the Window. The only options are the one available into the project settings.
Yes, this is unfortunate. Consequently, I have 16-bit set to raw as this is only used for png16 files of normal maps. I also only export bump maps as EXRs as the HDR detail seems to get lost in an 8-16bit jpg or png. Your approach of having everything as EXR also seems like a good one. I do wish they would support EXR compression like DWAB.
Didn’t think of this feature at all, after testing mask are still considered as “Raw” channel so even with the Export to file option they are properly exported no matter the format.
There is a new option Gamma corrected alpha/mask when you right click on the mask. It seems to only
affect Material preview thought.
You don’t need to, as mentioned if your channel is in the list of scalar channel it will be automatically considered as “Raw”. No matter the file format.
Thanks for the feedback, will update the article with the thing about masks !
A note on using the color picker: The color picker works in the working color space (ACEScg). Therefore in order to pick a color from the viewport the Display color space (in the viewport, not in the color picker) needs to temporarily be set to Raw to sample the color properly.
Are you sure about this ?
With my test and as mentioned in my blog post the color_picker always apply a revert transform based on the color_picking role defined in the config. As such you have to always revert this transform.
Yes I have verified this behavior. SP samples the display color. If the display color is set to raw then it will pick that raw scene-linear value, which is the color space the color picker works in. Let me add that this works in Base Color mode, but does not in material mode. Here’s steps to reproduce:
- set viewport display to raw.
- change the drop-down from material to single channel (Base Color)
- sample the color in the viewport
Similarly if you take the scene linear values for a color swatch in Maya and type of those same values into substance viewing them both through the same display transform (in the render view in Maya and in the view port in substance) they will appear identical.
Remember Substance does not support OCIO roles. The color picker uses the working space as its color space and only displays the colors through the selected display transform.
Ok redid my test. I was wrong on the color_picking thing :
So I loaded substance with config using ACEScc as color_picking role.
Used a random ODT:
Manage to get the same values in Nuke using the invert transform Output_ sRGB to ACEScg.
This transform is still applied even when view_transform is disabled as you can see above.
And of course same result for the roughness channel.
SO there is definitely always an inverted transform applied which modify the values.
The question now is then why the Output - sRGB colorspace is picked and not an other ?
So I modify the config by putting Output - DCDM (P3D65 limited) at the top of the displays and
as the first active_displays :
And well, result match. So it just use the first display specified.
I can conclude that the color picker is definitively “fucky” as it always apply the inverse transform of the first display specified in the config.
Will update my blog post.
Thanks for for the heads up, really usefull.
Cheers.
Liam.
The pictures help a lot to see what your doing, so I’m adding my own in the hopes that they are also worth 1000 words too.
What I believe we are doing differently is what we set to raw. Note below in mine that I set the viewport to raw, not the color picker. This results in picking the same color in ACEScg.
Nuke picks the raw color of the image. Substance picks what ever the display is set to. Probably it should do what Nuke does, but the workaround is to set the viewport display to the color space that the picker works in, which is ACEScg in Substance.
In Maya’s color picker the color management can be toggled off to get these same raw values, regardless to what the color picking role is set to. So you can have Maya and Substance side-by side and pick a color from Maya’s color picker.
Here’s another screenshot. Here in Nuke and Substance the display color is sampled. It seems to be a visual match, but the RGB values differ. That’s above my pay grade to make sense of.
Hey, what OCIO config are you using ?
So I can just quickly try on my side
I’m using my custom config here:
However, you can instead just use the Maya 2022 default OCIOv2 config. Mine is built from that adding in some rules, roles, and LMTs.
So, ran more experimentations with various config. There is definitively something fucky but I don’t know where yet.
Here is a simple tab I did to try to find clues :
The decisive factor is : does the picker pick the right value when the view transform is disabled. (vt off working ? column )
Only 2 configs have it working, they are v2 config and are using display colorspaces and shared views.
Will continue investigating.
Fascinating. What does a check/uncheck by “active set” refer to?
btw, here’s what my config was derived from (no LUTs needed):
https://opencolorio.readthedocs.io/en/latest/configurations/ocio_v2_demo.html
Updated my blog post with my latest conclusions.
Here they are :
Case 1
You are using an OCIO v2 config that uses Display colorspaces and Shared Views (OCIO v2 new features) :
The picker take the value at the display (after the view-transform is applied) and return it.
This only work when there is, well …, no view-transform, i.e. is it is disabled or use a display with a “passtrough/raw” encoding. If you are viewing color data with the proper view-transform, the picked value will not correspond to the original value you used.
Case 2
You are using an OCIO v1 config or v2 without the new features :
The picker take the value at display (with the view-transform), then apply an inverse display transform. It pick the default one, i.e. the first defined in the config or in the
active_displayskey. And as the sliders don’t go above 1, the result is clamped between the 0-1 range.
See Color-management in Substance Painter with OCIO | Liam Collod's Blog section.
Results of the experiment are available here :
https://liamcollod.notion.site/Substance-Painter-Color-Picker-Issue-1d1cdeeb0e2846ba977ebc453e5ae56b
Will try to fill a bug report on the forum. Solved: Color-picker doesn't behave consistent across OCIO... - Adobe Community - 12603389
Even if I’m still not sure of what is going on, this is certain that the picker is broken most of the time.
Cheers.
Liam.
1 Like
Great work Liam!
Hopefully once they implement OCIO roles they will make the color picker work like Maya which allows one to define the color picking role in the config.
2 Likes
So forget to give an update here :
On 08/03/22 the Sp’s team released 7.4.2.
I did test this release and updated my blog-post accordingly :
(same link) https://mrlixm.github.io/blog/substance-painter-color-management/
TLDR: the team did a great jobs and fixed a lot of issues. The color-picker behave much more as expected which is super-cool. I recommend to update.
Cheers.
3 Likes
Thanks for this update Liam. Great that OCIO roles work now! I see that the color picker still samples the display color rather than the raw color like Nuke does. Hope that changes in the future.