Output Transform Naming

Some of the transform variations that are being added in ACES 1.1 required us to work some new details into the transform filenames to distinguish their purpose. In doing so, there were a few slight tweaks to existing names that were made to align with those changes. You can see the proposed list of ACES 1.1 Output Tranforms here. The tweaks to exisiting transform names are highlighted in bold in the 1.1 column.

In general, an effort was made not to change the naming scheme too much in 1.1.

However, a few individuals have proposed some further name adjustments be made in an effort to “figure out what works” as we work toward ACESNext.

So I wanted to start a discussion thread here where people could air their grievances about any existing filenames and offer suggestions on how they might go about “fixing” what they think is broken.

I’ll prompt the discussion by trying to describe the naming logic I established for myself to follow in order to organize the 1.1 dev release.

Logic for ODT Naming Scheme (as of v1.1)

A full ODT descriptor string might be something like:
DisplaySetupPrimariesAndWhite_LimitingPrimariesAndWhitelimited_whiteSim_peakWhiteLuminance_midmidgrayLuminance_EOTF_surround_signalRange

Ex.
P3DCI_P3D65limited_D65sim_48nits_mid4.8nits_BT1886_dark_full

In general, any substring that can be easily inferred from the context can be omitted. If there is room for ambiguity, the name should err on the side of specificity rather than brevity.

Details

  • DisplaySetupPrimariesAndWhite
    AndWhite can be omitted if it’s implied. For example, D65 is defined as the white point for Rec.709, so it is not required (Rec709 is sufficient). However, P3 by itself just specifies the RGB primaries and does not specify a white point, so white point is required. This is to avoid the incorrect assumption that P3 implies “DCI white” (it doesnt!).
    Technically, DCDM is not a set of primaries but is used in their place when a projector is set to expect DCDM code values (i.e. X’Y’Z’). (ACES 2.0 will hopefully deprecate this and instead recommend converting P3 output to DCDM encoding using other means.)

  • LimitingPrimariesAndWhite
    LimitingPrimaries can be omitted when they are the same as the DisplaySetupPrimaries. This is commonly the case. Limiting primaries are only required when explicitly clipping to another set of primaries than those in the display setup.

  • WhiteSim
    If not provided, whiteSim is assumed to be the same as DisplaySetupWhite

  • PeakWhiteLuminance
    Always provided as display luminance is extremely important

  • MidGrayLuminance
    Used to indicate the default screen luminance at which an ACES value of 0.18 will appear
    If not provided, assumed to be 4.8 nits

  • EOTF
    Used to indicate the expected display EOTF
    Only required when EOTF is not easily inferred from the context. For example, a gamma 2.6 is implied and need not be explicitly stated for P3 digital cinema ODTs.

  • signalRange
    Used to specify whether signal is full range or SMPTE “legal” range
    If not provided, assumed to be full range

This process highlighted for me that we do deviate from our existing naming conventions on a few occasions (e.g. P3DCI should be P3DCI_D60sim).

(Personal note: I do not necessarily believe this to be best naming scheme for ACES moving forward, but it explains the process I used to reconcile the requisite additions needed for the v1.1 transforms into the existing names.)

I propose some modifications to the naming convention. I find the list Scott shows to have confusing elements. Here are my main points:

A) D60sim is consistently confusing. This is the main ACES white point, not a ‘sim’. It loses the distinction that ’sim’ really means that you are on a D65 device, but that the RRT-adopted-white is being rendered unchanged for the output image on a device. The other choice is a D65-adopted-white for either TV or Cinema. The D65-adapted versions are a ‘sim’ because they use a chromatic adaptation and are thus not an exact match to the cinema timing. But lets not confuse things further, instead just clarify the use of adopted white on a device in the name:

D60sim is really ‘D60-on-D65’ – showing D60, ACES adopted white, on a D65 calibrated device.
P3D65 is really 'D65-on-D65’ but agree that since both are the same, only one is needed – P3D65

B) ‘limited’ does not need to be spelled out. A short form like ‘Ltd’ can be used. It needs to be recognizable as different than the interface setting of (full/limited) which is often used instead of (full/legal). This can be done by putting it first before the color space reading ‘LtdP3D60’ as limited to P3D60. Another benefit of putting it first is that it makes it clear that the second color space is a modifier not the primary.

C) nits as well does not need to be spelled out. The abbrev. of ‘nt’ is recognizable.

D) Although having a 15nt can be recognized from context as a lower level brightness target. Clarity would suggest that it would be better to identify which luminance it is. (e.g. mid15nt ) Not sure if this one is really needed but wonder what people think.

Figuring a full naming logic is really a task for ACESnext, but new ODTs that require more explanatory names can start on the right path. Only occasionally do the .ctl names wind up in the interface.

So here is a modified proposal:

ACES 1.1 (proposed)
P3D60_48nt
P3_D60onDCI_48nt
new P3_D65onDCI_48nt
new P3D65_48nt
new P3_D60onD65_48nt
new P3D65_LtdRec709_48nt
DCDM
DCDM_LtdP3D60
new DCDM_LtdP3D65
Rec2020_100nt_dim
new Rec2020_LtdRec709_100nt
new Rec2020_LtdP3D65_100nt
Rec709_100nt_dim
Rec709_D60onD65_100nt_dim
sRGB_100nt_dim
sRGB_D60onD65_100nt_dim
P3D60_ST2084_1000nits deprecated
P3D60_ST2084_2000nits deprecated
P3D60_ST2084_4000nits deprecated
Rec2020_ST2084_1000nits deprecated
new P3D65_108nt_mid7.2nt_ST2084
new Rec2020_1000nt_mid15nt_ST2084
new Rec2020_2000nt_mid15nt_ST2084
new Rec2020_4000nt_mid15nt_ST2084
new Rec2020_1000nt_mid15nt_HLG

I hope that these are clearer about the intended use even if we are only talking about the .ctl filenames.
More naming fun to come in ACESNext.

I know that Scott would like to collect feedback on what is partly a preference (how to make it clear to as many as possible in ACES 1.1 ), so please leave comments or a reaction either way in the thread.

Thanks,

Jim

p.s. since formatting sucks… here is a PDF

ACES1.1naming.pdf (32.3 KB)

I’ll go further than that and stop spreading confusion by calling the ACES whitepoint D60 which it is not and AFAIK the ODT does use the ACES whitepoint: https://github.com/ampas/aces-dev/blob/master/transforms/ctl/odt/rgbMonitor/ODT.Academy.RGBmonitor_D60sim_100nits_dim.ctl#L40

Strictly true, yes. But how do you abbreviate “ACES white point” so the names aren’t unwieldy? Just putting “ACES” in there doesn’t tell people you are referring to the white point. I would put a case for the benefit of continuing to use the approximation of calling it “D60” because then everybody knows it refers to a white point. And since it is an output transform, I challenge anybody to see the difference between D60 and ACES white.

And I don’t actually have a problem with calling an ODT “D60 sim”. It is after all simulating a display being calibrated to D60 (OK ACES White) on a display calibrated to a different white point.

Maybe one of those:

  • ACESWP
  • ACESW
  • AWP
  • ACESWhite
  • ACES-WP
  • ACES-W
  • A-WP
  • ACES-White

I personnally don’t really care much about the length provided it gives the exact information and is not a lie.

Cheers,

Thomas

My two cents:

  • In ACESNext, there needs be a way to refer to ODTs (and other core ACES transforms) in a more consistent way than just “by filenmame”, which may simply not “stick” with the transform’s algorithm.
    For example, I proposed several times to use UUIDs (or even hashing) mechanisms.

  • Please don’t use abbreviation nt: there’s simply not any unit abbreviated like that. Using the SI unit cd/m² would be good, but not for filenaming convention’s sake [read the above cent]. Maybe better stick with simply nit (singular, as in kg, ft, W, etc.).

  • Please be consistent with the order of output colorimetry parameters to put: always use primaries / whitepoint / transfer-characteristics(gamma) / target-luminance(s) / any-other-business

1 Like

Well the issue has never been that it isn’t accurate, but rather that it confuses too many people because it does not say for a D65 device. SO they think it is for a D60 device and of course all video devices are for D65 so why would you ever use D60. If doing a cinema grade, I think you should always use D60sim, but the name doesn’t tell you that either. “D60onD65” and “D60onDCI” are better names for what they really do, though they are JUST as accurate. So trying to reduce the real confusion that has arisen even on big projects.

SO they think it is for a D60 device and of course all video devices are for D65 so why would you ever use D60. If doing a cinema grade, I think you should always use D60sim, but the name doesn’t tell you that either. “D60onD65” and “D60onDCI” are better names for what they really do, though they are JUST as accurate.

I feel like it’s worth emphasizing that as ACES is more widely used, it is used more by people who have limited knowledge of color technicalities and no-one to set things up for them or tell them what they should use when.

Jim’s example “of course all video devices are for D65” put it perfectly. I picture the average artist choosing “aces” in the color prefs of their application and then scrolling through the list of options trying to guess what to pick for output. “D60onDCI” as an example not only says what it does but cues them that if they find out what the display device is they’ll know the right choice to pick.

A few added characters to make names explicit and free of assumptions is a small price for enabling more people to use ACES successfully and confidently.

1 Like

Re: what to call “D60 Sim mode”… well, it’s easier than saying, “not-chromatically-adapted-to-the-output-device-calibrated-whitepoint” mode… maybe “ACES Creative White”? That’s how I normally think of it.

Re: naming, tokenization – I strongly agree with @mplec – intelligibility and consistency trumps brevity and convenience. Respectfully, I find it less confusing – visually, conceptually – if all output transform names err on the side of redundancy, so long as it’s easy to determine what the differences and similarities are among a list of ODTs. In fact, as far as file names go, I wouldn’t mind if each token was populated for each transform, so information about each transform could be easily parsed from the filename without resorting to fancy logic. Like, if we’re gonna start listing midpoint luminances, I’d like to see them listed for the 4.8nits default cases as well.

What isn’t helpful, to me, are shortcuts, abbreviations, and assumptions. I have a veritable closet filled with LUTs from various vendors and shows that use obscure shorthand to convey allegedly meaningful information. If something is meant to be implicitly meaningful, it shouldn’t require a decoder ring. Any more than colorscience requires in the first place, anyway.

By the same token, I couldn’t agree more with @walter.arrighetti – UUIDs are the way forward, in terms of evolving ACESclip / CLF workflows and color pipeline APIs, and communication in general. Perhaps an official schema for UUIDs / associated metadata – in the case of ODTs, signal range, peak white, gamut limiting, etc. – and, indeed, “CTL module” (since CTL does depend on filenames, after all), maybe “short name” if you’re not into the whole brevity thing… enough information to uniquely identify a reference implementation (expressed as CTL module filename on disk, or symbolically with MathML, or a symbol from the SMPTE metadata register…), and enough metadata to provide users and vendors with a way to not only name luts or present transforms as verbosely or succinctly as one’s heart desires, but also imbue a layer of intelligence to the CTL library that can help to reconcile differences between the “model” and the “view”, especially as the two become increasingly abstracted (in terms of ACES relative to other systems, and within ACES itself).

(A part of me does feel that using straight up uuid4 hashes is the way to go, to enforce use of ACESclip / CLF mechanisms, but we’re far from there yet, and that seems a bit draconian and opinionated)

Related… what about the dreaded LMT+RRT+ODT… you know, the ones that concatenate on the front end one of those LMTs that serve to “replace” the RRT with another, most often display-referred rendering. For sake of argument, let’s just say, a given show has decided to work under the ACES RRT, but for each device in the pipeline, there’s a matching LMT that needs to be applied, something like (AP0-to-AP0-limited-to-LogC) --> (K1S1 Tonemap + inv-OETF + LogC-to-deviceRGB + OETF) --> (invRRT+invODT). And this needs to be applied directly before the RRT.

In other words, we live in a world where productions employ show LMT+RRT+ODT concatenated transforms “hijack” RRT rendering (plus or minus gamut compression and desaturated yellows); which, in turn, means standard ACES 1.0 LMTs won’t perform as expected (without doing anything even more contrived); and all “LMTs” created under the LMT+RRT+ODT are, defacto, LMT+RRT+ODT-referred, instead of RRT-referred.

So:

  • Should we have a way to refer to LMTs that override the RRT look, and must be concatenated with a specific RRT+ODT transform? The last thing I want to do is introduce a new acronym, but it is important to differentiate, for lack of a better term, “anti-RRT” LMTs that behave differently from, and have different implications from, regular LMTs?
  • Likewise, how to differentiate between standard LMTs and looks created under “anti-RRT” LMTs?
  • Similarly, should there be a way to refer to LMT+RRT+ODT transforms that’s a little more evocative of what’s taking place? I suppose that’s what the Target Rendering Transforms and Device Encoding Transforms are intended to generically encompass, but those terms really aren’t used anywhere, and they don’t do much to differentiate one type of rendering transform from another in any practical sense.

I don’t have any particularly smart suggestions, I’m more just curious to hear other people’s thinking about this – it’s not a concept that sits comfortably within the ACES paradigm, and it’s conceptually very confusing to just under 100% of the human population… but it does seem to me that we need a naming convention for LMT+RRT+ODTs, as well as for the atypical-LMTs in that are specifically LMT+RRT+ODT-referred or “anti-RRT”-referred, because, even though it’s tempting to think of partially-implemented ACES pipelines as outside the scope of ACES concerns, for ACESclip to be successful, and in order to communicate and automate effectively, it’s something worth brainstorming about.
Damnit, should’ve saved it for another thread.

2 Likes

@zachlewis, thanks for backing both of my petitions:

  • naming-convention templating for Input/Output Transforms (and other color transformations)
  • adding MIC (intergrity-checking) / referencing capabilities on pre-defined color-transforms (e.g. CTLs, LMTs, …).

I think an Academy-supported online registrar service – at least for the original core components and CTLs provided in the official ACES releases, would be beneficial. This may “proxy” the transforms back directly to the .ctl files in the GitHub repositories.

As regards a naming for LMT+RRT+ODT combinations, I still don’t think it’s a good idea.

  • First of all, RRT and ODTs are now “ACES internal” components; they should never be referneced individually in UIs (and UX documents), and be only referenced together by the applications as the Output Transforms. BTW: the same goes for IDTs becoming the Input Transforms.
  • Even if LMTs can be used for “undoing” the effect of the ACES RRT and replace it, overall, with a customized tone-mapping (which is called, in FilmLight’s color-sicence, a “display-rendering transform” ― or DRT), this is not really allowed in ACES 1.0. Not because of creative reasons, but because it breaks output-device interoperability with all those products with limited-to-none capabilities to appply LMT(s) in between.

So I’m in favor of better naming LMTs ―even when used as additional creative tone-mappings like a “show LUT”― but I’d never “pre-bake” combinations of LMTs with Output Transforms and ship them with a default release of ACES ― unless for a very good reason dictated by a “solid” production workflow.

Thank you for the various responses to this topic. You have brought up some really great feedback that I’m logging for the ACESNext effort (and by the way, I love the idea of UUIDs too). It sounds like there is no huge objection to leaving the naming for the ACES 1.1 transforms as proposed by Scott, so we’re going to release these named as is.

We will definitely look at clearer naming for transforms in ACESNext, so we appreciate all of the feedback that you have given. You should see the new transforms which will complete ACES 1.1 later this week. Cheers.