It is inside Flame as OFX.
As an extra cost.
But itâs not just the matte, but also despill, lightwrap, etc. At that point Iâll just do it in Nuke. Keeps it seamless.
But Iâd like keyers in Flame to be better either way for all the other cases where you need to isolate something quick.
That said, Flame has several great keyers. And some cool features others donât have, like the patches.
But then some that are just aggravating. For example the HSV keyer is very useful and intuitive as a tool, but the UI is unnecessarily cumbersome and frustrating compared to how easy the Resolve HSV key is.
The diamond keyer is another one where I spend more time fighting the UI than keying because itâs lacking in UI usability.
2 Likes
Diamond keyer would be great to bring out of the grade/colour nodes. Wasnât it a stand alone in combustion?
Thereâs a simple cheat to use DiamondKeyer (actually all the keying you know from the Image Node, including semantic keyers for human face, etc.) in batch.
- Add an action node
- In action drag out the background media
- Right click on surface, âAdd Selectiveâ
- From the popup of SelectiveFX select âSelectiveMatteExtractionâ
- Double click on the resulting Selective which is the same as the selective you know from Image, you have access to the diamond keyer and all the other selection features
- The main output of the Action node will be the matte created by the selective, which is your key, etc.
In fact you can take a step further and add gMask and other manipulations to your key result inside the actionâŚ
PS: The image node is nothing but a pre-assembled action, which is why this works. You can turn it around and just add an image node, and then in the first selective it auto-creates, just add a âSelective Matte Extractionâ via the + sign and the whole image node will output the matte from selective 1.
Here I just added an Image node to batch, and added the Selective Matte Extraction. Thatâs a lot fewer clicks. Same result.
1 Like
I usually use the colour warper. Your method sounds interesting. Both have a really small ui though. It would helpful if the UIs were bigger.
1 Like
Yes, my single biggest complaint about the diamond keyer. You spend forever scaling and moving the diamond around to get to the control points of the tolerance and softness. It would also be fantastic to have an actual cross hair at the center point of the diamond, so you know where zero saturation is, in case you need to come off just a tad from it to focus on saturated colors, not neutral tones.
2 Likes
I have an idea.
Yes it was, just shows how old the code is.
What does âMulti-Channel Everythingâ means? Workflow? Maps? Other?
I just wanted to say amen to this.
It was bait. The goal was to put a giant all-encompassing option when the rest were more granular. I was curious if there was any single feature that could get an overwhelming share of the votes. I know a lot of us who are active on here feel strongly about multi channel stuff so I wrote that as broadly as I could and got 24%. 
THAT SAID, it may be worth everyone answering what they feel it means, so hereâs my take:
My wish is to handle large multi channel files in a more elegant way. Nuke does this by having everything pass through nodes and having you isolate (shuffle out) the desired channels from the main stream. In Flame we have to draw node paths from each channel all the way down to where they are used in the comp.
What I want is a system that allows multiple channels to be combined, carried, and extracted throughout a node tree, with the option to apply the node effects either to the whole, or to the exposed RGB(A). Happy to make illustrations. 
6 Likes
There is merit to both systems (Nuke & Flame). Nukeâs system keeps the tree more tidy, but you have to read the fine print if you need to see what flows where. And you need extra nodes to access specific channels. Flame is very transparent and flexible but makes for extra labor and clutters busy batches.
I could see a middle ground. If we had a âsuper elbowâ in lack of better terms, which is a variation of the Nuke shuffle node. A âsuper elbowâ would be the beginning/end of a multi-channel pipe, allowing you to flow multiple channels as a single connection in portions of your node-tree where it creates efficiencies without upending Flameâs node tree in total. In addition, certain nodes could recognize that theyâre being connected to a âsuper elbowâ and then flow all their outputs as a single connection to the super elbow, same with inputs on select nodes, recognizing that theyâre connected to a âsuper elbowâ and accepting a multi-channel connection (condition being that the super elbow connected to an input match channel count - which could be setup in the node settings - similar to Nuke shuffle UI).
If I find time this weekend, I might mockup a node graph to illustrate (taking Alanâs advice that a video or picture is better than a long description).
But imagine loading a mutli-channel EXR, connected to super elbow that takes all outputs of the clip, then throughout your node graph you have super elbow endpoints that can shuffle out individual channels to other nodes where needed, and might terminate in a render node that takes all those channels plus some that got changed.
Same thing with an action that has 6 outputs, connects to a super elbow as a single connection, and then you can tap into it in various places, or pipe it into another Matchbox nodes that expects several of those connections.
This would only require the need for one new node and selectively updating a few high value nodes, not making broad changes. Yet, achieve pretty high impact.
2 Likes
You can do the same with a Selective inside the Colour Warper and set the View to Matte.
I am not sure what you are refering to when you mention the HSV Keyer.
Heck yeah!
A âmulti channel freeway systemâ would be wonderful.
1 Like
Iâm a little surprised multichannel everything is top⌠Is that really going to speed up things and enable more creative/ better work? Batches will look cleaner for sure⌠but Iâm not delivering batch setups to my clients⌠and⌠also whereâs the machine learning stuff?
Iâll be honest with you @Ton
I switched my vote so many times that I ended up just jumping on the biggest band wagon believing it all to be somewhat inconsequential.
I comp a lot of CG and I am often connecting heaps of passes up. A change to our RGB-A methodology would be good but I donât want it at the expense of speed. After I voted for the last time I was tormented by the fact that this request would mean our streams would get bogged down with excessive 32-bit z-depth passes.
A tidy batch is also for creativity and speed. Finding the stuff you need quickly and applying it efficiently is part of the aim especially once the last minute client comments come flying.
I would love a Checkpoints node. Iâm using warp Fusion all the time. Currently using if for a shampoo spot, using the orig shot of the model swishing her hair, but recreating it more perfectly in AI, then painting/masking in the better AI hair for touchup. Iâll do a vid about it when finished. but yeh Stable Diffusion Checkpoint files would be amazing as a filter in Flame now, theyâre gonna be used so much.
Also I think we should be allowed more than one vote, I think we would get a better idea if we were allowed maybe 5 votes each.
2 Likes
What I would suggest is that an inconsequential poll with only 72 voters doesnât actually say or prove much. Nothing against the poll whatsoever or where it was coming from.
I also wonder how insightful Flame Family Feedback polls are to the greater Flame User community when if you see double digit numbers of people voting for something is a rarity.
Please donât read anything into this being a suggestion about the number of people using Flame. I think it is more having some faith in the Product Management team that they are directly in contact with a large enough subsection to make decisions on the best interest of Flame. From my own perspective, I would have given a very different answer a couple of years ago than I have answered now. I would have suggested proper IMF & Dolby Atmos support plus an updated text module was of paramount importance. That ship has sailed though, both my current and previous facility I have worked for are now Resolve based. Now I would like better multichannel handling and several VFX features that are currently lacking. However, what I want may not reflect what the majority of Flame users would like implemented. I think it is disingenuous to suggest that because you cannot see the point of why text should not be updated means that nobody else would see a point. The move to Vulkan & Metal was HUGE and vitally important to do but I doubt that anyone would have voted for that in a poll.
One of Flameâs major advantages as a product, that it works for several different use cases in several different markets, is certainly a disadvantage when steering limited dev resources as to what the priorities should be. Sure, polls and Flame Family Feedback must certainly aid in the direction of Flame development (and makes it easy to point to data that suggests they are implementing what the majority want) but Iâm sure Stephane, Fred and the rest of the Flame team have their own roadmap that you have to have faith is shaped by the extensive conversations they undertake with the user base. As much as I would have liked to see properly integrated IMF, DCP authoring with Atmos support, I donât begrudge that never materialising. What I have faith in is that the Flame team know what is best for their product in the long term with them also understanding that certain parts of the user base have either moved to other software already or will do in future, but that a strong user base, which I believe is growing, will continue to use Flame because they are seeing development that suits their needs the best.
You can please some people sometimes but you canât please all the people all of the time.
5 Likes
I have loudly complained about the lack of persistent multi channel in Batch before but I donât think the devs should devote the time to implementing that. At the end of the day, it wouldnât add any new functionality. It would just make for cleaner Batches. And a lot of what you would use those channels for would be in Action, so you would still need to have separate media inputs for each of those channels or some sort of complicated channel selector in Action. It just doesnât strike me as a pressing issue.
What I do think is a pressing issue, something that has basically made me comp CG in Nuke - but this is not just a CG issue - is the lack of a high quality Z Blur tool. When you compare Bokeh in Nuke with the various blur tools in Batch, itâs no contest in terms of quality and speed. Bokeh on my Mac Studio in Nuke 15 is surprisingly fast. Physical Defocus, a Matchbox that presumably is computed by the GPU is slow and does not look nearly as good.
4 Likes