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 #25, September 1st, 1pm PT

Attendees

Alex Fry
Kevin Wheatley
Scott Dyer
Nick Shaw

Rémi Achard
Lars Borg
Chris Brejon
Chris Clark
Francesco Luigi Giardiello
Jean-Michel Gilbert
Zach Lewis
Thomas Mansencal
Michael Parsons
Carol Payne
James Pickett
Matthias Scharfenberg
J. Schulte
Shane Smith
Jed Smith
Troy Sobotka

Meeting Notes

  • Kevin Wheatley: After last week's meeting we have the start of a spreadsheet with a list of viewing conditions and displays. And we have a Miro board of the flow of the current SSTS OT.
  • Alex Fry: Initially I was just doing a basic list of viewing conditions, without every permutation of gamma encoding etc., then Keven added a tab with more detail. sRGB is the one where the reality differs most from the specs. Nobody uses an 80 nit display, so what should we target? 250 nits in a bright office environment? sRGB was probably the most commonly used in the original ACES configs, as the default in Nuke. But the reality of 2.2 vs piecewise needs discussion. Well defined ones like DCI theatre are easier.
  • Lars Borg: Also for BT.1886, are we looking at reference conditions or practical use conditions?
  • Kevin Wheatley: We do have sRGB displays that follow the specs with 80 nits and 2.2 gamma, although not D50 surround.
  • Jean-Michel Gilbert: Many monitors use 2.2 gamma not the piecewise, but the OS profiles expect piecewise. scRGB expects 80 nits diffuse white, which is not the real world.
  • Thomas Mansencal: Actually many big shops do use 80 nits if people are doing comp work in a dark surround.
  • Lars Borg: For an Output Transform, shouldn't we target consumer living rooms where this is being viewed, not reference conditions?
  • Nick Shaw: I would argue against that. We've always mastered on a 100 nit display in a dark room, and the viewers with their 300 nit display in their living room have viewed stuff mastered at 100 nits, so what they see looks normal to them. If you master to deliver your creative intent on their 300 nit display, it will look wrong to them.
  • Kevin Wheatley: I found a lot of variation in the specs. I put 2.2 as the gamma for sRGB, because that's what is says in the spec I had (1998 version, section 2.1, item 4)
  1. Display input/output characteristic (R, G, and B)     2.2
  • I didn't search for every single standard, but I know with sRGB there is controversy.
  • Alex Fry: I've worked at a facility where half the monitors were 2.2 and half were sRGB, and we needed different transforms for each. The surround is up for debate. Should the sRGB OT assume a bright room? On-the-wire is simpler, but surround compensation needs to be baked into the image.
  • Jean-Michel Gilbert: I think HP and MS designed sRGB as a bright surround version of Rec.709.
  • Kevin Wheatley: I found a wide range of values for HDR surround. Some so close you wonder if the difference is significant. Sunny vs cloudy etc. Some docs say grading suite illumination is 5 cd, but elsewhere it says 10%. But that's 10% of something that can vary.
  • Jean-Michel Gilbert: You asked should we support other monitors than the display HDR list. I say yes. 1500 nits is becoming common, e.g. ASUS. Display HDR 400 and 600 are more common than 100 due to cost. 
  • Kevin Wheatley: We need to pick something, but give our implementation wiggle room in the parameters. Release a restricted subset.
  • Alex Fry: We don't want a default OCIO config with every variant, but we should test against a wide range.
  • Jean-Michel Gilbert: Display HDR 400 isn't HDR and needs to die! They don't even have to support beyond Rec.709.
  • Carol Payne: If we drop something included in previous ACES releases we need to explain why. I'm ok with limiting the list. We basically have two types of people - those who don't calibrate and need only SDR or HDR, and those who do calibrate and will know what OT they need. And game engines will be adapting to the scenario.
  • Alex Fry: It would be useful for a flip-booking application if it could adapt to the connected display, rather than hand off a 1000 nit buffer and let the display do some unknown mapping to e.g. 400 nits.
  • Kevin Wheatley: We can add another tab to the spreadsheet so people can make an include/exclude list. The Miro board shows where we are today with the order of the SSTS code as blocks.