[FFmpeg-devel] [PATCH] swscale alpha channel support

Michael Niedermayer michaelni
Sun Mar 22 23:25:23 CET 2009

On Sun, Mar 22, 2009 at 06:48:16PM +0000, ?yvind Kol?s wrote:
> On Sun, Mar 22, 2009 at 6:01 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Sun, Mar 22, 2009 at 12:51:18PM +0000, ?yvind Kol?s wrote:
> >> On Tue, Mar 17, 2009 at 4:40 PM, C?dric Schieli <cschieli at gmail.com> wrote:
> >> > 2009/3/17 ?yvind Kol?s <islewind at gmail.com>:
> >> > Or are you suggesting that scaling non-premultiplied alpha can't work
> >> > ? What I'm sure is that fully transparent stays fully transparent, and
> >> > fully opaque stays fully opaque.
> >>
> >> Yes the alpha component is treated correctly, the color components are not.
> >
> > what is correct when it comes to resampling is a matter of definition as
> > well as what input one has and what output one expects.
> > And above all "correct" resampling is not seperable or linear nor linear
> > of a scalar non linear transform. Still we use linear & seperable stuff
> > because its good enough and the alternative is non trivial and rather
> > slow
> Correct as in expected result that can be used in compositing without
> surprise is what I aim for. Knowing that ffmpeg doesn't resample
> images correctly I would know to avoid using ffmpeg for frame scaling
> for video compositing needs (if I start using videos with alpha for
> some reason

videos tend not to contain alpha and we just added alpha support,
and while i agree that you did found problems that need fixing i like
to repeat that correct resampling is not trivial and what you
suggest is not even close to it. Correct resampling requires analysis
of things like textures and edge direction and is not linear also not
after gamma correction and premultiplication.

> using ffmpeg and GEGL I would only add the code to get the unscaled
> frame out anyways.)
> Video compositing is normally done using pre-multiplied alpha sine it
> makes the equations and
> computation simpler. What for instance GIMP does for blurs,
> resamplings warps etc is to bake the premultiplication into the
> equations complicating them.

a patch that adds support for premultiplied alpha is welcome, this
should be rather trivial ...

> > Optional because this surely causes a noticeable speed loss ...
> It indeed does, but is video with alpha primarily a real-time deoding
> concern or a feature to be
> used by compositing applications?

faster is better, besides at least subtitles might need alpha scaling

> > i wonder if ignoring gamma correction leads to any artifacts at all
> > it would be interresting to see a example of such artifacts if you
> > have one?
> See http://www.4p8.com/eric.brasseur/gamma.html

good, i see the issue, this too is not hard to fix, its a matter of
doing gamma correction before and after the scaler, the scaler itself
doesnt change. Besides this you of course can only do gamma correction
in rgb space and you need enough bits to represent the colors accurately
now because videos are not in rgb space this means it will have some
speed impact

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090322/6d393cfa/attachment.pgp>

More information about the ffmpeg-devel mailing list