okamibl / xy-vsfilter

Automatically exported from code.google.com/p/xy-vsfilter
0 stars 0 forks source link

8x8 Bilinear Scaling Bug with /N broken lines when PlayResX & PlayResY are set lower than video resolution #114

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Set scaling to 8x8 bilinear.
2. Play any subtitled file with a /N two-line split.

What is the expected output? What do you see instead?

Generally I would expect the new scaling algorithm to make the subs look 
significantly better across the board. Instead, the only time a subtitle looks 
'natural' is the bottom line of a /N two-line phrase. Any single-line phrase as 
well as the top line of a /N phrase look exactly the same as 8x8 VSFilter 
Default, which is to say, jagged edges. The bottom line of a /N split line 
looks perfectly smooth. I've attached a screenshot to illustrate the problem.

The screenshot is of a 1280x720 file being played in full-screen on a 1920x1200 
monitor.

What version of the product are you using? On what operating system?

Was noticed using xy-VSFilter 3.0.0.41, is still happening with 3.0.0.63. Am on 
Windows 7 Ultimate x64, using a 1920x1200 monitor. Am using madVR to render in 
MPC-HC.

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.

Trimmed script is attached.

Original issue reported on code.google.com by shirocla...@gmail.com on 11 Aug 2012 at 11:32

Attachments:

GoogleCodeExporter commented 8 years ago
By the looks of it, this has been an issue ever since we introduced the feature 
back in October 2011. Some sort of weird interaction between PlayResX & 
PlayResY set below the video resolution, use of \N, and the 8x8 Bilinear 
sub-pixel positioning option. We'll look into it, since there shouldn't be such 
a large difference on lines broken with \N.

Workaround: Author scripts with PlayResX & PlayResY matching to the video 
resolution

Just keep in mind that the reason we introduced the 8x8 Bilinear setting was 
not to blur subtitles or make them look better. The original hope was that it 
would be faster than rasterization, but it turned out to be slightly slower... 
We left it in only in hopes of future performance improvements, still haven't 
occurred yet. Most users should stick to using the 8x8 VSFilter Default.

Original comment by cyber.sp...@gmail.com on 12 Aug 2012 at 1:30

GoogleCodeExporter commented 8 years ago
Thank you for the response! Of course changing the resolution in the scripts 
causes the subtitles to appear at the wrong size (not xy-VSFilter's fault but 
the script author's lazy work), but that's okay. For now I've switched back to 
default instead of bilinear.

However, since doing a test fix (setting PlayResX and Y to 1280 and 720) caused 
all the subtitles to be uniformly jaggy... is there any way to get an option 
that would make all subtitles appear nicely like the bottom one in my example 
image? It looks a lot less jarring that way, like the subtitle is actually part 
of the rendered image. Of course I can't be sure if such a look is the 
intention of the script author. You guys who know the VobSub engine inside and 
out would probably know better than I would how it's intended to interpret a 
script.

Original comment by shirocla...@gmail.com on 12 Aug 2012 at 3:08

GoogleCodeExporter commented 8 years ago
> Of course I can't be sure if such a look is the intention of the script 
author.

The \be and \blur tags are available if the person authoring a script wants a 
softer look like your screenshot. It's not something we intend to allow the 
end-user to override within xy-VSFilter. The side-effect of a softer look from 
using the 8x8 Bilinear sub-pixel positioning option, is about as far as we'll 
go in that regard.

The underlying issue is VSFilter's GDI-based rasterizer has always had a bit of 
a problem with aliasing (jagged edges) on TrueType outlines. On some lower 
quality font outlines, the problem can be quite horrible. As a long term goal, 
we tentatively plan to do a rewrite of the rasterizer to enable higher quality 
anti-aliased font rendering similar to FreeType which Libass uses. No ETA, but 
that would be the proper solution to the issue of aliased font rendering.

Workaround: Use fonts with Postscript outlines instead of TrueType outlines, 
and rendering quality will be much nicer with VSFilter and GDI alike.

Original comment by cyber.sp...@gmail.com on 12 Aug 2012 at 7:03

GoogleCodeExporter commented 8 years ago
> Workaround: Use fonts with Postscript outlines instead of TrueType outlines,
> and rendering quality will be much nicer with VSFilter and GDI alike.

I should probably say 'Partial Workaround', since it looks like that release 
does use a font with PostScript outline. Half of the aliasing in your image is 
likely caused by the resize algorithm used by your video renderer. Bottom line 
is VSFilter's rasterizer needs an overhaul, which may occur eventually.

Original comment by cyber.sp...@gmail.com on 12 Aug 2012 at 7:24

GoogleCodeExporter commented 8 years ago
Issue 192 has been merged into this issue.

Original comment by cyber.sp...@gmail.com on 28 Dec 2014 at 10:36