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