Attendance:

Discussion:

• Discussion of color space name and metadata:

•  

  • If OCIO is involved, what’s the relationship between the OCIO profile & chromaticities

  • Should there be an OCIO-profile-name attribute?

  • Larry: It’s intimately tied to how to move forward with the OCIO stuff, tied together.

  • Larry: There are some approved attributes in openexr from which you can infer a bit about the color space, except that chromaticities is not the complete picture. It’s hard to take that data and map it to OCIO color space names throughout the facility. And the metadata is often wrong. Is there a way to have an attribute that helps to map data to color space. It’s a recurring pain in the behind as a practical matter for OIIO.

  • Rod: OCIO is designed to be poor in this regard. Names are arbitrary names. “The one from our show”.

  • Larry: but it’s things like AcesCG

  • RGB: You hope it’s the same thing, if it says AcesCT that they have the right log function. Even worse, you can’t copy/paste either. There’s a lot that’s wrong

  • Joseph: Antipodal: the way SMPTE does it with, carry both white point. There’s no flag in OpenEXR that says this is scene linear.

  • Rod: people put data in a file that is not linear. Really what they’re doing is storing half float values.

  • Joseph: I’ve got an exr with Rec709 data in it.

  • Rod: I’ve got log data.  What they’re saying is “The tool that I want to use doesn’t read camera raw, so I’ll put it in an exr file.”

  • Rod: OCIO is headed towards reasonably standard configs. If those become studio standard, then the thing we’re asking about would be OK. They’re this close to making them public. Studio config, ACES config, etc.

  • Rod: That idea that they’re putting out the thing you’ll use, it will open a whole new workflow if people use them.  I was hoping the configs would be strict subsets of each other, but instead it’s a venn diagram. There are things in one that aren’t in the other.  The proposals are all in the same color space at least. They all have the same reference. Why not say what it is, then we can do math on it. It’s not written for people who know what they’re doing.

  • Rod: In camera VFX shoot, they pick something off a list, you have no idea whether it’s right.

  • Larry: At Sony, you can’t believe anything in the metadata. So we said, “We’re going to use the filename.” The fact is, that doesn’t solve my problem as a software developer. Somebody tell me what we should do. Is there any alignment we can get between projects that all do different things?

  • People are doing sidecars, naming conventions, this is lost quickly in pipelines, especially across cross-facility

  • RGB: there’s input files, and output files.

  • Joseph: There's a bunch of stuff that should have been cleared out years ago. OpenEXR went to lengths to not have self-contradictory information in there. What state are we in? It’s icky.

  • Rod: There’s no law that the name of an OCIO is properly descriptive, or that a OCIO profile that claims AcesCG is properly implemented

  • Joseph: SMPTE does the opposite, there is a global enum of known chromaticity+whitepoint and transfer functions

  • Rod: If we have contradictory data in the header, that’s a problem. If you trust only one, trust this, except that it can be wrong sometimes.

  • Rod: We have the advantage is that it’s assumed to be linear. They say it’s color space, but it’s color space and color encoding together. There’s an aspect of display referred in there.

  • Larry: I’m super intrigued by the new configs. What do I do when there’s no OCIO config? I know about AcesCG, Rec709. A lot of default cases.  But if it’s not one of the standard names, it could be named anything.

  • Rod: The OCIO group is working on some standardized studio configs meant to address the problem. No LUTs, but standardized basics.

  • Rod: The problem is you can’t ask the config questions and get answers back. Can’t ask if it has a linear transfer function. If you could ask things about it. But they’re against doing that. 

  • Larry: I’ve softened them over the years. Doug is aware of how these become problems.

  • Rod: Unreal is supporting OCIO, people go pick something they’ve seen on the internet. The new things will be better. But we need to have this conversation with Doug.

  • Larry: We should go to their meeting. 

  • Rod: We agree on many of these points.

  • Larry: I’m less dogmatic about it, just trying to figure out how the software should work.

  • Chris: users of the texture want to know the color space.

  • Rod: we’ve recently adding options to the texture loading in unreal.

• Chris: Windows build warnings. 

•  

  • Started fixing them, then started to feel like it was a lot.

  • Many MVSC warnings are are from type conversion. 

• Compression:

•  

  • Should we namespace zlib? 

  • Larry: I’d like to hear more about these modern forks of zlib, API compatible.

  • Nick: Facebook has published simple compression libs that don’t do  all the fancy stuff.

  • Larry: We should explore these other implementations. In real work, the I/O bottleneck is how fast data can be shoved through the compressor. Different compression/time is huge.