With the recent improvements/bug fixes to transparent tracks the resulting frame quality is inferior to the result achieved with explicit affine transitions when semitransparent text is present. For your convenience please find the a simple example Kdenlive project attached that shows the variance in quality between transparent tracks and using the traditional method of explicit affine transitions. In addition, semitransparent text gets opaque instead of semitransparent with transparent tracks. At the same time, curves and edges of the text get ragged and torn-out. In addition to the example regression project I've added two screenshots taken from the example project: one showing that semi-transparency gets lost, another showing the inferior compositing quality. Reproducible: Always
Created attachment 97564 [details] example Kdenlive project including required clips This example Kdenlive project contains a background picture clip, a Kdenlive title clip, and an Inkscape-made SVG title clip using semitransparent text. In the timeline you'll find a region using transparent tracks, and a second region where explicit affine transitions are used. Please notice the differences in the quality of the resulting frames between the first region and the second one.
Created attachment 97565 [details] Side-by-side comparison of semi-transparent text in frames from first and second region
Created attachment 97566 [details] Side-by-side comparison of text in frames from first and second region
Comment on attachment 97565 [details] Side-by-side comparison of semi-transparent text in frames from first and second region left: transparent track rendering causes opaque, ragged text. right: affine transition results in smooth semi-transparent text.
Comment on attachment 97566 [details] Side-by-side comparison of text in frames from first and second region left: transparent track rendering causes ragged text. right: affine transition results in smooth text.
@wegerf, I just opened your sample project. I can confirm the transparency issue. I think there's a greater issue with alpha channels in general with the compositing in the timeline multitracks. I also noticed that your fonts in both the title clip and the .svg gets a little bit thicker without Affine, and a little thinner (and slightly smoother) with Affine. I've had some transparency issues with the composite feature as well. I'll have to do some more tests and write up a details bug report revolving around all kinds of transprency tests with tracks.
Wegerf, try opening the title clip in your clip monitor. Does it look rough to you? I just created a test title, and opened it up in the clip monitor. I definitely looks rough. However, in the title editor widget, it looks nice and smooth.
Jesse, this is a long-standing, erm, feature. ;) As far as I understand the reason is that the clip monitor shows the clip directly and MLT then ignores transparency in the clip viewed. Only when compositing a frame containing transparency onto another clip, even a black clip, then MLT takes transparency into account. I always wondered if Jean-Baptiste could make the clip monitor use a checkered background and composing the clip onto it. Advantage: correct transprency. Disadvantages: eats CPU and makes clip monitor slower.
I cannot reproduce. For me the result is the same using the automatic composite or the affine transition. wegwerf, in your project, can you try turning off and on again a track's composite transition ? That will switch an old project file to the updated compositing added to fix bug #359160 Maybe that will solve the problem..
Jean-Baptiste, this is a fresh Kdenlive project, created with git master. It isn't a reused project.
JB, here's a video sample I made just now: https://youtu.be/AwG5-95NyVI. This at least exhibts the font roughness in title clips between using just the composite track and the Affine transition. I can confirm that there's something off about just the composite alone. I full-screened the monitor which, even with YouTube's compression, should still give you an idea. I'll test the semi-transparent issue on mine with a .svg and .png as well, and make another video of my findings.
Strange, I cannot reproduce on my side. Please attach the project file you used for the demo video so that I can try it here.
wegerf: like JB, I can't seem to duplicate the transparency issues you're having with .svg or .png images. But with Title clips, the transparency/Alpha channel of the font color does seem to be different. From the looks of it, it doesn't look like the composite tracks are acknowledging the alpha channel values of the title clip's font color. Here's a more detailed experiment video: https://youtu.be/UA42quBDQ1w.
Created attachment 97568 [details] Example project - title clip doesn't show alpha properly w/ composite tracks
@JB, here ya go. It's the Example Project attachment.
@Wegerf, curious, try this: On the title clip with the alpha channel transparency, try adding the Pan and Zoom effect to it to see if the transparency works. I don't know what happens in the program behind the scenes, but maybe that'll help deduce the issue?
Jesse, adding a zoom&pan effect to the SVG title clip with transparency leads to the expected proper semi-transparent rendering.
I suspect the frei0r.cairoblend to cause the issues, maybe due to different versions? How can I find out which version of frei0r.cairoblend including Cairo I'm using?
I'm on Ubuntu 15.10 with frei0r-plugins at 1.4-3build1; libcairo2 at 1.14.2-2ubuntu2.
Please pay attention to the title clip: on my system installation I get proper semi-transparency for the title clip, yet alpha composition is not correct at the outline of the letters. You should notice a slightly lighter letter outline -- which is incorrect. For reference, please see the screenshots I've attached: this clearly show the difference in quality.
MLT is 6.0.0, today's git master.
As mentionned in bug #353019 I think this is also caused by a frei0r.cairoblend bug that was fixed last november. Unfortunately, no frei0r release was made since 2 years, so mosts distros ship an outdated version. I asked if they could make a new frei0r release on the mailing list this morning, waiting for an answer. Frei0r bug was fixed here: https://github.com/ddennedy/frei0r/commit/63808414a36882b8bdd397aa24d5f61450151c4c
Jean-Baptiste, thank you for tracking this down! I suspect that this already affects several Kdenlive users today in different situations, I remember at least one rather recent forum post about borked png alpha composition.
Tried with the qtblend transition from recent MLT git master and Kdenlive also from git master. I had to upgrade the project manually to make the internally added transitions use qtblend instead of frei0r.cairoblend using Kate. Quality now looks fine. So we can finally close this long-standing bug as resolved/fixed. Thank you very much, Jean-Baptiste!