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 #162, July 24th, 1pm PT

Attendees

Alex Fry
Kevin Wheatley
Scott Dyer
Nick Shaw
Rémi Achard
Jeffrey D Mathias
Willem Nagtglas
Pekka Riikonen

Meeting Notes

  • Kevin Wheatley: We need to end this meeting on the hour so Scott and I can attend the ASWF OCIO town hall Mainly this week we need to go through the changes Scott has for release candidate 2.
  • Nick Shaw: As I mentioned last meeting I tested making LUTs with a log2 shaper covering the full range required. They seem to work fine for SDR, but for HDR they don't quite work. For most images they look fine, but ACEScct works fine for most images. Stretching the range to cover what we need for HDR there is a visible difference in strong magentas like the ARRI bar and Rec.2020 spheres. I need to investigate why that is.
  • Scott Dyer: For the last few weeks we've discussed things which are bugs or that we want to change for rc2. I have a list of commits which address those, and have written up a change log. If everyone here agrees, I think we are ready for rc2. I've compared the results with rc one, and apart from a couple of bugs I found and fixed, they match.
[Scott showed the commit list and corresponding issues, and went through them one at a time]
  • Remove primaries from namespace (housekeeping)
  • White scaling changed to a bool control, giving direct control rather than a condition
  • Simplify gamut compression compress function, removing power functions and unused parameters
  • Reorder EOTF enum
  • Remove unused smoothJ
  • Update transform IDs
  • Housekeeping and change log
  • Scott Dyer: In aces-output I added two top level directories for D60 and D65. The file names are now fully descriptive. The D60 folder duplicates D65 transforms but with a different limiting white and white scaling enabled.
  • Kevin Wheatley: The two trees make sense to me. The question is whether we tell implementers both trees are required? The organization of the mid level directories is up for debate. Those are organized by user-focussed names. It depends who the directory organization is intended to make it easier for. Somebody parsing it in code could ignore the mid level, because the names fully define the transforms. So the user names may be easier for more casual end users looking in GitHub.
  • Nick Shaw: This organization means that transforms which are the same rendering but differently encoded may be in different directories.
  • Kevin Wheatley: whether we need to provide D65 and D60 for everything is a high level TAC decision. If we want to be backwards compatible we need both. Although we've remove some so we're not 100% backwards compatible.
  • Alex Fry: What's the official ACES line on D60? Arguably only D60 is 'the correct way'.
  • Nick Shaw: D60 was only the default for theatrical. For SDR and HDR video it was always native D65 white.
  • Kevin Wheatley: I think we have to provide both, and recommend people don't make it a giant flat list.
  • Alex Fry: It makes sense that people make a top level decision on their white point, and everything below that only uses that white.
  • Scott Dyer: And it keeps "D60 sim" away from people who don't use or understand it.
  • Kevin Wheatley: We should snapshot the spreadsheet as a CSV or something to go with this release.
  • Scott Dyer: One other change I made was Nick's suggestion of making the linear scale factor 48/100 instead of 0.5 for all the cinema outputs. That makes it consistent. The only issue I haven't addressed is handling of Inf and NaN.
  • Kevin Wheatley: The clamp to 8x r_hit may deal with Inf, and possibly NaN, depending on how an implementation of the clamp works.
  • Scott Dyer: I'll test what CTL does. Are people happy with the other changes?
  • Kevin Wheatley: I think all those can be closed except the NaN issue.
  • Rémi Achard: I noticed a duplication of a table lookup which could be removed. Once in compressGamut() and once in getReachBoundary().
  • Kevin Wheatley: That's removed in my implementation, because you can get the value once and then pass it in.
  • Rémi Achard: The chroma compression curve approximation is not in rc2, correct?