New filters for rendering ACES in Substance Painter

[Thomas_Mansencal]

@Dogway

Sort of. Filmic LUTs or looks for CG rendering is a rather recent concept

Absolutely not, studios across the world have been working with filmic View Transforms for many-many-many years. This presentation about games (not films but games) by @hpduiker is from 2006.

@Dogway

What this means is that when you apply the RRT to a render of an old authored sRGB material you are effectively applying a filmic look TWICE. The filmic ground truth embedded into the sRGB material, and the ACES RRT.

I disagree with that, who is to say that all the sRGB materials are authored with a filmic look in the first place? Making incorrect assumptions can be dangerous and might bite back.

@Dogway

When light component is removed with a surface shader you get a match of the ground truth (plus PBR and unclamped HDR values

How many times are surface shaders that are not light sources rendered and end up in final frames on shows? My guess is pretty much none.

The complex BxDF and light transport interactions are what makes your suggested workflow something I would not consider to start with because applying the Reverse View Transform on textures will not get back to the previous rendered sRGB View Transform look anyway. The more complex the shaders and lighting are and the more it will diverge. This only works for Logo and Branding that sits on top of the rendered image really…

If you are working with an annoying client that is so fond of the previous look developed with an sRGB View Transform, why shoot yourself in the foot and use a filmic View Transform? If you really want to use a filmic View Transform, then have your Comp artists or Colorist build a compensation for you.

@Dogway

AdobeRGB is the defacto color space for HDRIs given its wider gamut, you are certainly safe honoring the assumption that an HDRI is AdobeRGB unless specificied otherwise (it should be tagged in the metadata). Telltales are lack of banding in skies or very dull HDRIs when viewed with the sRGB IDT

This is an assumption I would certainly not make, if anything the only commonly agreed colour space is the lowest common denominator: sRGB. I shoot myself a lot of HDRIs, process them with my own code, and I use sRGB as encoding space very often.

Who is to say that the HDRI author did not simply desaturate it? A ton of people online use Adobe tools to generate them and they end up with ACR tone curve embedded in their images without even knowing it. If one has no clues on how the HDRI was processed and encoded, i.e. does not ship with a Colour Rendition Chart, he cannot expect to have physically correct results. As a matter of fact, he does not even know if the HDRI is representing radiometrically linear illuminance values. In that case, the adopted gamut is probably not the major concern and the HDRI look will be subjectively tweaked until it produces the expected results.

@Dogway

The RRT development roadmap includes a parametric RRT to ease on the reversible aspect of the function, that tells something important.

Yes, very much aware of that, for what it is worth, it is something the authors of the ACES RAE, I’m one of them, have been pushing for.

Again, the frustration point of things looking too dark should be addressed with the hooks the system was designed with, e.g. exposure compensation with an LMT, OCIO config tweaks, etc… In LookDev, we spend our time changing image exposure to assess if the tones are correct everywhere anyway, one should not be attached too strongly to a particular exposure value.