NTSC to PAL: aspect ratio?

[GrofLuigi]

After following the numerous threads here, let's say I'm satisfied with the bob.ConvertFPS.selectevery method often discussed here, in terms of motion fluidity. But what about size? I haven't come accross that. With studying different topics about aspect ratios and active displays, and my head still smoking, I've come up with this:

Addborders (64, 48, 64, 48)
BilinearResize (720, 576)

for translating the NTSC 640x480 to PAL 768x576 display area, assuming the source is 4:3 interlaced borderless picture (720x480 DVD).

I didn't want to resize vertically because of interlacing. But, now the picture looks funny because of all the borders. Any suggestions on improving it? Maybe resize when the picture is bobbed?

The full script is:
MPEG2Source ("D:\VIDEO\SOURCE\1.d2v", upConv=1) # to YUY2 for CCE
TDeint (mode=1, expand=4, slow=2)
ConvertFPS (50)
AssumeTFF() # it's TFF
SeparateFields ()
SelectEvery (4, 0, 3)
Weave ()
Addborders (64, 48, 64, 48)
BilinearResize (720, 576)

GL

[davidhorman]

It sounds like you're getting a little confused about your resolutions - you talk about resizing from 640x480 to 768x576, but then say your source is 720x480 and you want to resize to 720x576...

Anyway, yes, you should resize after you bob:


bob
convertfps(50)
...resize(720,576)
assumetff
separatefields
selectevery(4,0,3)
weave


David

PS I wonder if the confusion is because you're not aware that PAL and NTSC have different aspect ratios?

[525/60]

Yes, you should bob first.

The simplest thing to do is to stretch horizontally 480 -->576.

Otherwise you have to shrink the image vertically by the same ratio:

BilinearResize (600, 480)
AddBorders(60,48,60,48)

[davidhorman]

The simplest thing to do is to stretch horizontally 480 -->576.

If by "horizontally" you mean "vertically"... ;)

David

[GrofLuigi]

It sounds like you're getting a little confused about your resolutions - you talk about resizing from 640x480 to 768x576, but then say your source is 720x480 and you want to resize to 720x576...

Because DVD players also resizes on playback... Both NTSC and PAL ones. The idea is:

- I don't want to stretch vertically.
- 720x480 in 4:3 ratio is 640x480
- 720x576 in 4:3 ratio is 768x576
- how to put the 640x480 rectangle into 768x576 rectangle?
- the PAL picture will be 768x576, but stored on DVD like 720x576
- so, I came up with the above.

PS I wonder if the confusion is because you're not aware that PAL and NTSC have different aspect ratios?

Maybe I'm wrong, but my current script looks better to me than before (when I was resizing/adding borders directly from 720x480 to 720x576). Circles were much more squashed then. Now, I'm satisfied with this, but would like to use more of the display (to reduce the borders).

GL

[GrofLuigi]

Yes, you should bob first.

The simplest thing to do is to stretch horizontally 480 -->576.

Otherwise you have to shrink the image vertically by the same ratio:

BilinearResize (600, 480)
AddBorders(60,48,60,48)

Where did 600 come from? And yes, I was thinking along the same lines, with resizing twice to mimic the behaviour of DVD players, but I wanted to "optimize". :)

GL

[davidhorman]

I'm confused about the way you're thinking about this...

I think it's easier to think of it this way - both NTSC and PAL DVDs are 720px across, and that's the full width of the picture (actually, that's not strictly true, but it's a good assumption for this purpose). They have different aspect ratios (neither of which is 1:1), so they have different heights. If you want to translate from one to the other, just scale vertically.

Is your target to produce a PAL DVD?

David

[GrofLuigi]

I'm confused about the way you're thinking about this...

I think it's easier to think of it this way - both NTSC and PAL DVDs are 720px across, and that's the full width of the picture (actually, that's not strictly true, but it's a good assumption for this purpose). They have different aspect ratios (neither of which is 1:1), so they have different heights. If you want to translate from one to the other, just scale vertically.

Is your target to produce a PAL DVD?

David

Anything would do, as long as circles are round. Probably I'm wrong about the ratios, but with plain 720X480 resize to 720x576 they're not. Same with addborders. I'm not talking about particular DVD, I'm trying to find general solution/model for understanding. And that's not even trying to touch letterbox... :)

Yes, the target is PAL DVD.

GL

[Didée]

If your're starting with a NTSC DVD source and want to end with a PAL DVD, then refer to David's code in post #2 (http://forum.doom9.org/showthread.php?p=975119#post975119). Nothing much to add ... you can artificially complicate the matter, but it won't get more correct than that. :)

[525/60]

- 720x480 in 4:3 ratio is 640x480
- 720x576 in 4:3 ratio is 768x576
- how to put the 640x480 rectangle into 768x576 rectangle?
I think you are on the right track here. (I am going to try to get my horizontal and vertical switched back around.)

768x576 is larger than 640x480 both horizontally and vertically by a ratio of 6:5. The only issue is how they were arrived at and how to reverse the process.

For NTSC 4:3 DVD, the width is shrunk by a ratio of 10:11

Crop(8,0,-8,-0)
BilinearResize(640,480)

For PAL 4:3 DVD, the width is stretched by a ratio of 12:11

Crop(8,0,-8,-0)
BilinearResize(768,576)

In order to convert from NTSC to PAL, you need to shrink the width by a ratio or 10:11 to get a neutral 1:1 pixel aspect ratio, the shrink that by the inverse of 12:11, 11:12.

Since the 11s cancel out, we are left with a ratio of 10:12 or 5:6.

720 times the ratio of 5:6 is 600.

So to convert from NTSC to PAL, either the image must be shrunk horizontally by 5:6 or stretched vertically by 6:5. (Did I get that right? Either shrink the width by 5:6 or increase the height by 6:5.)

480 times the ratio of 6:5 is 576.

So I guess I was right and you have the answer to this question:

Where did 600 come from?

[525/60]

Probably I'm wrong about the ratios, but with plain 720X480 resize to 720x576 they're not. If you re-encode to a 4:3 aspect ratio mpeg2 file, it would look right on any software player that honors the aspect ratio flag in the header or after you make the 4:3 PAL DVD it will look right on any player. Don't confuse how the raw 720x576 frame looks on a computer screen with how it will look in an mpeg2 stream.

[davidhorman]

So to convert from NTSC to PAL, either the image must be shrunk horizontally by 5:6

A small nitpick, but that's not an option, because the picture will still only have 480 lines and so will not be PAL-compliant.

David

[525/60]

First of all Didée is right, it doesn't need to be complicated (Sorry).

Second of all, davidhorman is right, all you need to do is resize to 720x576.

Third of all, I am right too. What we have in common is that the 3:2 ratio frame of NTSC is resized to the 5:4 ratio frame of PAL as a first step. That way you convert to the proper PAL pixel aspect ratio.

720:480 is 3:2; 720:576 is 5:4 is 600:480.

The ratio to convert between NTSC and PAL is 5:6 as can be seen in the equation

3:2 times 5:6 equals 5:4.

As long as you resize to a frame with a ratio of 5:4 from the NTSC 720x480 frame, circles will be circles on the PAL DVD, just the size of the circles will change.

For instance 700:560 is 5:4.

If you don't want to deinterlace first or if you don't want to deinterlace at all, wouldn't this work?

MPEG2Source ("D:\VIDEO\SOURCE\1.d2v", upConv=1)
ConvertFPS (50)
SeparateFields
SelectEvery (4, 0, 3)
Spline16Resize(700,280)
Weave
AddBorders(10,8,10,8)

I think it would. Perhaps it would look the best due to less resizing and more of the picture being visible on the TV screen. Is de-interlacing really necessary? I mean couldn't you encode it as an interlaced PAL DVD? Is Video NTSC intelaced differently than PAL? What I am asking is does anyone know how to convert directly from Video NTSC to interaced PAL without de-interlacing between them? I'm going to investigate that.

After using the above script, you would have to re-encode to mpeg2 as a 720x576 frame 4:3 aspect ratio 25fps file using an mpeg2 encoder like HCEnc. Don't judge the outcome until after you see it as an mpeg2 file or as a 4:3 PAL DVD watching it on your TV.

Stephen

[525/60]

A small nitpick, but that's not an option, because the picture will still only have 480 lines and so will not be PAL-compliant.Yes, but that is why I said 'as a first step'. For a second step you have to use AddBorders for any resize smaller than 720x576. My point is that the relative pixel aspect ratio would be the same and circles would still turn out circular. I was addressing GL's specific constraint that he did not want to resize vertically. Since only about 702 pixels worth of the line is visible on a PAL TV, my third option has its benefits and I could not have arrived at that solution if I had not generalized your solution from a 720:576 resize to any size 5:4 frame.

Some of what I have said is too complicated, but I think I corrected that in my last post.

[davidhorman]

525/60, your code does deinterlace, when you separatefields - you've (over-)simplified a few steps but the end result will be (almost*) the same as a bob/resize/separate/select/weave. For some reason you've chosen to complicate matters by slightly shrinking the picture and fitting it inside a black box, too...

*You've also introduced a new problem - by resizing fields rather than bobbed frames, each pair of fields will now have an additional offset of a fraction of a line when it comes to weaving, which will cause a possibly unpleasant vertical judder.

(Edited to add due to new post...)

I was addressing GL's specific constraint that he did not want to resize vertically.

True, he did say:

I didn't want to resize vertically because of interlacing.

But then he said:

But, now the picture looks funny because of all the borders.

David

[GrofLuigi]

Now my head started smoking again. :)

Stephen(525/60): I need more time to follow your math and try your script. I'm not seeking for exact numbers, just something "eye pleasing" (and, if possible, with more of the active picture).

And I'm checking the picture in VirtualDub (or Mod) with right clicking on the active panel and selecting the ratio.

All: I was reluctant to resize bobbed (or separatefield-ed) picture vertically because I wasn't sure if that would introduce artefacts (I think interlace lines are always one pixel tall) - I can't check right now since currently I have only one NTSC DVD which is very dark. Also, what if the bobber leaves some residue? (I don't know what parameters to feed it to be completely sure that doesn't happen).

As I said, I was asking this as a general and future-proof question (that would work with any DVD). I will experiment more and try the scripts in few days, but currently my work is taking over. :(

GL

[davidhorman]

All: I was reluctant to resize bobbed (or separatefield-ed) picture vertically because I wasn't sure if that would introduce artefacts

Any decent bobber won't leave any residual combing, although by their nature they can never fully reconstruct the missing lines when promoting a field to a frame. In general, quality increases as bobbers get slower ;)

You really only have two choices here - either don't resize vertically, in which case you must resize to 600x480 and add borders to maintain the aspect ratio for DVD, or bob and resize vertically by 125%. I'd always recommend the latter over the former.

David

[525/60]

You really only have two choices here - either don't resize vertically, in which case you must resize to 600x480 and add borders to maintain the aspect ratio for DVD, or bob and resize vertically by 125%.@davidhorman
Thanks for confirming that both options are correct.

I need more time to follow your math and try your script. Ratios multiply like fractions. 5:6 is the ratio to convert the pixel aspect ratio from NTSC to PAL. This can be accompliched either by multiplying the width by this ratio:

720 time2 5:6 equals 600

or by multiplying the height by the inverse of this ratio:

480 times 6:5 equals 576.

In either case, the ratio of the width to the height of the destination frame is the same: 5:4 which is 1.25. It's five fourths, a fraction. And 6:5 is 1.2. It's what you multiply the height by or divide the width by to obtain the 5:4 destination frame ratio.

As long as the destination frame has a ratio of 5:4, you've preservered the aspect ratio. You take the width and you divide it by the height and you get the aspect ratio of the frame. For instance:

720x576, 600x480, and 700x560

all have the same ratio of 5:4. The reason why 700x560 is good is because a PAL TV only displays 702 pixels worth of each line, so you get to see then entire width on the TV. The reason 720x576 is good is because it eliminates the black matting entirely. And the reason 600x480 would be good is because it preserves the original lines, you don't blur the lines with resizing. However, davidhorman pointed outAny decent bobber won't leave any residual combingSo the third option is not meant as a recommendation, only a demontration of the proper way of resizing the width to maintain the correct aspect ratio. You can obtain the same result by stretching the height to 576 and then shrinking the frame proportionately until the height is 480 again.

Stephen

[davidhorman]

The reason why 700x560 is good is because a PAL TV only displays 702 pixels worth of each line

Is the same not (almost) true of NTSC? That the active picture is supposed to be within 704 pixels? By resizing to 700x560, you're actually bringing more of the inactive NTSC picture inside the active PAL frame.

ETA: Reading up, it seems that TVs should display at most 702/704 pixels - in reality they display quite a lot fewer.

David

[525/60]

525/60, your code does deinterlace, when you separatefields - you've (over-)simplified a few steps but the end result will be (almost*) the same as a bob/resize/separate/select/weave.Yes, yes, yes. Please take me out of the question of how to deinterlace entirely. I only claim to understand aspect ratios, which is the topic of the thread anyway. Although resizing after separating the fields is a quick and dirty approach, I see now that it is not as good as resizing after bobbing. The part that confused me is that you end up with PAL interlaced video anyway, but bobbing allows both the blending of frames with ChangeFPS (a function that didn't used to work as well as it seems to be doing now) and the vertical resizing to be done correctly.

Indeed both bobbing and ChangeFPS are techniques I gave up on many years ago. Bobbing always bobbed and ChangeFPS smeared the image too much; I don't see those problems anymore now, however. This is why I don't understand these techniques and should have left it alone. I guess I was trying to insert my suggestion within the larger context of the script. But you can do that much better than me.

Right now I am experimenting with this script:

LoadPlugin("C:\PROGRA~1\GORDIA~1\DGMPGDec\DGDecode.dll")
mpeg2source("H:\DMB\VIDEO_TS\VTS_01_1 - 0xE0 - Video - MPEG-2 - 720x480 (NTSC) - 4~3.d2v")
TDeint (mode=1, expand=4, slow=2)
ConvertFPS (50)
Spline16Resize(700,560)
AssumeTFF.SeparateFields
SelectEvery (4, 0, 3)
Weave
AddBorders(10,8,10,8)
AudioDub(WavSource("VTS_01_1 - 0x80 - Audio - AC3 - 2ch - 48kHz - DRC - English - DELAY -66ms.wav"))
Trim(8400,49979)


I think you have to resize before you separate the fields and weave, because you seem to end up with interlaced video after the weave. Again, I might not understand it correctly !?

Stephen

[525/60]

ETA: Reading up, it seems that TVs should display at most 702/704 pixels - in reality they display quite a lot fewer.Yes, that is why you still will not see any matting on the sides. The reason I recommend it, however, is based on the idea that the more you resize the image, the more you blur it; the less you resize, the sharper the image will be. If this is true, then you end up with a sharper image if you resize just enough to fill the entire width of the TV screen and no more. That is not an advantage if the plan is to watch the PAL DVD on the computer or even if you have a digital TV. For watching on an analog 4:3 TV, I think it's the best option. That's a qualified 'best' mind you, based on how you plan to use the DVD. And also whether the sharpness vs. size compromise seems optimal to you when you view it on your televison.

Stephen

[davidhorman]

ChangeFPS smeared the image too much

It's ConvertFPS that smears (ChangeFPS only duplicates or deletes frames), and the logic behind it was fixed between versions 2.5.6 and 2.5.7, which may explain the differences you've noticed.

I think you have to resize before you separate the fields and weave, because you seem to end up with interlaced video after the weave. Again, I might not understand it correctly !?

Looks fine to me, except for the resize to 700 and the addborders, about which:

The reason I recommend it...is based on the idea that the more you resize the image, the more you blur it; the less you resize, the sharper the image will be.

You may be right in this specific case, but there's more to it than bigger=>blurrier. A back-of-the-spreadsheet calculation suggests that the lines in a 480->560 resize may be on average less blurred than those in a 480->576 resize, but I think this is more down to coincidence than anything else - a midway scale factor of 5/4, for instance, will be a lot more blurred (almost 7% more) than either of the two under consideration.

Of course, I'm quantifying all this in a particular way, based on my own understanding of AviSynth resizers. The quantified quality difference between the 560 resize and the 576 resize is on the order of 0.6%, almost below RGB rounding error level!

There's also one more obvious problem with your method - by resizing to 700x560, you're losing horizontal resolution, which would otherwise be maintained - sharp vertical lines will no longer be sharp.

David

[525/60]

Quote:
I think you have to resize before you separate the fields and weave, because you seem to end up with interlaced video after the weave. Again, I might not understand it correctly !?
Looks fine to me, SelectEvery (4, 0, 3) Alternately selects top and bottom fields from successive frames. The resize should occur prior to reinterlacing the stream.

It's ConvertFPS that smears (ChangeFPS only duplicates or deletes framesI get confused between them. GL is using ConvertFPS.

There's also one more obvious problem with your method - by resizing to 700x560, you're losing horizontal resolution, Analog TV has such poor horzontal resolution that it doesn't matter. If it has better vertical resolution, then it still has the edge. However, the edge has been whittled down to the point where the black mattes, small as they are, are no longer acceptable. It is pretty much a tossup. The only way to tell is to try it out.

Stephen

P.S. Moving the resize up to before SeparateFields is the only important remaining issue.

[davidhorman]

Analog TV has such poor horzontal resolution that it doesn't matter. If it has better vertical resolution, then it still has the edge.

I wasn't aware we were talking about analogue TV - I thought the source currently under discussion was an NTSC DVD. I'd still rather resize in one dimension only rather than two, especially when we're only talking about a possible 0.6% improvement in vertical resolution (and if you're that desperate, I think there's a way of squeezing another marginal improvement over native AviSynth resizing - I just haven't worked out how to implement it yet, and it's only really of academic interest).

David

[525/60]

I thought the source currently under discussion was an NTSC DVD.Yes, that is the source, but the target is arguably not the freshly burned PAL DVD, but the TV it will be viewed on.

Stephen

[GrofLuigi]

Me again. :)

For all practical purposes, I've settled with the method in post #2. Works well and close enough for everything and recommend it to everyone.

But, as I said I was thinking 'in general', the 'theoretical solution' that would follow my line of thinking (in terms of keeping the largest active rectangle, while mimicking the behaviour of DVD players) would be:


mpeg2source(...)

resize (640,480) # not needed, just to show that it would happen on a NTSC player
bob ()
resize (720, 576) # resize with same aspect ratio - enlarge the same rectangle
addborders (24,0,24,0) # need to get it to PAL displayed size...
resize (720, 576) # ...and prepare it for DVD encoding

changefps ()
SeparateFields ()
SelectEvery (4, 0, 3)
Weave ()

But I doubt I'll ever use this script. Just theoretical! If I ever touch this topic again, it'll be with circle in paint program passed through this script. :)

And thank you all for your answers.

GL

[davidhorman]

resize (720, 576) # resize with same aspect ratio - enlarge the same rectangle
addborders (24,0,24,0) # need to get it to PAL displayed size...
resize (720, 576) # ...and prepare it for DVD encoding

Eh... not that I wish to flog a dead thread, but what you'll end up with is a picture with the wrong aspect ratio (slightly too thin), a black border on the left and right (approx 14.5 viewable pixels, 22.5 overall, on each side*), and lost horizontal definition.

*and this border will be bigger if, as is the case with some DVDs, the edge of the film frame is visible in the overscan area.

David

[GrofLuigi]

resize (720, 576) # resize with same aspect ratio - enlarge the same rectangle
addborders (24,0,24,0) # need to get it to PAL displayed size...
resize (720, 576) # ...and prepare it for DVD encoding

Eh... not that I wish to flog a dead thread, but what you'll end up with is a picture with the wrong aspect ratio (slightly too thin), a black border on the left and right (approx 14.5 viewable pixels, 22.5 overall, on each side*), and lost horizontal definition.

*and this border will be bigger if, as is the case with some DVDs, the edge of the film frame is visible in the overscan area.

David

Yes, as I said, only theoretical and not practical for practical use. (can I say that?) :)

In practice (other encodings), I always try to do AddBorders of MOD16 and sacrifice few pixels here and there for the sake of easing the encoder's task.

Also, in general, I never take account of overscan. For starters, currently viewing video on oooold Commodore 1084 (amiga) monitor - no overscan, sharp picture and precise(?) colour. Downside? Small - only 13 inch.

GL