Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

February 15, 2022

Host: Michael Dolan

Attendees: 

  •  
  • Sean Cooper (TSC ACES TAC Rep) - ARRI

  • Michael Dolan (TSC) - Epic Games

  • Thomas Mansencal - Weta Digital
  • Carol Payne (TSC Chair) - Netflix
  • Doug Walker (TSC Chief Architect) - Autodesk

  • Kevin Wheatley (TSC) - Framestore

OCIO Config Working Group Meeting Notes

  • CLF directionality naming:
    • Doug: Could imply directionality in urn (urn:aswf:ocio:inputTransformId), or in name (LogC_V3_EI800_to_ACES2065-1).
    • Thomas: If using urn and IDT needs to map to another space, would have to know version compatibility.
    • Michael: Directionality already implied in CG config CLF names, so would just be studio config.
    • Thomas: Could have both. Best of both worlds.
    • Carol: Could just be explicit in the name so it's clear.
    • Doug: Issue is you could have two transforms that aren't exact inverses. In OCIO we tend to invert the transform, but may be cases where you don't want to do that.
    • Group agrees to put direction in name, using explicit naming, and leave urn as-is.
    • TODO: Update document about directionality.
  • AMF:
    • Doug: Giving talk at HPA about AMF, CLF, and OCIO. AMF is ACES Metadata File, released in ACES 1.2. Sidecar file for media describing color space and how it should be viewed (looks, etc.). Defines a color processing pipeline. Each transform can be defined as a file, or as a transform ID. Transform ID is a common way of working so far. In order for AMF to work, needs to be a robust mapping of transform IDs to transforms. Could be aces-dev, which is how we have used it for these configs. In practice though, not all cameras are there. Just a README file in aces-dev pointing to external location for some IDTs. AMF seems a bit fragile at this point, with different vendors using their own transform IDs. There is a gap there, and with the work this group is doing to talk to camera vendors and get IDs, OCIO could be the missing piece of how to map those. There has to be a registry of transform IDs somewhere for AMF to be practical. Might be something for us to take on. In that case, maybe we should just use ACES transform IDs. Or in addition to asking for OCIO ID, we could ask for ACES ID and put it in the config. I wrote script that takes a version of the ACES reference config and adds a bunch transform IDs to it (forward and inverse ACES transform IDs, CSC and IDT transform IDs, etc.). Curious others thoughts?
    • Carol: Agree that something needs to happen. Already some interest in OCIO being this. Ideal to not have to reinvent the wheel. We're both open source projects so agree OCIO would be good choice for this. We should have the conversation with the AMF implementers and working group.
    • Kevin: Agree with what's been said. If we were to become the implementation, we would want to provide an explicit field in the config, or a separate file. There's a many to one naming problem and multiple directions. Would want to make those things more explicit.
    • Thomas: Being in description of color spaces makes it fragile.
    • Doug: Totally agree. Should be a transform ID field or something similar. The directionality is also an interesting thing since in AMF both directions can be used. The AMF file will have both directions, on either side of your CDL transform, but in the OCIO config we don't have both of those directions. OCIO generates the direction it needs. It might be counter-intuitive to have both direction transform IDs in a color space, but seems to work ok in practice.
    • Kevin: In OCIO we could create a mapping, but it may not be a generic source of truth for all vendors. Would need a database that can be used by both us and others. We could all use the data source to generate configs and other implementations.
    • Michael: Could do something like ASWF asset repo.
    • Thomas: Yeah, good idea. We're using that license for spectral data.
    • Doug: There is a question of where this should be eventually, like a database, but proposing for now a pragmatic step that we could take, to increase the amount of information we're writing to the reference config.
    • Kevin: Totally agree. This highlights the problem. Not a long term solution. Also brings up other challenging areas, like how on-set grades are handled, etc. Something else OCIO doesn't have an opinion on. Can implement it in OCIO, but we don't tell you how. This falls into a similar area. Something we don't mandate, but encourage. Would need more than these transforms required to make it work in real life.
    • Carol: Agree. Work in AMF is base image pipeline. As we move forward and AMF grows, something needs to happen. Agree with Doug that this intermediate step is a good starting point, to illustrate this. Can bring in AMF team and talk to them about it. And then could do more work on it, and discuss where it lives, and in what format.
    • Michael: CLF metadata shows up in OCIO config. Might be another option instead of description as an interim solution.
    • Carol: Directionality would complicate it, since it's GroupTransform metadata.
    • Kevin: Description would solve that for now. May be the cleanest way until we have a dedicated field.
    • Sean: Is there a more generic solve, since it's a mapping issue? An alias file for example, where an input string maps to the needed output.
    • Kevin: Yes, think that's potentially the right way to support this moving forward. For now we're relying on convention anyway, so can put it in description where the user can see it.
    • Doug?: Since we're going to vendors to ask for input transforms, would be good to help sort out ACES transform IDs too. Challenge with ACES ID is there are multiple: CSC and IDT. 
    • Kevin: So our IDs would be canonical. Or the ACES IDs are canonical and we point to that.
    • Carol: I think we can move forward. The camera vendor email is ready to send out. Ok if we need to change the name in the future. We have version control to allow changing stuff.
    • Michael: Just want to make sure the release of these configs isn't blocked too much.
  • CLF doc notes:
    • Michael: Zach raised point about mentioning use of Half domain LUTs if a LUT is required. Should we add that?
    • Kevin: Agree. Prefer CLF, followed by 3x3 matrix and Half domain LUT, and 3D LUT as last resort. The more options you give people, the more likely they are to pick the wrong one.
    • Carol: Especially with IDTs. Want it to be as precise as possible, so it can be invertible.
    • Doug: Agree. Since OCIO computes inverse, that also has implications. Suggest we provide python script demonstrating how to implement LUT where needed (Half domain LUT). Here's Python code you can use to generate the CLF. If someone can write CTF file, they have ability to write this.
    • Carol: Ok to send mail?
    • Group: Yes.
    • Doug: Will be good to have it in the queue anyway. Some vendors will have people at HPA, so good to have that discussion.
    • Carol: Ok, will send.
  • TODO: Michael will update spreadsheets to match CG config changes.


  • No labels