"Federated" Output Transforms

Discussions - ACESNext VWG – Output Transforms
1

This is a post (as promised) just simply outlining my thoughts from today’s (27.01.20) VWG meeting more clearly.

Context
There had been a lot of discussion back and forth about the potential futility of creating the one output transform “to rule them all”. In simple terms there are two mutually opposing audiences, the amateurs and the auteurs. On one side we have people that need a mountaineer-guided experience, and on the other we have individuals that already have the compass and route to the image(s) they desire. It had been raised as a question whether to open Pandora’s box and allow anyone to craft an Output Transform (OT) and insert into the ACES system, but this had clearly raised some unease from studios and other content producers in addition to other potential technical concerns. But perhaps there is a middle road, somewhere between one and infinity.

Summary
The high-level concept of “Federated” OTs would be to create a system of adoption and certification of OTs from third parties, and create the appropriate metadata and tracking systems within ACES its self. This adoption system would be in place to validate implementations, ensure core tenants of the ACES philosophy are followed, and ensure that they make a unique and valuable contribution to the community.

Extended Description
In true following of the term “federated” (formed into a single centralized unit, within which each state or organization keeps some internal autonomy), these OTs may be “owned” by an organization/individual which are responsible for crafting and maintaining them to meet new/unknown challenges as the ACES/Imaging community evolves. The responsibility of the ACES Organization its self would be to produce the clear guidelines and requirements that an OT submission must adhere to, and produce an “exemplary” OT which is the pinnacle of all requirements and ideals of the ACES OT Review Procedure which will remain as the “default” and “reference” implementation for all ACES users.

Idealistic Thoughts
The accepted federated Output Transforms should be small in number (2-5), and determined to be orthogonal in the utility they provide. New/altered OTs should be released only with ACES versioned releases and be tracked as a holistic system, as well as having a clear procedure for deprecation.

These Output Transforms should be contributed as CTL and be license compatible with the ACES project. Whether they live directly in the aces-dev Github repo or not is hopefully a trivial implementation detail.

Open Questions to the Group

  • Does this correctly ride the line between the amateur and auteurs needs?
  • What would this list of requirements/ideals for acceptance be?
  • What “orthogonal” OTs can we already think of?
  • How would this be tracked and presented to end-users?

Footnotes

  • Output Transform == OT == RRT + ODT “Family”
  • If this idea is fruitful, this VWG can hopefully be more productive by focusing on the “pinnacle” OT, and a separate group/block of time should be dedicated to the OT system its self
  • I am not presenting this as the correct solution, but rather just giving a less vague explanation of what my intent was
2 Likes
2

Modular and Flexible
I really like the idea put forth in this last meeting of further modularizing the output transform.

  • LMT - Look and creative intent: scene-linear to scene-linear.
  • RT - Render from scene-linear to display-linear, given a viewing condition and type of output (cinema, office, hdr, sdr etc)
  • ODT - Apply the EOTF, given an output display device

If the components of an output transform looked something like the above, the RT and ODT would become almost technical transforms, and the LMT is where variability and creativity would come into play.

  • I could see maybe a default LMT that doesn’t look hugely different from the current rendering. Maybe just incorporating some of the feedback (lower contrast, less saturated, reduced hue skews, etc)
  • Maybe a more neutral LMT as a more fitting working space for cg look development. (Maybe we would get this with a null LMT, with only the RT+ODT)
  • Maybe a more saturated rendering for fully animated features.

The people who need a guided tour are happy because they have off the shelf options that work well and look good. And the mountaineers are happy because they have the flexibility to solve the more complex problems involved with making your own trail.

1 Like
3

Yeah I like it as well.

I think Daniele’s idea will give us flexibility and is a win-win for everybody. This proposition could give us a nice structure/framework for the Output Transform while still working on a great vanilla transform.

That’s the beauty of it : not mutually exclusive. Here is a link to the original post from Daniele if you haven’t read it.

This idea was proposed during meeting#2, discussed a bit during meeting#3 but I think it is a good thing that it was brought back during meeting#5. It’s like the whole conversation was going around this idea without clearly mentioning it…

A good next step would be to see it in a diagram I guess. I have been thinking about which consequences it would have like in an OCIO config :

image

Or in Nuke Viewer (that’s probably more appropriate) :

image
image1280×720 49.9 KB

Anyway, this is just me fiddling around. :wink: Exciting times !

Chris

4

My concern with accepting submissions of 3rd party OTs to be considered as officially certified is that it places an onus on app developers to keep up with new submissions. This approach would certainly need to be limited in the regularity of updates, as it would not work if people could not be sure that a custom OT they used in one app would be available in every other.

I think I tend to err on the side of including custom OTs in the package to make an archive of any ACES project that didn’t use the stock rendering self contained. That would probably mean they would have to be LUTs, but at least they could be optimised CLFs using the built in operators as much as possible.

1 Like
5

Yeah, it looks there are tow ideas here :

  • A modular and flexible approach by Daniele
  • A certification/federation of Output Transforms by Sean

Sorry, I should have probably replied to the original post.

Chris

6

Agreed, it also puts a lot of pressure on the back of the AMPAS in term of maintenance and administration of the system. The question then becomes: Does it have the bandwidth to do so?

Then it leads to an explosion of transforms, imagine the 3 or 4 versions of ACES multiplied by 4 or 5 as being officially blessed. I don’t think it necessarily benefits the system and it also muddies the waters with the role of the LMT.

@ChrisBrejon : Please add 20 more rows to your mockup :wink:

7

I think that ACES does not need to “ship” with many vanilla output transforms. Our goal should still be to come up with a reference implementation which works for many use cases and either emphasis on LMT for look dev.

The custom OT should just make the whole framework adaptable for projects which need special treatment, so that every “proper colour managed” project can be archived as an ACES project.

I also would vote for a CLF package along the archive master for unambiguous archival restoration. (I suggest that even for current projects of all kinds)

Also I think we should consult with other working groups and with the ACES Leadership in the next meetings before we go into details too soon. There might be all sorts of angles we might need to consider (IMF etc…)

I will put some thoughts into written form over the weekend.

8

These are good conversations to have, but I definitely think we are getting more into the ACES architecture realm and dealing with issues that aren’t necessarily meant for this group to tackle (but certainly valid issues to discuss). I’m glad the concept was brought forward, but I’m concerned there could easily be effort diverted away from our central task if we go too far down this road.

Relevant questions in my eyes would be if we open up the Output Transforms (federated or otherwise), does it impose any restrictions or guidelines we need to follow. Even that being said, that is more a question for the implementation group that this group I think.

9

Yes and agreed, we should provide hooks to elegantly empower people to insert their custom rendering transform into the system. It has been acknowledged that studios running an “inverse RRT (+ODT)” LMT to squeeze in their own transforms to comply with delivery requirements is underlining a system design failure.

Those are excellent points to raise!

My take on it is quite opposite though: the Working Groups should not only discuss the architecture and implementation of ACES but also propose architecture and implementation changes if they feel the need for it. Then, the respective TAC can weight in and evaluate it. @Greg_Cotten and a few of us even discussed formalizing the approach with ACES Enhancement Proposals (AEP).

Some members of the Architecture and Implementation TACs are also highly involved in the Working Groups and even wear their TAC hats from time to time, for example:

Cheers,

Thomas

10

Thanks for the continued discussion, I’ll clarify some more points (not to be interpreted as pushing for this to be the final solution) since I don’t think I was fully understood yet.

The idea is that there would be very few variants of OTs, and their adoption and release should be treated just as seriously as an ACES release. I don’t think it adds too much more complexity than developers currently chasing ACES releases… how may apps in the wild still don’t have 1.1? OCIO will still be able to drive instantaneous adoption in a lot of cases.

The actual method of review and whatnot is definitely too far down the Implementation rabbit hole right now, but I don’t see the process/people being any different than us right now. The implied system is really just a procedure, much like these VWGs.

Again the number should be small. I wrote 2-5, but really it should be 1-2 with 3 being near crazy town. There was the specific point that these “internal” OTs (probably better name than federated) would be agreed by us, so they wouldn’t be any more muddied with the LMT than what we allow them to be, we’re still in control. Whereas the case of “let anyone do what they want” releases all control, and any “ACES” project can be anything (per-shot OTs with no LMT), which in my mind doesn’t stay in the spirit of what ACES was/is trying to accomplish.

The core idea or reason for suggesting a small number of OT variants is that there are, I think we all agree, several valid ways to do scene-referred rendering. Here I don’t really mean smaller aesthetic differences, but rather more core/fundamental color management differences.

The idea is very similar to the previously presented idea where we have the OT do the absolute bare minimum, and instead enforce a default LMT. But, in this paradigm, these would be two OT “variants” in the block diagram. Both still utilizing LMTs and the rest of the ACES framework/chain. This “do nothing” variant would only be added if we decided that it was valid/useful/safe to adopt into the system. The third variant could be a CMY Density film emulation based paradigm… or something like that… who knows. I’m just reinforcing that the variants should be as wildly different from each other as possible, so they have a “real” reason for existing, not just two subtly different tone-scales. This is what I tried to express by saying they were “orthogonal”.

This is definitely the core question. What I was presenting here was an attempt at a smaller step in that direction. It is largely driven by the fact that we cannot ensure that only the “proper colour managed” projects use ACES and archive as ACES, there is no quality gate in that paradigm.

The procedures and technical details are just there to help people visualize the possible future, I definitely don’t suggest we take that as the core topic of conversation, but it was required to be mentioned in order understand how this idea works.

The hope was exactly the opposite. If we moved towards a stance that “someday” there would be adopted variants of OTs, we could laser-focus on what the default/core OT should do. What makes it “exemplary”? Meanwhile, other ideas could be shelved and reorganized for the orthogonal variants that could come at a later date. Its a potential “pressure release” for two equally valid but opposing ideas for OTs.

Just as a last couple words. I’m not arguing this is the correct way to proceed, but just trying to weave a logical thread between what I see as two valid ideas (1) keep ACES as it is and fix the obvious stuff (2) acknowledge that one solution will never be one-size-fits-all until the end of time. Allowing for variants could still provide reassurance to all users that an ACES workflow is guaranteed to be “proper colour managed”, and would continue in the Open Source spirit of community/discussion/validation/adoption and provide openly visible implementations.

1 Like
11

Small addendum.

I’m most certainly not against creating a system which allows for externally defined OTs either :slight_smile:

Just trying to presenting a bridge/stepping stone to that land here.