Kevin Wheatley: Scott wants to bring something up he and Thomas discussed on Slack, and I came across some things reimplementing the transform in Blink.
Scott Dyer: The list of transforms in the v2 developer release includes a number of forward transforms with a limited gamut in a larger encoding one. In v1 we did not include separate inverses for those. We just has e.g. a Rec.2020 inverse, so anything within P3 in that would round trip back to within P3. Now with our chroma and gamut compressions I would expect there to be a difference between inverting a whole container and a limited gamut within that. I tried to do some modeling, and I ended up with NaNs from the inverse when I ended up with negative J going into inverse chroma compression. It's either a bug, or something we need to trap for.
Nick Shaw: Is this what happens when you try to invert a value outside P3 through a P3 limited transform?
Scott Dyer: I used the ACES Macbeth chart values through a forward transform, which I would expect to be valid. Adding explicit inverses for the limiting gamut seems like overkill. But maybe not.
Kevin Wheatley: The way I see it, a Rec.709 limited transform inside Rec.2020 should produce the same result as the Rec.709 transform. So the inverse would be to de-encapsulate it from the Rec.2020 and use the Rec.709 inverse. There are two aspects. Have we found a bug? And what is the expected behavior?
Nick Shaw: Using a Rec.709 inverse do you need to clamp the Rec.2020 to Rec.709 to limit it to meaningful values before inverting?
[Alex showed in Nuke various combined forward and inverse pairs]
Alex Fry: I'm only seeing small round trip differences in the fifth decimal place.
Scott Dyer: Maybe I made a mistake.
Alex Fry: When I do a forward and inverse of a full 10000 nit Rec.2020 cube I get a weird shape outside a'cone of reasonableness'. We never tried to fill that cube with plausible AP1 values.
Thomas Mansencal: Why can't we do that?
Alex Fry: Our path to white will mean we can't hit some values.
Kevin Wheatley: So we can't invert that. We've only got to P3 and Rec.709 filling the cube. I would expect to be able take a full display P3 cube, embed that in a Rec.2020 container, and invert that and then when I go forward again get back something close to where I started. What's the difference between inverting full Rec.2020 and the P3 limited version? You'll get back different numbers, but it should work.
[Alex created a P3 in Rec.2020 round trip test]
Alex Fry: Most of it round trips, but we loose a little bit at one edge.
Kevin Wheatley: Those look like negatives, which we would expect the transform to force positive.
Nick Shaw: Why are we starting with any negative values?
Alex Fry: The P3 primaries are not all completely inside Rec.2020, so full P3 ends up with a few negative Rec.2020 values.
Kevin Wheatley: We're assuming somebody knows the limiting gamut of the container they are inverting. We should look at what happens if they don't and there are values outside the limit. We can use that as an example to show people why they shouldn't do that, and are better just using the right inverse from the limiting gamut. It may be you can just go backwards through full Rec.2020 as long as you go forwards through the transform afterwards. The inverse is not designed to create the best source pixels. It's just to create values that map back close to where you started.
Thomas Mansencal: From a UX standpoint we should pick a set of inverses and clearly document the reason only those are provided, and which should be used.
Nick Shaw: I feel we should only provide inverses for e.g. ST.2084 P3-D65, and then you can go forward either through the same or P3-D65 limited Rec.2020. Don't start with Rec.2020, because the inverse of values outside P3 is undefined.
Alex Fry: We clamp the forward transform, so we could clamp the inverse to the limit.
Kevin Wheatley: I'm against hard clamps unless there is a good reason. What do those values invert to? And where will they round trip to? If they break we may need a clamp. Or clamping is a parameter.
Nick Shaw: Because the forward transform clamps the input to AP1, something that inverts to outside AP1 will get skewed onto the boundary.
Alex Fry: The P3 red primary is non-physical, and outside Rec.2020.
Kevin Wheatley: We should note that embedding P3 into Rec.2020 produces negatives.
[Alex showed round-tripping the ARRI bar image]
Kevin Wheatley: We haven't tested, but we can't round trip full Rec.2020. We need to list out what ranges we can round trip from display referred. If there isn't enough room between e.g. Rec.2020 and AP1 for the compression it won't round trip.
Nick Shaw: In my fork of aces-docs I've converted the PDF I wrote on the gamut compression into Markdown, as a step towards final documentation. You can preview it in GitHub, but to see it properly with all the images you need to run the Docker container locally.
Kevin Wheatley: I started writing a Blink version with only the options in the CTL version. I didn't complete that. I hope to have that done by next week. It's almost half the number of lines of code of v59. Going though the code, I noticed a few things, such as the lower hull calculation being used more times than the upper one.
ACES Output Transforms VWG
Meeting #151, May 8th, 1pm PT
[Meeting Recording]
Attendees
Meeting Notes