Slate breaks Multichannel EXR when reading in Flame

Flame isn’t reading the matte channels in exr renders that I’ve received form another vendor because the slate frame does not have the channels. The colorist is reading the matte channels in baselight.

I see there is an older post where someone posed this question but i haven’t found a solution better than doing manipulation to the image sequence outside of the application in order to just not read the slate frame as a part of the comp.

maybe is there a way to have flame read the file header from a frame which is not the first frame of the stack to in order to derive the clip properties, while still keeping the full image sequence intact as a part of the clip?

I’m on Flame 2025.1.1, and I’ve tried pulling the comps in through media hub as well as directly into batch.

2 Likes

Heya @ryan_m - I had some time and was curious about this and I reproduced your issue here on 2025.2.2. I too can’t figure out how to get Flame to recognize the matte for the clip as a whole. If I switch from File Sequence to Frames, I can clearly see that Flame sees the first frame doesn’t have a matte and the rest of the frames do have a matte, but it seems clear that Flame uses that first frame to “understand” the matte for the clip as a whole.

I know there was a relatively recent improvement (I think it was introduced in 2024?) to the Clip Options for EXRs to compensate for another similar circumstance regarding a “Part Name”. Not the same issue as this, but probably in the same world.

If you and I are both not missing anything, then we’re probably in feature request territory whereby for now you’ll have to settle for a manual intervention like what you’re describing.

Let’s see if anyone else chimes in with a solve though.

Thanks so much for checking! At least I know I’m not totally crazy if you are able to replicate the issue

1 Like

We wrote a python script that when we encouter that, we select the image sequence in MediaBrowser, right click run script, and it will rename the slate so it doesn’t get considered as part of the image sequence, but can still be brought in on its own.

4 Likes

That’s a pretty slick workaround. In my case, we need to maintain the integrity of the image seq as delivered to us because flame and baselight are potentially accessing the comps independently of each other, and sometimes it’s the baselight accessing first. Someone further up the chain from me put in the request to the vfx vendor to render the slate frames with the matte channels in them moving forward, and they’ve agreed. So, it’s no longer an issue for me on this particular project, but it is a bummer that flame has this issue which baselight does not have.

2 Likes

Had the exact same thing happen recently, same cause.

Perhaps they should use tail slates.

1 Like

Why stop at slates, why not add bars and tone and a clock?
Sigh…
21st century what?

Unfortunately been dealing with this as well. Massive pain in the ass. A quick fix is remove the first frame.

Slates are so dumb. I just finished work with a major film vendor who couldn’t provide time code and tape name in their renders but of course they had slates. Like, who meeds fucking slates when you have tape name and time code?

2 Likes

I am anti slates too.

However, on a lot of films they have the info on what has been done to a shot in terms of revisions so they occasionally ask for it. In VFX reviews I have seen this happen maybe once or twice so the benefit isn’t worth the pain. It is generally editorial who use the slates most but really, they should already know where it goes. I think in the end it is bureaucratic blunders where people keep doing the same thing as they did last time.

That’s an understandable scenario and exists in other context to… I get the same thing with cryptomattes, when the objects they describe don’t exist for the entire duration of the shot. So if the object doesn’t exist on the first frame, you can’t select it in the cryptomatte.

The core issue is that the software opens the first frame to determine channel layout and then expect that exist for the duration of the sequence. Certainly would be true for everything else.

The proper solution would be to modify Alan’s script, which would make a copy of frame 2, rename it as frame 1, and only replace the RGB channels with the slate information from the original frame 1. Then you are guaranteed to have channel continuity.

That’s really on the slate generator, not on Flame to be honest.

A few years ago we had an issue like this with audio on a film. The location sound mixer decided to turn off channels of actors that weren’t in the scene. Sometimes he forgot and would then do it in the middle of the take. Instead of just muting them. Because that does change the channel layout, the Sound Devices recorder would then split the file, and start a new file with the new layout. We had some takes where the audio was split 3-4 times as he turned off channels here and there. Was maddening to repair so we could actually edit.

Short answer - don’t do this to files. It will always break something.

This also occurs with say, a 1920x1080 slate, and the rest of the shot is 3840x2160, no matte or other channels. How do Baselight and other software ignore the slate and read the rest of the file? I would hope Autodesk could fix this. We currently run a script that puts the slate in a folder and the rest of the shot in another. Seems silly to have to do this.

1 Like

I would assume that they know that sometimes the first frame can be something else, and so they have a feature to skip the first frame and base it on the second frame instead. But if you had a 2 frame slate it probably would break too.

The easy fix would be if the ‘Import’ function had checkbox/button to ‘skip first frame’. I checked, doesn’t exist right now. Of course that would drop the slate from what you work with inside Flame, and then when you write it back out you would have to re-add it.

The proper way would be if an image sequence (or for that matter any clip) could have a dedicated slate frame, similar to a ‘thumbnail’. So if present (possibly indicated by button/checkbox or auto-detected), it would load it, but store it separately. And then when you export, and such a frame was stored as part of the clip, it gets re-exported. And then all you need is a way of being able to copy something in this buffer from within the app, and you could skip all the slate generating trickery.

Is there already a feature request for something like that? Otherwise we can write one up.

1 Like

… or they should add same channels to the slate frame. First time I hear that exr renders need a slate :hushed: Sometimes things get unnecessarily overcomplicated.

1 Like

I mean, we used to do tail slates all the time for certain camera rolls and stuff that came off an oxberry.

2 Likes

I worked on a project recently where not only did they need to know what had changed from the previous version, but also 1st, last and a mid frame from the shot.
Total PITA!

I dont suppose you could share the script by any chance? Coming up against this problem all the time

Doubtful… It’s part of a larger package of tools. I’ll see though. If you are coming to the LA User Group, I’ll be demonstrating it though.

Sadly im in London. What are the other tools?