|
| 1 | +<!-- SPDX-License-Identifier: CC-BY-4.0 --> |
| 2 | +<!-- Copyright Contributors to the OpenColorIO Project. --> |
| 3 | + |
| 4 | +November 3, 2020 |
| 5 | + |
| 6 | +Host: Michael Dolan |
| 7 | + |
| 8 | +Attendees: |
| 9 | + * [X] Mark Boorer (_TSC_) - Industrial Light & Magic |
| 10 | + * [X] Michael Dolan (_TSC Chair_) - Epic Games |
| 11 | + * [X] Doug Walker (_TSC Chief Architect_) - Autodesk |
| 12 | + * [X] Kevin Wheatley (_TSC_) - Framestore |
| 13 | + * [X] Dennis Adams - Sony |
| 14 | + * [X] Alessandra Tomassi - Industrial Light & Magic |
| 15 | + * [X] J Schulte - Industrial Light & Magic |
| 16 | + |
| 17 | +Apologies: |
| 18 | + * Carol Payne |
| 19 | + * Thomas Mansencal |
| 20 | + |
| 21 | +# **OCIO Configs Working Group Meeting Notes** |
| 22 | + |
| 23 | +* Time change: |
| 24 | + - Michael: All daylight savings shifts are now done and Thomas is unable to |
| 25 | + attend. Can we shift one hour earlier next time? |
| 26 | + - All ok with this. We will try to not change time mid-daylight savings |
| 27 | + shift in future to reduce confusion. |
| 28 | + |
| 29 | +* Projects status: |
| 30 | + - Michael: If there is needed discussion around the current generator, |
| 31 | + let's move that to Slack for now. Other code can be shared via a |
| 32 | + draft PR to share if needed. |
| 33 | + - Mark: Still need to talk to ACES about naming goals, to get on same page. |
| 34 | + Alex was at last meeting. We should reach out to him. Since we're pulling |
| 35 | + naming from CTL, ideally correct in aces-dev. CTL in flux - some PRs that |
| 36 | + when merged will remove a lot of complexity. We can influence change |
| 37 | + there similarly to how ACES influences OCIO change. |
| 38 | + - Michael: Last meeting we discussed that the input BuiltinTransforms were |
| 39 | + largely present, but needed output transforms to proceed. Is there an |
| 40 | + expected timeline for that work Doug? |
| 41 | + - Doug: Will try to get something before next meeting. |
| 42 | + - Mark: OCIO v2 has display transforms. Are we making use of that? Some |
| 43 | + transforms have OCES space, but PQ goes straight from scene linear. This |
| 44 | + config is supposed to represent all the features of OCIO v2. should we |
| 45 | + make use of both? |
| 46 | + - Doug: Yes, will include this in proposal, but think will make use of |
| 47 | + display color spaces, so output transforms will be view transform plus |
| 48 | + display transform. OCES wouldn't have an interface. More recent ACES |
| 49 | + transforms have moved away from it. OCES was interesting theoretical |
| 50 | + idea, providing a break point between points of transform that proved to |
| 51 | + be more confusing. Would not use OCES. |
| 52 | + - Mark: What would become the display space? The generator draws |
| 53 | + connections between the ACES blobs and the newer transforms skip the OCES |
| 54 | + step. |
| 55 | + - Doug: Display colorimetry. All the Output Transforms go through that but |
| 56 | + don't break it out as external interface in CTL, for historical reasons. |
| 57 | + - Mark: That will make it difficult to make generator which looks at CTL to |
| 58 | + generate. Not married to that plan but seems sensible for tracking |
| 59 | + upstream. Also happy to abandon it for config expressed in code if that's |
| 60 | + more useful. |
| 61 | + - Doug: Was thinking could use generator to identify the ACES end and |
| 62 | + display code value end, but not necessarily use the OCES interface. For |
| 63 | + output transforms, some go direct from ACES and others through OCES, but |
| 64 | + we could handle them as if they went from ACES to device. |
| 65 | + - Mark: At moment, generator doesn't parse CTL code, just looks at URN in |
| 66 | + header of files, so no way to track transforms or chains between functions. |
| 67 | + - Doug: We know anything that expects OCES as input wants to include RRT. |
| 68 | + - Mark: So use RRT as point? |
| 69 | + - Doug: Part of problem is the RRT does not produce display referred |
| 70 | + imagery, which has caused confusion. Produces idealized output referred |
| 71 | + intermediate. Actual display referred colorimetry requires first part of |
| 72 | + ODT. RRT doesn't provide technical benefit. Think we can ignore RRT, and |
| 73 | + for transforms with OCES input, go from ACES to OCES. |
| 74 | + - Mark: Not sure benefit to tracking CTL to get these relationships if we |
| 75 | + need to implement transforms. Maybe skip checking of CTL and |
| 76 | + programmatically build transforms. |
| 77 | + - Michael: Could use generator for testing if not for config generation. To |
| 78 | + do image comparison etc. |
| 79 | + - Doug: Thomas' generator found issues which have value to go through and |
| 80 | + report the problems. Agree it may not make sense to follow it strictly |
| 81 | + from built graph. Needs to be manual intervention at some point. Agree |
| 82 | + with treating it more as CI process. |
| 83 | + - Mark: Yeah, to get the names from it and try to call those transforms. |
| 84 | + Will wait until display referred spaces are setup in ACES context. |
| 85 | + - Doug: Yes, will help for me to take one transform and show how it works |
| 86 | + in OCIO. Will also reduce amount of code. The way I'm proposing it is |
| 87 | + removing a lot of the redundancy in the current CTL code. If you look at |
| 88 | + ODTs there are lots of commonalities, so my proposal takes that common |
| 89 | + part and factors it into the view transform. Will make the overall |
| 90 | + structure easier to follow. |
| 91 | + - Michael: That would then be a point of divergence in the code. The |
| 92 | + current code for testing against upstream ACES, and a new generator for |
| 93 | + a config itself. |
| 94 | + - Mark: Will be more similar to other generators. |
| 95 | + - Doug: With input transforms, ones implemented already are CSC transforms. |
| 96 | + Bunch of those are also IDTs, or the code is similar. Some slight |
| 97 | + differences between CSCs and IDTs, which were called out and not sure |
| 98 | + those have been harmonized. Need to investigate that. Should lookout for |
| 99 | + that issue. Also need to decide if we want to do all the IDTs. ARRI has |
| 100 | + one per ISO for example, and multiple versions. Tons of IDTs. Do we want |
| 101 | + to implement them all? Most can be implemented compactly with |
| 102 | + LogCameraTransform, but at the extreme ISOs ARRI introduces hermite |
| 103 | + spline to keep from running off edge of LUT, so those would need a Lut1D. |
| 104 | + - Mark: Talked before about making multiple configs, with customizable |
| 105 | + generators. Think some IDTs would not make the cut, but could be in |
| 106 | + another version. ARRI could be in there since it's common. |
| 107 | + - J: EI 800 would make sense, but not sure all are needed. |
| 108 | + - Doug: Current ACES config has a bunch of these color spaces so need to |
| 109 | + decide about compatibility. |
| 110 | + - J: Need to figure out which flavor we publish. One complaint we have |
| 111 | + heard is the config is unwieldy because of so many color spaces. |
| 112 | + - Mark: Not sure how many need to be builtin transforms as well. Could |
| 113 | + include LUTs and matrices in some. Could be example for implementation. |
| 114 | + - Michael: We'll need the transforms that make ACES ACES for the reference |
| 115 | + config. Others can be for the studio config. |
| 116 | + - J: What determines which are included? |
| 117 | + - Mark: We decide with community feedback. |
| 118 | + - Doug: Thomas' graph will illustrate that. Another area where manual |
| 119 | + intervention is needed. Don't need all ARRI IDTs. |
| 120 | + - Mark: Already filtering if not EI 800. |
| 121 | + - J: EI 800 is base one anyway, so good mandate. |
| 122 | + - Doug: Other thing about the IDTs. ACES repo doesn't include CTL for RED, |
| 123 | + Canon, etc. Also need to decide about those. In current ACEs config some |
| 124 | + work was done to track down that stuff and create transforms. |
| 125 | + - Michael: Could cut off stuff not in aces-dev repo. |
| 126 | + - Doug: Need some RED and Canon, and there are CSC transforms for those. |
| 127 | + Maybe don't go beyond that. Some needed discussion around what those |
| 128 | + transform are. Was hoping Thomas' work was to produce list of proposed |
| 129 | + transform IDs to use as builtin transform names. Think thats one of the |
| 130 | + next steps. Make spreadsheet of specific list of transforms. Which have |
| 131 | + CTL and which don't, and assign someone to figure out the latest and |
| 132 | + greatest collection. |
| 133 | + - Mark: Lot of noise in output from generator, filtering through |
| 134 | + relationships with various rules. Not sure how much of that snuck into |
| 135 | + graph. Not sure how many intermediates we want in there too. |
| 136 | + - Doug: Think it will help. Discussion that needs more community input. |
| 137 | + What is in the config and what are the strings. |
| 138 | + - Michael: Can put all transforms in spreadsheet and show which are |
| 139 | + excluded and why. |
| 140 | + - Mark: Can have column for what is included. |
| 141 | + - **TODO**: Mark will use generator to create a spreadsheet for discussion |
| 142 | + of which transforms are included in reference config. |
| 143 | + - **TODO**: Doug will create example of builtin output transform in OCIO. |
| 144 | + |
| 145 | +* ACES reference config goal |
| 146 | + - Michael: Shall we set a goal to have the reference config done by OCIO |
| 147 | + v2 (non-RC) release? Would be good to ship an example if possible. |
| 148 | + - Mark: We can try for that. Might get pushed. |
0 commit comments