I got all excited about the Subtitles track and used a load of supplied SRTs to subtitle about a dozen spots (some long form, too). All looks great in Flame, but when you export (either render in foreground or not) they all look terrible. Doesn’t make any difference what format I export, mp4 or ProRes, they all look the same. Really jaggy edges and probably worse than normal flame text. There doesn’t seem to be any anti-alias settings for burning in the subs, or am I missing something somewhere?
What makes it more annoying is that on one subtitle for about 10 frames it look perfect. So there’s something odd going on somewhere.
I was excited too. In Flame it’s using active filtering and looks great, but on export it’s basically the old Text module with zero anti-aliasing.
Might this help?
-Ted
No, unfortunately not. I gave that a go earlier but it came out the same.
That’s weird, I did some recently and they were okay, probably not amazing but not jagged at least. I’m on Linux and was using Flame 2024.2.
I did some with “Include Subtitles” selected and “Burn in Image”
Also did some with “export as files” and the srt’s worked as well.
I just did a quick test on Mac 2024.2.1 and they were okay as well.
One thing that might throw you off is that the subtitles on the timeline are rendered on-the-fly overlayed on the viewer; for instance if you zoom the viewer in, they look razor sharp as they’re rasterized at whatever scaling factor over the viewer, as opposed to the text being rasterized at the sequence resolution and then the result scaled up like usual…
So it will always look a little different in the UI. But if you do the afore-mentioned ‘Copy subtitles to track’ to create “real” clips, they should get rasterized basically the same as how they’d export from the native subtitle track.
And with that said, they seem to look OK to me, they are definitely anti-aliased here; Perhaps not the most perfectly – at small sizes and/or with very thin delicate fonts it’s not oversampled enough, but for typical open captions scenarios they seem fine. I know someone was wanting/hoping to use it for disclaimers, and it’s definitely too chunky for that typical size.
In any case I’m not excusing that we should probably have options for antialiasing level like in the Text module (!!) or have it use the default as set in the prefs.
Hi Andy,
Did you get this working in the end?
And out of interest are you seeing this result on Mac or Linux?
I’ve just moved my subtitling project from Linux onto my Intel Imac for portability and I am noticing some crunchy aliasing which wasn’t there before.
It appears to me as though there is a difference between Mac and Linux when it comes to rendering out the subtitles.
Working on Mac, so that could be the issue. In the end I decided I was being too picky, sent off to client for approval and they were happy. Would be interested to compare linux with mac, so will try that out this week and report back.
We have a job coming up where we would need this feature pretty extensively however the text looks not-so-amazing. I’m really surprised there’s no way to control the amount of aliasing.
That said, having all the attributes link up is pretty slick. Now make those curves just as slick and we can call it a day!
I used this function once. I bailed after that and went back to the old way. I felt like I “got away with it” on the one job and didn’t want to have the future experience of converting an entire set of spots at the last minute because some art directed got a bug up his ass about the jaggies on the letter O. I did like the fact that I could turn it on and off at the export level, and some of the other features, but if it looks like crap, those features are worthless. I can’t speak for AD, but I’m guessing this is an “in-the-mean-time” feature that will become superseded by a new character generator feature. Gaffer tape and bubble gum, so to speak.
It does seem to be graphic hardware dependent.
I have just output many masters from my linux box with rtx3090 and it looked good, but when I tried outputting from my Intel Imac it looked really bad and jaggy.
When it works it’s good and useful, I like being able to render out burnt in, then do some versions with srt only. It could do with a few more options to please art directors, the last one wanted to do rounded background rectangles which is not possible. Unfortunately I’ve found burnt in subtitles sometimes get treated as graphics in their own right so that needs to be accounted for when committing to your approach.
Also I was just working on a Mac Studio M2 and legals starting looking really weird in the text module with Auto Softness. Some letters were half missing, but once I set it to 16 samples it looked okay again (but thinner because of the difference between auto softness and samples). So Mac users might want to keep an eye on that as well.
All the small type I do on the timeline I do in a BFX. I keep a prebuilt set-up in my user nodes. I set my text node at twice the project size and once I have set the type I put it through an action and reduce it 50% with EWA filtering. I then comp on the timeline, either with an action or the comp node. If i need to move it I will do it on the timeline action in integers. If I need to resize it, I go back into the bfx. 3D text in action can be a bit better using HWAA, but until we get a better character generator, everything is a bit of a kluge. 16 samples in the text node is a bit harsh. I think it looks soft, and it thins the type out too much.
Interesting thanks, I will try that next time.
Finally got around to doing test between Mac and Linux. Can confirm that when making Subtitles using the same font between Mac and Linux, the Linux version is superior in terms of aliasing.
Imported an srt file in Linux as a subtitles track, chose Helvetica Neue Light Condensed as the font, exported as a ProRes422HQ, choosing to burn in the subs.
Archived this master, then imported the archive into a Mac and then exported from that machine as ProRes422HQ, choosing to burn in subs.
Linux version is smoother. Mac version looks like it has little chunks missing from the letters here and there, rather than being just worse aliasing.
When I used the same font on the Mac and used regular timeline text, it seemed much better.
Linux Version Subtitles Screengrab
Mac Version Subtitles Screengrab
Mac Version Timeline Text Screengrab
Edited as one image was incorrect
3 Likes
Great research Andy. Thanks for sharing. And I think if anyone else can confirm this on their end it’s definitely worth escalating to see if we can get support to acknowledge it and work on a fix!
@Jeff
Hi Jeff, looks the same here, output with burnt in subtitles as prores 422hq then screen grabbed.
Linux burnt in subtitle screengrab
Intel Imac burnt in subtitle screengrab
Hey all. After talking with Fred Warren during today’s Logik Live Patron’s Q&A, we concluded that this should be a feature request, even though it blurs the lines between a defect and a feature request. Take a peek here and upvote if you would like it to get some love, and add a reply if you think it needs some additional clarity.
1 Like
I see what you did there.
-Ted