Alex Fry: The main thing that's come up recently is invertibility of SDR P3. We're getting a tiny bit of clipping on a round-trip.
Pekka Riikonen: I made a v58 that does round-trip in P3. It means Rec.709 is a bit more clipped because the intersection is puffed out a bit more. It's not a huge amount. It's because our gamut intersection is only an approximation so we always need to expand a bit. The approximation seems to get worse for larger gamuts.
Nick Shaw: And is 100% P3 round tripping essential to people?
Alex Fry: I think these days we need to be able to say we can hit the corners of P3. If we're clipping the input to AP1.
Nick Shaw: Could we expand the input clip just outside AP1?
Pekka Riikonen: I did experiment with clipping to the chroma compression gamut, and that worked.
Nick Shaw: I suppose people expect to hit the boundaries while working in positive AP1.
Pekka Riikonen: This post shows the changes in v58.
Alex Fry: If we need to change the lower hull gamma for P3, should we just use a solve for it.
Pekka Riikonen: Our solve gave gamma values that were unnecessarily large.
Alex Fry: It feels wrong to compromise Rec.709 just for a P3 round trip. Could we store different parameters for different gamuts.
Nick Shaw: Then it doesn't generalize to any gamut.
Alex Fry: We could document how we derived the values.
Nick Shaw: How visible is the extra Rec.709 clipping.
Pekka Riikonen: It's not visible until you gamma up and look at clipping.
Nick Shaw: And the core rendering obviously doesn't change at all.
[Pekka showed the difference between v57 and v58 with gamma raised]
Pekka Riikonen: Red actually clips less, but blue clips more. There's maybe a little more noise. v56 had more clipping.
Alex Fry: If we have to increase the gamma for P3, we'd have to increase it even more for Rec.2020 if people could see that.
Scott Dyer: Ideally we would round trip any gamut. But we need to ship something. My CTL now matches the Blink. That's when I plotted round trips and noticed small P3 differences. If v58 solves that we have to admit it's not perfect but lock it down. We've improved on the things we set out to. I have made an LMT which matches the v1 tonescale. I've updated the surround adjustment code, so it is just a luminance gamut the same size as in ACES 1. It's off by default, but the code is in there.
[Scott showed the code where the surround adjustment is applied]
Scott Dyer: I put it after the clamp to peak luminance, but before the white point scaling for any"sim" encoding.
Alex Fry: DO we need it for HDR? We didn't have it before.
Scott Dyer: Maybe not
Nick Shaw: It's off for now, but gives people the option if they think it's necessary.
Pekka Riikonen: Should vendors expose it?
Scott Dyer: Probably not to end users. We should probably only expose primaries and white point of the limit and the display, and the display EOTF. Other things are for advanced users.
Nick Shaw: Has the built in Output Transform function you just pass parameters to for a custom DCTL ODT, if you are not writing the processing from scratch. We probably only want to expose a similar set of parameters in there to what is there currently.
Alex Fry: There's a question in the chat, about"would a Rec.709 image look the same on a P3 display?" If the source fills a lot of AP1, no. Values on the edge will extend more into P3. If you have a display referred Rec.709 image and put that though the inverse Rec.709 and then forward P3 transforms, again it will be expanded at the edges into P3, along the same hue line.
Nick Shaw: But a Rec.709 red primary won't end up as a P3 red primary. It will be on the edge of the P3 gamut, but along from the primary at a more orange hue.
ACES Output Transforms VWG
Meeting #148, April 17th, 1pm PT
[Meeting Recording]
Attendees
Meeting Notes