2025-01-20 TSC Meeting notes

New GH Action to deploy web site

Doug: Thank you to Zach for a new PR to improve the generation of the website. How does it work? Zach: This will make the gh_pages branch unnecessary. The site will be generated on the Actions runner via Hugo, using the contents of the docs/site directory. People will still be able to run Hugo locally to preview their changes. Mark R: It won’t run on people’s forks? Zach: That’s correct, only want the website updated from the main repo, after a PR is approved. Sean: Is it a problem that the updates go live immediately rather than being synced with an official release? Doug: Our ReadTheDocs integration also goes live immediately and that is where all the documentation is. The website from Hugo is only the landing page and so it should not be a problem. Zach, once we get a review of the PR I will reach out to you so we can merge it together and ensure it is running as intended.

TSC Meeting time

Doug: Thomas has a standing conflict with our current TSC meeting time, so we’re trying to find a new time. Carol proposed staying on Monday but moving one hour earlier, will that work for people? Mark Reid, that will be very early for you, is it ok? Mark R: Yeah, it’s 6 am, but it would be ok. Doug: Remi, Kevin, Mark B., Sean, does that time conflict with your dinner, or is it ok? All: Yes, one hour earlier is ok (actually better for some). Zach: Is it ok for you (still middle of afternoon)? Zach: Yes, I can make it work. Doug: Great, we will try moving it one hour earlier for next time and see how that works out.

OpenAPV

Doug: Samsung has joined the ASWF and their OpenAPV video compression codec has been accepted as a sandbox project at the ASWF. OpenAPV is setting up a TSC and would like to have representation from OCIO. Kevin: I’m interested and am in discussion with Sam Richards to see if the meeting time will work.

ACES 2 implementation

Kevin: I’ve been working on splitting the hue table out of the cusp table. This avoids polluting the cache with unused J/M values and is a first step towards further hue-lookup optimizations. It’s working on the CPU and am working on the GPU port. (Have noticed that the shader code has many opportunities for optimization too.) As with some of the other optimizations, it will change the results slightly along the edge of the gamut.

Doug: I’ve been looking at writing additional unit tests. Was looking at the “cubes” test images that are part of the supplied validation materials but am noticing that the round-trip is not accurate. Might need to move inside the cube in order to get unit tests that pass, any suggestions? Kevin: There is a point at which the gamut compression transitions to using a Reinhard-type roll-off, perhaps make a ramp at that point. Any place where the target gamut is close to the AP1 gamut, the compression function will flatten out and might not have enough precision to get an accurate inverse. The neutral axis tone-scale, by design, preserves a non-zero slope up through the max white value, so that should be less of an issue.

Remi: I have Nvidia NSight (non pro version) working on a Windows machine with an Nvidia GPU. Using sample code provided by Eric, since NSight doesn’t work with OpenGL, needs Vulkan or DX12. The program processes a ramp, not an image. Seeing similar results as Eric, which is that ACES 2 is about twice as slow as ACES 1. The gamut compression takes about 2/3 of the time, so it’s a good subject for optimizing. It looks like texture look-ups are a bottleneck.

Color Interop Forum

Doug: The next Color Interop Forum is scheduled for next Monday, we’re thinking of proposing OpenEXR color management as the next work item for the group. Nick will be mentioning this at the OpenEXR TSC meeting this week.