conditional resizing

[kolak]

My poor avs grammar shows up again, so I'm asking for help.

I'm looking for a conditional padding (adding border).

What I'm trying to do is:

- any frame size which is as per broadcast standard (720x576, 720x480, 1280x720, 1920x1080) stays untouched
- any other frame size gets "padded" to closets (higher) broadcast size.

Example1: 640x360 gets padded to 720x576 (actual data stays 1:1 in the centre, but frame gets filled with black borders)

Example2: 1024x576 gets padded to 1280x720

Thank you!

[StainlessS]

- any other frame size gets "padded" to closets (higher)

Example1: 640x360 gets padded to 720x576


Why not 720x480 which is next higher ?
What additional requirement made you choose 576 rather than 480. Frame aspect ratio, Frame Rate ?

Your requirement needs elaboration.

EDIT: Progressive ?

[kolak]

Frame rate is not that important (90% will be 25 fps, so I haven't mentioned NTSC size). 99% files are progressive.
Here is what I have done (surprisingly) and it works fine:

a=last
w0=width(a)
w=(720-width(a))/2
h=(576-height(a))/2
w1=(1280-width(a))/2
h1=(720-height(a))/2
w2=(1920-width(a))/2
h2=(1080-height(a))/2
w0<=720 ? addborders(a,w,h,w,h): (w0<=1280 ? addborders(a,w1,h1,w1,h1) : addborders(a,w2,h2,w2,h2))

Fps can be taken into account, but it only affects SD resolution- HD are always the same size. Rendering filter detects it automatically.
Aspect ratio is always 1:1 (16x9).

[creaothceann]

x = Width
y = Height
(x <= 720) ? (x = 720 - x y = 576 - y) :\
(x <= 1280) ? (x = 1280 - x y = 720 - y) :\
(x = 1920 - x y = 1080 - y)
x = x / 2
y = y / 2
AddBorders(x, y, x, y)

[kolak]

Looks nice and clean- even if this is not that important I like it :) :thanks:

Any suggestion for improvements?

[raffriff42]

## TEST
#BilinearResize(688, 480) ## -> 720x480
#BilinearResize(700, 572) ## -> 720x576
#BilinearResize(848, 480) ## -> 1280x720
#BilinearResize(1278, 680) ## -> 1280x720
#BilinearResize(1280, 720) ## -> 1280x720 (no borders added)
#BilinearResize(1290, 720) ## -> 1920x1080

x = Width
y = Height

t = ((x <= 720) && (y <= 480)) ? "720x480"
\ : ((x <= 720) && (y <= 576)) ? "720x576"
\ : ((x <= 1280) && (y <= 720)) ? "1280x720"
\ : ((x <= 1920) && (y <= 1080)) ? "1920x1080"
\ : "(none)"

x = (t=="720x480") ? ( 720 - x)
\ : (t=="720x576") ? ( 720 - x)
\ : (t=="1280x720") ? (1280 - x)
\ : (t=="1920x1080") ? (1920 - x)
\ : 0

y = (t=="720x480") ? ( 480 - y)
\ : (t=="720x576") ? ( 576 - y)
\ : (t=="1280x720") ? ( 720 - y)
\ : (t=="1920x1080") ? (1080 - y)
\ : 0

x = x / 2
y = y / 2

AddBorders((x + x % 2), (y + y % 2), (x - x % 2), (y - y % 2))

## DEBUGGING
#Subtitle("width=" + String(Width) + "; height=" + String(Height) + "; class = " + t, align=2)

[Gavino]

t = ((x <= 720) && (y <= 480)) ? "720x480"
\ : ((x <= 720) && (y <= 576)) ? "720x576"
\ : ((x <= 1280) && (y <= 720)) ? "1280x720"
\ : ((x <= 1920) && (y <= 1080)) ? "1920x1080"
\ : "(none)"

x = (t=="720x480") ? ( 720 - x)
\ : (t=="720x576") ? ( 720 - x)
\ : (t=="1280x720") ? (1280 - x)
\ : (t=="1920x1080") ? (1920 - x)
\ : 0

y = (t=="720x480") ? ( 480 - y)
\ : (t=="720x576") ? ( 576 - y)
\ : (t=="1280x720") ? ( 720 - y)
\ : (t=="1920x1080") ? (1080 - y)
\ : 0
Your version gets the logic right - the others failed to see that both width and height must be tested together (not independently) to determine the final size.

Personally, when setting several variables under different conditions, I think it's clearer to use GScript:
GScript("""
if ((x <= 720) && (y <= 480)) { x = 720-x y = 480-y }
else if ((x <= 720) && (y <= 576)) { x = 720-x y = 576-y }
else if ((x <= 1280) && (y <= 720)) { x = 1280-x y = 720-y }
else if ((x <= 1920) && (y <= 1080)) { x = 1920-x y = 1080-y }
else { x = 0 y = 0 }
""")
creaothceann tried to do something similar in standard language, but the syntax doesn't support that.

I see you also cater for non-mod4 sizes in the border calculation, but the logic will still go wrong if the original width and height are not even numbers. Is it required to support odd-numbered sizes, kolak?

[kolak]

update: even sizes is all what I need

Why do you need to check both dimensions?
I assume width is always bigger than height.
I think it just need to take fps into account for NTSC, as PAL frame with NTSC fps won't play on broadcast equipment.
For HD res fps does not matter.

[Gavino]

Why do you need to check both dimensions?
Consider, for example, an input of 720x600.
This needs to be padded to 1280x720, the next highest available.
If you only took the width into account, you would use a target size of 720x576 and try to add negative borders, which would fail.

[creaothceann]

creaothceann tried to do something similar in standard language, but the syntax doesn't support that

...yet? (http://i.imgur.com/xhSiR9n.jpg)

[kolak]

Consider, for example, an input of 720x600.
This needs to be padded to 1280x720, the next highest available.
If you only took the width into account, you would use a target size of 720x576 and try to add negative borders, which would fail.

Yes- I thought about it, but I think I assumed that files have rather "typical" sizes. Almost all of them are 16x9, so situation like 720x600 is not going to happen.

It's good to have proper detection anyway- why not :)

How can I add this exception:
if fps is 23.976 or 29.97 and <NTSC size it gets padded into NTSC
?

[raffriff42]

>Aspect ratio is always 1:1
>Almost all of them are 16x9
Does not compute. Normal 720x480 or 720x576 may or may not be 16:9, and in either case, the pixels are not square.
Pixel aspect ratios of common video formats (http://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_common_video_formats) (wikipedia)

>it should work for any file size.
>I think I assumed that files have rather "typical" sizes.
Does not compute. Odd-sized videos are very rare - thankfully. (link to related thread) (http://forum.doom9.org/showthread.php?p=1641117#post1641117)

Thanks very much @Gavino , as always. I'm still a bit uncomfortable with run time programming...

[kolak]

There will be 2 types of files- broadcast standard ones and "web" ones, which are always square pixel (16x9 frame proportions).

Anamorphic PAL/NTSC files can be "corrected" by forcing aspect in TV.

[raffriff42]

grumble.... (http://www.youtube.com/watch?v=xCc-RWIp7XU)

[kolak]

PAL and NTSC frames would need "correction"- inserting 1:1 pixel aspect ratio video won't give correct preview even for 4x3.

[kolak]

>Aspect ratio is always 1:1
>Almost all of them are 16x9
Does not compute. Normal 720x480 or 720x576 may or may not be 16:9, and in either case, the pixels are not square.
Pixel aspect ratios of common video formats (http://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_common_video_formats) (wikipedia)

>it should work for any file size.
>I think I assumed that files have rather "typical" sizes.
Does not compute. Odd-sized videos are very rare - thankfully. (link to related thread) (http://forum.doom9.org/showthread.php?p=1641117#post1641117)

Thanks very much @Gavino , as always. I'm still a bit uncomfortable with run time programming...

I've corrected it- was thinking about even numbers, but typed odd.

[raffriff42]

>if fps is 23.976 or 29.97 and <NTSC size it gets padded into NTSC
Change the script slightly:
is_ntsc = (abs(Framerate - 23.976) < 0.001) || (abs(Framerate - 29.97) < 0.001)

t = ((x <= 720) && (y <= 480) && is_ntsc) ? "720x480"
\ : ((x <= 720) && (y <= 576)) ? "720x576"
\ : ((x <= 1280) && (y <= 720)) ? "1280x720"
\ : ((x <= 1920) && (y <= 1080)) ? "1920x1080"
\ : "(none)"

[wonkey_monkey]

PAL and NTSC frames would need "correction"- inserting 1:1 pixel aspect ratio video won't give correct preview even for 4x3.
Mod parent up! Oh wait, wrong site...

(the following assumes the video has been generated to spec which isn't always the case)

Anyway, PAL 720x576 should (I think) be cropped to 702x576 then resized to 1024x576 (or 768x576 for 4:3)

NTSC 720x480 should be cropped to 704x480 then resized to [852 or 854]x480 (or 640x480 for 4:3)

You may even want to crop a little further to account for overscan (and the same can still be true for HD - broadcasters do still allow for it).

David

[kolak]

Yes- quite a lot of pre-processing. If you insert eg. 640x360 (with borders) into PAL frame and try to display it on 16x9 TV it will be way wrong (bit wrong aspect on 4x3 TV).

I'm going to pass PAL, NTSC as is and use 1280x720 for all "small" non standard frame sizes. In this case it's easy and keeps all at 1:1 pixel aspect ratio.