Collated Feedback from the Studio Config

## @flord

- There is no Arri input space in the studio config? That is almost the only one we need!
- There is no linear sRGB colorspace? I understand it's the same as linear Rec.709, but I would expect sRGB to be mentioned somewhere to avoid any confusion. linear Rec.709/sRGB perhaps...
- In Nuke, when loading a .mov file, it seems to be hard-coded to use the Gamma2.2 space. With either config, Nuke throws an error because that space does not exist. How are we going to deal with that? Tell Foundry to stop hard coding spaces?
- In Nuke, there is only one menu for displays and display spaces. This makes the raw space being repeated multiple times, making the list of spaces even longer. I guess we also need to ask Foundry to fix that.


## @MrLixm

- https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/issues/57#issuecomment-1160856386

> Hello, great to see this discussion. A thing I'm wondering is why the unique identifier of the colourspace is also the pretty name used for interfaces? Shouldn't decoupling the UI and the logic a better idea to allow for more flexible configs that can be updated at any moment ?
>
> SImple naive example :
>
> ```yaml
> - !
> identifier: displaysrgb
> name: True-PRO sRGB Display
> family: Display
> equalitygroup: ""
> bitdepth: 32f
> description: Convert CIE XYZ (D65 white) to sRGB (piecewise EOTF)
> ```
>
> Where anyone could just change the name and it wouldn't break anything in any software.
>
> This could then open a lot of other discussions (identifiers formats, identifiers conventions, ...) but just wanna know your thought about this ? Cheers. Liam.

## @anderslanglands

> I understand that it may be too late but it would be _really_ nice if compact, unique identifiers could be split from the “display name”, especially if the display name is forced to have extra context to be used in isolation.
>
> For instance, some applications will bake the colour space name into file names (substance does this when exporting) and with the current ACES configs this results in some absolutely horrific file names. Plus all those spaces are just bugs waiting to happen.
>
> As someone who likes to think he knows a little about colour, but doesn’t know OCIO very well, I find the current naming in the ACES configs extremely confusing - eg which sRGB is actually sRGB? Or are they both the same thing? (I still don’t know the answer to this).

## @KelSolaar

- `Rec. 709/Rec. 1886` for display names vs `Rec.709/Rec.1886` for colorspaces.
- Ensure that colorspaces version is updated when we update the generator.

## @scoopxyz

- Just a small comment to include a link to the spreadsheets that are used as the "ground truth" for naming, etc. in the README.md if you can :)

## @nick-shaw

> Is there a reason that the ACES Reference Gamut compression is available as a look in the Reference config, but not the Studio config? I feel we should be encouraging people to start using it, and making it easy for them to do so.
>
> On that subject, because the "Blue Highlight Fix" is alphabetically before the RGC, that comes up as the default look when the Reference config is used. That should really be deprecated in favour of the RGC.
>
> And finally (not that I'm obsessed with the RGC at all!) but it brings up the point that support for aliases in looks could be useful, so you could simply use e.g. "RGC" instead of typing "ACES 1.3 Reference Gamut Compression" in full.

## [Bartłomiej Styczeń](https://app.slack.com/team/U02QZ2F6ADC)

> [@Thomas Mansencal](https://opencolorio.slack.com/team/U3RLQD2KH)
> so I finally got to this, and all seems to go well until I specify a BuiltinTransform Style in the CSV, I tried with these:
> ACEScc_to_ACES2065-1
> ACEScct_to_ACES2065-1
> ACEScg_to_ACES2065-1
> ACESproxy10i_to_ACES2065-1
> And they all crash the generator with
> INFO:opencolorio_config_aces.config.cg.generate.config:Creating a "Colorspace" transform for "ACEScc_to_ACES2065-1" style...
> Traceback (most recent call last):
> File "/home/aswf/OpenColorIO-Config-ACES/opencolorio_config_aces/config/studio/generate/config.py", line 274, in
> config, data = generate_config_studio(
> File "/home/aswf/OpenColorIO-Config-ACES/opencolorio_config_aces/config/studio/generate/config.py", line 228, in generate_config_studio
> _config, data = generate_config_cg(
> File "/home/aswf/OpenColorIO-Config-ACES/opencolorio_config_aces/config/cg/generate/config.py", line 997, in generate_config_cg
> colorspace = style_to_colorspace(**kwargs)
> File "/home/aswf/OpenColorIO-Config-ACES/opencolorio_config_aces/config/cg/generate/config.py", line 415, in style_to_colorspace
> [beautify_alias(signature["name"])] + signature["aliases"]
> KeyError: 'name'
> Before I delve into the source code, just wanted to ask if it’s something you recognise and maybe the problem is as trivial as error in the BuiltinTransform Style name

> After some debugging and slight modification to the code and csv, I got a config, but not really sure about the correctness of it.
> The problem I mentioned above is due to a signature["name'] never being set. I have no clue where that name should come from so I just fed it style name.
> Later on there was a problem with the config version:
> PyOpenColorIO.Exception: Error building YAML: Only config version 2.1 (or higher) can have BuiltinTransform style 'ACES-LMT - ACES 1.3 Reference Gamut Compression'.
> It seems like the generation starts with the proper 2.1 version, but then it is changed midway to 2.0 in
> config/cd/generate/config.py:
> 1085: data.profile_version = VersionData(2, 0)
> If that was intended, can I just remove that line or will it mess up the further logic? (edited)

> Sidenote: Dockerfile seems to be a bit out of date, it’s based on old ci-ocio that uses python 3.7 and one of the requirements requires python >= 3.8 (numpy 1.22 if I remember correctly).
> I’ve used FROM aswf/ci-ocio:2022 and it built fine, but maybe that can cause some issues with the generator?

## @mdecaria

Hi, congratulations on the beta config release, just have some general questions/feedback on the Studio Config
- I'm curious about the reason behind no Linear P3-D60? Why have P3-D60 Display and D60 sims if the linear equivalent isn't available to help with those workflows?
- How are the aliases' names chosen? Some seem a little inconsistent/missing.
srgb_texture would be nice to have on sRGB - Texture
Should ST-2084 - Curve have the st2084_crv alias for consistency with the display name?
Why does Linear Rec.2020 get a combined alias with no underscore but other spaces don't?
- For categories labels - ACEScg is a working-space, Linear Rec.709 is also one; although not typical, Linear P3-D65 could be labelled as one?
- As the DCDM ODTs are now omitted ( sadly ), what's the best re-implementation for backwards compatibility sake besides relying on the previous LUTs?

## @remia

I looked quickly at the studio config, nothing really important to report or probably already known:
- The config generates the following warning: `"[OpenColorIO Warning]: file_rules: defines a default rule using color-space 'ACES2065-1' that does not match the default role 'sRGB - Texture'."`,
- The `'/'` family separator is used in some colorspaces which cause additional menu hierarchies in Nuke but seems to be handled correctly with the newer app helpers so just need to update the UI,
- NamedTransform for ST2084 curve encoding attribute is "log", might be "hdr-video" but I guess the former also makes sense strictly speaking,
- I was a bit mislead by the OCIO version in the config name, it seems to be the one used by the generator but not the one to be used by the end-user. As in if it was the case I would expect the OCIO 2.1.2 studio config to include the RGC and have a 2.0.4 version without it,
- Testing on ociodisplay exposed a crash on Linux when there is no Looks in the OCIO config and you hover the Looks override menu (more of a note for OCIO dev to look at).

Great work everyone!

## @zachlewis

My quickie beef -- can we get rid of the " - Display" part of the Display names? Gets to be quite a bit to type.

I understand that we want to keep " - Display" in the Display Color Spaces names, and that's fine. But maybe instead of using Shared Views for all the ACES-based views, we can use plain-ol regular views.

## Derek Flood

I see that the Canon CLFs have been updated for C-Log3 and its corresponding linear.
https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/pull/71

Is it planned to also support the C-Log2? Or is C-Log2 depreciated/unsupported?

Just seeking education/understanding, thanks!

Begin by reviewing the generator paths mentioned in the traceback, especially opencolorio_config_aces/config/studio/generate/config.py and config/cg/generate/config.py, along with the Dockerfile and README.md. Separate the configuration requests, generator errors, naming questions, and application-specific notes before choosing a scope. Done should mean that the selected items have explicit decisions and corresponding verified configuration or generator changes.

Written by the indexing model from the issue text.