Hi,

With my latest project I just wanted to throw a quick white title screen over black colour clip - thought it would be no sweat.  But unfortunately both preview and render show horrible aliasing/blockiness of the text. 

So I tried to import some pngs, including my business logo and it suffered the same problem - this happens to pngs that were made the same size and aspect ratio.

 

So as a workaround I have done the following:

Use inkscape and create the title/logo etc etc - export to png with transparent background.

Import the png into Synfig 2D animator using the same canvas size as your kdenlive video project.

Set synfig settings to however long you want the clip to be and export as yuv420p (ffmpeg doesn't seem to work on my version of synfig)

Now after about 2 minutes there will be a massive file (like 300 MB for 10 seconds) but that can easily be transcoded with this command:

 

# ffmpeg -i synfigexport.yuv -sameq mytitle.avi

 

This will transcode it in about 2 seconds to a very managable 1 or 2 MB avi file.

Import it as a clip into kdenlive and enjoy antialised titles and pictures/logos etc etc

NOTE: transitions between the clips still create a visible 'movement' of the words and a slight aliasing....so cutting directly instead of fading will avoid that problem

 

Now if someone has a quicker and simpler method - please do share.  I hope soon kdenlive will have the issue sorted out =)

 

Cheers,

Solv

Hi,

look's like I'm not the first one who's annoyed by poor anti-aliasing for title clips.
For 0.76 or pretty recent SVN snapshots available on Debian unstable, smooth, anti-aliased
text is given just "sometimes" (preview or rendered output).
I haven't figured out what's causing the difference. May some issues with alpha channel during compositing are generating blockiness ? I don't know yet ...

Is anybody else faced with similar issues for title text ?

Toby

Now, after playing around compositing a bunch of title clips, I have to correct myself:
Anti-Aliasing is not an issue, poor text qualitiy I'm observing in some of my rendered output
is caused by the rescale function of the render stage (kdenlive or mlt ?).
Maybe it's a fast algorithm (linear?), but it's performance on text is not acceptable.

Here's a comparison with mplayers bilinear resize (avidemux filter):
http://www.streumix.com/tmp/scaled_comparison.png
Just compare the work "clip".

IMHO, the rescale operation needs to be adjusted to a more accurate, higher-order
interpolation scheme. Could any of the developer tell where to file a bug report ?
kdenlive or mlt ?

Toby

If you do not composite it using the Composite transition, then it will not apply the alpha channel. That is the typical cause of aliasing.

The preview monitor uses a cheap, fast scaler, but on render it uses blinear scaling. There is an even higher quality scaler setting you can put on your render profile if you want to experiment: add "rescale=hyper" to the render profile.

When you are using a project profile with non-square pixels, and then still images and graphics in general including kdenlivetitle are assumed to be square pixels, so MLT must normalize this difference and scale the graphic and its alpha channel. Sometimes, this can lead to some undesirable artifacts due to imperfect alignment of the alpha channel to its image data. This is what appears to be happening in your sample although I am having trouble to reproduce it at the moment. What project profile are you using?

Hey, if rendered output is based on bilinear scaling, something unknown, undesirable
seems to happening.

My project setting is 16:9 DVD PAL (widescreen), the resolution of my source footage.

In addition to unscaled output for DVD , I'm typically rendering slightly rescaled
versions with square pixels for online sharing/preview. In the provided comparison,
output was scaled down to 640x360 (1:1 pixel -> 16:9 aspect). A lossless storage
format has been choosen (FFV1).

One time the kdenlive internal scaling was applied, the other time rescaling was performed
afterwards with the help of avidemux (resize filter (mplayer) set to bilinear mode, target codec FFV1, too)

Toby

hmm, today I am using a different system and with your info I am seeing some problems. The kdenlivetitle producer, with which I am not that familiar, is doing some things differently than I expect. As such, it is suppressing the general MLT scaler in the DVD PAL Wide -> DVD PAL Wide case. It will take more time to look into this further - right now I am feeling rather confused :-(. Feel free to open a bug for tracking.

When you are doing 640x360, am I correct to assume that you are using the DVD PAL Wide project profile and overriding the resolution in the render dialog?

Yes, when doing 640x360, I am using the DVD PAL Wide project profile and override the resolution in the render dialog.

By the way, I've figured out the root cause of missing anti-aliasing for title clips I' have been faced with for a while.First of all, it only appears for title clips with transparent background, where anti-aliasing "info" is stored in the alpha channel. Is it correct that final stacking of individual clips on the time line does not pay respect to the alpha channel ? It seems to be that case. Because once you place a transparent title clip without a composite transition, anti-aliasing is gone.

The bad thing about it: IMHO it's common practice to have transparent title clips, where you fade the
background clip to black and keep the title on black background for some time. At the moment, you have to split the title clip and add a composite transition to the later part compositing it onto black. Or you have to generate a second version of the title clip with solid back background. Or ... any other, cumbersome work-around.

Would it be a big deal to add alpha compositing in case of transparent timeline clips being put onto the global, black background ? Maybe just a hack for internal title clips to maintain anti-aliasing ? I'm not talking about a full alpha compositing of all stacked clips on timeline. (as cinelerra does, which is way more intuitive and easier to control for multiple clip compositing than stacks of composite transitions in kdenlive ... but that's a different story with a lot of implications, right ?)

Regards,
Toby

This all falls under the issue that Kdenlive requires explicit Composite. I am mainly focused on MLT, where there is no obvious place for automagically blending an image with its alpha channel over black. There is another case for auto-compositing as well that someone raised: Blue Screen effect. I would not be surprised if effects system in Kdenlive gets some redesign because besides this issue, there are other things MLT is capable of that is difficult to do in Kdenlive today (e.g. masking).

If you are still following, upon debugging this, I discovered that the yuv-scaler introduces some bad artifacts, and these are especially exaggerated when you alter the output resolution from the project setting. Of course, one resolution is to force usage of the RGB scaler, which I can confirm resolves it for me. However, I have not decided that is the best approach even as an interim resolution.

I am testing a change you can try yourself. Edit $prefix/share/mlt/core/loader.ini so that the rescaler line reads:
rescaler=swscale,gtkrescale,rescale

libswscale has traditionally been limited at compile-time to a resolution of 2048 wide, but in May 2009, it was raised to 5120 for non-PPC systems. The nice thing about libswcale is that it is flexible (YUV and RGB, various routines) and well-maintained (part of FFmpeg). You might still run into a limitation if you are playing around with very high res digital photos - panorama photos being a good test case. I can add a guard to prevent usage of this scaler when the source resolution is too large, but the destination resolution is limited as well, and some effect conditions can request a large destination resolution. I think I can come up with a test case and simply limit the scaling and therefore practical range of the effect.

These changes were made in MLT Git. Please test. The plan is to include them in the 0.5.2 release within a week or so.

Thanks Dan !
I'll give it a try.

Greez,
Toby