Meeting Summaries 

ACES Output Transforms VWG 

← Use sidebar to navigate to a particular meeting.
Use Cmd+F or Ctrl+F to search this page.

Meeting #37, January 12th, 1pm PT

Attendees

Alex Fry
Kevin Wheatley
Scott Dyer
Nick Shaw

Rémi Achard
Lars Borg
Daniel Brylka
Chris Clark
Alex Forsythe
Jean-Michel Gilbert
Thomas Mansencal
Carol Payne
Joshua Pines
Matthias Scharfenberg
Daniele Siragusano
Shane Smith
Troy Sobotka
Mike Whipple
Joachim Zell

Meeting Notes

  • Alex Fry: I've been looking at why Matthias' implementation looked different to mine. I realized I was using the original c9 curve for SDR, where Matthias was using the 100 nit SSTS curve. I made a version of his node with selectable curve, including c9, SSTS and Kevin's "average real production" curve. Kevin's curve is remarkably similar to the 100 nit SSTS, which we don't normally see, because the current SDR renderings are all based on 48 nits. So 100 nit SSTS may give us the lower contrast we've been asked for.
  • Kevin Wheatley: My data needs cleaning, because it doesn't quite hit 100 nits, and the bottom rolls of too much. I've looked again at the Doug Walker / Gary Demos presentation. They were looking at a curve with end points that we straight lines in log/log. Maybe we should add something similar to that to the SSTS. That does raise questions about handling of shadows and highlights, and how we might put that into an LMT, but the principle is interesting.
  • Nick Shaw: Won't a straight line on a log/log plot never reach zero? Might that be a problem for colorists who wand CV 0 output.
  • Kevin Wheatley: You could maybe target zero out for zero in. My average data is just a way of quantifying what people mean by "lower contrast". It's a guide not an exact target.
  • Thomas Mansencal: Have you tried fitting a curve to it?
  • Kevin Wheatley: Not yet. We need to think what the slopes should be at the ends. That's why I rewatched Gary and Doug's SMPTE presentation In some of their work there is discussion of how you should map grey, and if it should be relative to display brightness and surround. Also is a 709 display as our middle ground reference is a good idea. Should a real HDR display be the reference and we map down? Or a virtual display like OCES?
  • Thomas Mansencal: In this time an SDR reference seems retrograde, and HDR make more sense.
  • Kevin Wheatley: OCES has advantage, but also the disadvantage that there is no real display to validate.
  • Thomas Mansencal: Have the BBC done a recent survey of consumer displays?
  • Kevin Wheatley: Not that I am aware of. Many now may be more than 1000 nits, but we don't have t chase manufacturers. What is our professional display target?
  • Alex Fry: If manufacturers make 500 nit SDR displays, it's up to them to make them to make 100 nit content look sane on them. I've also done some experiments with varying the scaling of the input data for ZCAM, which has a big effect on saturation. The original choice of 100nits was slightly arbitrary, and not necessarily appropriate for outdoor scenes. Going above 100 rapidly goes nasty rapidly on skin tones.
  • Kevin Wheatley: Is this a function of the surround value. It's like a transparency where the backlight is brighter than the surround environment. That is what happens if your backlight is too bright.
  • Daniele Siragusano: If you raise the output exposure, does it desaturate in the same way?
  • Nick Shaw: I just checked my DCTL implementation, and the effect of varying the surround value is pretty minimal. But It's possible I hard coded the default value of 10 in there somewhere.
  • Daniele Siragusano: This is the value you want to vary to control the colorfulness of your rendering. You're setting up the brightness of your golden scene.
  • Jean-Michel Gilbert: I used 201 nits in my tweaked version. It enabled me to see some subtle red fog in one screen of our game I hadn't noticed before.
Jean-Michel Gilbert showed a comparison of his tweaked ZCAM DRT, and Open DRT, which he had posted about.
Matthias showed some visualizations he has been working on of hue slices in JMh, showing gamut boundaries at different hues.
  • Matthias Scharfenberg: I am looking at gamut compressing along a different line, so instead on only in M towards the J axis, it compresses up or down in J as well, perhaps towards the J value of the cusp of the target gamut at that hue. I don't have anything to share on that yet.
  • Nick Shaw: I'd be interested to look at the output of my DCTL implementation of the ZCAM DRT using that visualization tool, to see how my iterative approach to the gamut compression compares to the 2D LUT implementation.
Nick showed his DCTL implementation of the ZCAM DRT and explained the various parameters.