2021-07-26 - OpenColorIO - Academy Software Foundation Wiki

John: All OSS projects are available under a license. While that license puts into place the downstream IP pieces, it doesn't consider areas where projects are aiming to drive an ecosystem. How vendors implement projects can be really inconsistent despite advertising support for a lib. Idea is to give community ability to define what it means to be in alignment with and compatible with a project. Might be APIs that need to be implemented, or specify how to interact with the project in a certain way. Helps customers identify which vendors help them achieve their goals. Vendors have to follow criterion defined by community and LF handles evaluation. Create a set of marks allowing vendors to say that they are conformant with the project and which specific versions. Can define downstream requirements for use in the ecosystem, to promote compatibility in upstream project.

Mark: Specific things driving this consideration?

Kevin: Helps with identifying features that an app must support for a complete implementation.

Carol: Can also guide how to handle data, working in 32-bit float for example. Make sure implementations are handling data properly. Also UX/UI stuff. How often does this fall into UX vs programmatic side?

John: There are different approaches. Can have series of tests to put app through. Including UX alignment. There's a lot of latitude on what you can do. Important to make sure there is clarity downstream, and be clear about how a vendor can evaluate this on their own.

Kevin: Someone could claim to be OCIO v2 compliant, but only implement v1-style GPU rendering. Those things would be good in a compliance program. Could have acceptable threshold levels for image output and comparison.

John: Yes, those are exactly how projects are implementing this. Some items can be optional. Doesn't stop anyone from implementing things their own way, just creates a standard.

Kevin: If someone is implementing ACES through OCIO, we need a way to verify that too, to honor ACES.

Mark: Software can be patched and used in many ways. Don't see a current problem needing this, but open to it. Will be up to the DCC wanting the label. Apps can continue to implement things their own way.

Carol: Can see it as a program to help DCCs, not as a restriction from using OCIO. For those implementing OCIO for the first time, this specifies a baseline, and a recommended approach, which is helpful. Some implementations are very varying right now. Different usages may also have different implementations, but the more prevalent OCIO gets, we should have a baseline of features to implement correctly.

Michael: How long to set something like this up?

John: Biggest task is coming up with criterion and getting alignment around that. Need to walk through the legal side of things too, and handle things like evaluations and forms, etc. Doesn't take too long though - a couple months overall. Typically with this program, there is a program fee in place, but most projects wave it for those involved in the project. Ensures the vendor is getting a benefit from meeting standards.

Carol: Makes sense as a next step for the project. Goes beyond supported app page on website.

John: Other side of conformance programs is that they are run as a self-conformance program. Projects will make this available so outside parties can indicate when apps aren't following guidance.

Carol: Self service make sense.

Doug: How do you handle new versions?

John: Project makes set of marks for a version, which are lasting. If a new version is released, new marks are added and vendors need to resubmit. Existing conformance is kept though.

Doug: One of the problems with ACES v1 is that they put the bar very high (needed to implement ACES clip, etc.) and I don't think any software companies ever got the logo (although camera companies did). The other problem ACES had was they needed to have different sets of requirements for different types of products. Not sure we would have the same problems (e.g. no OCIO cameras or monitors).

Mark: Maybe good first step is to list things like looks which need to implemented certain ways.

Kevin: Yes, like a feature matrix. If vendors are leaning on this for ACES compliance, also need images for verifying quality, and to what level (preview, production, etc)

John: In response to Doug, yes having too many sets of requirements for different uses can be problematic. Good to start smaller with lower complexity.

TODO: Proposed making this the next step following UX guidelines completion.