Attending:
- Cary Phillips
- Christina Tempelaar-Lietz
- Joseph Goldstone
- Kimball Thurston
- Larry Gritz
- Nick Porcino
- Peter Hillman
- Rod Bogart
- Michael B Johnson
- David Aguilar
- Robin Lowe
Discussion:
Wave: Lead of ASWF Assets working group
Example question we're dealing with: “How can we get a bunch of USD asets with MaterialX materials?”
Instead, why don’t we approach the projects and ask them what they would want, in the space that they care about?
At Apple we have some example EXR's we're trying to get clearance to send, mostly illustrating bugs.
Larry: We already have openexr-images, covers the basic.
Two examples that frequently come up with OIIO:
Test cases for all crazy things with metadata, range of data formats.
openexr-images has a couple of deep images, but they’re very simple caes, they aren’t indicative. We need hairy production images that would, say, confirm an application isn't going to run out of memory.
Kimball: could generate some AOV’s from the Moana scene.
Wave: Could we hire an intern to generate images from Moana?
Kimball: We don’t have a good version history. But then, backwards compatibility isn't that much of an issues, since we don't change the file format very often.
Wave: "Would like to be able to say there are 17 AOV’s in that image." Larry: "I'd would pay so much for anyone at my studio to use less than 50!"
Cary: maybe the project CII badge should include entries for example data. Project should be encouraged to provide representative example data.
Larry: OSL has a huge shader library, but everything’s interconnected, nothing public that is representatives of production use.
New features added to the library need corresponding test images.
Joseph: None of the compression methods are documented. Could we get an intern to document them? Not a Google Summer of Code intern, the project have to involve actual code. But it would be good to get it standardized.
Joseph: Maybe the Academy Sci-Tech intern? Speak to Alex Forstythe, there have been some great interns with the Academy.
Robin Lowe: I’m participating in the discussions on the 16-bit float type with the C++ standards committee.
The C++ proposal is still active.
One of the key differences with 16 bit floats is how they do rounding. C++ allows for severa kinds of rounding. OpenEXR only does one. We don’t allow the other kinds of rounding.
Whatever is in hardware is going to be stamped into standards.
Joseph: compatibility with existing code, will it be a templated type?
Robin: standard type should be the native type on the hardware. Or, these are three separate things.
OpenEXR is largely compatible with the Nvidia type.
Could typedef half to fp16.
“Call it half”, be done.
Larry: Will a standardized C++ 16-bit float be the same data layout as our half (what IEEE 754-2008 calls "binary16", and others call "half", "fp16", or "s10e5")? I imagine that it will, or that one of several fp16 types will be this one -- it kinda has to be because it's implemented already in so much hardware, including NVIDIA, AMD, and Intel chips for quite some time. I think there are two issues wrapped up here:
If they do have the same data layout but there is some minor variation in operational semantics (some subtlety about rounding modes, etc), should we change our software implementation to match what other conforming implementations or hardware do? I think, yes, we should. There is no merit to doing something that's extremely subtly different from the rest of the world for what is obviously supposed to be the same data type. Even if we did the nonstandard thing before the standard arrived.
If C++ defines multiple different 16 bit floating-point formats (e.g., bfloat16) should we extend the OpenEXR file format to accept pixels of that type? Maybe, it probably depends on how widely it's adopted, implemented in HW, and whether it's important to people who use OpenEXR. I know that bfloat16 is finding favor in ML circles, but I have not investigated whether it's a good choice for color or other things we tend to store in images. IIRC, bfloat16 has the full range of float, but even more limited precision than half. I don't know if it loses so much precision that it can't represent perceptual JND, and therefore would be a bad choice for storing color images.
Continue C++11 support?
Cary: ILM still has code that needs that requires C++11.
Kimball: So does Weta.
Larry: Then that's it, we maintain compatibility with C++11 for now.
Imath PR #72: Eliminate normalize and length methods for Vec
Cary: I recommend dropping the wonky integer methods. Better to have missing functions that functions that do weird things.
Larry: This is a part of the bigger thing of trying to put noexcept on everything. The integer methods throw exceptions, even the ones that aren't supposed to.