I made the Substance EXR LUT using Thomas’ Nuke script above. I tried adding in log conversions to this as others have discussed, and also tried it without converting to log. My experience was that none of the log flavors (I tried a ton) quite matched, including the one from Brian (which has a very slight greenish tint to it). However the one without log seems to match perfectly.
I know that typically one needs to do a LUT in LOG space because it needs to work in the 0-1 range. However in this case I am not writing out a typical LUT file like .cube but rather writing to an EXR file which can go above a 0-1 range.
So it would appear that in the particular case of Substance Painter, which uses an EXR file for a LUT, it works better to have no LOG conversion, and indeed none of the (exr) LUTs that come with Substance Painter appear to be in LOG.
I just wanted to confirm the validity of this approach with those more scientifically minded than I just in case I’m missing something.
I don’t think I’ve ever noticed a green tint. Is this noticeable in Painter directly or when comparing to another renderer? Just to be sure, your Painter camera settings are clear of everything but the Log tonemapper, since the default setup has some things enabled iirc. The biggest issues I’ve seen in my primary renderer(UE4), aside from shading differences, is UE4 also includes a few adjustments to fake a wide gamut and to fix the “electric blue” issue. No obvious color tint that I’m seeing though
The stock linear EXR provided by Allegorithmic is already clamped between 0-1. You can see this with the stock Log LUTs too. There’s this older thread where my original LUT was shared, before I did the pre-transform and Nick provides a lot of helpful information ACEScg for Animation feature and further questions
Thanks @bleleux I’ll give that a read. FYI I was comparing Substance with a render in Maya and noticed blues in Substance had a slight teal hue compared to Maya.
Out of curiosity, what linLog function are you doing in Nuke for your LUT?
It was a Log2Lin function with inverted default values. The Painter tonemapper converts the linear image before the LUT, so I had to do the inverse in the LUT. This is something I think could be done better in my LUT for accuracy’s sake.
I’m a Nuke noob and used the OCIODisplay node which looked like it did the color transform and ODT, but I don’t know if it does the chromatic adaptation as well? That could be where some of the colors differ, or the fact that I used the ACEScg colorspace.
As you guys are well aware, without the log tone mapper inverted, highlights will clamp. I’d like to get rid of that… I have tried lots of combination of log2lin/lin2log in Nuke but none did the trick…
Hey @ChrisBrejon!
It’s a bit un-intuitive: to create a log shaper pre-lut on your lut image, you need to first apply the inverse log transform, then apply the color transform (your OCIODisplay in this case).
I usually think about it like this: How do you get from the colorspace you will be applying the lut image in (Painter Log) to the colorspace that the color transform is applied in (ACEScg Linear)? You need a Painter Log to ACEScg Linear colorspace transformation. There are no more transformations to be done because once the Output Transform is applied you are where you need to be.
Hope that makes sense.
Anyway, I was poking around curiously at this same problem a few months ago. I’ll share what I came up with in the hopes it might help you, though I’m not convinced it is a perfect solution!
As far as I can tell, the Substance Painter tonemapping log curve is undocumented. I wasn’t able to get a perfect match with the usual suspects (simple log function, log2lin, cineon, acescct etc).
Without the math of that curve, or a good approximation of it, you obviously can’t do a forward or an inverse transform to get into or out of painter log. So I tried to reverse engineer the painter log curve by putting a linear ramp on a sphere, applying the log tonemapping in Painter with a Mapping factor of 64, and analyzing what happened to the displayed pixels. Not exactly elegant but I did manage to get a log curve out of it that at least seems to resemble the proper thing.
The log curve is here as an spi1d, and there is a lut image for the rec709 and p3d65 aces output transforms there as well if you want to test it out.
I’m pretty sure someone on here who is way smarter than me is going to come along with a better solution and an exact match for the log curve, but hey maybe this will help someone.
Perfect ! That’s exactly the information I needed.
I definitely tried the setup from your screenshot and since it was not working as expected, this is where I tried different things that did not make much sense. I naively thought that Substance log curve was standard.
Your explanation makes perfect sense (as usual !) and is much appreciated !
I’ll let you know how this goes ! Many many thanks !
Thank you @jedsmith ! it worked like a charm ! I used your nuke setup and replaced the Log2Lin node by an OCIOFileTransform reading your spi1d LUT. It is the first time I was able to really match an ACES render to the ACES viewport of Substance Painter (no highlights clipping). Ideally we would get the log curve from Allegorithmic to be more accurate. I have asked them. Thanks !
Log : This results in mapping that is even more gradual than Reinhard , and contrast that is low. It causes the resolution of the high luminance components to become high, and the strongest reproduction of the luminance variations in the bright portions.
LogLum : Type for implementing the tone map of the logarithmic space with the luminance as the reference and keeping the original saturation (vividness: RGB ratio). This maps only the luminance information to the logarithmic space and then reproduces the original saturation. The saturation in the HDR space is also kept after tone mapping.
Not much of an help. But we have found out that this Log Function actually comes from Yebis. So I have written to them and they are investigating the matter.
Unfortunately no secret revealed… @jedsmith Here is the answer I got :
One of the tone map curves provided by YEBIS, which is a YEBIS original function, is based on a logarithmic function. This is the most gentle curve in the YEBIS tone map, and has a low contrast. Therefore, it is easy to express a wide range of brightness. However, it’s not a very good curve from an artwork perspective.
Hey,
Thanks to your instructions i managed to build the LUT on my side too .
Will @jedsmith and @ChrisBrejon allow me to share my result on my Gumroad (for free so i’m not selling it) to help people work with SP while waiting for OCIO support ?
Yeah for sure! If it helps people I’m all for it. Post a link when you have it up.
Just out of curiosity, is your LUT for a view transform that is not in the repository? Or is it because you have a different working gamut than ACEScg? Just curious what your use-case is.
Thanks !
First cause i wanted to just know how to do it , then to have the choice between working with sRGB or ACEScg primaries. (sRGB included a converting step after export but allow to keep the same workflow/tools in SP)
Good idea @MrLixm ! We did some LUTs for the studio based on a linear - sRGB working space, with a variation using the log tonemapper. I think it would be of great interest to list them all and have them available at one place for free.
Let me know if I can help,
Chris
Here is the Instructions and the ReadMe that are going to be included with the LUTs. The work is shared under CC BY-SA license.(details in README).
Credits are included in the README.
LUT supplied are:
ODT: rec709, sRGB, P3D60, P3D65
WorkingSpace: Linear - sRGB, ACEScg
Don’t know what kind of other ODT are often used and could be added.
