Output Transform Design Requirements

Hello guys,

sorry, my microphone was not working properly during the meeting and I just wanted to mention that acescentral is a great place to start/continue a list of design requirements. :wink: I’m all good with dropbox paper and google docs, but I kinda like the way acescentral is structured. It is easy to follow a conversation and keep track of things.

So this post is just an attempt at starting a conversation. I’ll just throw my ideal design requirements in here and I’d be curious to see if any of them are contradictory.

Before throwing a list, I just think it is worth defining quickly what is the goal/target of this DRT. In my opinion, if ACES tries to be all things to everyone, we’d have to compromise so much that we would eventually fail at what we are trying to achieve.

The LMT/DRT I have in my head is mainly for feature films and PBR animation movies, with an attempt at reproducing Print Film Emulsion (PFE). So I am not taking in account here edge cases, like logos or illustrative renders.

Here is the list for the DRT :

  • Easy to work with (no strong look) : it should be “neutral” aka a faithful representation of the scene (no sepia filter).
  • Going to “white” : probably the most controversial point but we have a separated thread for this specific point.
  • Gamut-Preserving : No gamut clipping when going from scene to display.
  • Safe : You should be able to throw any grade on the footage and the DRT does not break.
  • Hue-Preserving : I think it goes hand-in-hand with “neutral” and “faithful”.
  • SDR/HDR predictability : An orange flame in SDR does not become red in HDR.
  • Simple/Fast/Invertible/Easy to extend : kind of self-explanatory, right ?

With this DRT, I would imagine an LMT activated by default :

  • Filmic look, especially for pyros and skin tones. So if anyone wants to remove it, it is possible.

I could throw more examples and images of mine. But I think you already get what I mean by my previous posts. So I’ll just share a couple of renders about “going to white” if that’s okay.

I have a hard time picturing a project that would want the light sabers to look like this. And I guess it would be safe to say they’re edge cases ?

Same behavior here. This is probably professional deformation but I struggle to see the “logic” here :

And finally, the blue to magenta sweep using spi-anim :

Maybe an optional LMT could be provided to remove the “going to white” if needed. But I don’t think it should be other way around since a majority of projects would require this behavior in my opinion. Happy to be proven wrong on any point. :wink:

Update with a new design requirement :

Please join the conversation !

Chris

3 Likes

Quite coincidentally, this came up while at was massaging iron at the gym:

Might need to pause at times!

Cheers,

Thomas

  1. The existing implementation pipeline and mechanic in ACES would already prohibit this from being even remotely possible.
  2. It should be noted that this is precisely the case where a radiometrically closed grade could be manipulated into any form, because the source chromaticities are actually perfectly preserved in the lower frequency gamut compress radiometric closed domain.

There is so much merit to treating the closed radiometric domain as an entirely valid grading and compositing point. Logos, lower thirds, “print” like grades, you name it.

Thanks guys ! I have done a silly but fun experiment with the Selena Gomez’ clip. I wanted to see if I could reach its look (should we call it clipped saturated colors’ look ?) with several DRTs.

I modeled the stage in Maya, threw some lights in there and waited approximatively 27 hours for render. :wink: Here is my reference :

For the CG renders, I used 0.18 midgray on most assets and the human skin patch from the CC24. I rendered in ACEScg with white lights and added the lights’ colors in Nuke.

Colours used for the lights are :

  • Green : ACEScg (0, 1, 0.3)
  • Orange : ACEScg (1, 0.25, 0)
  • Pink : ACEScg (1, 0, 1)
  • Red : ACEScg (1, 0, 0)

ACEScg render using sRGB (ACES) as a DRT (we can see the yellow skew with the orange light) :

ACEScg render using the “naive” DRT :

For the last example using TCAM, I used “different” chromaticities since my working space is Linear - E-Gamut. I reckon I could have tweaked the values to get closer to the reference but I am not sure if the comparison would have been fair ? I don’t know. Here are the values anyway :

  • Green : E-Gamut (0, 1, 0.3)
  • Orange : E-Gamut (1, 0.25, 0)
  • Pink : E-Gamut (1, 0, 1)
  • Red : E-Gamut (1, 0, 0)

ACEScg render using the TCAM DRT :

And since we were having this very interesting conversation about flames, explosions and orange/yellow tones, I think it is worth having a look at the orange light by itself.

sRGB (ACES) :

“naive” DRT (Is the orange skewing to pink ? Is my brain playing tricks on me ?) :

TCAM :

I have to say that I am quite happy with the TCAM “look” and would be interested to test more renders with it (like the EiskoLouise concert or my volumetric spotlights for instance).

I also tried to reach some very saturated yellows with ACES out-of-curiosity :


I was quite pleased with the result and I personally did not feel limited in terms of saturation.

On a side note, it is also worth comparing the contrast between these DRTs (especially the neck area) :

I think it is nice to have a bit of extra info in the shadows, such as with the naive DRT and TCAM.

I don’t know if those tests prove anything. From what I can see :

  • A “going to white” DRT such as TCAM does not necessarily prevent you to display very saturated colours.
  • I could probably reach a more saturated look by using a display linear grading with the naive DRT, even if we may not want go down that road (architecture-wise).

So, maybe I should add two design requirements to my personal wish list :

  • softer contrast (already listed in the paper dropbox)
  • the DRT algorithm should be compatible with the current ACES architecture or not ?

Regards,
Chris

2 Likes