search

kenygia / xy-vsfilter

Automatically exported from code.google.com/p/xy-vsfilter fork:xy-vsfilter-2015-05-04-rc
GNU General Public License v2.0
0 stars 0 forks source link

Use of arbitrary PlayRes with multiple adjacent \clip may cause visual anomalies in VSFilter & Libass #118

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Create an ASS script with vector clips of 1 pixel in height (I didn't check, 
but the effect is probably there for 1 pixel width as well)
2. Render said script into a video with a resolution that differs from either 
script resolution or multiples of powers of two thereof

What is the expected output? What do you see instead?
Expected is a clean output (for example, a gradient), whereas only a grey-ish 
corruption is rendered.

What version of the product are you using? On what operating system?
xy-VSFilter 3.0.0.53 in Aegisub 3.0.0 RC 0
xy-VSFilter 3.0.0.65
both on Windows 7 Ultimate SP1 (64 bit)

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.
Please have a look at the attachment.

Please provide any additional information below.
Creating lines of 1 pixel in height causes some sort of corruption when drawing 
them onto a video with resolution that differs from the ASS script resolution. 
The same does not happen with rectangular clipping, even if the exact same 
portions of the text are clipped.
The corrupton apparently does not appear when vector clipping lines of a height 
greater than 1 pixel, as the sample shows (top and bottom part of the right 
"TEST" - the left one is just rectangular clipping to show that it's specific 
to vector shapes).
Neither does the corruption appear on videos that are of twice/4 times/8 
times/... the script resolution (although it is still present on videos that 
are e.g. half the script resolution).

The issue probably results from the fact that, as explained in 
http://docs.aegisub.org/manual/ASS_Tags the rectangular clip always has 
fullpixel boundaries, regardless of script/video resolution, whereas the vector 
clip even has a strength parameter that allows for subpixel accuracy (similar 
to \p) and therefore probably does not only have fullpixel borders but subpixel 
borders instead. My guess is that something goes wrong when calculating the 
fullpixel value in regards to the several subpixel clips on the same pixel, 
which leads to this corruption.
The sample file also clearly shows that the corruption is there (but not as 
visible) on resolutions greater than script resolution (e.g. 720p script 
resolution on 1080p video), but it's more visible on e.g. 720p script 
resolution on 480p video.

I thought that, even though it happens with regular VSFilter as well, I should 
report it here because the clipping code has been changed to work faster in 
response to Issue #94. Furthermore, I believe it is relevant to Issue #91 and 
may  also be relevant to Issue #97.

P.S.  This disregards the fact that twice the horizontal resolution and twice 
the vertical resolution is actually 4 times the original resolution. That case 
is treated as doubled resolution, and all other resolutions are treated 
accordingly.

Original issue reported on code.google.com by TheDarkS...@googlemail.com on 18 Sep 2012 at 10:00

Attachments:

GoogleCodeExporter commented 9 years ago 
This is an unpreventable anomaly which occurs in both VSFilter & Libass when 
alpha-blending adjacent sub-pixel /clip boundaries. The issue has already been 
'fixed' via rounding when using the scale function from 
xy-VSFilter_Scale_Test_Build_1 which is linked from Issue #97. 

Typesetting should always be done using a PlayRes which matches he Video 
Resolution, so it's probably for the best it remains broken to not encourage 
this behavior. Lazy half-corrected typesetting from a lower resolution video 
used with a high-resolution video needs to stop.

We've been considering allowing the user to manually tag the correct layout 
resolution (original authored video resolution) to the script, which would 
automatically configure and enable the scale function. Going forward for things 
like 720p/1080p dual releases, 720p scripts with typesetting could be left 
untouched, with xy-VSFilter scale function used so everything will look 
identical independent of final output resolution. Though if a typesetter 
desires good compatibility with subtitle renderers other than xy-VSFilter w/ 
scale function, they'll need to change the PlayRes from 1280x720 to 1920x1080 
and go to the effort of fixing all their typesetting effects.

For the time being, I'm going to mark this as WontFix. If anybody feels there 
is a good reason why this should be fixed outside of the xy-VSFilter scale 
function, feel free to continue discussion here in Issue #118. Discussion 
relating to use of \clip with the xy-VSFilter's scale function should be 
restricted to Issue #97.

Original comment by cyber.sp...@gmail.com on 19 Sep 2012 at 3:23

GoogleCodeExporter commented 9 years ago 
In that case, thank you for telling me. Actually, though, I noticed because I 
tried typesetting for a 480p DVD video in 720p script resolution, so it's not 
really the "lazy half-corrected typesetting from a lower resolution video used 
with a high-resolution video", but the opposite case.
The reason was that this would make any manual PAR compensation in the script 
unnecessary by defining the scale as 100/100 for 1:1 PAR, while also increasing 
rendering precision. I only noticed that corruption when defining the blur 
values on the original resolution, so I thought I should mention it here... 
anyway, it works fine with the testing build for both 480p and 720p (script 
res) set to 480p, so I think the problem is not so important any more.
Thank you for your elaborate answer!

Original comment by TheDarkS...@googlemail.com on 19 Sep 2012 at 10:14

GoogleCodeExporter commented 9 years ago 
correction: it still doesn't display correctly on the 720x480 video.

Original comment by TheDarkS...@googlemail.com on 19 Sep 2012 at 10:21

GoogleCodeExporter commented 9 years ago 
> but the opposite case
Yes, it can go both ways. Pretty much whenever there is a mismatch of PlayRes 
and video resolution, this is likely to happen.

> 480p DVD video in 720p script
> while also increasing rendering precision

There shouldn't be any real increase in precession, since sub-pixel positioning 
is always only accurate to 1/8 of a pixel at the output resolution.

> 1:1 PAR
> The reason was that this would make any manual 
> PAR compensation in the script unnecessary

This isn't really true if using VSFilter.dll and your video was 720x480. 
No matter if you set a PlayRes of 853x480 or 720x480, PAR compensation is still 
necessary if you don't want your main dialog stretched.

> I only noticed that corruption when defining the blur values 
> on the original resolution, so I thought I should mention it here...

I suspect the blur just changed the color at the sub-pixel \clip boundaries, 
which made the anomaly more visible.

> it still doesn't display correctly on the 720x480 video.

What doesn't? Please explain.

Original comment by cyber.sp...@gmail.com on 19 Sep 2012 at 12:18

GoogleCodeExporter commented 9 years ago 
> PAR compensation is still necessary if you don't want your main dialog 
stretched.
Now that seems sort of stupid... isn't PlayResX/y there to define the Aspect 
Ratio of the subtitles at Script Resolution level, which would mean that it 
automatically adapts to Aspect Ratio changes as well? I would have expected 
such behaviour, anyway... well, thanks for the notice, I guess?

> There shouldn't be any real increase in precession, since sub-pixel 
positioning is
> always only accurate to 1/8 of a pixel at the output resolution.
Yes, maybe... but for example, by the time I started on said script, 
xy-VSFilter didn't support non-integer fscx/y values yet...

> I suspect the blur just changed the color at the sub-pixel \clip boundaries, 
which
> made the anomaly more visible.
Actually, I worked on a 720p upscale the whole time and only loaded the 480p 
video into Aegisub in the ned, so I could define the blur values... and I 
somehow doubt that I wouldn't have noticed the error before, it's quite visible 
(though I know that the gradient is not optimal).

> > it still doesn't display correctly on the 720x480 video.
> What doesn't? Please explain.
A screenshot (taken from Aegisub, the scaling test build looks the same, except 
for the blur) for both 720p and 480p is attached. If you want the script, I 
have isolated the lines and attached them.

Original comment by TheDarkS...@googlemail.com on 19 Sep 2012 at 1:10

Attachments:

GoogleCodeExporter commented 9 years ago 
> I would have expected such behavior, anyway...

In VSFilter, PlayRes mainly only has an effect things which are defined by x/y 
positioning coordinates, the PAR correction function, as well as relative font 
sizes. It does not do any scaling/stretching of fonts and most tags by default. 
The current PlayRes behavior is something VSFilter is stuck with. This is why 
xy-VSFilter needed to implement a proper scale function for use with the new 
subtitle interface.

> xy-VSFilter didn't support non-integer fscx/y values yet...

Even assuming non-integer fscx/y values, the gain from using a PlayRes of 720p 
vs 480p is negligible overall if you are trying to do high quality motion 
tracking. For the years prior to non-integer fscx/y support, typesetters were 
using a workaround of scaling extremely tiny font sizes with fscx/y values in 
the thousands to gain a similar effect.

> A screenshot (taken from Aegisub, the scaling test build
> looks the same, except for the blur)

You won't see that problem with this script at any video resolution if you set 
'Customize' set to 1280x720 in xy-VSFilter_Scale_Test_Build_1. Keep in mind 
that Aegisub 3.0 will be unable to use or preview xy-VSFilter's scale function. 
For your example script this won't matter though, since if Aegisub shows your 
\clip gradient or anything else as broken, that's how it will look by default.

You can't have a mismatched PlayRes and video resolution without the risk of 
\clip gradients getting messed up.

A) Open the 720x480 video in Aegisub and use the Resample Resolution function 
scale down to 720x480 with tweaks to blurs and other things as necessary. 

B) Go to the tedious process of creating a special gradient at 1280x720 
PlayRes, where each clip rectangle boundary scales down to whole pixels when 
divided by 1.5 for 480p.

Original comment by cyber.sp...@gmail.com on 19 Sep 2012 at 3:04

Attachments:

GoogleCodeExporter commented 9 years ago 
> We've been considering allowing the user to manually tag the correct layout
> resolution (original authored video resolution) to the script, which would
> automatically configure and enable the scale function.
I guess that means you abandoned the thought of adding the Layout Resolution to 
the script, then? Because if it's just "planned, but not ready yet", I can 
gladly wait and manually edit the script header to include this (and 
reconfigure blur values and such) when it's ready and I know the header field 
names.

> A) Open the 720x480 video in Aegisub and use the Resample Resolution function 
scale
> down to 720x480 with tweaks to blurs and other things as necessary.
I think this is probably the best solution if I have to add in AR correction 
anyway. Though, personally, I'd of course prefer it if there was a way I'd only 
have to tag the Layout Resolution and redo the blurs, which would be less 
effort.

In any case, I sincerely thank you for the interest you have shown in this 
issue, and also for the free lesson in how VSFilter treats Script Resolution. I 
guess now I know why at first, I thought it had worked on the 480p video as 
well... my bad.

Original comment by TheDarkS...@googlemail.com on 19 Sep 2012 at 5:40

GoogleCodeExporter commented 9 years ago 
> abandoned the thought of adding the Layout Resolution
> if it's just "planned, but not ready yet"

The tagging method to use for the xy-VSFilter scale function (if any) hasn't 
been agreed upon yet. It's too late to have anything related to the scale 
function included in Aegisub 3.0, we don't intend to officially release an 
xy-VSFilter build containing the scale function until consumer/provider 
subtitle interface work with madVR is completed, and then there is the matter 
of deciding the best course of action which avoids distorting correct PlayRes 
handling even further for other subtitle renderers.

> I'd of course prefer it if there was a way I'd only have to tag
> the Layout Resolution and redo the blurs, which would be less effort.

With the xy-VSFilter scale function everything is scaled, including blurs, so 
you shouldn't need to redo anything when it's used. Having true script 
portability for past and present scripts is the main reason I've personally 
been favoring explicitly tagging the layout resolution, but as mentioned above, 
at this point it's too early to predict if that's the method which will 
ultimately be agreed upon.

Original comment by cyber.sp...@gmail.com on 20 Sep 2012 at 3:18

GoogleCodeExporter commented 9 years ago 
> The tagging method to use for the xy-VSFilter scale function (if any) hasn't 
been
> agreed upon yet.
Thank you. In that case, I'll gladly wait until it is decided and simply 
rescale blur values for 720p resolution when it is decided.

> the best course of action which avoids distorting correct PlayRes handling 
even
> further for other subtitle renderers.
I'm not an expert, but I think that libass might want to make use of that field 
as well, when it is present, as some kind of substitute for the original video 
size fields that appear to be required for correct scaling of the \blur tag to 
output resolution.

> With the xy-VSFilter scale function everything is scaled, including blurs, so 
you
> shouldn't need to redo anything when it's used.
As I understood it, I need to setLayout Resolution to 720p for the vector clips 
to display correctly, and that means I have to scale the blurs from Display 
Resolution (720x480; 16:9) to Layout Resolution (1280x720) from where the 
scaling algorithm will then scale them to Display Resolution. Anyway, I will 
wait until that matter is decided upon (as e.g. Matrix Flagging was decided 
upon eventually) and then update the script. Thank you!

Original comment by TheDarkS...@googlemail.com on 20 Sep 2012 at 8:01

GoogleCodeExporter commented 9 years ago 
Issue 169 has been merged into this issue.

Original comment by cyber.sp...@gmail.com on 8 Feb 2014 at 5:25