Attendance:

Discussion:

• Larry’s .x change: https://github.com/AcademySoftwareFoundation/Imath/pull/214

•  

  • need a comment in the doxygen/rst

• Fuzz testing issue continue:

•  

  • When a file fails, it’s added to the corpus, they start fuzzing that, which explains why related things seem to com in clusters.

• Christina’s CI change:

•  

  • Named like OSL

  • Still need to add the bleeding edge run

  • Will update Imath, too.

• We should accept aras-p’s compression level change: https://github.com/AcademySoftwareFoundation/openexr/pull/1125

•  

  • Should it go into 3.1? 

  • Technically, it should probably be 3.2, but it should be OK to bend the rules.

  • We don’t have a setup to run the ABI compliance checker.

• The only merged PR that breaks ABI is the change to the file checker

•  

  • We’re the only ones who use the checker, but then…

  • But no reason to merge to 3.1

• Cary: I’ll start preparing a 3.1.3 release, target about 2 weeks from now.

• Kimball: Phil Barret at Filmlight reported an error with piz compression

• Joseph:

•  

  • Macos package managers (dominate one is homebrew) 

  • Less glitzy but better theoretical foundation: macports

  • Macports puts everything in /opt

  • Homebrew and the os compete on where stuff should be installed.

  • Nick: the only system I use is conda, even though it’s a python manager.

  • It does a better job of containing stuff rather than polluting your system.

  • Nick: Conda is the only system that’s “not significantly like running with scissors”

  • Macports’ openexr is old

• Larry, from the TAC:

•  

  • In an OIIO conversation, a guy responsible for fedora distribution got involved.

  • Doesn’t know much about internals of the projects he maintains

  • Always hearing about broken things

  • We should invite him to discuss what he does, either at the TAC or CI working group meeting. 

  •  

    • :What are the things we do that make life difficult?”

    • Best practices

    • It’s onene guy who’s been doing it for years, for lots of packages, none of which he understands.

• Larry: order of mipmap levels

•  

  • Working with AL on texturing system

  • Made a local file format that reverses the order in which the mipmap levels appear. Give better performance. 

  • In a render, the first access is blurred, it doesn't need details.

  • Hypothesis: can we lay out mip levels 

  • Peter: set the tile order to random. Then write in the order you want them in the file. 

  • If you do a structured read, you need to know what order the tiles are in.

  • If you tell it it’s random, but you write them in order, there’s no penalty, right?

  • In random order, it doesn’t know

  • Could add a “reverse mip level”, alongside “increasing y, increasing x”

  • But that wouldn’t be backwards compatible, old libraries wouldn’t read it.

  • Kimball: introduce some kind of sparse udim. Some kind of rumblings of the texture department.