Plugins / Tools missing from FLAME

Hey All, this is Eric from VFX Tools. I was just talking with Jeff on Logik Live about my software Headcase & Wrap It, and he suggested we could talk here about other plugins/tools that you’d like to see in Flame.

The reason I made my first AE plugin (Extendo!) was because I couldn’t accept that there was no edge extension (aka pixel spread) in AE. I’m driven by solving these products. Same with Wrap It. Nuke has Project3D, and we need it in AE & Flame too!

So: What’s missing from Flame that’s available in other DCCs? What are problems in your day-to-day workflow that drive you nuts that could be solved with an OFX plugin? Are there integrations with ML tools that you’d like to see in Flame? Or does the inference node pretty much cover it?

4 Likes

match grade node like Nuke. feed in a graded version and the ungraded plate and then export a LUT you can then use in a timeline, on a different take of the same shot, etc.

7 Likes

I use a DCTL in Resolve that has a great ‘density’ tool. I bet it’s possible to do the same thing with a matchbox/ofx node and I would pay money for it:

““Density” reduces luminance, while saturation is subtractively increased to avoid greyish colors. This results in “film style colors” where colors appear deep and saturated.”

1 Like

That seems doable. Are you on Mac or Linux?

I’ve converted DCTLs to Mistika in the past. It’s just another iteration of GLSL, just have to fix up syntax and swap out API calls, but turning them into a matchbox should a straight forward task.

One caveat is that Mono Nodes is a commercial DCTL, so it wouldn’t be appropriate for us to do it.

And a lot of people take inspiration from Baselight.

1 Like

Yes Jan - I wouldn’t say copy/paste the MonoNode DCTL. I just figured the math behind ‘density’ is common knowledge… just not to me :slight_smile:

OK, following now. Density is not a singular math - well, I think it was precise in the film days with stock, but in digital color applications it has different interpretations. Usually affecting gamma or exposure in combination with a log curve. The exposure wheel in Master grade, when control is set to ‘Log’ might behave similar.

Since the Mono Nodes take inspiration from Baselight’s operators, we could easily do a contrast compare of the Baselight operator and find Flame operations that are similar in response. Happy to chat further about that. And if there are no good matches, maybe write a Matchbox for it.

The problem with developing specifically for Flame is that I need an expensive Flame license. $650/mo for a software I don’t use. Does Autodesk have a developers program or something?

No, there is no developer program. You can run it with flex tokens on an as-need basis. 18 tokens per 24hr period ($54/day). So you want to be judicious, but cheaper than a long-term license.

On occasion you can maybe borrow someone’s license for a day via remote access (i.e. remoting into someone’s system).

This seems pretty powerful.

They have great marketing, folks that have tried it have been mixed about it, in color circles. There have been numerous discussions in our color Discord about it.

Hi, please try this Linux build of an OFX plugin MatchGrade node. It works in Resolve, but… we’ll see about Flame. Right now I’ve only tried 2 sRGB inputs.

Let’s see if we have proof of life.

There are signs of life…

I can’t seem to export the .cube LUT though. I tried a few different ways to set the path, but it doesn’t seem to write a file.

Could you add a debug message with the result of the write() function and the path it was written to, so we know where to look?

Try putting an actual path in there, like: path/test.cube.

That indeed fixed the file writing problem.

In this relatively simple test case it does seem to work as desired.

Wipe - left is the LUT applied to the original, right is the color grade that was the test case.

Applying the same LUT takes this other image to a similar treatment:

I haven experimented with the other settings.
I think the output name / path handling could be cleaned up.

More complex test case, doesn’t quite work yet.

In the previous example it was simply an offset shift between the channels, a global color adjustment, which could have been a CDL.

In this second test, a number of more complex color elements - a FEL, a H-S curve on the lips, a H-H curve on the shirt strap, and an overall S-S curve adjustment to remove most saturated.

Not all of these changes were captured by the matched LUT. And there’s a difference between the output of the OFX, which captures 80% of the change, and the LUT which captured less:

Output of the OFX (left) / color change (right)

Generated LUT applied (left) / color change (right)

I’ll need to A/B all of this against Nuke at some point. Not sure how accurate or good that node is. The only way to figure this out is with a baseline.

Completely understood. Inferring LUTs from two images is not easy and may not always resolve accurately. Which is why I added corrections to the second case that would be borderline.

You can also just use match grade in Nuke, then export a .cube to use in Flame. Works pretty well.

1 Like

I only have Nuke non-commercial, and that node is all greyed out for me. Nils (or someone with Nuke,) you think you could run a couple image pairs through and send the results + the cube files?

@allklier, do these nodes really pick up that level of detail? I thought it was a little more general than that. I should get the lips, the shirt, etc?