From 22a5f55548747265e55a6cc4e3b129b1e9fb8ec8 Mon Sep 17 00:00:00 2001 From: Michael Dolan Date: Thu, 2 Jul 2020 02:50:30 -0400 Subject: [PATCH] Add Config working group notes 06-16-2020 (#1040) Signed-off-by: Michael Dolan --- docs/tsc/working_groups/configs/2020-06-16.md | 232 ++++++++++++++++++ 1 file changed, 232 insertions(+) create mode 100644 docs/tsc/working_groups/configs/2020-06-16.md diff --git a/docs/tsc/working_groups/configs/2020-06-16.md b/docs/tsc/working_groups/configs/2020-06-16.md new file mode 100644 index 0000000000..6b54c7cd11 --- /dev/null +++ b/docs/tsc/working_groups/configs/2020-06-16.md @@ -0,0 +1,232 @@ + + + +June 16, 2020 + +Host: Michael Dolan + +Rotating Secretary: Michael Dolan + +Attendees: + * [X] Mark Boorer (_TSC_) - Industrial Light & Magic + * [X] Sean Cooper (_TSC ACES TAC Rep_) - DNEG + * [X] Michael Dolan (_TSC Chair_) - Epic Games + * [X] Carol Payne (_TSC_) - Netflix + * [X] Doug Walker (_TSC Chief Architect_) - Autodesk + * [X] Kevin Wheatley (_TSC_) - Framestore + * [X] Matthias Scharfenberg - Industrial Light & Magic + * [X] Dennis Adams - Sony + * [X] Thomas Mansencal - Weta Digital + * [X] Michael Parsons - MPC + * [X] Chris Clark - Netflix + * [X] Rémi Achard - DNEG + * [X] Troy Sobotka + +# **OCIO Configs Working Group Meeting Notes** + +* Working group direction: + - Michael: Goal of group could be to design and develop the next gen ACES + config, but also to maintain it long-term. Do we want to make it a formal + working group with dedicated leadership? + - Thomas: Good to formalize the group. Current ACES config work is done + when there is time. There's not a good commitment which can lead to + delays. Group would be good for prioritizing work. + - Sean: Should it be distinct from OCIO TSC, or a subgroup? + - Mark: Division of power is better. There's some overlap, but the OCIO TSC + is more dev centric. This is more user centric. + - Michael: There could be a formal chair, or co-chairs, but without a + formalized group. + - Sean: The TSC has the benefit of governance structure. + - ACES will likely be involved to support the work, but the goal from our + previous meeting was for OCIO to own the ACES config. + - Carol: We just need to make sure the OCIO TSC is represented in the + group. + - Michael: Studios will become highly dependent on this config, so it + will be important work. + - Mark: Software vendors (i.e. Foundry) will also be dependent on it. + - Thomas: Vendors are already asking about it. + - Michael: Anyone interested in leading the group? + - Sean and Matthias will co-chair. + +* Config structure: + - ACES reference config, studio in a box, or both: + - Michael: As discussed, could potentially have one code base which can + create an ACES reference config (minimal), and the big "studio in a + box" config. + - Mark: If nobody is using the reference config, there's no point in + duplicating efforts. + - Thomas: The smaller config is a subset of the bigger one. May not + need everything depending on what you are using. A base. + - Kevin: We will often take a stock config and strip out stuff not + needed. Depends on distribution. How we generate it could lead to + module configuration. + - Doug: Does seem like build settings to select options would be good. + Pure ACES model is good for OCIO as an ACES product partner, to + submit the implementation to the ACES logo program. + - Carol: Something to be said for ACES transforms being builtin to OCIO + v2. Not needing external files is nice. + - Mark: If you have multiple things to release, people have to make a + choice of what they use. People who want the studio in the box will + be upset depending on what DCCs choose as default. Lose benefit of + consistency. If we up front have minimal ACES only, that has some + value. We should be clear about what we’re giving out. + - Matthias: Will the config be OCIO v2 only? Is it backwards + compatible. + - Sean: Needs to be backwards compatible. We’re probably the wrong + people to answer this question. Should ask community what they want, + rather than deciding on something. + - Thomas: Breaking backwards compatibility makes migration hard. + - Carol: We might get polarizing opinions. + - Mark: Almost feel whole idea of giant config is atypical of how OCIO + works. People are supposed to have their own configs. May as well + build everything into the library at that point. + - Carol: Some just use whatever config ships with an application. + - Michael: Think it is useful to support ACES-only reference for + checking against ACES, etc. + - Thomas: ACES would like this config to be “the” config, to make + exchange between studios easier. Something ready to use out of the + box seems to be desired. + - Doug: Some projects, Like MaterialX, want to make this config their + default. + - Thomas: That could be done for USD as well. +- Utilizing OCIO v2 BuiltinTransform, and CLF where needed: + - Michael: The implementation could focus on utilizing BuiltinTransform, + and CLF where external files are needed, since CLF is the ACES format. + - Doug: If Academy publishes transforms in CLF as well as CTL, would be + interesting. + - Mark: Doesn't hurt to use it. + - Doug: CLF also supports metadata. + - Thomas: We currently ship ICC profiles, for things like Adobe tools. Need + those for wider support. We could provide scripts to help people generate + ICC profiles. Would result in simpler package. + - Mark: ICC profiles generated with ociobakelut often need to have + additional stuff injected into them from an external script. Cant just + use ociobakelut directly necessarily. + - Kevin: Repo should mostly be Python code, and generated artifacts. + +* Repository: + - Python code base + - Store generated config in repo? Or only as build artifact? + - Mark: Nothing in repo but code. + - Michael: We discussed previously if we should include the generated + config in the repo for reference. + - Thomas: Need everything to go with config. Would be missing LUTs, + etc. We need to get past that old issue. + - Matthias: Might be some vendor LUTs that are needed, where it is just + a curve. Would potentially need to be in version control then. + - Mark: if the only source is only a LUT. + - Michael: Thoughts on pulling dependent data from upstream? + - Mark: Prefer to store it in repo if it's ASCII. + - Kevin: Need to be careful relying on vendor storage. May not always + be available. + - Config repo will only contain config generation code, and text data + resources where absolutely necessary (i.e. LUT data where no + BuiltinTransform is available) + - Compound versioning (OCIO, ACES, semver): + - Michael: People need to know what they are getting. Sean proposed a + compound versioning structure previously, to include OCIO version, + ACES version, and a config release version. + - Carol: Yes, users need to know what is being used. + - Mark: Version structure like: + `__` + - Kevin: Recommend incremental build #. + - Michael: Could also use metadata to associate with ACES version. + - Mark: Can reset build number counter at new ACES version or OCIO + version, etc. + - Doug: Could be comment in config file that shows what you have. + Printed out nicely with different components. + - Mark: There could also just be a text file with the config. + - **TODO**: Determine how and where to differentiate the config release + versions. + +* CI/CD: + - Build configs/LUTs for download + - Use CI to build complete config packages for release and easy + download. + - Mark: In releases tab should be multiple entries at a time. Can + generate: ACES reference config, ACES full config etc. Any variations + are present for download independently. + - Validate config results against ground truth (ACES images, CTL) + - Michael: Proposing (and volunteering) to setup CI system, via GH + Actions, to validate config transforms against ground truth CLF + and/or ACES images. + - Thomas: There is facilities like that now, in the current ACES + config. Optional utility. Generator is slow. + - Michael: GH Actions supports 20 concurrent jobs, so can be sped up a + bit there. + +* Config contents: + - Color space, alias naming + - Michael: Do we keep names consistent with existing config? A question + was raised in ocio-dev regarding underscores in alias names. Without + underscores, many color space names become problematic. + - Thomas: Make configurable delimiter for future version. + - Stick with existing names? + - Thomas: Can change names, but need easy way to migrate. People are + building pipelines around this to do conversion. If we break + everything, people will be sad. + - Kevin: Is there anything wrong with existing names? Or just opinions? + - Thomas: The later. + - Kevin: For OCIO v2 we had discussed being able to deprecate color + space names but maintain backwards compatibility. + - Doug: The new inactive color space feature supports this, yes. + Deprecated spaces would work in color space transforms, but not + discoverable in menus. + - Kevin: Need survey monkey to get feedback on general opinions of + naming, etc. + - Displays, views, reference spaces, looks. + - Michael: Should displays and views be restructured to use OCIO v2 + features like display reference space and view transform. Might be + good to organize views by actual display instead of grouping under + one ACES display. + - Doug: Current config was setup to avoid display use. Needs to be + revisited. To what extent do we want to use v2 features. They are + optional, but would help with working. + - Mark: Make it v2 as much as possible, and if someone complains, + make a backwards compatible config off the tail-end of the project. + Good opportunity to force DCCs to do the right thing. Incentive. + - Carol: v2 makes things easier to implement. Will want config that + works and takes advantage of new features. + - Doug: Good opportunity to ask vendors to improve things. Could put + together list of minimum expectations: support displays, views, + looks, etc. + - Sean: Agree on using displays properly. + - Matthias: Maintain family names (which group color spaces in some + DCCs, like Nuke)? Want to keep name similar to aid migration, but + might want to fix family names. + - Doug: v2 has option to build hierarchical menus from family. + - Sean: I think the ACES config families were a reaction to the size + of the config. + - Thomas: Worth pinging vendors, to have more people on the table + discussing that. + - Sean: Can't blame vendors in previous version. We didn't tell them + what we were looking for. + - Kevin: Think the idea of roles appearing in menus was an annoyance. + Roles should be a Pipeline detail. + - Michael: The new categories don't work with roles right? + - Doug: Categories are for reducing color spaces in menus based on use. + +* New code base: + - Doug: Where did we land on whether old code could brought over? + - Michael: I don't think it can with the current license. + - Thomas: Would be better to start fresh. + - Sean: Also thinking to start from scratch. To make it work well for CI + too. + - Doug: Agree. + - Michael: When should we target completion for this project? + - Doug: OCIO v2 stabilization period over second half of year. Vendors will + work on incorporating, and find bugs, etc. Want people to start using it + before that. + - Thomas: Are builtin transforms being shipped at that point? + - Doug: ACES transforms are there now. Over stabilization period we could + increase number of builtin transforms. Not changing API. Just adding stuff. + - Michael: Can we have something functional by end of year? + - Sean: Good to have unit test config at feature complete time. Need + something to get right impression at start. + - Mark: There will be a long period of requiring v1 configs, until every + DCC at studios is updated. Might be period where this config can't be + used. + - Carol: Some people might not use OCIO v2 until there's a config. + - Goal is to target reference config at feature complete time, and + end of year for "studio in a box". This working group will meet at the + same day and time every other week, for now.