Resizing for 16:9?

[mantis2k]

For a movie with a width of 720, what height should the picture be before adding borders to satisfy a 2.40:1 ratio for:
a) PAL
b) NTSC
?

More of a mathematical question, really! My brain is getting a bit rusty lately. Any help would be much appreciated!

[b66pak]

a) 436 {[576*(20/11)]/2.40} if you using DAR or {[720*(16/11)]/2.40} if you using SAR (PAR)

b) 364 {[480*(20/11)]/2.40} if you using DAR or {[720*(40/33)]/2.40} if you using SAR (PAR)
_

[MatLz]

a) 426
b) 356

If you don't want to always calculate, take a look here:
http://forum.doom9.org/showthread.php?t=151158

[Keiyakusha]

a) 426
b) 356
i got the same numbers as MatLz

[mantis2k]

That's great! Appreciate the quick responses, guys; much obliged! :)

[MatLz]

That's great! Appreciate the quick responses, guys; much obliged! :)Of course...it's not doom10 here...:D

Well, it's really basic maths:
((576or480)x(16/9))/yourAR

(Only if yourAR is more than 16/9)

[wonkey_monkey]

b66pak, I'm not sure where your 20:11 constant comes from, since by that logic a 16:9 PAL picture should be 589 (rather than 576) pixels high...

David

[b66pak]

see this:

http://seemoredigital.net/03_Video_Only_Info/What_is_an_anamorphic_encode.html

for 16:9 NTSC DVD SAR (PAR) is 40:33 so DAR is (720:480)*(40:33) = 20:11

for 16:9 PAL DVD SAR (PAR) is 16:11 so DAR is (720:576) * (16:11) = 20:11
_

[Keiyakusha]

I guess this is more like personal taste. For example I prefer 32:27 par, only this looks right for me ^_^
For 40:33 image should be resized to 704 horizontal + 16px black borders added.

[Alex_ander]

b66pak, I'm not sure where your 20:11 constant comes from, since by that logic a 16:9 PAL picture should be 589 (rather than 576) pixels high...

David


Like all other mystery numbers (which are IMO absolutely unnecessary for calculations :) ), they most likely come from those well-known 704/720:
576x720/704=589

[wonkey_monkey]

My brain hurts, but MatLz's example doesn't involve any confusion between 704px and 720px, so I still think 426/356 are the correct heights. The page that b66pak linked to doesn't seem to take nominal analogue blanking into account, despite being quite technical.

David

[Keiyakusha]

Let's see on NTSC example.

Here (http://imgur.com/5X2IV.png) is perfect 2.40:1 padded to 16x9 (sorry, its big...)
Whatever PAR we use, height is never changed. So if we resize it to
720x480 (http://imgur.com/6e38a.png) and will use 32:27 PAR
or
704x480 (http://imgur.com/UbhIi.png)+16px borders and will use 40:33 PAR
height is always 356

PAR alters only width, mantis2k asked about height...

{[720*(40/33)]/2.40} if you using PAR

IMO its wrong. For 40/33 par actual image should be only 704 in width. other 16 px is garbage and should not be taken into account. Thats how I see it. Also depending on which PAR I set in this formula, height can be different, but par alters only width, as shown above.

[Didée]

I have a Deja-Vu. Feels like this discussion has been done before ... and before ... and before ... and before ... and before ...

Also, it should be noted that mantis2k's actual source is spatially skewed, the "active frame" dimensions do not adhere to any standard. Therefore, whatever oh-so-exact numbers you may come up with - they don't apply in this case.

Take the source, and size it until it looks "right" by eyeballing. That's the most accurate you can do in this case.

[Emulgator]

Take the source, and size it until it looks "right" by eyeballing.
That's the most accurate you can do in this case.
Thats what I did in this case too...

[MatLz]

I agree...'eyeballing':eek:
To return on the topic, the par can change if 704 or 720...but the final dar won't change. It's why we just need to do our calculations with only base ourselves on the standard height and the dar.

[Motenai Yoda]

generic par are
pal 4/3= 16/15
pal 16/9 = 64/45 (4/3*4/3 =16/9 XD)
ntsc 4/3 = 8/9
ntsc 16/9 = 32/27

instead ITU-R BT.601 par are
pal 4/3 = 128/117 * 767/768
pal 16/9 = 512/351 * 767/768
ntsc 4/3 = 4320/4739 * 767/768
ntsc 16/9 = 5760/4739 * 767/768

http://lipas.uwasa.fi/~f76998/video/conversion/#conversion_table
http://forum.doom9.org/showthread.php?p=1058927
http://smok3.t35.com/resize/

[MatLz]

pal 720x576
16/9 par=64/45
4/3 par=16/15

pal 704x576
16/9 par=16/11
4/3 par=12/11

ntsc 720x480
16/9 par=32/27
4/3 par=8/9

ntsc 704x480
16/9 par=40/33
4/3 par=10/11

In my humble newbie opinion, in the real world of dvd video, all other values are simply jokes or phantasms...
Don't forget we live in a mod16/mod8...at least a modeven world, so have a par which is (xxxx/xxxx)*(xxx/xxx) is beyond that rule.

Maybe...:D

[Alex_ander]

In my humble newbie opinion, in the real world of dvd video, all other values are simply jokes or phantasms...

The values like 'PAR' inclusive :) , you don't have to remember or store them somewhere since they come from well-known real numbers (which are easier to use directly).

[2Bdecided]

PAR in gory detail:
http://forum.doom9.org/showpost.php?p=1256670&postcount=27
(see table in attachment)

...though has already been said, when you're looking at changing the height, you only need to know what fraction of the original height you want - and multiply the original height by that fraction. Job done.

e.g. PAL 16x9:
576 * ((16/9) / (2.4/1)) = 426

e.g. NTSC 4x3:
480 * ((4/3) / (2.4/1)) = 266

See. Simples. No PAR needed!

Cheers,
David.

[Motenai Yoda]

See. Simples. No PAR needed!
par is the same thing but 2.4 can be incorrect or rounded. (can be between 2.35/2.45)
usually a 2.40 film has 16/9 par (rarely 4/3) with letterbox so the height must be calculate on cropped framesize's height.
eg 16/9 pal (itu) -> 720x576 (par = 512/351 * 767/768)
cropped -> 720x436
436/par-> 720x300 (mod 4) or 720x304 (mod 16)

relative avisynth script would be
crop(0,70,0,-70).blackmanresize(720,300)

sorry for my english

[2Bdecided]

sorry for my englishYour English is fine. Sorry, but your maths doesn't make any sense at all!

Cheers,
David.

[Keiyakusha]

par is the same thing but 2.4 can be incorrect or rounded. (can be between 2.35/2.45)
Sorry but in current thread we don't care about that. Unless otherwise is stated somewhere, we should assume that the source is 2.40:1 with correct aspect ratio to begin with and without any borders.
And the maths doesn't makes any sense to me either... :scared:

[Motenai Yoda]

Your English is fine. Sorry, but your maths doesn't make any sense at all!

Cheers,
David.

sorry but
e.g. PAL 16x9:
576 * ((16/9) / (2.4/1)) = 426

e.g. NTSC 4x3:
480 * ((4/3) / (2.4/1)) = 266
if the correct aspect ratio is 2.4 and width=720
720/2.4=300
720/426= 1,69
720/266= 2,7
then both examples you quoted are completly nosense (the same image has different height between ntsc or pal???)

par is a ratio between width and height of each pixel u can multiply width or divide height.

I'm telling about converting to square pixel.
omitting the ratio said, the general formula is
if par > 1 cropped area's height/par
if par < 1 (only ntsc 4/3) cropped area's height*par

i.e.
from kingdom of heaven pal (16/9 generic par)
original screenshoot
http://img176.imageshack.us/img176/3978/koh4originale.png
after crop(0,70,0,-70) height = 436
http://img443.imageshack.us/img443/9060/koh4cropped.png
436/(64/45) = 306, dar = 720/306 = 2.35
http://img189.imageshack.us/img189/357/koh4resized.png

edit:---- sorry I was wrong to interpret the mantis2k's request, my English is not good enough XD

[Keiyakusha]

the same image has different height between ntsc or pal???

of course! PAL by default have more height!

par is a ratio between width and height of each pixel u can multiply width or divide height.
No. You can divide or multiply width. You can do nothing with height. PAR alters only width.
Theoretically maybe you can, but thats not how it works.

EDIT: you can do that if you going from anamorphic to square pixel. But in this thread we are going from square pixel to anamorphic.

[Motenai Yoda]

sorry I was wrong to interpret the mantis2k's request, my English is not good enough XD
I had all misunderstood

[Alex_ander]

sorry but
Quote:
e.g. PAL 16x9:
576 * ((16/9) / (2.4/1)) = 426

e.g. NTSC 4x3:
480 * ((4/3) / (2.4/1)) = 266

if the correct aspect ratio is 2.4 and width=720 ......

As you can see, 720 is not mentioned at all in those equations, that's because it doesn't matter for the resulting numbers here. It could be an SVCD or DVB source as well, encoded as 480x576 (544x576, etc.) with 16:9 or 4:3 flag. Only that flag defines how the actual number of pixels will be displayed (be the pixels round or elliptical). And this calculation assumes, that the width of the 2.4:1 letterboxed image will remain the same as the width of the standard 16:9 (4:3) image, e.g. 704 by ITU. Then only relationship between two display AR's does matter. If you want to modify the result, e.g. stretch width to 720, then to keep correct proportions you can multiply height pixel numbers by 720/704 value and forget forever about the 'PAR' big mystification :) .

[Ghitulescu]

For a movie with a width of 720, what height should the picture be before adding borders to satisfy a 2.40:1 ratio for:
a) PAL
b) NTSC
?

You got a lot of answers here but the correct answer is always IT DEPENDS:
Well, it depends of your intended target and of your source (and of the intermediate storage if any).

Let me explain:
You have a DVD that is 2.4:1. This DVD has always 720x576 (or x480) pixels (well, there are also DVDs having 704 horizontal pixels, which makes the things even more complicated). To further complicate the matter, these 720x576 pixels can accomodate a 2.4:1 image in 2 modi: either as 16:9 anamorph or as 4.3 letterbox.
This is the source aspect.

Now the destination aspect. If it's for TV/DVD/BD or any other standardized norm, you'll have to create an image having again exactly 720 (704)x 576 pixels, based on your original image. You also have to specify its DAR (which sets the PAR), either as 16:9 or as 4:3.

Supposingly you have a 2.4:1 PAL movie coded as 4:3 LB which you intend to store it on a DVD as 16:9 anamorph then you'll have to resize the image according to these values:
First, the real image (without the black bars) would be 720x320 TV pixels. So you have to crop 128 pixels from top and 128 pixels from bottom, resize the vertical size of 320 pixels to 426, and add black borders up to 576 (75 each side). Don't forget to set the DAR to 16:9. You'll end with a beautiful 2.4:1 16:9 anamorph encoded movie. You did nothing than resizing the vertical size of the image. In a PC player that does not respect DAR/PAR, only SAR (like DVD shrink) you'll notice the image is even more distorted that the original, however on the TV both movies would look identical (except for the scaling issues, you vs. TV).

Supposingly you have a 2.4:1 PAL movie as 4:3 letterbox or 16:9 anamorph and you want to make an AVI out of it, with PC pixels (PAR = 1), then you can use the calculations made by the other contributors to this thread (http://forum.doom9.org/showthread.php?p=1378417#post1378417 or http://forum.doom9.org/showthread.php?p=1378790#post1378790).

If you have an AVI with a PAR=1 and want to do a DVD out of it, just resize the image to 720x426, add black borders to 576, set the DAR to 16:9 (or to 4:3 if you resized to 320) and be happy. But you figured this already, don't you?

On the PC domain, you have however no restriction at all, you can create videos of 295x123 if the codec allows you such sizes.

[SeeMoreDigital]

see this:

http://seemoredigital.net/03_Video_Only_Info/What_is_an_anamorphic_encode.html

for 16:9 NTSC DVD SAR (PAR) is 40:33 so DAR is (720:480)*(40:33) = 20:11

for 16:9 PAL DVD SAR (PAR) is 16:11 so DAR is (720:576) * (16:11) = 20:11
_Well... here's the actual quote from my web site: -

http://i44.tinypic.com/kd1v61.png

Personally, I don't follow ITU re-sizing calculation methods...

[Maccara]

Personally, I don't follow ITU re-sizing calculation methods...

And your reasoning for this is valid in some cases (ITU vs generic PAR), but unfortunately only correct if the DVD is incorrectly mastered (they *should* use ITU - but it seems many probably don't, especially nowadays when they come from digital sources).

*Only* way to be sure of what PAR the DVD have been mastered with is to measure some known objects (basketball etc) and derive from there.

Personally, I don't bother to try to measure, but I do at least check if the DVD "seems to" utilize the whole 720px for the picture (so I assume generic PAR) or only 704 (blanking is obvious, so I assume ITU -> I today see this mostly on DVDs which come from analogue sources originally) and go from there.

[Ghitulescu]

*Only* way to be sure of what PAR the DVD have been mastered with is to measure some known objects (basketball etc) and derive from there.

You cannot do this. I mean, you cannot rely on this, although it's the best way of doing it, when other methods are not available. That's because the vertical physical size of a TV screen is beyond your control (factory determined) and that of the displayed image is customizable (older TV had a V-Size potentiometer, while the newer ones still have it but it's hidden or it lacks completely - EEPROM settings).

But yes, it's the method one can use.

[Maccara]

You cannot do this. I mean, you cannot rely on this, although it's the best way of doing it, when other methods are not available. That's because the vertical physical size of a TV screen is beyond your control (factory determined) and that of the displayed image is customizable (older TV had a V-Size potentiometer, while the newer ones still have it but it's hidden or it lacks completely - EEPROM settings).

But yes, it's the method one can use.

Oh yes, I should've mentioned that you cannot rely on your display only, unless you know it's calibrated for this. :) Also, you can't rely your player doing the right thing either (probably all of the software players resize assuming 720x is the full picture area whereas many (some?) hardware players assume ITU).

One method is to take raw pictures (i.e. not resized by anything for playback) of the stream showing the object with known properties (perfect circle, f.e.) and derive the data from that.

Edit: ...and we're not even going into possible lens distortions on the source etc etc, which will screw all assumptions up trying to measure something... :)

[Ghitulescu]

Yeap, but there's still one problem, as there are several players in this game:

1. the camera that took the pictures of the basketball (does it comply with ITU-R, is it SMPTE? which one?)
2a. was it an analog->digital conversion in between? how was it done?
2b. was it analog editing involving gear from several manufacturers? All using the same SMPTE?
3. the editing suite (again ITU-R or SMPTE, and which SMPTE?) - probably the easiest issue, as here only ITU-R is of relevance (once you have the video digitised)
4. the playing device
4a. image transfer standard (analog=SMPTE, SDI=ITU-R)
5. the displaying device.

So using a digitally custom image (test pattern) may help to calibrate the player/viewer, then using these to check the ahead of the chain, one by one. You see, not all of us have [access to] a profi CRT monitor.

For me this subject is moot: I don't use AVI/DivX/MKV and stuff (which are the main cause of these stormy issues) but PAL (evtl NTSC) compliant videos (camcorder, DVD, DVB, VHS etc.) and I don't give a xyz on the slight difference that exists between ITU-R and SMPTE (which one ;p) in terms of PAR and samples/scanline. It's for purists.

[SeeMoreDigital]

One method is to take raw pictures (i.e. not resized by anything for playback) of the stream showing the object with known properties (perfect circle, f.e.) and derive the data from that.Another method would be to compare still images from the DVD (non-square pixel) release against the Blu-ray (square pixel) release ;)

[Maccara]

Yeap, but there's still one problem, as there are several players in this game:


Yes, you're absolutely right.

But we can ignore most of the intermediate stuff when you're counting pixels from the raw pictures just to determine a factor you need if you want your own end result to end up having possibly distorted circles as circles. I mean, we just have a squished circle -> we make it round; we don't care how the circle got squished in the first place (as long as we count raw pixels and not look at display measurements!).

Of course, as many things are shot with multiple cameras, possibly composited from multiple sources etc, you can't have a "perfect" method for all possible scenarios, even if you can measure and correct for one sequence from your file.

The best you can hope for is that the person mastering the original source knew what they were doing and knew the hardware and software they were using, so that the entire material conforms to single spec. That's a lot to rely on. :)

That's why I generally just go by "intuition" and "eye balling", and stick to "standard" values by that. Probably close enough (we're not talking about "too many" pixels of differences here anyway).