The last two meetings, we’ve had lively discussion around standardizing naming for BOTH the published, fixed, CTL version as well as thinking ahead to the future of wanting consistency in the parameterized version’s naming.
Many good thoughts were put forward, so thank you all for the input and candor. @matthias.scharfenber , @nick and myself are proposing the following naming scheme, and opening up the floor for dissent:
ACES Reference Gamut Compression 1.3
This would be the official, fixed, default parameters as published in the CTL. It would be what should be used on set & tracked via AMF.
ACES Variable Gamut Compression 1.3
This would be our suggested naming for any tools wishing to implement a parameterized version of the Reference. It would be the naming for the underlying FixedFunction in OpenColorIO.
It will be up to us as the implementation group to make it very clear the intended workflow and use cases, and that as of ACES 1.3, the Variable version will not be trackable via AMF. We think this is an acceptable caveat, as if you need the variable parameters, you are leaving technical workflow operations and entering the land of creative choices - similar to other grading or VFX operations which alter the pixels of an image.
We are trying to avoid the poll approach, as many options were already discussed at length in the meetings.
If enough folks feel strongly about Parametric instead of Variable, I have little objection to that… other than that technically, the Reference is already parametric, it’s just default values… we liked Variable as it hints at user-controlled or situation-controlled parameters.
One could equally say that the Reference is also Variable but with default values Variable being also a programming related noun feels less elegant and specialised than Parametric which is really just an adjective/qualifier.
The naming differences aren’t distinct enough. Marketing people will further reduce the difference to the ACES GC. in “Yes we support the ACES GC”.
For many users, variable seems more powerful than fixed, so they’ll go for variable even when not needed.
Better would be to call the variable method Las Vegas, because What happens in Las Vegas stays in Las Vegas, that is, the method is not interchangeable. Oh, and using it for interchange would be a gamble. This is a highly memorable name.
Because I’m coming from an educational background, I mostly have other sights to the problem than the people in the heart of production. There, things are often conveyed by jargon. Teaching people means starting with a rough outline and then approaching the details. Along the way, there are a lot of pitfalls being imprecise because of the shortcuts. So it helps when the waypoints are clear.
What does it mean for the naming?
I have the feeling that „parameterized“ is a bit of internal jargon. „Variable“ has the issues that Thomas said. From a user perspective, „editable“ sounds more appropriate for me because it suggests that the user can do something with it, but I could live with each of the three names.
If you want the acronyms pronounceable, change the character order. GCR would be „geezer“ like Geezer Butler from Black Sabbath. Ok, that’s just a joke.
It is a more common word than “Parametric” and feels simple and plain-spoken. Selecting something with “Custom” in the name also suggests to the user that they are the ones choosing not to use defaults (reference).
The qualifier “Reference” feels really awkward to me. “Reference” with respect to what… fixed values for parameters that aren’t exposed in the first place? The word is kind of meaningless outside the context of comparison.
My vote goes for “Gamut Compress Fixed” and “Gamut Compress Parametric”. “Fixed” vs “Parametric” unambiguously and precisely describes the difference between the two. One exposes parameters, the other doesn’t. I’d also be happy with “Gamut Compress Interchange” and “Gamut Compress Tool” or something like that, which distinguishes between their practical uses.
I think of at least equal importance is canonizing a name for the image state after the “fixed” / “reference” function has been applied – maybe something like AP0-GC or AP0’ or AP0gc or something like that.
@matthias.scharfenber, @nick and my opinion is that between parametric, editable, custom, and variable - all of these sit in a very similar space, and preferences most likely come down to personal interpretation of language. Everyone has our own very valid opinions! Therefore, our decisions to use Reference and Parametric come down to their precedence of use in other areas of the ACES framework.
Variable being also a programming related noun feels less elegant and specialised than Parametric which is really just an adjective/qualifier.