Page History

...

• Display P3 texture spaces
  • Doug:  The current CG and Studio configs have a basic set of texture spaces (for example they have the set of MaterialX color spaces that existed at that time).   We did have some discussion about extending the list but ran out of time before the release last October.  HP mentioned that he thinks Display P3 would be very helpful.
  • HP:  Yes, Display P3 is something that we are using very widely at Apple.  It aligns well with our hardware and is used in various Apple APIs.  It would be really helpful to have this added to the ACES configs as both linear and texture color spaces.
  • Doug:  The CG and Studio config currently have a "Linear P3-D65" color space, but the texture spaces are either Rec.709 or AP1 primaries.  I agree it would be helpful to have an option with P3 primaries.
  • Thomas:  Agreed.  This should be a simple addition.
  • HP:  Doug and I were discussing how to name it.  Doug: Yes, given that all of the display-referred color spaces in those configs end with " - Display", we should discuss whether using "Display" in a scene-referred texture color space would cause confusion.
  • HP:  One compromise would be to use the "Display" word in an alias.  Doug/Thomas: Agreed.
  • Doug:  Some of the current texture spaces use an "sRGB Encoded " prefix, so one option would be to follow that pattern.  For example: "sRGB Encoded P3-D65 - Texture" as the main color space name and then use something along the lines of "Display P3 - Texture" in an alias.
  • Chris:  I sometimes see things tagged as "Image P3", what is the difference between that and "Display P3".  Dhruv: I think "Image P3" is basically the same but is Adobe's implementation.
  • Doug:  There is a related question of whether we should add a display-referred Display P3 space for use with displays/views.  We discussed this before and one reason it was not added is that there is no corresponding ACES Output Transform.  HP, you may want to reach out to the ACES 2.0 Output Transform working group to get that added.  That way it would flow through automatically to at least the Studio config.
  • Action Item:  HP to create an issue on the configs GitHub.
• Release timeline for OCIO 2.3.0 configs
  • Doug: The guidance we've received regarding the VFX Reference Platform timetable for this year is that we should be targeting the 2.3 release for the end of August.  Given that the built-in configs are part of the library release, that means we should aim for having any updates to the CG and Studio configs ready by SIGGRAPH.
  • Doug: If you have changes you would like to see to these configs, please create issues on the ACES config's GitHub.
• Config merging
  • Doug: Let's continue the discussion about the config merge feature that we've been having for the past few TSC meetings, especially since it has implications for config development.  People have expressed different opinions about what is the best approach.  For example the merge vs. #include approach.  I've tried to capture the discussion so far in this Google Slides deck.
  • Mark: One of the controversial aspects is the use-case where an application could use this to add color spaces it needs.  Mixed feelings about this.  On the one hand, it's good to remove black-box application-specific code and put it in the library where it makes sense.  On the other hand, I understand why config authors don't want applications adding anything to their configs.
  • Doug: Agreed.  However, especially as OCIO gets deployed to a wider set of users beyond the high-end VFX houses with in-house color scientists, this might be really helpful.  Without that, what actions would be required for future releases of the ACES configs?  For example, would we be asked to add application-specific role names or color space aliases?  Is the release cadence adequate to keep up with application requirements?
  • HP: It's important to enable the application vendors to move at their own speed, not slow them down.
  • Mark: Applications could provide their own edited versions of the ACES configs to add any application-specific requirements.  This could address the "out of the box" experience for less knowledgeable users in a timely way.
  • Zach: What are some other examples besides an sRGB space or a linear sRGB space that applications might want to add?  Doug: Camera log spaces are one example, for applications that provide input from camera vendor SDKs.
  • Mark: The File Rules might be another example.  For example, Maya allows users to edit the config's File Rules.  Doug: That's right, we didn't want to overwrite what is in the user's config so currently they are in a separate config-like file.
  • Zach: There is also the OpenEXR file chromaticities example that was discussed awhile back.  Given that applications are already able to add color spaces to a user's config via the API, I'm not too worried about this.  It's not really adding a new capability as much as standardizing something applications are already able to write custom code for.
  • Thomas: It would be helpful to have the ability to prevent the host program from doing a merge, as a debugging tool.  For example, if the user color spaces are not behaving as expected.
  • Doug: Yes, Kevin suggested that as well.  I agree there should probably be something like that, but I'm not clear on exactly how it would work.  For example, if the app cannot do the merge, it cannot proceed, it would just reject the config.  Although the error would alert someone that an app needs to do a merge, an app may not be able to proceed in a way that would allow debugging.  Someone would still need to run ociomerge outside of the application to do the debugging.  Is that sufficient?
  • Doug: This has been great input, thank you everyone.  We will discuss again at the TSC meeting.  We would need to start implementing this soon if we want it in the 2.3 release.  However, all options are still on the table, including doing nothing.  Ideas/suggestions are very welcome regarding how to best address everyone's feedback so far.