TSC Meeting Notes 2022-05-19

Attendance:

Cary Phillips
Christina Tempelaar-Leitz
John Mertic
Joseph Goldstone
Kimball Thurston
Larry Gritz
Nick Porcino
Peter Hillman
Rod Bogart

Guests:

Doug Walker
Zach Lewis

Discussion:

  • Outstanding fuzz issues:

  •  

    • Kimball: A couple fuzz issues with Core. But they’re primarily problems with the checker, so don’t really matter. 

    • Peter: There is one that’s a heap buffer overflow.

  • 3.2 schedule

  •  

    • Kimball: I have the majority of ImfHeader and friends switched to use the C core underneath. Need to change it to using string_view if you’re using C++17 or newer. And ImfUtil. 

    • Kimball: Still todo is to port over the rest of DWA compression stuff.

    • Larry: Is it the compressor that’s not working yet?

    • Kimball: We’re going to majorly change the ABI. I don’t know if that means 4.

    • Larry: I’ve been experimenting with an automated ABI checker. Checks when releasing a break. Ready to start recommending it. Check github for ABI compliance checker. Three related projects. It’s looking at debug information that gdb uses. Pretty comprehensive. Easier to integrate into CI than in production cases. I’m working on prototyping it on one of the other OSS projects.

    • Let’s just call it 3.2. 

  • Cary: non-public reports of performance improvements from software vendors using 3.1.5 with the new C core, will share when it’s publicly available.

  •  

    • Rod: Some partial improvements in unreal. We’re using the C api.

    • Kimball: Biggest improvement is the multithreaded.

  • DWA compression

  •  

    • Rod: How frequently is DWA used? 

    • Larry: At my place, recently not at all. But we did some tests of how much compression we could tolerate in different places. We’re AOV heavy, but also do checkpointing. So reading/writing has expanded a bit recently. We’ve come to like DWA. Haven’t rolled it out widely yet.  But we’re about to start using it.

    • Rod: If anyone chooses lossy compression, DWA is the one to use. 

    • Larry: B44 has never been on our radar.

  • Color space discussion:

  •  

    • Doug: 

    •  

      • An email from Anders Langland asking about interchange roles, and whether a robust way to connect a config to the outside world is mandatory. Proposal to make it mandatory for OCIO 2.2. Some discussion of naming, but no objection to making them mandatory.

      • A few comments on the slide deck shared last time. 

      • Which takes precedence when reading a file? Code in the OCIO app helpers to ease the burden on app developers? Will propose some code for how that would work, what the API would do.

      • How could we support the chromaticities in an exr file if it doesn’t map to an OCIO config? If it requires the app to convert the file into a known space, I’m not sure how that would work.

    • Zach. Having the mandatory interchange attributes is a good idea.

    • Zach: could we encode the OCIO config into the exr header?

    • Kimball: It came up in the last meeting.

    • Rod: It feels kind of big.

    • Joseph: Were the exr attributes that named CTL ever used?

    • Kimball: I don’t think so. It wasn’t just the CTL file, it was the CTL code? 

    • Rod: That was a Florian thing. The original CTL paper referred to it.

    • Rod: Storing an entire config would be hefty.

    • Kimball: But you don’t need the entire config.

    • Zach: Could have a serialized version of the processor.

    • Rod: But to what end? Does it suggest things that should happen to the file? Or specify things that have happened to this file?

    • Peter: For example, does it have a grade in it? Has it had a different grade applied. “The director looked at it like this.”

    • Larry: What do these pixel values represent? And how do you display it?

    • Rod: Is a full description of the color space sufficient, if you don’t say a reference? The reference of an OCIO color space is unspecified, so it tells you nothing if you don’t know the reference.

    • Rod: If you have chromaticities and the assumption of linearity, that’s enough.

    • Rod: If you had a color space that’s Rec709 and the reference is nothing, there’s no way to know.

    • Zach: depending on whether a config author specifics the interchange role specifically, that has implications for how one does the chromatic adaptation. 

    • If ACES interchange is specified as a role, that implies

    • Rod: We’re asking, what information do we put into files so we can do further operations on them? So that OCIO has enough information to proceed. If you just say chromaticities, you have to do a search.

    • Larry: The common case in all of this is, the exr file is in a facility, the pixels are in the space of a config in that facility. I know these things match, you just don’t know what color space it is. 

    • Cary: When an ILM artist loads an exr into Unreal, how does unreal know what the pixels mean?

    • Rod: It doesn’t. You have to tell it. Our stuff is very by hand.

    • Rod: Need a way to say whether this thing is scene linear. And then a color space. You always need to know the encoding and the color space. And maybe chromatic aberration. But that’s it.

    • Rod: Can we be more specific on the kinds of things we’re talking about?

    • Zach: I posted a thing to Doug’s slides, I’ll repost it to the mailing list.