There is a subpixel gap between the main glyph and the border

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Render some text with a border onto an RGB video.

What is the expected output? What do you see instead?
I see a transparent gap between the main glyph and the border. It is thinner 
than a pixel, but it's visible if the background (video) colour is different 
from the glyph and border colours.

What version of the product are you using? On what operating system?
Latest CCCP on Windows 7.

Please provide related subtitle script (if any). And the less characters
the script is, the less effort I have to make to fix the issue, so if you
could make the script as simple as possible, that would be appreciated.
{\fs60\bord5\c&H000000&\3c&H000000&}test

Original issue reported on code.google.com by chortos@inbox.lv on 26 Apr 2013 at 11:01

[GoogleCodeExporter]

Here's a screenshot: http://i.minus.com/iEpK4ARNTkG6p.png

Original comment by chortos@inbox.lv on 26 Apr 2013 at 11:09

[GoogleCodeExporter]

I am unable to reproduce this in Aegisub (CSRI), Avisynth (TextSub), or 
DirectShow using your script, a white RGB video, and Arial.ttf (v5.15) from a 
fully patched and up-to-date Windows 7 SP1 installation.

Please provide a complete MKV sample (video + script + font) with detailed 
steps to reproduces the problem.

Original comment by cyber.sp...@gmail.com on 27 Apr 2013 at 1:36

[GoogleCodeExporter]

Theoretically a problem like you describe could occur with VSFilter 
implementations, it only seems exceedingly unlikely
with black body + black border + white background at 100% opacity.

VSFilter implementations perform alpha blending in layers:
1) Border is alpha blended on top of Video Background with 8x8 subpixel 
positioning
2) Body is alpha blended on top of Border + Background with 8x8 subpixel 
positioning

If you make your text semi-transparent or fade in/out, an anomaly like your 
screenshot is expected behavior for VSFilter.
Libass has the opposite problem and instead of a white subpixel threshold, they 
have a dark black subpixel threshold. 
The same anomaly in VSFilter will also occur with clip masks. There should not 
be a gap, only a slightly dirty subpixel edge.

Last year I asked YuZhuoHuang about something similar to this. The below 
response may interest you as a developer:

> That is NOT a bug that sometimes they're not perfect outline color or body 
color,
> because that 1px may be composited by a fraction of outline and a fraction of 
body 
> (as a result of subpixel rendering), and combining the 2 fractions into one 
pixel produces
> a semi-transparent effect. Assuming body takes w1 out of 1 of that pixel, and 
border takes
> the fractions left, the result should be w1*body+(1-w1)border, a weighted sum 
of body and border.
>
> However I am convinced that the actual value of that pixel VSFilter produces 
is not
> w1*body+(1-w1)border, but w1*body+ (1-w1)* ((1-w1)*border + w*background). 
VSFilter
> takes border and body as different layer, it alphablend border onto 
background first,
> and then body. When either border or body is ascend, the result, w1*body + 
(1-w1)*background (if no border)
> or (1-w1)*border + w*background (if no body), is right. But when both body 
and border exist,
> the final result becomes w1*body+ (1-w1)* ((1-w1)*border + w*background) . 
The body gets its w1 share
> but the border doesn't get its 1-w1 share. Part of the border's share is 
given to the background.
>
> But again, that is the theory. When I try to construct an visual example, 
> I find it much harder than I've imagined. So maybe the artifact is not very 
serious. 
>
> On the other hand, even if the artifact can be noticed easily, there are no 
easy solutions for this. 

"No easy solutions for this"

Patches welcome if you have an idea to fix or at least improve the appearance 
of VSFilter's subpixel alphablending thresholds.

I'm also still interested in a sample which reproduces this with the script 
snippet in your first comment.

Original comment by cyber.sp...@gmail.com on 27 Apr 2013 at 3:24

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

> I am unable to reproduce this in Aegisub (CSRI), Avisynth (TextSub), or 
DirectShow using your script, a white RGB video, and Arial.ttf (v5.15) from a 
fully patched and up-to-date Windows 7 SP1 installation.

> Please provide a complete MKV sample (video + script + font) with detailed 
steps to reproduces the problem.

Interesting. Some more testing shows that this only happens when either the 
primary alpha or the secondary/karaoke alpha (or both) are non-zero (not fully 
opaque). Particularly interesting is the fact that the secondary alpha is 
relevant even when karaoke effects are not used.

I can now reproduce it with this line in a clean ASS script on a white RGB 
background, using DirectShow on Windows 7 SP1:
{\fs60\bord5\c&H000000&\2a&H01&\3c&H000000&}test

Sorry about this.

Now, I didn't realize this initially, but it very much sounds like this is the 
exact same problem which the following patch I wrote for libass aims to resolve:
    http://code.google.com/r/astiob-libass/source/detail?r=6ce7e74b7a9da84ff95ecb8e770e071e1cfee479&name=alpha
This is good: the patch is mathematically proven and definitely works for 
libass, so a similar patch should be applicable to VSFilter. I could look into 
it, but I'm afraid I'm not going to get much spare time until June...

There's a detailed derivation of the final formula in the commit message. The 
patch hasn't been merged into libass yet because it doesn't take into account 
karaoke; more significant changes are needed to fix that, as detailed in 
http://code.google.com/p/libass/issues/detail?id=78#c22 (and the 
libass-specific c16). I will most likely implement it in June. Meanwhile, my 
personal copy of libass is compiled with the patch in its current state, and 
the "good" screenshot in issue #144 was rendered with it. As you can see, it 
does not have any cyan between white glyphs and black borders whereas the 
xy-VSFilter screenshot does.

Original comment by chortos@inbox.lv on 27 Apr 2013 at 4:33

[GoogleCodeExporter]

And just in case, here's a small MKV.

Original comment by chortos@inbox.lv on 27 Apr 2013 at 5:00

Attachments:

• gap.mkv

[GoogleCodeExporter]

>> 
http://code.google.com/r/astiob-libass/source/detail?r=6ce7e74b7a9da84ff95ecb8e7
70e071e1cfee479&name=alpha

Good job.

Original comment by YuZhuoHu...@gmail.com on 27 Apr 2013 at 7:01

[GoogleCodeExporter]

YuZhuoHuang was able to understand the concept described in your formula, and 
believes it should be compatible with VSFilter's existing code scheme. Thanks 
again for the heads-up about your work in this area.

Original comment by cyber.sp...@gmail.com on 27 Apr 2013 at 8:22

• Changed state: Accepted
• Added labels: Priority-Medium, Type-Enhancement
• Removed labels: Priority-Low, Type-Defect

[GoogleCodeExporter]

Work on this has started.

The wip code by chortos is not being used. It was determined to be too much of 
a brute-force solution to the problem, and we were concerned about efficiency. 
Our current line of thought is to use addition instead of alpha-blending for 
mixing border+body.

Original comment by cyber.sp...@gmail.com on 26 Jul 2013 at 6:38

• Changed state: Started

[GoogleCodeExporter]

In the process of implementing our addition draw method, our developer 
discovered that VSFilter actually already contained compensation code which 
achieved the same end result as the method which chrotos previously described. 
The problem was this code was only doing its job when when both Primary and 
Secondary colors were opaque, and no fade effect was active. This explains the 
observations made in Comment #5.

So this is good is a couple ways. It reduces the scope which our new addition 
draw method needs to be used, and it also leaves the potential for expanding 
the functionality of VSFilter's existing subpixel gap compensation method in 
the future.

Original comment by cyber.sp...@gmail.com on 28 Jul 2013 at 8:53