Skip to content

Commit 3d3eefc

Browse files
michdolanmichdolan
authored
Add TSC meeting notes for 11-09-2020 (#1200)
* Add TSC meeting notes for 11-09-2020 Signed-off-by: Michael Dolan <[email protected]> * Clean up notes Signed-off-by: Michael Dolan <[email protected]>
1 parent 8feb1fa commit 3d3eefc

File tree

1 file changed

+251
-0
lines changed

1 file changed

+251
-0
lines changed

‎ASWF/meetings/tsc/2020-11-09.md‎

Lines changed: 251 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,251 @@
1+
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
2+
<!-- Copyright Contributors to the OpenColorIO Project. -->
3+
4+
November 9, 2020
5+
6+
Host: Michael Dolan
7+
8+
Attendees:
9+
* [X] Mark Boorer (_TSC_) - Industrial Light & Magic
10+
* [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
11+
* [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
12+
* [X] Michael Dolan (_TSC Chair_) - Epic Games
13+
* [X] Patrick Hodoul (_TSC_) - Autodesk
14+
* [ ] John Mertic - Academy Software Foundation / Linux Foundation
15+
* [X] Carol Payne (_TSC_) - Netflix
16+
* [X] Mark Titchener (_TSC_) - Foundry
17+
* [ ] Carl Rand (_TSC_) - Weta Digital
18+
* [X] Doug Walker (_TSC Chief Architect_) - Autodesk
19+
* [X] Kevin Wheatley (_TSC_) - Framestore
20+
* [X] Bernard Lefebvre - Autodesk
21+
* [X] J Schulte - Industrial Light & Magic
22+
* [X] Matthias Scharfenberg - Industrial Light & Magic
23+
24+
# **OCIO TSC Meeting Notes**
25+
26+
* Response to ILM questions:
27+
- Doug: Wrote up answers for ILM, provided doc in last week's TSC notes.
28+
Also created issue #1199 to facilitate discussion on topics.
29+
30+
* Overview of new PRs:
31+
- #1183 - Add operator << for FormatMetadata:
32+
- Doug: Making more convenient to access file format metadata from
33+
python. Maps to `__repr__` in python.
34+
- #1184 - Description in Config files
35+
- Doug: Improved descriptions in config files. Cases where single or
36+
multiline desc for color space, etc. Cleans up handling of those and
37+
adds unit tests.
38+
- #1189 - Named color transforms
39+
- Doug: Issue #1101, discussed at August v2 wg meeting. Sharing slides
40+
from wg meeting. How to integrate legacy transforms into OCIO.
41+
Sometimes users just want to apply gamma or log-to-lin (with no
42+
matrix). But want to specify them in OCIO config and access via OCIO
43+
tools. Example: "Utility Curve/Shaper" color spaces in ACES config,
44+
which are kind of broken (i.e. only a shaper if going to ACES2065-1).
45+
- Add named transforms section to config. Authors can define these
46+
transforms in that area. ACES config has these transforms,
47+
represented as color spaces, but problematic if you're not
48+
starting from the right color space. These curve/shaper color
49+
spaces could then become named transforms instead.
50+
- Apps could provide plug-in for accessing named transforms, or use
51+
with ColorSpaceTransform or DisplayViewTransforms. They do not
52+
show up in color space menus by default.
53+
- In ColorSpaceTransform and DisplayViewTransform, accepted like
54+
color spaces as arguments to these transforms. Would bypass the
55+
"other half" of the conversion. e.g.
56+
ColorSpaceTransform("Utility - Curve - sRGB", "ACEScg") -> apply
57+
the named transform and consider the result as ACEScg.
58+
- As mentioned in previous meeting, open to other proposals for
59+
how to handle this, but nothing has been presented. Made very
60+
clear that this is a hard requirement and want to do it within
61+
OCIO rather than as separate tool. See issue and PR for more
62+
info.
63+
- Mark B: Not excited about it. Not part of config authoring process
64+
so can't see how chain of operations ties together. Highlighted by
65+
ACES config, which ref color space is ACES2065-1, but people want to
66+
work in ACEScg, so problematic with the extra matrix and color shift.
67+
What users have hard requirement?
68+
- Doug: From users of thing like Maya and Flame, CG animation and
69+
rendering, or finishing or compositing.
70+
- J: More dangerous in those applications. Easier for UX, but breaks
71+
fundamental rules of moving to color managed process.
72+
- Doug: In big facility with color scientist, makes sense. A lot of
73+
users don't have that. Proponent of the benefits of working proper
74+
color managed way, but a lot of our users have not gotten to that
75+
point yet. Looking in OCIO example configs repo, one is called
76+
nuke-default, a Foundry config, made up of these sort of utility
77+
transforms as well.
78+
- J/Mark B: Legacy config, made to allow continuation of Nuke workflows
79+
with OCIO. Just proof of concepts to get Nuke color management
80+
outside of Nuke.
81+
- Mark T: Just to replicate Nuke color management system.
82+
- Doug: Not recommending this approach, just saying it's a reality that
83+
a lot of people want to work this way. Because of legacy. Users 5-10
84+
years behind state of art.
85+
- Mark B: Talking about OCIO, not legacy workflows. Don't want to
86+
enshrine these workflows, allow people to break the model.
87+
- Carol: If not using the standard ACES config, using nuke-default, not
88+
making own configs. If you're trying to get facilities caught up in a
89+
non-disruptive way, this would be an ok way to do that since it's
90+
saying what it is explicitly. Not getting unintended results. I Like
91+
that.
92+
- Mark B: Disagree. This is enabling people. Those that don't
93+
understand color management are not are not going to be set right by
94+
named transforms. Going to be enabled to work how they want and think
95+
they have OCIO blessing. OCIO is an opinionated color management
96+
library, not just a toolbox.
97+
- J: Valid question, is there an appetite for something like this as a
98+
guiding path? Love to get input on that. Everyone has valid point of
99+
view, but as a whole, what is the missions statement here? Are we
100+
willing to compromise OCIO principles, or are there decisions and
101+
workflows we want the industry to move into?
102+
- Doug: To clarify, think its clear users feel a need for this. It's in
103+
the ACES config for a reason. Not that we're encouraging this, just
104+
calling it what it is. Right now masquerading these as color spaces,
105+
but they aren't. Reality that some want these and we should not call
106+
them color spaces. If you're worried about encouraging this behavior,
107+
I don't see that. See it as making it clearer to people how to do
108+
color management. If you say we don't want you to use named
109+
transforms, clear way to talk about the scenario. Don't want to frame
110+
the question as: is this a good idea for color management? Most on
111+
same page to not recommend it. If they are going to do it, and ACES
112+
config has it, and should be called what they are.
113+
- Mark B: Color spaces are a simplification to allow talking about
114+
OCIO. Just a block in chain that joins images together.
115+
- Carol: Should be explicit though, call this what it is, not a color
116+
space.
117+
- MArk B: Increasing complexity with little benefit.
118+
- Matthias: Sort of agree with Carol. Agree having them in there as
119+
first class citizen potentially perpetuating workflow and simplistic
120+
interpretation of color management to avoid. Don't like to
121+
compromise, but if have to have it, see benefit of it being explicit.
122+
- Mark B: Who needs it other than the config author? If you're the
123+
author you know where you need to_ref and from_ref. Current toolkit
124+
not complex and solves all these problems without extra level.
125+
- Carol: Another group pf people sit between authors and users. Those
126+
that don't have someone to write config for them and need to
127+
understand the config. This would aid those people and it's a big.
128+
Not everyone can be a config author, requires skill not all have.
129+
Need to support them.
130+
- J: The question is what is OCIO, who does it serve? A lot of that
131+
user experience is driven by applications that use OCIO. What do we
132+
want to enable those workflows to be like in OCIO. If there's a need
133+
for these, that's a thing. But does OCIO have an opinion about this?
134+
Or do we sacrifice some of that to give users accessible use of OCIO?
135+
- Matthias: Look at it from different point of view. Having transform
136+
is one thing. Doug, any idea what would look like when presented to
137+
end user, in say... Nuke. OCIOColorSpace node would not have this.
138+
Doesn't fit there. Would it be a separate thing? Just an OCIO
139+
transform or legacy transform?
140+
- Doug: Will vary based on application and task. For example, if
141+
importing something into proper color managed env. If using Maya and
142+
ACEScg as rendering space. May want to bring something in and call
143+
it ACEScg, but you're not sure what the original texture is. Don't
144+
have info so going to apply inverse gamma curve and call it ACEScg.
145+
Same workflow as textures where you do know color space. May have
146+
other scenarios where want to apply transform itself like
147+
FileTransform.
148+
- Kevin: If I know how to read config, and just want to get transform,
149+
this is a convenience. File transforms don't encapsulate all new
150+
transforms, so harder to put this in file.
151+
- Mark: Config author could do that.
152+
- Kevin: Convenience for mocking up a config, but once done, not have
153+
it. Could create separate Nuke node with obscure name for special
154+
use, but not to be used by default.
155+
- Matthias: Feels like amalgamation of old Nuke 1D input color space
156+
for read node, and the new ability to use specific color space. Feels
157+
like jamming those two workflows together. Could cause confusion down
158+
the line, if you have color managed workflow.
159+
- J: From user perspective, having one thing that does full transform,
160+
or one that does just the 1D path, does this make it harder for
161+
people? User may not know what the differences are. Are we making it
162+
harder?
163+
- Carol: Like the analogy of using this in place where would have used
164+
FileTransform before. As simple as that.
165+
- Mark B: Who uses raw file transforms though? If this is just a
166+
shortcut to a 1D LUT.
167+
- Kevin: If it was just 1D LUT, no point, but encapsulating other
168+
transforms has more benefit. Have a lot of users who will try to
169+
decipher how to get between two images. Would be handy for that. Once
170+
you figure it out, put it into color space.
171+
- Carol: For many users, try in Nuke to figure out what happened, get
172+
to place of confidence of where they are at, and work on image.
173+
- Doug: A lot of people on OCIO/ACES forums that don't understand how
174+
OCIO config works, but in positron of having to use it to solve
175+
problems. Think there are a lot of those people out there.
176+
- Matthias: Maybe needs clear distinction that this is not a color
177+
space, with no to and from ref, just forward or reverse with name.
178+
- J: How do you solve this without offering up these workflows. At
179+
least gives them something over nothing.
180+
- Mark B: Just documentation, teaching how to use it. Adding named
181+
transforms not going to improve that.
182+
- Doug: Don't see how to solve this with documentation. Would need huge
183+
number of color spaces, for this audience who aren't config authors.
184+
If these are color spaces, would need every possible combination of
185+
color space and non-linearity. Another workflow is unfortunately that
186+
some apps allow a color transform where you specify independently a
187+
matrix and a non-linearity. Can create a lot of trouble by mixing and
188+
matching weird combinations. Sometimes people get things from these
189+
other software. Nightmare to include every combination, but with
190+
named transform, have way of undoing what had been done.
191+
- Carol: Seems like added complication, but could look at it as
192+
building block of step in direction of where we want to be. More
193+
educated users knowing what they are doing in color managed scenario.
194+
Until we get to that point, could view this as interim. Helps to
195+
teach and educate. Like in ACES gamut mapping wg, all agree it's not
196+
ideal, but we have to do what helps.
197+
- Mark B: Having multiple named transforms to reconcile error from
198+
another user. Are you anticipating a user assigning multiple named
199+
transforms in Maya UI, or still picking single transforms from named
200+
lists. If the later, still at mercy of config author, at which point
201+
it's just a doc or training session to explain choices.
202+
- Doug: Tried providing combinations in SynColor, many options, huge
203+
list of matrix and log-to-lin combinations and nightmare to deal
204+
with. Not desireable way of solving the problem.
205+
- J: Does TSC have a point of view on what color space interaction and
206+
user experience should be.
207+
- Michael: Think that's an important topic for discussion. Created
208+
issue #1174 for UX discussion where some of this could be determined.
209+
- Kevin: What I really need is a Nuke node, op builder, to put ops in
210+
a row.
211+
- Michael: Suggested a GSoC project to create OCIO GUI last year for
212+
exactly that reason. Would be awesome to have visual method for
213+
authoring configs.
214+
- Let's bookmark this conversation for next week. Gives us time to
215+
think this through more and can follow up to make an agreement.
216+
217+
* CUDA support:
218+
- Doug: Larry brought up topic about CUDA support, pressing issue for
219+
OSL and a number of CG rednderers.
220+
- Michael: We should follow up with Dennis about his OpenCL renderer. Could
221+
perhaps influence other GPU compute implementations like Metal, Vulkan,
222+
etc.
223+
- Mark B: Think this need is dying, since we now have OpenGL compute
224+
shader.
225+
- Michael: CUDA requirement might be tied to OptiX. Could also explore
226+
tools to emit to multiple APIs. Spir-V.
227+
- Mark: Spir-V builder needs large dependency graph, needs LLVM. Not stable
228+
dependencies.
229+
- Patrick: Something to keep in mind. A lot of effort in current impl to
230+
not have direct OpenGL dependency in core. Clear distinction between core
231+
and shader language. Try to keep that. Advantage of OCIO.
232+
- Michael: Could be like OIIO which has plugins depending on optional
233+
dependencies. More ideal to only depend on runtime though.
234+
- Mark B: Windows has HLSL, Mac has Metal. Don't want to support all that
235+
stuff in the GPU impl. Emitting HLSL on Linux, etc. Could have call to
236+
get native shader code.
237+
238+
* Misc:
239+
- Michael: Please have a look at my question in PR #1197 about workarounds
240+
to support Python API docs on RTD. somewhat controversial choices so
241+
would like input. Also to TSC, please have a look at the ASWF survey
242+
questions. Could use some input on multiple choice answers.
243+
- Patrick: New API docs very helpful. Built branch locally and looks good.
244+
- Mei: Pavel, engineer from SPI starting using OCIO v2. Provided feedback
245+
that overall very happy. Performance is faster, and has not been any
246+
issues. Happy with it. Can get more feedback if there's specific
247+
questions for him.
248+
249+
* Items for next TSC meeting agenda:
250+
- Continued discussion on named color transforms.
251+
- Follow up on AD response to ILM feedback and questions.

0 commit comments

Comments
 (0)