Logik Live follow-up multi-colorspace timeline export

[allklier]

Following up from the Logik Live with the specific question regarding the challenge of exporting/rendering mixed color space timelines. (@fredwarren The devs asked to post the example here.)

The test case is a short-film timeline colored in Flame. Color space rules setup with the ACES 1.1 preset. Most clips on timeline are Arri LogC and tagged as such, but there are a few select graphics that are in Rec709.

Viewing rules are setup by the preset, and everything looks good on the reference display and in the viewer. But exporting this timeline yields unexpected results.

Based on this old forum post Solved: ACES Export Nightmares! - Autodesk Community I’ve got it to work by adding a gap effect with color space transform, and then adding some gfx below and some gfx above that gap effect (as Grant suggested).

Without the gap effect, when starting the export by dragging timeline in media hub, warning appears stating that color space management will be based on first frame of timeline. With the gap effect that warning is not present.

3 different variations:

Expected look (as seen on reference monitor):

All default settings: image exports low-contrast (LogC non-transformed)

No gap effect, but enabled advanced settings / with LUT + view transform (looks correct):

But if a Rec709 graphic is stacked (footage is good, graphic is wrong:

Adding gap effect with color transform to view (looks as expected)

But if a Rec709 graphic id stacked (graphic right, footage reverts to LogC during stack and snaps back to correct where stack ends):

In summary - two separate problems:

1. Without gap effect there is hard to decipher warning message. It can be resolved by adding the gap effect - which has the same result as setting the advanced LUT option with rules. It might be helpful to clarify this workflow.

2. Regardless of gap effect / advanced settings, if two clips of different color spaces are stacked, they don’t render correctly. You have to transform one with a gap effect to the color space of the other, and then use the viewing transform during render. A similar problem exists in dissolves, if the one side of the dissolve is in a different color space, there is a visible transform step between the last frame of the dissolve and the next frame.

Expected behavior (as seen in other color space aware apps like Resolve for example):

1. There should be a clearly defined output transform for the export (not buried in advanced options). Could possibly be integrated into all the rules of the color space dialog as well.

2. During the render each clip on the timeline should be transformed to the working color space to be in a normalized state, blending operations should happen in the working color space, and then transform to output color space avoiding any conflicts of stacked color space differences.

The end goal should be that I can take any timeline that is color space managed with ACES, and where each clip is tagged correctly, and render it to a defined output color space without having to add any operations to the timeline. Then this process could be repeated for different outputs, if the timeline has to be exported for different deliverables.

The primary goal of ACES is allow for mixed color space application through workflow rules and eliminate all explicit color space transforms in timelines or nodegraphs. And should not require transcodes of the footage, but be purely metadata driven.

Maybe I’m overlooking something as I’m still relatively new to Flame…

[randy]

Yo! I’m around today if ya wanna hop into Discord, share your screen?

just @randy me in the Discord

[allklier]

@randy and I had a great Discord chat/screen share on the topic.

To clarify purpose of the question/post: I did get it to work and delivered the project. So this was more a philosophical question on how color management in Flame works, rather than ‘how the f*’ do I wrangle these color spaces to get it to render.

My instinct was that I shouldn’t have to put the gap effect on there to make it work. But @randy provided useful reference in how Flame drivers think of color management and also the ‘don’t you dare touch my pixels unless I give you permission and tell you to’ mindset, which is not a bad one.

[jamesw]

@allklier

No gap effect, but enabled advanced settings / with LUT + view transform (looks correct):

Hi

Reading this post with interest and would love to understand a little bit about what you and @randy discussed on Discord.

Is your preferred method now to use the gap effect? Or to use no gap effect, but enable advanced settings / with LUT + view transform.

James

[allklier]

My preference would be to use the advanced settings.

Having the gap in the timeline takes me back to old workflows of display referred grading, whereas settings for export is more in line of scene referred work that is inline with contemporary workflows. (That distinction was part of the discussion).

Unfortunately at present you may have to use the gap effect to render mixed stacks.

One interesting follow-up clarification will be if the definition of a working colorspace (ACEScg in this case) actually defines automatic transforms and how the math and blending works, or if it’s more of a default setting for various processes? It may be the latter, which creates a bigger gap.

That was the second part of the discussion, and Flames history in this regard.

[johnag]

@randy was it a text or audio discussion and is there a copy somewhere?

[imag4media]

Instead of transforming each individual segment w a gap effect for making rec709, maybe it’s easier to make one gap segment for entire layer that goes From Source to rec709? Anything format below should transfer, and if it was already rec709, shouldn’t change anything.

Hope it helps.
Andy D.

[allklier]

Hi Andy,

Absolutely. That was in fact the case already. Here’s a screenshot of the timeline.

15min short film. Individual clips and detail color on track 1, overall look on track 2, grain & halation bfx on track 3, a few gfx on track 4 (should have been moved up), track 5 is the color space trasnform, and then track 6 gfx that have to survive a stack with non-Rec709.

[imag4media]

Hi-

Sorry if I misunderstood.
Generally, I try to avoid BFX, tho I lean heavily on TL FX.
BFX is a bloated pig for me and only use rarely.
It also could conceivably throw off the color tag, but not sure.

So you have a deliverable w the GFX needing to be done before the rec709 convert? and others that need to be done only in rec709?
Overall the Timeline looks relatively tight, so no suggests aside from BFX avoidance.

When I get a chance, I’ll go back thru the thread to see what I missed.

Cheers-
Andy D

[allklier]

Definitely. The colorspace transforms is a TL FX. The only thing that was BFX is the halation effect and cinegrain comp on track 3.

Regarding the GFX and Rec709, this timeline grew organically as I was solving this problem. If I did the project again, all of the GFX would be above the color transform. They worked in the front where I started, because they’re on black, so the color space conflict when stacking Rec709 GFX on top of LogC footage didn’t come into play. As I placed the later GFX, that became and issue, and I moved them above the transform. Just didn’t go back to fix the other ones.

I’m still pretty new to the Flame family (coming from Nuke and other apps), so I’m sure there are better ways to do this, and really appreciate the suggestions.

[randy]

As @allklier and I were chatting and joking on our call together and spiritually I can definitely see why someone new to Flame would have a few WTF moments in there.

Flame is at heart a managed framestore, meaning, it wants to own and manage all the media so it can keep its promise to you that it can play it back in real time. This has been the heart of its identity for 30 years now. These days sure other apps may be close, but, Flame was always the king of playback and interactivity.

Another theme in Flame’s umm…themes… is trust. It desperately wants you to trust it. There are no complex paths to remember. Just clips. And it tries to present those to you in a memorable layout that represents how the user visualizes digital files I mean video files I mean film frames. Working in Flame feels like what you are working on lives on the tip of your pen. And that’s a good thing. The muscle memory it creates is world class.

So, ya put all these things together and Flame wants you to explicitly make something. If you are holding the timeline then likely you’ll have clients around and probably some monitors so you need to explicitly own the relationships between your source media, its science requirements, your monitor, your monitors science requirements, your client’s monitor, your clients monitor science requirements, blah blah.

Under the hood it really doesn’t do anything other than manage the framestore. It wants you to tag clips in import, but gives you options to manually tag them on the Desktop, in the timeline, in Batch, or in a Gap Effect above a timeline. It also gives you another option to change them on Export.

Relying on exporting settings to mess with your media is a bit risky. In multi artist environments there is no savable system of export behaviors. Of course there are export presets, but no way to remind someone “hey bozo, don’t forget to turn on the export on LUT thingamajig.”

Also, wiring. Moving media between Flames and Artists you kinda sorta want all this stuff baked in to a timeline. Sure, you can have projects setup differently, but Flame decouples project configuration with clips and timelines. And for me, that’s a good thing.

Its also a reminder that Flame’s Color Management settings in Batch Preferences don’t actually convert any pixels under the hood. All they are simply Default settings.

[imag4media]

Few suggests:

• name tracks (you can drag the bar out to see them in timeline). Just helps w clarity.
• If deliverable is only rec709, keep all the GFX above the transform to rec709. Also makes easy to turn off for Generic. Exception to this would be if you had to deliver GFX in log/linear format. Titles on a feature, as an example. then you’d obviously want that below the change to rec709. Then you could hide the rec709 layer to export your logC (as one example) deliverable and then turn back on to export your rec709 QT to go with it.
• I usually have a layer called BURN containing a burn_metadata gap fx. This can show all the info of shots below it: TC, colorspace, shot name, version, filename, etc. This is for internal ref, not for client.
• Also I add a COMMIT layer above all so I can just make sure there is no weirdness on export. If you name the track COMMIT, then name the gap segment: clipName_trackName_YYYY_MMDD and you’ll get each day’s COMMIT named automatically. I then add another Video Layer, not track to keep the last few of these in my WIP to compare. Keeping in another Layer allows you to collapse them, keeping your timeline more manageable.

Timelines have diff uses in my workflow:

• WIPs and deliverables. Similar to what you doing now.
  You are exporting a single stringout of the sequence.
  Includes colorTransforms, LUTs, repos, etc baked into the result.
  When you get errors like “multiple colorspaces” etc, here this is bad.

• Conform and shot publish, including to Shotgun.
  Generally you want to export the original plates at source rez.
  No repo’s or luts, just the raw plates and elements, along w reference, etc.
  These are options in Sequence Publish like Use Original Media, etc.

You’ll want to use both Shot Name and Segment Name.
I also use track name to specify asset type: plate, ref, gfx etc.
Then once Shot Name is set, all segments are basically: ShotName_TrackName. You can add variants for L1, L2 or FG, BG, etc. But I suggest doing that on the Segment Name not the track name.

When you get an error of “multiple colorspaces” here, it’s of no concern because you are indeed exporting logC and rec709 etc, but it’s not just one clip for all, but one for each segment.

When you play w it for awhile it becomes apparent pretty quickly.

Hope that helps a bit.

Andy D.