BLG in Flame

External sources (mattes, grain, etc) currently only work when you link to the Baselight scene which, of course, only works if the machine is in the same office. It works really great actually but it takes a bit to kick it into gear to switch to that mode, etc.

1 Like

There are two types of BLG and plugins.

Single-input-BLG:
The only source used in baselight is the source plate. No external mattes, no external grain plates, flare plates, comps with the same source and so on. At least they need to be disabled when generating the blg files.

Multi-input-BLG:
The exact opposite of above.

Nuke’s BLG Plugin:

  • can use both types of blgs.
  • is free of charge.
  • all platforms: Mac, windows, Linux
  • for a small fee you can open the baselight interface, check or change the BLG and save it. You can even grade from scratch inside Nuke. And that by using the same install (so no extra plugin needed)

Flame’s BLG:

  • only single-inputs are supported
  • no free version
  • costs way more.
  • no baselight interface
  • only for Linux

We asked the colorist to exclude all extra inputs media if possible.
Also all transforms like scale or such need to be disabled, since we render on same as source and rebuilt that in flame during conform.
That’s not only just for being prepared to use flame plug-in anytime but more to erase complications in the Nuke team. Because when you receive multi input blgs, you’ll get more inputs on the node itself. But no way of differentiate which source you need to put in. So you need a detailed briefing from the colorist or need to spend the extra bucks for the baselight interface and knowledge how to use that.

Another tip:

  • the blg file itself is a one-frame-multichannel-exr embedded with the ungraded source reference in original imported color space as well as a graded version in the destination color space. Those can be shuffled out for checking purposes. But you’ll need to color manage them to be viewed correctly.

Edit: that are some of the results of long term testing the blg workflow three years ago before implementing it.

3 Likes

Can i add to this thread?
I pushed for a workflow where i use BLGS’s to help with the schedule of a job im currently on. But having issues with the BLGS we received from a big house are not tracking with the shot. The windows are not tracking i mean. They are different than the DPX grades they rendered. I noticed if i bring in the BLGs as EXRs into batch they are all at 1920x1080 and the source res is 6048x4032. totally diff and diffd aspect. Is that why they are not lining up perhaps? We are trying to fix their BLG output as i dont have many options on my flame to really do much to help. Anyone out there have similar experiences? Ive only had great things to say about BLG until now so wouyld love to find the solution!

hey theo

did you try running through the exact same source you sent to color as you are trying to run through the BLG file? it has to be the same size, rez, duration and Timecode, so make sure to T-tap / copy the timecode from the source clip to the BLG node. Also make sure you have set it set to “blg files” not “one blg” for some reason that breaks any tracking power windows or masks. unfortunately in my experience BLG in flame is not 100% reliable. If the problem persists you can try to run the BLG plugin in nuke which is more stable in my experience. HTH!

We’ve just recently ran into the same issue where windows appeared static. The solution, weirdly, was to change the option from a single BLG to scanning a directory for a match (sorry, I forget the exact wording). Strangely that fixed it.

That said, if your aspect ratio is different then that will mess things up. Finally, if they have any transforms active when they exported the BLGs those will also come through so they’ll have to turn those off as well.

1 Like

yeah i have it mostly on BLG files in the timeline, when im in batch and grading under a comp then i use BLG one file. Still all that i do theres a discrepancy in where the power window is and doesnt track.

you can’t use “blg one” - things like tracking masks, film grain, etc won’t animate. you have to stay on the “blg files” mode

in your experience do the BLG actual files (EXRs) are the same resoluton as the source material? this could be an indication that our BLGS are saved in the wrong aspect and res. ours are HD and should be 1.5 aspect.
most of my BLGS are looking a folder of BLGS so this is not the thing thats breaking our workflow

Why am I under the perhaps wrong impression that BLGs in Flame only support HD? As in you have to do the resize to HD first and then do the BLG on top of that.

I only have experience with BLGs that are setup in a HD project (i.e. the target resolution) so thus far the BLG files are HD. Unsure if the target resolution has any effect on the blg itself.

Is it possible to ask whomever is doing the color to give you an ungraded frame of a given shot at the source resolution to make sure you guys have the same starting point?

Definitely not the case. The source should be the same resolution as what Baselight has but in reality it’s really the aspect ratio that needs to match, at least in my experience. It’s the same thing if you supply BL a comp at a different resolution than the source (i.e. 1/2 res). Everything lines up so long as the aspect ratio is the same.

1 Like

This makes sense with what I found out with more testing. Using the blgs in an HD timeline does not work due to the aspect ratio difference. My source has a 1.5 aspect. There is also a bug where even if the source shot is brought into batch the blg files option doesn’t read the time code properly. As if there was no tc on the clip. I turned it to blg one file and it read it but then the issue of it not tracking. So my workaround was on the desktop in the right aspect either full res or half I could attach the blg and color management and hard commit the clip. Then bring that into timeline or batch to do a comp. Takes way longer but works. I assume if my timeline was the same aspect as the footage it would have worked too. I’m afraid this is too annoying and unpredictable so I won’t be singing it’s praises anymore. What a pity

BLG files. Simultaneously a godsend and the bane of my existence. I try to steer away from them because they are slow and unreliable at times but due to colorist avails & short project schedule its the only way to do the job sometimes. If i’m going out of house for color i absolutely do a workflow test before hand. sometimes colorists like to trick out their setups with all manner of stuff which doesn’t play nice later on so a test is essential. We also prep and publish the timeline for color in flame so we know exactly the source res; aspect ratio, etc and ask to get it back the same way, no transforms, repos or resizes. Also as @kyleobley noted BLGs are not locked to an HD size. we mostly work at 2-4k resolutions. Be warned that once you get into 4K and above BLG render time is slow AF. I also don’t add the BLG in the timeline, too many other variables seem to confuse the plugin with TC offset, resize in TL, etc. It’s more work but i make a separate batch setup for all the BLGs or stick it at the end of the ungraded comp in batch as a trim pass. We’ve also heard from baselight that ADSK surfaces very little clip info for the plugin to use, that is why Nuke version has more features and better reliability. Maybe that will change with the upgrade to Rocky linux?

smart, before this project I had such a smooth experience, but we usually did create all the shots and export them to color instead of them getting the media from editorial. The aspect ratio difference must have never been a problem before, i never ran into that. BUt now i know its ficklness its usefulness is limited. Bottom line its buggy and doesnt work the way they advertise. could be ADSK, or could be filmlights fault, no matter its not really dependable without lots of testing. thank you everyone! I found a workaround so thats good!

2 Likes

Did you have the PyBox node selected and then T-click the source media? You need to do that to send the TC and tape name to the node so it knows what’s what.