1# 11/17/2020
2
3### Attending:
4
5* Cary Phillips
6* Christina Tempelaar-Lietz
7* Joseph Goldstone
8* Kimball Thurston
9* Larry Gritz
10* Nick Porcino
11* Peter Hillman
12* Rod Bogart
13* Michael B Johnson
14* David Aguilar
15* Robin Lowe
16
17### Discussion:
18
19* Wave: Lead of ASWF Assets working group
20
21  * Example question we're dealing with: “How can we get a bunch of
22    USD asets with MaterialX materials?”
23
24  * Instead, why don’t we approach the projects and ask them what they
25    would want, in the space that they care about?
26
27  * At Apple we have some example EXR's we're trying to get clearance
28    to send, mostly illustrating bugs.
29
30  * Larry: We already have openexr-images, covers the basic.
31
32  * Two examples that frequently come up with OIIO:
33
34    * Test cases for all crazy things with metadata, range of data formats.
35
36    * openexr-images has a couple of deep images, but they’re very
37      simple caes, they aren’t indicative. We need hairy production
38      images that would, say, confirm an application isn't going to
39      run out of memory.
40
41  * Kimball: could generate some AOV’s from the Moana scene.
42
43  * Wave: Could we hire an intern to generate images from Moana?
44
45  * Kimball: We don’t have a good version history. But then, backwards
46    compatibility isn't that much of an issues, since we don't change
47    the file format very often.
48
49  * Wave: "Would like to be able to say there are 17 AOV’s in that
50    image." Larry: "I'd would pay so much for anyone at my studio to
51    use less than 50!"
52
53  * Cary: maybe the project CII badge should include entries for
54    example data. Project should be encouraged to provide
55    representative example data.
56
57  * Larry: OSL has a huge shader library, but everything’s
58    interconnected, nothing public that is representatives of
59    production use.
60
61  * New features added to the library need corresponding test images.
62
63  * Joseph: None of the compression methods are documented. Could we
64    get an intern to document them? Not a Google Summer of Code
65    intern, the project have to involve actual code. But it would be
66    good to get it standardized.
67
68  * Joseph: Maybe the Academy Sci-Tech intern? Speak to Alex
69    Forstythe, there have been some great interns with the Academy.
70
71* Robin Lowe: I’m participating in the discussions on the 16-bit float
72  type with the C++ standards committee.
73
74  * The C++ proposal is still active.
75
76  * One of the key differences with 16 bit floats is how they do
77    rounding.  C++ allows for severa kinds of rounding. OpenEXR only
78    does one. We don’t allow the other kinds of rounding.
79
80  * Whatever is in hardware is going to be stamped into standards.
81
82  * Joseph: compatibility with existing code, will it be a templated type?
83
84  * Robin: standard type should be the native type on the
85    hardware. Or, these are three separate things.
86
87  * OpenEXR is largely compatible with the Nvidia type.
88
89  * Could typedef half to fp16.
90
91  * “Call it half”, be done.
92
93  * Larry: Will a standardized C++ 16-bit float be the same data
94    layout as our half (what IEEE 754-2008 calls "binary16", and
95    others call "half", "fp16", or "s10e5")? I imagine that it will,
96    or that one of several fp16 types will be this one -- it kinda has
97    to be because it's implemented already in so much hardware,
98    including NVIDIA, AMD, and Intel chips for quite some time. I
99    think there are two issues wrapped up here:
100
101    1. If they do have the same data layout but there is some minor
102       variation in operational semantics (some subtlety about
103       rounding modes, etc), should we change our software
104       implementation to match what other conforming implementations
105       or hardware do? I think, yes, we should. There is no merit to
106       doing something that's extremely subtly different from the rest
107       of the world for what is obviously supposed to be the same data
108       type. Even if we did the nonstandard thing before the standard
109       arrived.
110
111    2. If C++ defines multiple different 16 bit floating-point formats
112       (e.g., bfloat16) should we extend the OpenEXR file format to
113       accept pixels of that type? Maybe, it probably depends on how
114       widely it's adopted, implemented in HW, and whether it's
115       important to people who use OpenEXR. I know that bfloat16 is
116       finding favor in ML circles, but I have not investigated
117       whether it's a good choice for color or other things we tend to
118       store in images. IIRC, bfloat16 has the full range of float,
119       but even more limited precision than half. I don't know if it
120       loses so much precision that it can't represent perceptual JND,
121       and therefore would be a bad choice for storing color images.
122
123* Continue C++11 support?
124
125  * Cary: ILM still has code that needs that requires C++11.
126
127  * Kimball: So does Weta.
128
129  * Larry: Then that's it, we maintain compatibility with C++11 for now.
130
131* Imath PR #72: Eliminate normalize and length methods for Vec<inttype>
132
133  * Cary: I recommend dropping the wonky integer methods. Better to
134    have missing functions that functions that do weird things.
135
136  * Larry: This is a part of the bigger thing of trying to put
137    noexcept on everything. The integer methods throw exceptions, even
138    the ones that aren't supposed to.
139