Adds Apple Log 2 and Linear Apple Wide Gamut

[carolalynn]

Closes #163.

Adds the Apple Log 2 and Linear Apple Wide Gamut colorspaces to the Studio
config. Apple Log 2 uses the same transfer function as Apple Log but encodes
in the Apple Wide Gamut primaries rather than ITU-R BT.2020.

Depends on OpenColorIO#2343

Rather than declaring the conversion inline as a GroupTransform, the Apple Log 2 CLF transform is built from the APPLE_LOG-APPLEWG_to_ACES2065-1 builtin
added in AcademySoftwareFoundation/OpenColorIO#2343, so the generated config
declares the builtin directly:

    to_scene_reference: !<BuiltinTransform> {style: APPLE_LOG-APPLEWG_to_ACES2065-1}

The style is registered at Version(2, 6) in BUILTIN_TRANSFORMS, the release
the builtin lands in. BUILD_CONFIGURATIONS currently targets OpenColorIO 2.5,
so until that is bumped the row is skipped with a warning and Apple Log 2 does
not appear in the built configs. Linear Apple Wide Gamut is a plain matrix and
appears immediately.

Original issue uses ocio:linear_applewg_scene as the interop ID for the linear
colorspace. This uses ocio:lin_applewg_scene instead, for consistency with
the thirteen other scene-linear colorspaces, all of which use the lin_ prefix
(ocio:lin_awg4_scene, ocio:lin_dwg_scene, ocio:lin_rwg_scene, ...). The
Apple Log 2 interop ID is unchanged from the proposal.

@doug-walker, flagging for viz

ACEStransformID

urn:ampas:aces:transformId:v2.0:CSC.Apple.AppleLog2_to_ACES.a2.v1 is recorded
for Apple Log 2. The CSC exists upstream in ampas/aces-input-and-colorspaces
(2331f7d, "Add CSCs for Apple Log 2") but not in the currently pinned aces
submodule, so the interchange: amf_transform_ids: block does not populate yet.
It will once the submodule is bumped, with no further change here.

That bump is deliberately left out of this PR: the same upstream commit renames
CSC.Apple.AppleLog_BT2020_to_ACES to CSC.Apple.AppleLog_to_ACES, and a
separate commit moves the Canon and DJI CSCs from the a1 to the a2 token.
Four transform IDs currently referenced by the mapping files disappear at
upstream HEAD, which is a breaking change better handled on its own.

The second commit re-exports generate_clf_transforms_apple from the
opencolorio_config_aces.clf.transforms and opencolorio_config_aces.clf
packages and adds it to the documentation. It was the only vendor generator
missing from both, which went unnoticed because invoke build-clf-transforms
runs each generate.py directly rather than through the package namespace.

Verification

Built OpenColorIO from OpenColorIO#2343 to generate the CLF transforms
against the real builtin.

• The builtin on [0.5, 0.4, 0.3] returns [0.16030183, 0.09122278, 0.02640572],
  matching the unit test values in OpenColorIO#2343 within its 1e-6 tolerance.
• The Apple Wide Gamut to ACES2065-1 matrix derived from the primaries with
  Bradford adaptation matches the matrix published in Add Apple Log 2 color space #163 to 2.9e-15, and
  matches the matrix the builtin bakes into the CLF transform. The ACES CTL
  transform independently derives it the same way, via
  calculate_rgb_to_rgb_matrix, whose coneRespMat defaults to
  CONE_RESP_MAT_BRADFORD.
• Routing Apple Log - Curve into Linear Apple Wide Gamut is bit-identical to
  the Apple Log 2 builtin path in the generated config.
• The Studio config generates and validates, at both profile version 2.5 (row
  skipped) and with the gate lifted (row present).

Assisted by: Claude / Opus 5

[doug-walker]

Looks fine to me, but I will defer to Thomas, as he is the expert here. I did verify that the matrix in Apple.Input.Linear_Apple_Wide_Gamut_to_ACES2065-1.clf is correct.

When looking at the original spreadsheet on Google that is supposed to populate the Mapping.csv file, some of the boxes that I would have expected to be filled in are empty. Not sure if that is intentional.

[doug-walker]

@scottdyer, are the AMF transform ID changes Carol mentions above necessary? These kinds of changes create a lot of problems for downstream consumers such as OCIO.

[scottdyer]

Hi @doug-walker,

How necessary each change is depends on which change we're talking about:

1. I would argue that Canon and DJI (a1 to a2) is a necessary bug fix. The a1 was a typo leftover that is not compliant with the ACES 2.0 URN format and was breaking scripts. (Side note: I've never personally understood why we even need a1 or a2 in the URN format, but that's a debate for the ACES side of things...)

2. The Apple Log 1 rename (AppleLog_BT2020_to_ACES to AppleLog_to_ACES) was certainly more "cosmetic", and we were aware it might cause issues when it was first proposed in the PR back in January. The current form was selected in favor of brevity and to align the existing Apple Log 1 transform (originally added by Academy staff) with the vendor-preferred naming submitted with Apple Log 2. We could decide to revert this transform ID change if that's easiest.
   However, ACES would then still need to consider if the newer name should be aliased as an equivalent transform ID in transforms.json anyway since it has been published like that since February. That is to say, changing it back could help OCIO, but others might have already updated theirs with the new name.

But I completely understand the frustration - managing Transform IDs is painful. I am somewhat hopeful that the forthcoming python libraries can help a lot with assisting to make sense of the prior mess and version up to what will hopefully be cleaner moving forward. And we can do our best to be regimented about avoiding unnecessary breaking changes moving forward.