AMF Components - Where, How?

Hello,

@carolalynn, @doug_walker and I have been working on the new release for the OCIO Configs for ACES and we have added AMF Components to the various colourspace descriptions. Here are a few cherry-picked examples:

  - !<Look>
    name: ACES 1.3 Reference Gamut Compression
    process_space: ACES2065-1
    description: |
      LMT (applied in ACES2065-1) to compress scene-referred values from common cameras into the AP1 gamut

      ACEStransformID: urn:ampas:aces:transformId:v1.5:LMT.Academy.ReferenceGamutCompress.a1.v1.0

      AMF Components
      --------------
      ACEStransformID: urn:ampas:aces:transformId:v1.5:InvLMT.Academy.ReferenceGamutCompress.a1.v1.0
    transform: !<BuiltinTransform> {style: ACES-LMT - ACES 1.3 Reference Gamut Compression}

  - !<ViewTransform>
    name: ACES 1.0 - SDR Video
    description: |
      Component of ACES Output Transforms for SDR D65 video

      ACEStransformID: urn:ampas:aces:transformId:v1.5:ODT.Academy.RGBmonitor_100nits_dim.a1.0.3
      ACEStransformID: urn:ampas:aces:transformId:v1.5:ODT.Academy.DisplayP3_dim.a1.0.0
      ACEStransformID: urn:ampas:aces:transformId:v1.5:ODT.Academy.Rec709_100nits_dim.a1.0.3
      ACEStransformID: urn:ampas:aces:transformId:v1.5:ODT.Academy.Rec2020_100nits_dim.a1.0.3

      AMF Components
      --------------
      ACEStransformID: urn:ampas:aces:transformId:v1.5:InvODT.Academy.RGBmonitor_100nits_dim.a1.0.3
      ACEStransformID: urn:ampas:aces:transformId:v1.5:InvODT.Academy.DisplayP3_dim.a1.0.0
      ACEStransformID: urn:ampas:aces:transformId:v1.5:InvODT.Academy.Rec709_100nits_dim.a1.0.3
      ACEStransformID: urn:ampas:aces:transformId:v1.5:InvODT.Academy.Rec2020_100nits_dim.a1.0.3
    from_scene_reference: !<BuiltinTransform> {style: ACES-OUTPUT - ACES2065-1_to_CIE-XYZ-D65 - SDR-VIDEO_1.0}

  - !<ColorSpace>
    name: sRGB - Display
    aliases: [srgb_display]
    family: Display
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Convert CIE XYZ (D65 white) to sRGB (piecewise EOTF)

      AMF Components
      --------------
      ACEStransformID: urn:ampas:aces:transformId:v1.5:ODT.Academy.RGBmonitor_100nits_dim.a1.0.3
      ACEStransformID: urn:ampas:aces:transformId:v1.5:InvODT.Academy.RGBmonitor_100nits_dim.a1.0.3
      ACEStransformID: urn:ampas:aces:transformId:v1.5:ODT.Academy.RGBmonitor_D60sim_100nits_dim.a1.0.3
      ACEStransformID: urn:ampas:aces:transformId:v1.5:InvODT.Academy.RGBmonitor_D60sim_100nits_dim.a1.0.3
    isdata: false
    categories: [file-io]
    encoding: sdr-video
    allocation: uniform
    from_display_reference: !<BuiltinTransform> {style: DISPLAY - CIE-XYZ-D65_to_sRGB}

  - !<ColorSpace>
    name: ACEScg
    aliases: [ACES - ACEScg, lin_ap1]
    family: ACES
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Convert ACEScg to ACES2065-1

      ACEStransformID: urn:ampas:aces:transformId:v1.5:ACEScsc.Academy.ACEScg_to_ACES.a1.0.3

      AMF Components
      --------------
      ACEStransformID: urn:ampas:aces:transformId:v1.5:ACEScsc.Academy.ACES_to_ACEScg.a1.0.3
    isdata: false
    categories: [file-io, working-space, texture]
    encoding: scene-linear
    allocation: uniform
    to_scene_reference: !<BuiltinTransform> {style: ACEScg_to_ACES2065-1}

  - !<ColorSpace>
    name: BMDFilm WideGamut Gen5
    aliases: [bmdfilm_widegamut_gen5]
    family: Input/BlackmagicDesign
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Convert Blackmagic Film Wide Gamut (Gen 5) to ACES2065-1

      CLFtransformID: urn:aswf:ocio:transformId:1.0:BlackmagicDesign:Input:BMDFilm_WideGamut_Gen5_to_ACES2065-1:1.0
      ACEStransformID: urn:ampas:aces:transformId:v1.5:IDT.BlackmagicDesign.BMDFilm_WideGamut_Gen5.a1.v1

      AMF Components
      --------------
      ACEStransformID: urn:ampas:aces:transformId:v1.5:ACEScsc.Academy.ACES_to_BMDFilm_WideGamut_Gen5.a1.v1
      ACEStransformID: urn:ampas:aces:transformId:v1.5:ACEScsc.Academy.BMDFilm_WideGamut_Gen5_to_ACES.a1.v1
    isdata: false
    categories: [file-io]
    encoding: log
    allocation: uniform
    to_scene_reference: !<GroupTransform>
      name: Blackmagic Film Wide Gamut (Gen 5) to ACES2065-1
      children:
        - !<LogCameraTransform> {base: 2.71828182845905, log_side_slope: 0.0869287606549122, log_side_offset: 0.530013339229194, lin_side_offset: 0.00549407243225781, lin_side_break: 0.005, direction: inverse}
        - !<MatrixTransform> {matrix: [0.647091325580708, 0.242595385134207, 0.110313289285085, 0, 0.0651915997328519, 1.02504756760476, -0.0902391673376125, 0, -0.0275570729194699, -0.0805887097177784, 1.10814578263725, 0, 0, 0, 0, 1]}

We met a few challenges whilst doing that:

  • There is no canonical and authoritative source to pull those components from.
  • aces-dev does not have enough information to establish the relations between the various CTL pieces, for example, nothing relates urn:ampas:aces:transformId:v1.5:IDT.BlackmagicDesign.BMDFilm_WideGamut_Gen5.a1.v1 to urn:ampas:aces:transformId:v1.5:ACEScsc.Academy.ACES_to_BMDFilm_WideGamut_Gen5.a1.v1.
  • Some IDTs, e.g. V-Log V-Gamut, are not in aces-dev.

With that in mind, I would be keen to discuss on how to solve that? It seems like, if AMF is to be adopted, a dataset/database of some sort must be designed and maintained authoritatively so that people can refer to it. It would, for example, have been extremely useful that for a given ACEStransformID request to an online API, e.g. REST, a response with the related AMF Components is returned. A JSON file in aces-dev could also describe those relations. We for example created one for the purpose of the OpenColorIO Config for ACES that helps us finding the missing ones: https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/blob/ccf11e8c53641aebf9894acee6c91c06bd217399/opencolorio_config_aces/config/reference/discover/resources/ACES_AMF_Components.json

Cheers,

Thomas

1 Like

Thanks @Thomas_Mansencal . I’d be happy to discuss what makes sense for this and how I can help support the needs of products like OCIO moving forward. I welcome any ideas or requests on files that would be useful to add (like the JSON file manifest you mention) or restructuring to make tracking the transforms and any changes to them easier to integrate into products. We have a great opportunity in the prep for ACES 2.0 to try to “do it right” based on things we’ve learned or realized since v1 went out.

We also have need to officially set the form of the transform ID tokens (and fix broken ones)

The “Where? How?” that you ask also extends to other aspects of the maintained ACES components. I would also like to think about and discuss:

  • the tokens and ordering that go into the filename string for customized ODTs produced using the parameters but outside the commonly used stock transform that we provide as presets. (e.g. does the filename disclose all the parameters that are set in the Output Transform? - peak luminance, CAT used, EOTF, primaries, limiting primaries, etc. Is that a good thing or a bad thing to have verbose filename? Or can this information be communicated in another way?
  • The entire architecture of the transforms (directory hierarchy and what is stored where?)
    • what format are they provided in? CTL, DCTL, CLF, flspace, some mixture of the above?
    • IDTs separated? how are user-submissions delineated from those vetted by the manufacturer or, at the very least peers?
  • “versioning” (whatever that means) and the best way to track it and communicate it
  • anything else related to how the code is stored / maintained that has irked people over the years