Would be very happy to give it a try since moving to a fully ACEScg pipeline has become a huge part of interest within our team 
Hei, I would be interested in testing this tool too
Just to add to the possible workflows here, one approach that I find a bit more artist friendly in Substance Painter is set the Color Picking color space to the same as the Viewport color space. Here you can see that I have a value of 0.2 and it is appearing as charcoal grey.
Then below you can see how 0.8 looks (fresh snow)
Not sure how scienc-y that is, but it gives artists expected WYSIWYG results, where a dark color looks dark, etc.
As a comparison, hereās that same 0.1 dark grey value with the color picker set to Raw, producing a very unintuitive result:
Another thing that I thought might be worth mentioning is that the values @ChrisBrejon was saying were 0-1 while @the_fel395 was taking about a 0-255 scale.
For your OCIO settings I would set input āfloating point imagesā to Raw or ACES-cg, rather than to linear sRGB, like you have for the output. Donāt think that will affect the question at hand tho.
hope it helps.
Even textures? ACEScg and BT.2020 both need at least 10 bits of precision in textures to avoid color banding so you canāt use BC7 anymore for base map (and specular map if you use a specular workflow instead of a metallic workflow). You have to go to BC6H + optional separate BC4 alpha texture. That was one of my reasons for wanting to limit the upgrade of the color space used for textures to D65 when I previously talked about making a full wider-gamut pipeline (D65 all the way but could have been ACEScg all the way except textures). Asking because Iām curious if you have tested whether this is an issue or not. Iām working from a purely theoretical standpoint here and have not tested anything.
Yours,
Jean-Michel
1 Like
Hello everyone,
First apologies for the radio silence, but I had a couple of difficult client deliveries until the 22nd and then I just needed to switch off.
Second, it is great to see interest in this tool. Anton already gave me some good suggestions that I will be implementing soon, but for now, if anyone is interested in playing with this tool you can download it here.
(for some reason I canāt add links - so remove the underscore before the we)
https://_we.tl/t-SKNNF72MW2
Currently, it checks Albedo + Metalness by default. For now, I added an option to switch to monochrome, but I think I will be able to do that automatically with some if-else statements. Anton suggested adding checking Roughness and Metalness values as well and I am open to more suggestions and feedback.
1 Like
Hey Jean!
Long time no see, hope you had a great start of the year! Iām very happy that you replied to this question since textures is something that I have yet to understand how much of a 10 bit upgrade may be needed in case we wanted to go full ACEScg.
Currently what I am planning to have is an ACEScg configured project , and textures from Substance Painter exported as sRGB Encoded AP1, going 10 bit for textures was something that made me think twice the decision of exporting linear ACEScg since that implies as you mentioned, no longer BC7 and as consequence a considerable increase on disk size from the texture (also Substance wonāt export a 10 bit image, or so it seems).
So I am curious about what would be the highest that we could go about textures for a wide color gamut content authoring. I havenāt considered until you mentioned the possibility of going D65 (am I correct in assuming that you mean P3?). Configuration in the studio is still as standard as you get, artists working in sRGB monitors, with some HDR monitors here and there for content validation.
The ideal environment would be to have the textures worked in the wider gamut, even though the export is still sRGB, and validate if the OCIO transforms from Epic work as expected on 5.3.
This is definitely still a work in progress so I am currently trying to gather as much information as possible before flipping the switch on the project to go fully into ACEScg. Right now we have only adopted the vanilla OCIO view transforms to match viewports between Substance and Unreal. But even that, the plugin seems to be very buggy for games still.
Best,
Omar
Curious what the logic is here in doing this?
Hi Omar,
yes thatās pretty much my thinking. I havenāt investigated Epicās OCIO implementations but I see no reason why it shouldnāt work correctly. Iām not sure if they are using LUT or OCIO 2 shader version. As mentioned, I was told that, as long as you donāt need alpha, BC6 is as fast as BC7. One possible strategy for textures that need the alpha channel is exporting in the smallest gamut, either sRGB or Appleās Display P3 (P3-D65 with sRGB gamma curve applied on top for better use of the bits) in which they fit and tagging them so they are loaded with the proper transform. This is pure theoretical territory for me though as I havenāt tried it with any real dataset 
. At some point, I wondered if it would be possible to write a custom BC7 encoder that would drop bits in a predictable pattern so extra precision could be added back in shader but I quickly dropped that idea.
Yours,
Jean-Michel
1 Like
Hi guys,
I am planning to release to the public an initial version this week. Let me know if you have any kind of extra feedback, so I can implement it. Overall, thank you so much for the input and help here. It helped me tremendously understand ACES a little bit more.