BLG in Flame

Hi folks,

does anyone else use the Filmlight BLG plugin? If so, can you tell me what kind of speed you see when rendering? I know its a vague question and depends upon a number of factors so here’s our setup.

Flame 2021.1 on HP Z8 G4 with Mellanox 40gb connection and p6000 quadro card (single). Project set to ACES at 3840x2160. 1750 frames of internally cached EXR 16bit ACEScg at 3840x2160.

Baselight grade is mostly primaries, no keys or blurs. 2 shots have tracked masks and 1 shot has keyframed grade changes to check frame accuracy.

The render takes over 20mins. By comparison, a timeline grade on each shot with keys and blurs renders in around 2mins.

So I suppose the most sensible answer I can ask for is a comparison of how a BLG render differs from an internally generated grade render. I see a difference factor of 10 to 1. This seems excessive to me but perhaps I am misunderstanding how the BLG plugin operates and what it should be used for.

Autodesk are looking into this for us but some real world insight would be invaluable.


When I last used it I was very happy with performance, but I don’t think I ever did a direct comparison unfortunately.
Our workflow was to avoid having to download a ton of graded footage from the UK to the LA office and compared to that it was very quick!

1 Like

sorry for the late reply @rorcharch. We use BLGs a lot. They are not fast. I couldn’t begin to benchmark renders speeds against your setup but what you describe on a 4K clip doesn’t sound much different from my experience.

1 Like

My experience is similar to @TimC. It’s fine for a quick glance but the idea of depending on it for anything longer than a 30 is daunting.

1 Like

Hey experts! My first job using BLG. Works great in Nuke, but Flame is saying “can’t find BLGs” - even though I have sent the metadata from the clip to the Pybox, and pointed it at the same folder the Nuke guys are using. Any ideas?

1 Like

Did you T-Click on that source media with blg selected? Metadata are not automatically transmitted by connection only.

Yes, I meant to say that I did that. Figured it out. I had not tagged the source color space yet. All good now!!


its always good to have your colorist render out a reference for you. i ALWAYS compare my BLG flame plugin renders to what color made in case something is amiss. BLG plugin for flame is a fickle beast. Make sure you have the “blg files” option selected as opposed to “one blg” We have found that sometimes animated windows / masks don’t work if not set to “blg files” again, a ref clip from color and the difference node are your best friend here.

1 Like

interesting - thanks for that tip. This has been a mostly positive experience. I published out Flat plates and color house gave us BLGs for use in Nuke compositing, but I also had graded renders to check them against. Most of the time it worked great - when it didn’t, it was always a color space issue form the Nuker. Now I finally got the BLG on Flame, and it works, but damn, the renders are slow.

Regarding render times - we opened a case with Autodesk support. I would love BLG to work efficiently as it would steamline our long-form drama pipeline for Netflix deliveries. Unfortunately, at the end of Autodesk Support’s tests we were referred back to Filmlight. I’ve copied the relevant bit of Autodesk Support’s conclusion below -

FilmLight owns and distributes the BLG Pybox, and they have access to Flame licenses for development and benchmarking.

If FilmLight come to the conclusion that the poor performances are related to a lack of optimization in Flame they should raise the situation to the Flame Product Manager and the Flame development team.

Perhaps if you find the render times to be an ongoing issue, you could raise the issue too.


When have we ever not needed a faster render?

Would love blg for Flame on Mac support.


They had it for Mac at IBC for presentation.
I’ve asked them, but they said, there wouldn’t be much Mac User for Flame :face_with_monocle:

Also: BLG for Nuke does render A LOT faster on Mac/Linux than on Windows.

1 Like

I’ve also found it to be moody. You can easily get it into this error loop that’s hard to escape. What I find most frustrating is it holding onto the settings/BLG of the last time you opened it (when you add a new one) as opposed to a blank slate so it starts erroring out and then you get that framebuffer not supported warning.

Overall the UX just seems sticky somehow and doesn’t seem to update properly nor smoothly.

anyone done benchmark testing - Nuke v Flame on the same Linux box? My Nuke team seems to be rendered out flats and BLG grades without complaining about render times.

1 Like

do they have a render farm?

Yeah, I got caught in that loop once already using BLG in Batch, gives you an Error, only option is to confirm, but it doesn’t give you anytime to break the pipeline or select new BLG, so keeps getting the same error over and over. Had to hard crash out to reset it.

just confirmed- yes, it is slow in Nuke as well - they are rendering on a farm, but with the BLG plugin, the farm can only use one thread/node, so it is pretty slow. Would still love to see a head to head benchmark.

I found if you hit ESC after confirming that error you can often get out of it but sometimes it takes a few tries.

Just learned something new - BLG workflow cannot utilize external mattes. We spent a bunch of time prepping mattes for our CG, and they won’t follow through the BLGs. Apparently it is one of their hottest feature requests, so maybe someday…

Yeah bitten me on the ass that one. External Mattes work in the Nuke version :frowning: Hopefully one day the plugin will be the same across all platforms. The work around I’ve done before is to get a BLG for fill and a BLG for the bg and use the matte I supplied. Not ideal.

1 Like