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 #177, January 22nd, 12pm PT

Attendees

Alex Fry
Kevin Wheatley
Nick Shaw

Ake
Rémi Achard
Daniel Brylka
Carol Payne
J. Schulte
Doug Walker

Meeting Notes

  • Nick Shaw: Pekka has opened a PR for the Blink.
  • Kevin Wheatley: It makes three small changes to bring it up to date with the CTL.
  • Nick Shaw: The CTL commits are noted in the PR. It's now called ACE2 DRT v001.
  • Alex Fry: I've merged it. I should generate new LUTs.
  • Kevin Wheatley: My latest update goes quicker but changes some pixel values slightly. This may alter the round tripping we'll talk about later. I've replicated my previous redistribution of the hue tables, and a couple of minor changes. I'll look tomorrow at adding that to the GPU path. One thing I haven't looked at yet is what Nick mentioned on Slack about using A from the middle of the XYZ to JMh calculation when going back to Y, to cut out the J to A step. The achromatic conversion to J is the highest on the list of slow-downs.
  • Nick Shaw: It's unfortunate that the chroma compression needs both uncompressed and compressed J, or you wouldn't need to go all the way to J first time round.
  • Kevin Wheatley: I wonder if it's possible to do the chroma compression without uncompressed J? Now the gamut compression is not that different to the tone curve, in terms of time. It may be the profiler.
  • Alex Fry: How different are the pixels?
  • Nick Shaw: It's just a different approximation of the same curves, just sampling them in different places.
  • Kevin Wheatley: Nick and Pekka had a discussion about pre-calculating cuspintersections.
  • Nick Shaw: The cusp intersection would be constant for a given hue if it weren't for the focus_gain above a threshold. So if you ignored that it could be pre-calculated in a table. Is it worth an extra table and interpolation errors?
  • Kevin Wheatley: I'll investigate when I look at Pekka's other suggestion of replacing pow(x, 1/0.55) with x*x. That's it for me. There was discussion on Slack of round trips. Should we be able to invert everything.
  • Nick Shaw: Doug found that 1000 nit P3-D65 has missing bits of the cube after a round trip. Looking back, we agreed that we needed to round trip SDR Rec.709 and P3, but knew we weren't able 
  • to round trip HDR. Is that a problem if people can't hit those corners, which are quite extreme values in HDR.
  • Alex Fry: Certainly not Rec.2020, or anything above 1000 nits.
  • Nick Shaw: Even P3 at 1000 nits doesn't quite round-trip. Do you need 1000 nit cyan in a logo? Looking at the Reveal P3 PQ LUT, it doesn't go near those corners, so I don't think it's a problem for LMTs. Might graphic or animation people want to hit those corners?
  • Alex Fry: I don't think so.
  • Carol Payne: It just needs to be clearly documented what the expectations are. That will need to go into OCIO too.
  • Nick Shaw: What was the ACES 2.0 document you mentioned that talked about a two 12-bit code value tolerance?
  • Kevin Wheatley: The CTL doesn't achieve that, even in SDR. I think it means implementations need to be within two 12-bit code values of the CTL output of the round-trip. Except OCIO is not ahead of the CTL.
  • Kevin Wheatley: The CTL update will then need to match OCIO to that tolerance.
  • Doug Walker I had thought after a round trip it should be that close to the original image. I found it was ~400 12-bit code values. The document needs clarifying. I said I would write unit tests, and started from those cube images as the most sensitive test. I need to come inside the gamut to find values which will round trip.
  • Kevin Wheatley: My code is within 8 or 9 bit precision for a Rec.709 round trip. Most errors on the three cube faces nearest black.
  • Nick Shaw: Might that be due to the fixed lower hull gamma?
  • Doug Walker 8-bit is better than I was seeing from OCIO 2.4.1 or CTL.
  • Kevin Wheatley: I didn't search for the largest error. I was looking at patterns to help pin down the source. It's noise like, so could be because one component starts at zero.
  • Nick Shaw: In my DCTL I was seeing some zero channels round tripping to ~1% in SDR. HDR is less good, although most of the inner values do round trip.
  • Doug Walker Is it useful if I write SDR round trip unit tests with 2% tolerance?
  • Alex Fry: We need to look at the full cube as well as the faces.