[MPlayer-dev-eng] Documenting and extending the subtitles system

[Uoti Urpala]

On Tue, 2009-02-24 at 09:33 +0100, Reimar Döffinger wrote:
> On Tue, Feb 24, 2009 at 12:36:41AM +0100, Nicolas George wrote:
> > The ass_image_t has only one global field for the color, so apart from
> > splitting the overlay into one object per color, which is an awful waste, I
> > do not see how.
> 
> If it was one object per colour that would not be particularly wasteful
> and IMO not work the effort.
> But with full alpha-blending you would actually need 8 steps, namely
> with the colours
> black, red, green, blue, cyan, magenta, yellow, white

The libass glyph+border case would not require this because all the
occurring colors can be represented as a mix of the two original colors.
However the need to adjust the bitmap applied first based on the alpha
of the second bitmap probably still makes it impractical.

> and the coefficients (those stored in the bitmap, r, g, b, a stand for
> the desired overall blending value and assuming I did not miscalculate):
> a8 = FFMIN3(ar, ag, ab);
> a7 = FFMIN(ar, ag) - a8;
> a6 = FFMIN(ar, ab) - a8;
> a5 = FFMIN(ag, ab) - a8;
> a4 = FFMAX(0, ab - FFMAX(ar, ag));
> a3 = FFMAX(0, ag - FFMAX(ar, ab));
> a2 = FFMAX(0, ar - FFMAX(ag, ab));
> a1 = 1 - (1 - a) / ((1 - a8) * (1 - a7) * (1 - a6) * (1 - a5) * (1 - a4) * (1 - a3) * (1 - a2))

That's missing some scaling factors to account for the order in which
the bitmaps are applied (I think a2-a8 are a correct way to get the
desired target color as an weighted average of those colors, but the
factors need to be corrected for the effect of the alpha in bitmaps
applied later). For example if you have a color that is 1R+0.5G then
that can be expressed as a mix of 50% R+G and 50% R, but if you apply
the R first then you need to have alpha 1 for R and 0.5 for R+G, not 0.5
and 0.5.