How do i upscale PAL

[HansensUniverse]

I've been Googling for hours and i don't understand how every forum and site refer Pal 720 x 576 as 4:3 when it's clearly 5:4 aspect ratio, i want to upscale and deinterlace my footage in avsynth without stretching or distorting it, wouldn't it be correct to upscale my footage to 1280 x 1024 for HD and then edit and export it in an editing program as regular HD and have it keep the aspect ratio, i feel like no matter where i go forums make it complicated, no one gives a straight answer, assuming my pixels are square i don't see how it could possible be scaled in any other dimension without altering it's original dimension, god why couldn't there just have been one world standard instead of al of these billions of different pixel and display ratios causing confusion.

Why do i see 720 x 756 listed as 4:3 everywhere? It makes no sense at all, i have the impression that people don't seem to care at all for keeping their true aspect ratio, right now i am just utterly confused as to how to proceed...

I did a test run and i do think the deinterlaced footage looks a bit stretched vertically, even being it original format size, do i need to convert it to 1280 x 960 in avisynth to get it right?

[Sharc]

May be confusing for newbies, yes. But there are few strong standards like PAL, NTSC, DVD , Blu-ray with standard Display apect ratios of 4:3 or 16:9. Why the heck do users always want to convert, upscale etc. etc. if one world standard should be good enough?

[HansensUniverse]

Yeah but what is the correct way to upscale my footage? What dimensions do i use? 1280 x 960 to get 4:3??? from my understanding once the footage is interlaced assuming square pixels one should convert to using the 4:3 aspect ratio for Pal since that's what the targeted viewing aspect ratio is (DV) (DVD), i just want to have it confirmed by someone who know for sure.

[Sharc]

If your PAL 720x576 source is from a 4:3 DVD -> resize to 1280x960 for example, or 768x576 to avoid vertical resizing
If your PAL 720x576 source is from a 16:9 DVD -> resize to 1280x720 for example, or 1024x576 to avoid vertical resizing

Keep in mind that if your source is interlaced you have to deinterlace before vertical resizing, otherwise you mess the field structure up.

Or upload a sample.

[HansensUniverse]

It's from VHS

[DB83]

It can be confusing. If you have mpeg2, a dvd source or DV.avi then you have 720*576 which have a 4:3 DAR flag to display that 720*576 as 768*576 which is now perfect 4:3Other 720*576 sources will report as 5:4If you must upscale you an choose practically any size you desire. But there are caveats. Your source is interlaced and if you crop anything you must de-interlace before resizing.Yes. 1280*960 is valid 4:3 but so is 1440*1080 which can save any ferther scaling in your player/tv

[Sharc]

It's from VHS

With small black borders left and right? Interlaced? 4:3? If so, bob-deinterlace, crop the left/right borders off (8pixels each) and resize to 1024x768, for example, or 768x576 to avoid vertical resizing and deinterlacing.

Or upload a sample.

Bed time now ......

[Cornucopia]

If 720x576 is showing up as 5:4 display aspect ratio, the player app (or your settings) is doing something wrong.
Do NOT assume your pixels are square. PAL 720x576 (and NTSC for that matter) *ALWAYS* uses non-square pixel (aka sample) aspect ratios. IOW, 5 tall rectangles side by side should NOT look the same as 5 squares of the same height side by side.

SD PAL (and NTSC) can *ONLY* be 4:3 (most common) or 16:9.

And if you cannot deinterlace ahead of time (prior to resizing), or use an interlace-aware resizer, best to avoid resizing vertically altogether.
Sharc's size suggestions are a good place to start.


Scott

[hello_hello]

HansensUniverse,
Given you're using Avisynth, try CropResize. If you follow the link there's pictures showing how to use it.

5:4 is the storage aspect ratio or resolution. Your capture is anamorphic so it has to be resized to the correct display aspect ratio (or dimensions) on playback. Or in your case, while upscaling.

The purpose of CropResize is to crop and resize while preventing aspect error, although it's calculations are based on the input display aspect ratio you tell it to use. A VHS capture should have a 15:11 display aspect ratio. It's slightly wider than 4:3 as only 704 pixels of the width should contribute to a 4:3 aspect ratio. The extra 8 pixels each side are probably black or crud.

This is an example for resizing 4:3 PAL to non-anamorphic dimensions (square pixels). Let's assume you need to crop 8 pixels from the left, 10 from the right and 4 from both the top and bottom to remove all the crud (of course cropping is optional). The first two numbers are the output width and height. If you specify both, the function will crop more picture if necessary to prevent distortion when it resizes, so it's possible to specify only one and zero for the other, which the script will then calculate for you.

CropResize(768,0, 8,4,-10,-4, InDAR=15.0/11.0)

If you want an output that's exactly 4:3, specify any exact 4:3 dimensions and the script will crop extra picture if necessary to make it 4:3 before resizing (based on the specified cropping below, it'd only need to crop a few extra pixels for 4:3).

CropResize(960,720, 8,4,-10,-4, InDAR=15.0/11.0)

Personally I wouldn't upscale unless there's a need to, but if you do need to, I'd consider converting the colors to the HD standard, although for VHS it probably won't make a noticeable difference.

CropResize(960,720, 8,4,-10,-4, InDAR=15.0/11.0, ColorMode="601-709")

If you're mixing the VHS content with 16:9 content, you can also upscale to your desired 16:9 resolution while adding borders to the sides. When adding borders, the script generally won't have to crop much extra picture, if any, in order to resize without aspect error. To add borders you must specify both an output width and height, and Info=true will tell you what CropResize is doing.

CropResize(1920,1080, 8,4,-10,-4, InDAR=15.0/11.0, ColorMode="601-709", Borders=true, Info=true)

Of course you need to de-interlace before CropResize in the script. How are you de-interlacing? With QTGMC?

Oh, and if you think the correct display aspect ratio for the capture is 4:3 rather than 15:11, use 4.0/3.0 for the InDAR instead.

CropResize(1920,1080, 8,4,-10,-4, InDAR=4.0/3.0, ColorMode="601-709", Borders=true)

[dellsam34]

Yes as hello_hello mentioned your VHS footage is only about 704x576, De-interlace first, crop to 704x576 and resize to 1440x1080 for a perfect 4:3 square pixel, resizing from 720x576 will not give you an accurate 4:3 aspect ratio.

[HansensUniverse]

HansensUniverse,
Given you're using Avisynth, try CropResize. If you follow the link there's pictures showing how to use it.

5:4 is the storage aspect ratio or resolution. Your capture is anamorphic so it has to be resized to the correct display aspect ratio (or dimensions) on playback. Or in your case, while upscaling.

The purpose of CropResize is to crop and resize while preventing aspect error, although it's calculations are based on the input display aspect ratio you tell it to use. A VHS capture should have a 15:11 display aspect ratio. It's slightly wider than 4:3 as only 704 pixels of the width should contribute to a 4:3 aspect ratio. The extra 8 pixels each side are probably black or crud.

This is an example for resizing 4:3 PAL to non-anamorphic dimensions (square pixels). Let's assume you need to crop 8 pixels from the left, 10 from the right and 4 from both the top and bottom to remove all the crud (of course cropping is optional). The first two numbers are the output width and height. If you specify both, the function will crop more picture if necessary to prevent distortion when it resizes, so it's possible to specify only one and zero for the other, which the script will then calculate for you.

CropResize(768,0, 8,4,-10,-4, InDAR=15.0/11.0)

If you want an output that's exactly 4:3, specify any exact 4:3 dimensions and the script will crop extra picture if necessary to make it 4:3 before resizing (based on the specified cropping below, it'd only need to crop a few extra pixels for 4:3).

CropResize(960,720, 8,4,-10,-4, InDAR=15.0/11.0)

Personally I wouldn't upscale unless there's a need to, but if you do need to, I'd consider converting the colors to the HD standard, although for VHS it probably won't make a noticeable difference.

CropResize(960,720, 8,4,-10,-4, InDAR=15.0/11.0, ColorMode="601-709")

If you're mixing the VHS content with 16:9 content, you can also upscale to your desired 16:9 resolution while adding borders to the sides. When adding borders, the script generally won't have to crop much extra picture, if any, in order to resize without aspect error. To add borders you must specify both an output width and height, and Info=true will tell you what CropResize is doing.

CropResize(1920,1080, 8,4,-10,-4, InDAR=15.0/11.0, ColorMode="601-709", Borders=true, Info=true)

Of course you need to de-interlace before CropResize in the script. How are you de-interlacing? With QTGMC?

Oh, and if you think the correct display aspect ratio for the capture is 4:3 rather than 15:11, use 4.0/3.0 for the InDAR instead.

CropResize(1920,1080, 8,4,-10,-4, InDAR=4.0/3.0, ColorMode="601-709", Borders=true)

I wish to upscale to 1440 x 1080, overkill but that's what i want to go for, the black borders don't bother me as they are minimal, so skipping cropping, all i do i just take a 4:3 dimension and resize it? Right? I will convert to the HD color mode thx.

[Sharc]

I wish to upscale to 1440 x 1080, overkill but that's what i want to go for, the black borders don't bother me as they are minimal, so skipping cropping, all i do i just take a 4:3 dimension and resize it? Right? I will convert to the HD color mode thx.

As has been said: If you resize vertically from 576 to 1080 you must deinterlace your interlaced video before upscaling unless you are using an "interlace aware" upscaler or your tool does it automatically (assuming your source is interlaced of course).
Note that if you don't crop the small black 8 pixels borders left and right and just upscale to 1440x1080 your picture will be slightly horizontally squeezed by 2.3% (if this should matter to your eyes, it's up to you).

[jagabo]

I wish to upscale to 1440 x 1080, overkill but that's what i want to go for, the black borders don't bother me as they are minimal, so skipping cropping, all i do i just take a 4:3 dimension and resize it? Right? I will convert to the HD color mode thx.

In an ITU rec.601 PAL video capture (virtually all PAL capture devices follow this standard) the 4:3 image is in a ~702x576 portion of the 720x576 frame. So if you want very accurate upscaling you should crop to 702x576 then upscale to 1440x1080. As was pointed out, if you upscale the full 720x576 frame to 1440x1080 the aspect ratio will be about 2 percent off.

Confusion arises because the DVD spec says the full 720x576 frame constitutes the 4:3 picture. So DVD players will upscale directly from 720x576 to 1440x1080 (then add pillarbox bars to fill out the 1920 pixel wide frame). Commercial DVDs made from analog PAL video tape are usually captured via the ITU spec at 720x576 and written to DVD without compensating for the fact that the 4:3 picture is really in a 702x576 portion of that frame. Nobody in the industry cares.

704x576 (the frame sizes others have used in this discussion) is supported by DVD and is a nice number for MPEG 2 encoding (which works internally on 32x32 blocks). It's only about 0.2 percent off of the true ~702x576 and is usually considered "close enough" for calculating aspect ratios. Actually, 702 isn't perfectly accurate either -- it's the closest even integer to the true value which I don't remember.

[Skiller]

Actually, 702 isn't perfectly accurate either -- it's the closest even integer to the true value which I don't remember.

For PAL 702 is actually exact: 13.5 MHz * 52 µs = 702 (no rounding at all).


But really, 704 is good enough. I use 704 for calculations and resizing because it spits out much more practical numbers.

[hello_hello]

I wish to upscale to 1440 x 1080, overkill but that's what i want to go for, the black borders don't bother me as they are minimal, so skipping cropping, all i do i just take a 4:3 dimension and resize it? Right? I will convert to the HD color mode thx.

If you go with a 4:3 display aspect ratio for the entire 720 x 576 resolution, then 1440 x 1080 is right.

If you go with a 15:11 display aspect ratio instead, which is likely to be very close to correct, then it's
1080 * 15 / 11 = 1472.72
and 1472 x 1080 would be a more accurate resize.
If you want 1440 x 1080 and accurate resizing, crop the width to 704 before you upscale.

If you go with the likely to be even more accurate DAR jagabo mentioned, where 702 x 576 makes up the 4:3 aspect ratio, you need to crop to 702 x 576 before upscaling to 1440 x 1080.

Or don't crop and the accurate resizing would be.....

576 * 4 / 3 = 768
768 / 702 = 1.094 (pixel/sample aspect ratio)
1.094 * 720 = 787.69
787.69 / 576 = 1.367 (display aspect ratio using the whole 720 width)
1080 * 1.367 = 1476.92

So the slightly more accurate resize would be 1476 x 1080.
1472 x 1080 and 1476 x 1080 are close enough to each other not to matter, but you'll obviously see some difference comparing them to 1440 x 1080 (without cropping).

If you need a plugin for the color conversion, ColorMatrix is easy enough to use.
ColorMatrix(mode="Rec.601->Rec.709", clamp=0)
http://avisynth.nl/index.php/ColorMatrix

Although I can't imagine going to the trouble of upscaling to HD and not cropping the video cleanly before resizing, as there's often half lines and/or noise at the top and bottom I'd get rid of too. Given you can crop while you resize with Avisynth's resizers though, and you at least know how much to crop from the sides to resize to 4:3 properly now.....

Avisynth's resizers can crop any amount. They're not restricted to mod2 cropping like Crop().

Spline36Resize(1440,1080, 8,0,-8,0) --- 704 x 576 to 1440 x 1080
Spline36Resize(1440,1080, 9,0,-9,0) --- 702 x 576 to 1440 x 1080

Although to crop a little more cleanly, I'd probably do the second cropping this way.

Crop(8,0,-8,0)
Spline36Resize(1440,1080, 1,0,-1,0)
or even
CropResize(1440,1080, InSAR=768.0/702.0) --- it'll crop to a 4:3 DAR before upscaling for you.

PS. If you're interested, someone recently created a thread on their upscaling experience with this type of source.
NTSC.... but their method would be much the same for PAL.
NTSC VHS summary 6: Hybrid for Conversions, Deinterlacing, Upscaling to MP4

[Skiller]

Now I know this is getting super-duper finicky and probably is overkill to anyone just trying to get stuff done, but while we are at it , regarding 702 being more accurate than 704 you guys should consider the following as well: there are two half scan lines added during digitization (first half of the top most line and the second half of the very last line). This is because the digital capture window needs to be rectangular. Analog PAL has 575 lines of image, not 576. So if you use a width of 702 you would also have to crop off one line.

If we use this ratio (702/575) and extrapolate this to 576 lines we get: 576 * (702/575) ≈ 703.22 – which is closer to 704 than 702.

This is also why I prefer to use 704 ever since I learned that these two half lines should be considered.

[HansensUniverse]

Now I know this is getting super-duper finicky and probably is overkill to anyone just trying to get stuff done, but while we are at it , regarding 702 being more accurate than 704 you guys should consider the following as well: there are two half scan lines added during digitization (first half of the top most line and the second half of the very last line). This is because the digital capture window needs to be rectangular. Analog PAL has 575 lines of image, not 576. So if you use a width of 702 you would also have to crop off one line.

If we use this ratio (702/575) and extrapolate this to 576 lines we get: 576 * (702/575) ≈ 703.22 – which is closer to 704 than 702.

This is also why I prefer to use 704 ever since I learned that these two half lines should be considered.

So basically: Crop(8,0,-8,0)
Spline36Resize(1440,1080, 1,1,-1,0)?

[dellsam34]

DVD has actually a legal resolution of 704x576 for PAL/SECAM and 704x480 for all NTSC variants, I haven't seen any mention to 702 being an official standard, But in practice the junk surrounding the frame is never the exact number, it varies from tape format to another and from a standard to another, But when I crop I always base my calculations on 704. It seems to be the most accurate, I even did a circle test in one of the threads to demonstrate it a while back.

[Sharc]

So basically: Crop(8,0,-8,0)
Spline36Resize(1440,1080, 1,1,-1,0)?

QTGMC() #or a deinterlacer of your choice for deinterlacing before vertical resizing of interlaced VHS footage
Crop(8,0,-8,-8) #also crop the bottom VHS head switching noise, assumed to be 8 pixels here
AddBorders(0,4,0,4) #pad and center to 704x576
Spline36Resize(1440,1080)  #upscale and convert to square pixels, 4:3

or upload a sample of your source to collect more (academic) comments.

[HansensUniverse]

So basically: Crop(8,0,-8,0)
Spline36Resize(1440,1080, 1,1,-1,0)?

QTGMC() #or a deinterlacer of your choice for deinterlacing before vertical resizing of interlaced VHS footage
Crop(8,0,-8,-8) #also crop the bottom VHS head switching noise, assumed to be 8 pixels here
AddBorders(0,4,0,4) #pad and center to 704x576
Spline36Resize(1440,1080)  #upscale and convert to square pixels, 4:3

or upload a sample of your source to collect more (academic) comments.

I did this which worked the best for my footage.

Crop(8,7,-8,-7)
AddBorders(0,7,0,7)
Spline36Resize(1440,1080, 1,0,-1,0)

This way the top and lower black bars are equal.

[hello_hello]

Personally, I never add borders (although when combining video with different DARs sometimes it can't be avoided), but the wider the DAR, the more the video fills a 16:9 display. Adding back top and bottom borders to make it 4:3 again does the opposite of that.

If there's a total of 14 pixels that need cropping from the height and you increase it by 3.

Crop(8,8,-8,-8)
Spline36Resize(1488,1080, 0,0,0,-1)

It's like being given an extra 24 pixels each side for free, and if it helps you feel any better about it not being exactly 4:3, it's only a couple of pixels off the Academy ratio of 1.375.

Anyway, as how much you actually need to crop is still a secret, you might want to have a play with Yoda's Resize Calculator.
In order to use the 702 x 576 = 4:3 DAR, you need to select PAL 4:3 as the input, check the custom DAR option and use 160:117 as the custom DAR.
160 / 117 = 1.367521. It's an exact representation of the DAR I calculated in my last post. To use 15:11 as the source DAR, you can select mpeg4 from the drop down PAR list.

The output dimensions turn red when you upscale, but it's just to let you know. Nothing to worry about. And using Mod4 for the resizing dimensions it fine.
And of course you can crop less from the sides if there's not much to crop there, rather than crop more from the height.


[Attachment 63166 - Click to enlarge]

[hello_hello]

This is also why I prefer to use 704 ever since I learned that these two half lines should be considered.

I also recall reading somewhere (probably Wikipedia) that a SMPTE square pixel isn't actually square, but it has a 767:768 aspect ratio. Know anything about that one?

I'd also like to understand this.
Wikipedia says the exact PAL digital PAR (that nobody uses) is 59:54.
https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Digital_video_processing
At some stage I discovered if you take the "almost exact ITU" PAL PARs from this list,
https://forum.doom9.org/showthread.php?p=1058927#post1058927
and multiply them by 767/768, you end up with the exact digital PARs mentioned on Wikipedia. For example:

128/117 * 767/768 = 59:54

It only works for the PAL "almost exact ITU" PARs in the list though, not NTSC. I don't know why.

By the way, I just noticed Wikipedia says the exact width is 702.915254 for PAL 4:3, but I'll have to think about that one after I visit the real world for a bit.

[Sharc]

....Wikipedia says the exact PAL digital PAR (that nobody uses) is 59:54.... .

Hmmm, how can you say that "nobody" is using this?
- Open a video in VirtualDub2, right click into the picture. What values do you find under AspectRatio?
- Run AvsPmod. Tools-> Resize calculator. Click the ... under Pixel aspect ratio. What values are listed there?
- See the table in https://www.afterdawn.com/glossary/term.cfm/pixel_aspect_ratio
The "nobodys" seem to be quite a few

At some stage I discovered if you take the "almost exact ITU" PAL PARs from this list,
https://forum.doom9.org/showthread.php?p=1058927#post1058927
and multiply them by 767/768, you end up with the exact digital PARs mentioned on Wikipedia. For example:

128/117 * 767/768 = 59:54

It only works for the PAL "almost exact ITU" PARs in the list though, not NTSC. I don't know why.

As I understand it, the original luma sampling rate for producing square pixels has been defined as
12 3/11 MHz for NTSC (defined by whom and rationale I don't know)
14.75 MHz for PAL (defined by whom and rationale I don't know)

The luma sampling rate for digital video has then been standardized to 13.5 MHz, same for NTSC and PAL, leading to non-square PixelAspectRatios like
12 3/11 : 13.5 = 10:11 for NTSC
14.75 : 13.5 = 59:54 for PAL
Something more here:
https://lurkertech.com/lg/video-systems/sd-pixelaspect-derivation.html

To find the "truth and nothing but the truth" between 702 and 704 for analog transfers one would have to trace and study in depth the full global history of the development from analog to digital video through all standardization bodies, understand the (right or wrong) assumptions, conflicting views, misunderstandings, agreements for (international) standardization, "best" compromises etc., and last but not least practical implementation aspects (the legacy mod 16 is just one of these), .... and eventually build up our own "truth".

Oh well, so far I felt pretty comfortable with the 704 pixels and 12:11 PAR for 4:3 PAL, for the sake of simplicity or lazyness

[hello_hello]

....Wikipedia says the exact PAL digital PAR (that nobody uses) is 59:54.... .

Hmmm, how can you say that "nobody" is using this?
- Open a video in VirtualDub2, right click into the picture. What values do you find under AspectRatio?
- Run AvsPmod. Tools-> Resize calculator. Click the ... under Pixel aspect ratio. What values are listed there?
- See the table in https://www.afterdawn.com/glossary/term.cfm/pixel_aspect_ratio
The "nobodys" seem to be quite a few

Oh well, so far I felt pretty comfortable with the 704 pixels and 12:11 PAR for 4:3 PAL, for the sake of simplicity or lazyness

Yeah, I generalized too much, but I was referring to a similar thing.
59:94 should be the SAR when sampling analogue PAL, but aside from converting analogue to digital, 12:11 is the standard, and as you do, 12:11 is often assumed for sources that began life as analogue too.

The main reason I use 12:11 is as a by-product of thinking in terms of DAR rather than SAR, because like 4:3 and 16:9, there's only two mpeg4 DARs for both PAL and NTSC... 15:11 and 20:11.
I almost always resize to square pixel dimensions when re-encoding anyway, so all I need to remember is the two DARs and generally don't need to think about the SAR, which is a good thing because my memory is terrible. Although I suspect 59:54 might have made it all the way into long term memory while I was typing this post. I'll know tomorrow.

[Skiller]

I also recall reading somewhere (probably Wikipedia) that a SMPTE square pixel isn't actually square, but it has a 767:768 aspect ratio. Know anything about that one?

Yes, as Sharc said these industry square pixel formats use a different base sampling rate to archive the higher pixel-per-line count to make a 768x576 frame (instead of resizing the 13.5 MHz originated frame to square pixels in the digital domain as we would). AFAIK this format was mostly used in CCTV systems.

For PAL 14.75 MHz was standardized for this. However, as I'm going to proof in the next paragraph, that sampling rate only does produce a perfect PAR 1:1 768x576 frame if the sampled line length was 52.06780 µs (instead of 52 µs). This slightly longer line sampling compensates for the two half lines.
But if the usual standard of 52 µs was used instead, the PAR would change from 1:1 to 768:767.

52.06780 / 52 = 768:767

By the way, I just noticed Wikipedia says the exact width is 702.915254 for PAL 4:3

It seems this is to take the half lines into account by adding some slight horizontal padding to balance out the vertical padding of the half lines (to keep the resulting frame at 576 lines, rather than 575). It is needed in conjuction with PAR 59:54 or 14.75 MHz sampling rate to produce a 768x576 PAR 1:1 frame, which makes sense I think. See:

702.915254 * 59:54 = 768
14.75 MHz * 52.06780 µs = 768


Conclusion: the difference between 52.06780 µs and 52 comes from 52.06780 being optimized to spit out perfect square pixels in conjuction with a base sampling rate of 14.75 MHz while keeping the frame's line count at a nice 576 (taking half lines into account), while 52 µs is the actual active image.




59:54
This PAR seems to be derived from the above mentioned industry square pixel format.
As Sharc mentioned 14.75 / 13.5 = 59:54
Again, 14.75 MHz * 52.06780 µs = 768
Makes sense I think!



128:117
This PAR is based on 13.5 MHz * 52 µs = 702 pixels, but it does not account for the two half lines at all and assumes that analog PAL has 576 active picture lines.

576 * 4:3 / (13.5 MHz * 52 µs) = 128:117



1150:1053
This PAR is like 128:117 but it does take the half lines into account (i. e. active PAL = 702x575). It is almost literally the same as 59:54 but with a more practical, straightforward approach that doesn't bother with the industry square pixel 14.75 MHz and 52.06780 µs stuff.

It is derived like this:
575 * 4:3 / (13.5 MHz * 52 µs) = 1150:1053





My personal conclusion:

128:117 is flawed and should not be used.
1150:1053 and 59:54 are equally exact but 12:11 is the sane one to use.

[Sharc]

Thanks. Something to bookmark.

[hello_hello]

Skiller,
thanks for the info. I'll bookmark this one too.