2021-04-19
- Michael Dolan
- doug walker
April 19, 2021
Host: Michael Dolan
Attendees:
OCIO TSC Working Group Meeting Notes
Talk about a 2.0.1 version:
Summary: TSC agreed to cherry pick PRs 1303, 1306, 1324, 1336, 1338, 1339, 1350, 1351, 1352, 1353, 1365, and 1370 for a v2.0.1 release. This patch release is focused on big fixes and compiler support. No new features. All PRs have already been approved and merged so will be cherry picked to the RB-2.0 branch. Group agrees to allow fast-track merge since all work was already approved in original PRs. This release does not break ABI compatibility.
Talk about a 2.1.x version for CY2022, and communicate it to VFX Reference Platform:
Summary: VFX ref platform presented at last weeks TAC meeting. Current proposal for CY2022 still has OCIO v2.0.x. If we want to change that version we need to have a compatible release by about SIGGRAPH time frame for it to be accepted. TSC agrees to request a change to OCIO v2.1.x and target a release by September. v2.1.0 will include removal of the recently deprecated legacy GpuShaderDesc constructor, which was replaced by a new constructor which solves OCIO v1/v2 parity issues. The new version will also include an implementation of the ACES 1.3 gamut mapping transform. Other changes must be merged by August to be considered. Bug fixes can continue to be made following the v2.1.0 release without impacting the VFX ref platform specification.
ACES gamut mapping transform discussion:
Michael: What's the anticipated timeline for implementing the gamut mapping transform?
Carol: Think it could get done this summer. A lot of it is on us deciding preliminary implementation details up front. We could move forward with getting ready for it.
Michael: Will it be a parametric transform or just a builtin?
Carol: Could go either way.
Kevin: Think we should do both but only attach ACES name to the fixed implementation. It's beneficial to avoid confusion of changing ACES.
Carol: Have to discuss approach for OCIO.
Doug: Needs to be fixed function to support that math. Could have parameters, and have builtin version which hardcodes those parameters.
Carol: Current limitation is with AMF tracking parameters.
Michael: Fixed function transforms receive an arbitrary list of params, so can be more of an advanced interface for those who need them.
TODO: Michael will reach out to VFX ref platform about bumping OCIO to v2.1 for CY2022.
CLA switchover status check:
Summary: The new CCLA is available to be signed in EasyCLA. Autodesk, Netflix, and Epic Games have signed it. We will reach out to community about the change to give opportunity for others to sign it before the switch over in May. Both CCLAs are available in EasyCLA so can be signed side-by-side now.
TODO: Michael will inquire with John Mertic as to other corporate contributors who have not signed yet, to notify them of the change.
Verifying the config environment section:
Doug: Patrick and I have been looking at section in config called "environment". Was in v1 but was not widely used. Turns out there's a big performance boost in some situations by using this. It allows you to declare the context variables used in config. Tell OCIO what they are. Otherwise OCIO uses the entire environment, which in a big studio can be large. In v1 ociocheck and validate() did not check this section to see if it was present. In v2 we added validation steps which are being improved for v2.0.1. Can declare env var with context var and default value, or specify that there is no default and it should be taken from environment. Trying to now check that this is valid. The complicated section is when variable is defined in terms of another variable. We're wondering, does anyone use anything more complicated than FOO=$FOO in this section?
Summary: OCIO supports nested (recursive) variable expansion (which in v1 could cause a crash from an infinite loop), but the TSC agrees that this "environment" section of the config is intended more for simpler declarative use and so validation doesn't need to handle recursive evaluation of variable names or defaults. Proposed validation changes won't affect use of the config, but will simply check whether the variables exist and have a default.
Issue 1369 discussion: Add optional view transform to ColorSpaceTransform:
See discussion in: https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/1369
Michael: Think there are three possible outcomes of this discussion:
Add view transform support to ColorSpaceTransform, exposed on tools that implement it to provide flexibility to work with scene and display referred color spaces.
Don't change ColorSpaceTransform, but change UX so that tools implementing color space transform can only transform between like-referenced spaces, encouraging use of a DisplayViewTransform to transform between scene and display referred spaces.
Don't change anything. Encourage proper use through documentation, and potentially warn on tool interfaces (UX) when a transform is between a scene and display referred space.
Doug: Complicated issue from use point of view. In OCIO there are three types of color spaces:
Pure scene referred spaces (ACEScg, ALEXA Log C)
Pure display referred spaces (sRGB, Rec. 709 monitor)
Color space with view transform builtin (had to be done in OCIO v1, baking in RRT/ODT, etc.).
Doug: For color scientists these aren't all color spaces.
Kevin: Yes, it's a shoehorning in of various concepts.
Doug: In v2 wanted to give config authors opportunity to clean this up. In perfect world (user point of view) could offer user color space transform that does unit conversion (ACEScg → ACES2065-1), Same color, just encoded differently. DisplayViewTransform tool would then convert between scene and display color spaces. The problem is we still have OCIO v1 configs, with the third category of color space, like with the v1 ACES configs. Question is how do we disentangle that?
Carol: Have to be careful. Ideal would be to separate them and not make it possible. Reality is in houses without color scientists or ability to edit configs, rely on the ability to use the baked in view transform. Some studios turn off Nuke viewer and only use color space nodes. Would be work getting everybody to use the new thing, which isn't a bad idea, just more to consider.
Kevin: In agreement we should reduce chances of people doing the wrong thing from color science perspective.
Carol: Maybe a combo for now. Introduce the correct way alongside current way.
Kevin: In Nuke terms, there is OCIOColorSpace and OCIODisplay. Could see new display view transform with full description of changes. Could probably make that compatible in Nuke.
Doug: Like the idea of doing gradual transition. Could introduce DisplayViewTransform and encourage people to use it, and have warning when ColorspaceTransform is not doing the right thing. And then later make it more rigorous.
Kevin: Could have variable in config about strictness too.
Sean: Could the default view transform be set?
Michael: Yes, currently when transforming between scene and display referred space the default view transform is used, but in new ACES configs this default to "Un-tone-mapped", so won't do what a user might expect. But yes, the config could set the default to the correct view transform to solve it, but it gets tricky since if using the builtin ACES transforms in OCIO which has many view transforms, depending on the display/view being used.
Sean: Sounds like its about config compatibility. Have to present a color space which combines the view and look transforms you need during this transition period, to use with regular color space transform.
Doug: Yes. If apps have DisplayViewTransform tool would be ok, but if some don't have that, and only have color space transform, have to use workaround.
Issue spotlight:
Michael: Some interesting issues to solve if anyone is looking for a task to work on: See issues 1367, 1362, 1360, 1359, 1240.
Doug: 1359 is candidate for v2.1.0. 1360 is candidate for v2.0.1.
Items for next meeting agenda:
Future discussion: OCIO ACES gamut mapping implementation