"PAL 16:9" aspect ratio is not accurate

Get answers to your questions about color grading, editing and finishing with DaVinci Resolve.
  • Author
  • Message
Offline

markhimsley

  • Posts: 47
  • Joined: Sun Oct 21, 2018 9:40 am
  • Location: London, UK.
  • Real Name: Mark Himsley

"PAL 16:9" aspect ratio is not accurate

PostSat Nov 14, 2020 9:36 pm

The "PAL 16:9" aspect ratio ignores the fact that "PAL 16:9" is the centre 702 active pixels in a 720 pixel line.

When I put "PAL 16:9" archive into a square pixel timeline I have to transform the media to zoom the X (horizontal) to 1.026 in order to get the aspect ratio 100% correct.

This BBC web page had lots of information, until we culled old web pages in early 2011, so here's a link to the way-back-machine:

http://replay.waybackmachine.org/201008 ... size.shtml

The Adobe web page describes how they got it wrong all the way up before After Effects CS4

http://help.adobe.com/en_US/AfterEffect ... 7f3aa.html

This page also describes the difference between Adobe After Effects CS3 and CS4

http://www.mikeafford.com/blog/2009/03/ ... s4-vs-cs3/

I can provide BlackMagicDesign with calculations and sample media if you need it.

Please can you make the "PAL" and "NTSC" aspect ratios accurate.

Thanks.
--
Mark Himsley

ATEM Mini
DaVinci Resolve Studio
Intensity Pro 4K Ubuntu 18.04.4 LTS Intel Core i7-2600 CPU + NVIDIA GeForce GTX 1070 Ti
UltraStudio 3D macOS 10.15 Catalina
Offline

Andrew Kolakowski

  • Posts: 6842
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: "PAL 16:9" aspect ratio is not accurate

PostSun Nov 15, 2020 12:05 am

Did BBC actually test behaviour on modern TVs?
As far as their values may be correct based on 'original' standard I found them not working on modern TVs.
I had to switch back to "digital" approach with 720 active lines. Another reason was also fact that 2 clients also complained that their circle logo were distorted :D

BBC also removed their article fairly quickly.
If you want to use BBC approach better to test it on your TV :)
I have big doubt it's actually correct approach these days.
Offline

RCModelReviews

  • Posts: 734
  • Joined: Wed Jun 06, 2018 1:39 am
  • Real Name: Bruce Simpson

Re: "PAL 16:9" aspect ratio is not accurate

PostSun Nov 15, 2020 1:34 am

Yes, old CRT-based TV sets had "overscan" which meant that the edges of the image were not visible. Modern LCD/OLED panels do not need that overscan so can display the full raster. Hence, all 720 x 625 pixels are effectively visible on a modern TV whereas both the edges and some of the top/bottom were lost to overscan before.
Resolve 15 Studio, Fusion 9 Studio
CPU: i7 8700, OS: Windows 10 (1709) 32GB RAM, GPU: GTX1060/6
I'm refugee from Sony Vegas slicing video for my YouTube channels.
Offline

markhimsley

  • Posts: 47
  • Joined: Sun Oct 21, 2018 9:40 am
  • Location: London, UK.
  • Real Name: Mark Himsley

Re: "PAL 16:9" aspect ratio is not accurate

PostSun Nov 15, 2020 3:04 pm

Yes, the BBC does still check what TVs do.
Yes, some TVs are broken.
You might have clients who do not respect the old standards - that's fine.
The BBC took down its SD production guidelines after 5 years - in what scale is that "fairly Quickly"?.

I am a subject matter expert in SD to HD conversion. Honestly, I deal with a lot of SD - there is still a lot of SD production in regional TV and there is a lot of archive to deal with. I do a lot of SD to HD and HD to SD conversions, and I have to get the round-trip conversions right. My peers in other departments all agree. All the SD I deal with is treated as 702 active pixels in a line.

As I posted, many other companies have corrected their software. Shouldn't BlackMagicDesign at least offer the correct aspect ratio? Some hardware manufacturers have a dedicated switch for "SD Analogue line length" to switch them into 702 pixel line mode - that would be good a good start.
--
Mark Himsley

ATEM Mini
DaVinci Resolve Studio
Intensity Pro 4K Ubuntu 18.04.4 LTS Intel Core i7-2600 CPU + NVIDIA GeForce GTX 1070 Ti
UltraStudio 3D macOS 10.15 Catalina
Offline

Andrew Kolakowski

  • Posts: 6842
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: "PAL 16:9" aspect ratio is not accurate

PostSun Nov 15, 2020 6:49 pm

I tested few TVs (Pioneer, Sony, Samsung) and all were "broken". Only TV which worked properly with BBC approach was old Sony CRT TV, which is expected.
I would like to see this "some" number. Is it 10% broken TVs or 10% behaving correctly as per old standard?
702 is very bad number as it's not mod 16. Some people use 704 which is better choice (for the price of tiny distortion).
5 years? I thought it was few months.

It has nothing to do with clients, but TV manufactures as this is only medium which uses "analogue" or "digital" approach. All other display devices are rather digital. What may matter is how your treat your old archives, so when you do conversion your aspect is preserved properly. Problem is that probably 30% or more SD main masters have already broken aspect and there is no easy way to know what is the correct one. Another reality check is that many deliveries are done with clean edges and quite often you distort image anyway as otherwise it would have to loose too much useful data. Whole 720 vs. 702 active pixels problem may be least important in this whole chain of possible compromises.
Option in Resolve would be useful.
Offline

markhimsley

  • Posts: 47
  • Joined: Sun Oct 21, 2018 9:40 am
  • Location: London, UK.
  • Real Name: Mark Himsley

Re: "PAL 16:9" aspect ratio is not accurate

PostSun Nov 22, 2020 11:01 am

I thought I'd make a drawing: hopefully someone from BlackMagic Design could comment.

Compare the 720x576 ("PAL") 4:3 SD (Testcard-J) with the 720x576 ("PAL") 16:9 SD (Testcard-W) and with the 1920x1080 16:9 (Testcard-HD).

Note that the picture area of both the 720x576 ("PAL") 4:3 SD (Testcard-J) and the 720x576 ("PAL") 16:9 SD (Testcard-W) extends past the 4:3 and 16:9 lines.

This is because the 'active' picture (up to the chevron points) is the centre 702 pixels of the whole 720 pixel SD video like. The 'active' area is 4:3 or 16:9, the whole picture is wider than 4:3 or 16:9.

When converting from SD video into HD video the edges past the 4:3 or 16:9 lines must be cropped away. Only the centre 702 pixels of the 720 pixel SD video line must be used.

When converting from HD video into SD video the edges past the 4:3 or 16:9 lines must be added back. The HD video must fill the centre 720 pixels of the 720 pixel SD video line.

Testcard-J_W_HD.jpg
Testcard-J_W_HD.jpg (931.3 KiB) Viewed 732 times
--
Mark Himsley

ATEM Mini
DaVinci Resolve Studio
Intensity Pro 4K Ubuntu 18.04.4 LTS Intel Core i7-2600 CPU + NVIDIA GeForce GTX 1070 Ti
UltraStudio 3D macOS 10.15 Catalina
Offline

Steve Fishwick

  • Posts: 156
  • Joined: Wed Mar 11, 2015 11:35 am

Re: "PAL 16:9" aspect ratio is not accurate

PostSun Nov 22, 2020 12:08 pm

What previous commentators are telling you is correct. Every single modern NLE will handle SD Pal in the same way, from analogue digitized, and some digital sources too, I know Avid does - i.e pixel for pixel. These standards you are referring to are for CRT under scanned monitors (And rasters that incorporated VITC and accounted for tube/CCD deficiencies within the criterion 720x576) and at the time the BBC article was current (2010) they were still quite a few around and the BBC was mandated to ensure all domestic screens could exhibit broadcasts correctly.

Even digital SD formats from broadcast cameras such as DSR570 can exhibit side banding and every NLE will capture the full raster VITC, warts and all. And with legacy formats, because of that, you will more than likely have to rescan and crop, I have such a case now. You may have to 'de-squeeze' for digital but no current SD display/delivery standard, I know of, is 702 x 576.
Offline

markhimsley

  • Posts: 47
  • Joined: Sun Oct 21, 2018 9:40 am
  • Location: London, UK.
  • Real Name: Mark Himsley

Re: "PAL 16:9" aspect ratio is not accurate

PostSun Nov 22, 2020 5:30 pm

Oh for goodnes sake. Are you trying to shrink away from the problem?
  • I have SD archive
  • SD active picture is shorter than the a full line
  • I want to incorporate SD archive into an HD timeline for broadcast
  • When scaling SD to HD my NLE must scale the active picture and ignore the line length
Premier Pro gets the aspect ratio of SD media right.
Quantel gets the aspect ratio of SD media right.
FCP gets the aspect ratio of SD media right.
DaVinci Resolve fails to get the aspect ratio of SD media right.

I think we all deserve BlackMagic to correct that problem.
--
Mark Himsley

ATEM Mini
DaVinci Resolve Studio
Intensity Pro 4K Ubuntu 18.04.4 LTS Intel Core i7-2600 CPU + NVIDIA GeForce GTX 1070 Ti
UltraStudio 3D macOS 10.15 Catalina
Offline

Steve Fishwick

  • Posts: 156
  • Joined: Wed Mar 11, 2015 11:35 am

Re: "PAL 16:9" aspect ratio is not accurate

PostSun Nov 22, 2020 6:05 pm

Let me try and be clearer: In 625i analogue times, all domestic monitors showed an under scanned picture, both vertically and horizontally, the vertical included VITC at the top and Teletext and other signal at the bottom, and because of this under scan also the sides were cut-off too. Therefore it stands to reason if you stretch 702 pixel to 720 pixels only in the horizontal, you will change the aspect ratio. You have to zoom in on 702 x 561 to maintain that aspect ratio, and that will approximate what the original video would have looked like on a normal CRT telly. I do not see this in Avid or Resolve, because I zoom into the intended under scan, with SD 16:9 material, not stretch it one way only.
Offline

markhimsley

  • Posts: 47
  • Joined: Sun Oct 21, 2018 9:40 am
  • Location: London, UK.
  • Real Name: Mark Himsley

Re: "PAL 16:9" aspect ratio is not accurate

PostSun Nov 22, 2020 9:38 pm

Let me make it clear: I am not talking about 625 line analogue video. I am not talking about CRTs. I do not care about Vertical Interval Time Code on analog lines 19 & 21. I do not care about Teletext. I do not care about front porches, back porches, sync pulses, colour bursts, horizontal blanking or vertical blanking.

I am talking about digitised SD video. The 16:9 portion of SD video is 702 pixels by 576 lines, which is held in middle pf a 720 pixel long line. Feel free to read ITU-R BT.601-7 TABLE 4 and ITU-R BT.470-6. These are facts.

You have not managed to bring any facts to this discussion. You have only amplified the confusion.

I repeat - the active (16:9 or 4:3) portion of SD video is 702 pixels by 576 lines.

Premier Pro knows this.
Quantel knows this.
FCP knows this.
DaVinci Resolve does not know this, and therefore the aspect ratio of SD media when used in non-SD timelines in DaVinci Resolve is wrong.
--
Mark Himsley

ATEM Mini
DaVinci Resolve Studio
Intensity Pro 4K Ubuntu 18.04.4 LTS Intel Core i7-2600 CPU + NVIDIA GeForce GTX 1070 Ti
UltraStudio 3D macOS 10.15 Catalina
Offline

Peter Cave

  • Posts: 2168
  • Joined: Thu Aug 23, 2012 6:45 am
  • Location: Melbourne, Australia

Re: "PAL 16:9" aspect ratio is not accurate

PostMon Nov 23, 2020 12:28 am

The PAL 16:9 aspect ratio setting is accurate on my system for SD, HD and UHD timelines.

PAL 720 x 576 is a non-square pixel format that equates to 1024 x 576 when displayed.
Standard PAL square pixel dimensions are 768 x 576. This is equivalent to 720 x 576 non-square pixels. The overscan allowance is not really relevant as it is only a display device issue, not an aspect issue.

All the Adobe Photoshop presets for PAL video are still incorrect and display circles as ellipses when imported into Resolve.
Resolve 16.2.6
Mac OSX 10.14.6, Hackintosh i7 8700 32GB RAM, Radeon RX 580 8GB
Decklink Studio 2, FSI LM1770 Monitor
Offline

markhimsley

  • Posts: 47
  • Joined: Sun Oct 21, 2018 9:40 am
  • Location: London, UK.
  • Real Name: Mark Himsley

Re: "PAL 16:9" aspect ratio is not accurate

PostMon Nov 23, 2020 9:55 am

Peter Cave wrote:PAL 720 x 576 is a non-square pixel format that equates to 1024 x 576 when displayed.

It is quite astounding the confusion that is spread about "PAL" SD video. Please, go and read ITU-R BT.601-7 and ITU-R BT.470-6.
  • BT.470 says - in "PAL" SD video a line is 64 micro-seconds.
  • BT.601 says - "PAL" SD video is sampled at 13.5MHz making a 64 micro-second line 864 samples
  • BT.470 says - in "PAL" SD video a line has a blanking interval of 12 micro-seconds
  • That makes the line blanking 864 ÷ 64 * 12 = 162 samples.
  • That makes the "active line" 864 - 162 = 702 samples.
  • BT.601 says - "digital active line" in "PAL" SD video is 720 samples.
  • BT.470 says - in "PAL" SD back porch - datum to active video - is 10.5 micro-seconds, which is 864 ÷ 64 * 10.5 =~ 142 samples (to 3 significant figures).
  • BT.601 says - "digital active line" in "PAL" SD video starts 131 samples after the datum
  • That makes the "digital active line" start 9 samples before "active line"
In summary, the "active line" - the previously calculated 702 samples of picture information - sits in the middle of the "digital active line" of 720, with 9 samples before and 9 samples after the "active line".

The non-square pixel aspect ratio of "PAL" SD media means that the 16:9 "active line" 702 pixels would be scaled to 1024x576 for square pixels. But the 720 "digital active line" pixels must be scaled to 1050x576 to preserve the aspect ratio.

I know it's really hard when someone comes and says your understanding is wrong, but please stop spreading confusion. The specifications tell the facts.

These calculations are agreed between broadcasters. They are used by most NLE manufacturers. They are used by video server manufacturers. They are used by broadcast format conversion manufacturers.

I create the transcode profiles for material you watch on UK broadcast TV every day. They are confirmed by the absolute authorities in the industry. I'm not just making this up.

I only want DaVinci Resolve to improve, and to be adopted by broadcasters. That requires that editors using Resolve must have the option of sticking to the published standards.
--
Mark Himsley

ATEM Mini
DaVinci Resolve Studio
Intensity Pro 4K Ubuntu 18.04.4 LTS Intel Core i7-2600 CPU + NVIDIA GeForce GTX 1070 Ti
UltraStudio 3D macOS 10.15 Catalina
Offline

Peter Chamberlain

Blackmagic Design

  • Posts: 8945
  • Joined: Wed Aug 22, 2012 7:08 am

Re: "PAL 16:9" aspect ratio is not accurate

PostMon Nov 23, 2020 10:27 am

For clarification, the height is correct, but Resolve shows too many pixels either side of the SD 702 pixel width for the PAL 16:9 aspect ratio?

BTW, have you tried the v17 DNN de-interlace and SuperScale to UHD?
DaVinci Resolve Product Manager
Offline

markhimsley

  • Posts: 47
  • Joined: Sun Oct 21, 2018 9:40 am
  • Location: London, UK.
  • Real Name: Mark Himsley

Re: "PAL 16:9" aspect ratio is not accurate

PostMon Nov 23, 2020 11:42 am

Peter Chamberlain wrote:the height is correct, but Resolve shows too many pixels either side of the SD 702 pixel width for the PAL 16:9 aspect ratio?


Yes - this is correct Peter. The Pixel Aspect Ratio of "PAL 16:9" source media needs to make the pixels slightly wider so that the centre 702 fit across a non-SD timeline and the 9 pixels on each edge of the source media are off the edge of the timeline (when in "Scale full frame with crop" mismatched resolution mode). The height is correct.

A similar change to the Pixel Aspect Ratio of "PAL" (the 4:3 version) should also me made.

I believe the pixel aspect ratios should be:
  • "PAL 16:9" 1:1.4587 (currently 1:1.4222)
  • "PAL" 1:1.0940 (currently 1:1.0667)
I'm sorry I don't have the figures for "NTSC" source media at hand (and there are arguments in the NTSC standards documents regarding the length of the active line).

Even the timeline viewer for a "720 x 576 PAL" and "720 x 576 PAL 16:9" timeline should be slightly wider than 4:3 and 16:9 because of the PAR of media - but that really is nit-picking. ;-)
Last edited by markhimsley on Mon Nov 23, 2020 2:26 pm, edited 1 time in total.
--
Mark Himsley

ATEM Mini
DaVinci Resolve Studio
Intensity Pro 4K Ubuntu 18.04.4 LTS Intel Core i7-2600 CPU + NVIDIA GeForce GTX 1070 Ti
UltraStudio 3D macOS 10.15 Catalina
Offline

Andrew Kolakowski

  • Posts: 6842
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: "PAL 16:9" aspect ratio is not accurate

PostMon Nov 23, 2020 12:11 pm

When this is fixed at the same time MOV headers should be fixed as well for SD.
With those new active lines there is correct set of headers going to MOV as well
Now, clean aperture is set to 9 pixels each side as it should, but pixel aspect is wrong based on 720 math if I remember well.

Another issue- this 702 based math should be a setting as a lot of SD masters (specially those done from HD) will use 720 based math and these needs current math to keep correct aspect. If someone knows what to do then can switch, if not then 1 needs to be default setting.

HD scaled to SD should be resized to 702 and 9 pixels each side should be filled with black (some use 704+ 8 pixels on sides).
Problem is that about no one is doing it this way so there is huge amount of SD masters scale directly to 720 (so now they need to be also processed "back" same way).
Last edited by Andrew Kolakowski on Tue Nov 24, 2020 11:07 am, edited 1 time in total.
Offline

Jan Kels

  • Posts: 6
  • Joined: Mon Dec 04, 2017 4:21 pm

Re: "PAL 16:9" aspect ratio is not accurate

PostMon Nov 23, 2020 12:25 pm

another useless quirk with PAL resolution and Resolve.

When choosing 720x576 you can't have square pixels. So it is either squished or squeeze. Resolve forces you into either of the two options and greys the normal pixel aspect ratios out.

my solution is to go for a quad PAL resolution: 1440x1152. It is stupid but it also gives me better bitrates on youtube.


if you are wondering what kinda camera has PAL and square pixels: a thermal camera with analog out does.
Offline

markhimsley

  • Posts: 47
  • Joined: Sun Oct 21, 2018 9:40 am
  • Location: London, UK.
  • Real Name: Mark Himsley

Re: "PAL 16:9" aspect ratio is not accurate

PostMon Nov 23, 2020 2:23 pm

Jan Kels wrote:When choosing 720x576 you can't have square pixels

Yes, on a timeline there are "special" resolutions where Resolve thinks it knows best.
On a source clip, you can set the aspect ratio to any aspect ratio from the pre-defined list.
--
Mark Himsley

ATEM Mini
DaVinci Resolve Studio
Intensity Pro 4K Ubuntu 18.04.4 LTS Intel Core i7-2600 CPU + NVIDIA GeForce GTX 1070 Ti
UltraStudio 3D macOS 10.15 Catalina
Offline

Peter Cave

  • Posts: 2168
  • Joined: Thu Aug 23, 2012 6:45 am
  • Location: Melbourne, Australia

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 1:48 am

Here in Australia the active line length is defined as 720 pixels (non-square), not 702 pixels. I can provide the documentation if interested.
Resolve 16.2.6
Mac OSX 10.14.6, Hackintosh i7 8700 32GB RAM, Radeon RX 580 8GB
Decklink Studio 2, FSI LM1770 Monitor
Offline

RikshaDriver

  • Posts: 268
  • Joined: Sun Aug 12, 2018 10:08 am
  • Location: Oz, Gizzard of
  • Real Name: Asim Siddiqui

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 2:14 am

2.2.3 All SDTV programs produced using modern digital equipment shall have narrow horizontal
blanking, ie. active vision shall be 720 horizontal pixels wide. Legacy programs with 702 pixel wide
vision (wide horizontal blanking) will also be acceptable. A single program shall have consistent
blanking throughout.
2.2.4 All SDTV widescreen programs shall have 720 pixels x 576 lines active picture area.


https://www.abc.net.au/tv/independent/d ... g_2011.pdf
Specs: i386, 16M RAM, 150MB IDE HDD, Sound Blaster 16, Win NT 3.1

My commercial Resolve Looks, Plugins & Transforms: https://xtremestuff.net/store
My Open Source Resolve transforms: https://github.com/xtremestuff
Offline

Peter Cave

  • Posts: 2168
  • Joined: Thu Aug 23, 2012 6:45 am
  • Location: Melbourne, Australia

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 4:17 am

markhimsley wrote:
Jan Kels wrote:When choosing 720x576 you can't have square pixels

Yes, on a timeline there are "special" resolutions where Resolve thinks it knows best.
On a source clip, you can set the aspect ratio to any aspect ratio from the pre-defined list.


The reason you can't have square pixels in a 720 x 576 frame is because the square pixel 4:3 display equivalent raster is 768 x 576. This requires 720 non-square pixels to be mapped to the equivalent 768 display size, hence the non-square pixel format.
Resolve 16.2.6
Mac OSX 10.14.6, Hackintosh i7 8700 32GB RAM, Radeon RX 580 8GB
Decklink Studio 2, FSI LM1770 Monitor
Offline

Peter Cave

  • Posts: 2168
  • Joined: Thu Aug 23, 2012 6:45 am
  • Location: Melbourne, Australia

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 4:23 am

markhimsley wrote:Let me make it clear: I am not talking about 625 line analogue video. I am not talking about CRTs. I do not care about Vertical Interval Time Code on analog lines 19 & 21. I do not care about Teletext. I do not care about front porches, back porches, sync pulses, colour bursts, horizontal blanking or vertical blanking.

I am talking about digitised SD video. The 16:9 portion of SD video is 702 pixels by 576 lines, which is held in middle pf a 720 pixel long line. Feel free to read ITU-R BT.601-7 TABLE 4 and ITU-R BT.470-6. These are facts.

You have not managed to bring any facts to this discussion. You have only amplified the confusion.

I repeat - the active (16:9 or 4:3) portion of SD video is 702 pixels by 576 lines.

Premier Pro knows this.
Quantel knows this.
FCP knows this.
DaVinci Resolve does not know this, and therefore the aspect ratio of SD media when used in non-SD timelines in DaVinci Resolve is wrong.


Your referenced document ITU-R BT.601-7 TABLE 3 indicates 720 pixels per active line.
Resolve 16.2.6
Mac OSX 10.14.6, Hackintosh i7 8700 32GB RAM, Radeon RX 580 8GB
Decklink Studio 2, FSI LM1770 Monitor
Offline

Steve Fishwick

  • Posts: 156
  • Joined: Wed Mar 11, 2015 11:35 am

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 7:48 am

Peter Cave wrote:
Your referenced document ITU-R BT.601-7 TABLE 3 indicates 720 pixels per active line.


Peter, although I think Mark overstates the popular demand and urgency for this, he is absolutely right and is referring to the PAR of SD 16:9 non-square pixels and it appears that even Avid got it wrong and still I think do:

https://community.avid.com/forums/t/79387.aspx

I had forgotten all this hullaballoo in the mists of time and I agree with Andrew if BMD do introduce a change to the timeline settings to accommodate this then I would hope it is an option not a fixed interpretation. All the DVcam and Digibeta footage I have appears to be true 720 x 576, all digital footage should be (was there ever analogue 16:9?). The only case use for legacy SD footage now should be archival (i.e within a documentary) or remastering older programmes, where this could be important. The DVcam edge borders I referred to only require me to creep in a couple of pixels or so, I am not changing the PAR, perhaps I should have been but I have not noticed any aspect ratio distortion.
Offline

markhimsley

  • Posts: 47
  • Joined: Sun Oct 21, 2018 9:40 am
  • Location: London, UK.
  • Real Name: Mark Himsley

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 8:26 am

Peter Cave wrote:ITU-R BT.601-7 TABLE 3 indicates 720 pixels per active line.

The words in ITU-R BT.601-7 TABLE 3 are "digital active line". Don't confuse that with the old 52 micro-second "active line" in analogue video, which defines the aspect ratio of the pixels in ITU-R BT.601-7.
--
Mark Himsley

ATEM Mini
DaVinci Resolve Studio
Intensity Pro 4K Ubuntu 18.04.4 LTS Intel Core i7-2600 CPU + NVIDIA GeForce GTX 1070 Ti
UltraStudio 3D macOS 10.15 Catalina
Offline

Steve Fishwick

  • Posts: 156
  • Joined: Wed Mar 11, 2015 11:35 am

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 8:42 am

Mark, do you know if Avid still gets this wrong too?
Offline

markhimsley

  • Posts: 47
  • Joined: Sun Oct 21, 2018 9:40 am
  • Location: London, UK.
  • Real Name: Mark Himsley

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 9:08 am

Steve Fishwick wrote:All the DVcam and Digibeta footage I have appears to be true 720 x 576

All professional SD sources I've have worked with and continue to work with - which range from ENG cameras, studio cameras, caption generators, still stores, ... - encode the scene with a pixel aspect ratio such that the centre 702 pixels and the 576 lines make up a 16:9 image.

It is a shame that ITU-R BT.601-7 did not explicitly define the pixel aspect ratios, instead just defining the number of pixels which correspond to a 64 micro-second time period and leaving the implementer to refer back to ITU-R BT.470-6 to calculate the PAR, as I have demonstrated.

I am not saying that modern SD video sources don't have picture in the 9 pixels on each edge. I'm just saying that in my experience of professional video sources, those 9 pixels on each edge of the picture are outside of the 16:9 aperture.

There are many decades of archive media encoded with that pixel aspect ratio. And it is still being created, transcoded, transmitted, and archived today. The BBC made those testcards J & W with chevrons pointing at the edge of the 4:3 and 16:9 aperture for a reason. They publicly distributed the SD digital production guidelines for a reason. I trained graphics creators for a reason. I create transcode profiles for a reason. And that reason is to preserve the shape of media.

Respecting and preserving the 16:9 aperture of SD media - those centre 702x576 pixels of the 720 pixel digital line - allows perfect round-tripping through SD and HD workflows of multiple professional broadcast manufacturers.
--
Mark Himsley

ATEM Mini
DaVinci Resolve Studio
Intensity Pro 4K Ubuntu 18.04.4 LTS Intel Core i7-2600 CPU + NVIDIA GeForce GTX 1070 Ti
UltraStudio 3D macOS 10.15 Catalina
Offline

markhimsley

  • Posts: 47
  • Joined: Sun Oct 21, 2018 9:40 am
  • Location: London, UK.
  • Real Name: Mark Himsley

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 9:48 am

Steve Fishwick wrote:Mark, do you know if Avid still gets this wrong too?

I'm sorry, I haven't used a MediaComposer for over 10 years. And the departments who I support do not use Avid, so I'm a bit out of the loop there. I can ask when there's another trade show (IBC 2021??)

I moved out of operations and into development in 2010. I've been able to ensure all the video scaling from our department is accurate, and when I've seen mistakes elsewhere I've been able to nudge the right people to "have a word" :-)

I know that about 5 years ago I had to complain about a supplier who was using Avid to create SD trails using HD assets - including channel logos. They had to be nudged to get the transform between SD and HD correct so that channel idents didn't move when mixing between their trails and local media.

I've looked back at some training manuals I wrote. In 2006 I wrote a manual for video editors using Avid MediaComposer, Quanel sQEdit, and Adobe Photoshop. That was all just SD working, but includes details of getting square pixel media - like user generated media, and graphics elements - into an SD environment. It includes all the numbers I've written about in this thread.

There were references to Avid's "CCIR, non-square" setting specifically understanding square pixel media
of 768x576 (4:3 square pixel SD), 788x576 (digital active line "4:3" square pixel SD), 1024x576 (16:9 square pixel SD) and 1050x576 (digital active line "16:9" square pixel SD) and Avid doing the right thing. So I would be surprised if Avid didn't have a setting somewhere to do the right thing with SD-HD transforms.
--
Mark Himsley

ATEM Mini
DaVinci Resolve Studio
Intensity Pro 4K Ubuntu 18.04.4 LTS Intel Core i7-2600 CPU + NVIDIA GeForce GTX 1070 Ti
UltraStudio 3D macOS 10.15 Catalina
Offline

Steve Fishwick

  • Posts: 156
  • Joined: Wed Mar 11, 2015 11:35 am

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 10:16 am

markhimsley wrote:All professional SD sources I've have worked with and continue to work with - which range from ENG cameras, studio cameras, caption generators, still stores, ... - encode the scene with a pixel aspect ratio such that the centre 702 pixels and the 576 lines make up a 16:9 image.


The link you provided no longer exists but it is indeed there ( :o) in the current delivery specs, so thanks:

https://www.dropbox.com/s/tgsgk5gligm7q ... e.pdf?dl=0

With Avid, for UK broadcast delivery, capturing over the year from Meridian AVR77 through to Adrenaline Symphony 1:1 MXF component/SDI we never altered the PAR within Avid for BetacamSP, DigiBeta or DVcam. And I never came across a QC fail because of it. So presumably Component/SDI capture should be correct and only file import, if it is in Avid too, is affected? All the Digibeta/DVcam archive I have, which is my own, was captured SDI.

Thanks for comments on Avid it would be good to know. Although I still online as well as offline I have not had a show with SD material in it for a long time but you've shown me that you need to read the full specs thoroughly, each and every time, regardless, so thanks once again.
Offline

Andrew Kolakowski

  • Posts: 6842
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 10:56 am

markhimsley wrote:
Steve Fishwick wrote:All the DVcam and Digibeta footage I have appears to be true 720 x 576

All professional SD sources I've have worked with and continue to work with - which range from ENG cameras, studio cameras, caption generators, still stores, ... - encode the scene with a pixel aspect ratio such that the centre 702 pixels and the 576 lines make up a 16:9 image.


Wow- you seems to live in perfect world :)
I've seen so much crap and variation that if I were to apply single rule I would solve nothing. We don't have to look far, look at other UK broadcasters.
Even if it's not always about 720 lines been filled in real world you are almost sure when they are filled then you need 720 lines approach not 702. In the same time when you see those few black pixels side bars (which quite often shift side to side- analogue imperfection) then it's most likely 702 based master. I can't do grabs, but trust me- out of 10 random you would have mixture of anything (quite often including broken aspect).
Offline

Steve Fishwick

  • Posts: 156
  • Joined: Wed Mar 11, 2015 11:35 am

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 11:08 am

I've just checked in Avid with an SD master and Mark is right, and Avid is still not right. When changing project format to HD, Colour bars that were imported are wrong with black bars either side. The DVcam appears wrong but PAR correct (?) in it but the graphics seem OK and a rostrum still with a circle in it correct PAR too. Avid now has Frameflex though that has infinite adjustment and seemingly the correct presets for non-square pixels - but like DR this is a source clip adjustment.
Offline

Andrew Kolakowski

  • Posts: 6842
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 11:16 am

Well- you either crop those 9 pixels a side or you scale with different PAR (and cut everything outside 4x3 proportions). One or another way in HD frame those 9 pixels each side should be gone as they are not active picture.
Same other way- scale HD to centred 702 and fill rest with black.

I still don't believe that most modern TVs treat SD based on 702 active lines.
Offline

Steve Fishwick

  • Posts: 156
  • Joined: Wed Mar 11, 2015 11:35 am

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 11:23 am

Andrew Kolakowski wrote:Well- you either crop those 9 pixels a side or you scale with different PAR. One or another way in HD frame those 9 pixels each side should be gone as they are not active picture.
Same other way- scale HD to centred 702 and fill rest with black.


What I'm saying is that the DVCam (captured as I recall with a combination of a DSR1500A with SDI board and DSR2000 as SDI, via Adrenaline, not firewire) PAR is correct, I can see that by flicking back and forth between SD and HD. The over scan is not. So yes scaling would be necessary. The imported Colour bars from Media Composer presets are the wrong PAR, it seems.
Offline

Steve Fishwick

  • Posts: 156
  • Joined: Wed Mar 11, 2015 11:35 am

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 11:40 am

Andrew Kolakowski wrote:I still don't believe that most modern TVs treat SD based on 702 active lines.


That's because you're unlikely to be watching an SD broadcast from an original source today. SD archive content could be imported into a HD/UHD programme incorrectly though, over which a modern TV would have no control.
Offline

Andrew Kolakowski

  • Posts: 6842
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 11:56 am

Yes, I understand this. This is exactly why I said you need both options as not a chance all SD masters are based on 702 lines. So many of them been already processed, made from HD etc. with 720 active lines math.
Offline

Steve Fishwick

  • Posts: 156
  • Joined: Wed Mar 11, 2015 11:35 am

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 12:04 pm

Totally agree and I said so. Incidentally that link to the BBC specs has been deleted :o I hope it wasn't me!

But all UK delivery specs are based on the DPP now, so here is what it says specifically:

1.1.3 Standard Definition
Where agreed by the broadcaster, legacy material delivered for UK SD TV transmission must be:

• 702 x 576 pixels in an aspect ratio of 16:9;
• 25 frames per second (50 fields) interlaced - known as 576i/25, top field first;
• colour sub-sampled at a ratio of 4:2:2;
• colour space – ITU-R BT.601.

The SD format is fully specified in ITU-R BT.601.

Note: SD video has a picture area with a minimum of 702 x 576 pixels, where the 702-pixel wide picture must be centred in the active 720-pixel wide line. The picture information may extend the full width of the 720-pixel wide line, providing the image shape is not distorted.


Which shows clearly that 702 is minimum and as long as Aspect ratio is not altered you can extend beyond it. I'm going to get a mug of cocoa now :)
Offline

Andrew Kolakowski

  • Posts: 6842
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 12:28 pm

This has been always in DPP (if I'm correct).
Problem is that in 99% cases when picture extends to 720 active lines it means it's distorted :)
It's even hard and convoluted to make correct 702 lines and then add "rest" picture to remaining 9 lines :)
Also- if you have an old analog footage then it doesn't have those "extra lines", so the only way to fill all 720 lines is to break aspect and stretch those 702 lines (or even less as edges are crap most times).

This statement in real world actually allows (encourage) to create SD masters with bad aspect.
Offline

Steve Fishwick

  • Posts: 156
  • Joined: Wed Mar 11, 2015 11:35 am

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 12:48 pm

Andrew Kolakowski wrote:This has been always in DPP (if I'm correct).
Problem is that in 99% cases when picture extends to 720 active lines it means it's distorted :)
It's even hard and convoluted to make correct 702 lines and then add "rest" picture to remaining 9 lines :)
Also- if you have an old analog footage then it doesn't have those "extra lines", so the only way to fill all 720 lines is to break aspect and stretch those 702 lines (or even less as edges are crap most times).

This statement in real world actually allows (encourage) to create SD masters with bad aspect.


No the DPP derived it's base specs from the national broadcasters, whom it represents, and were largely BBC specs that all broadcasters now share.

We have to distinguish between transmission standards and camera/graphic standards. All that the specs say are that, if there is an SD broadcast of an SD master it will be transmitted at 702 x 576 - picture information may extend beyond that up to 720 pixels (as long as the AR is correct) but the end viewer will not see those extra 9 pixels either side. So you would have to make sure all relevant image and graphics/titles/astons etc. are within that area including safe action.

There is nothing I can find that mandates how we incorporate legacy SD into HD/UHD timelines, apart from avoiding aspect ratio distortion. Therefore unless you absolutely must be faithful to how it was originally broadcast and removing unsightly black borders, there is nothing to stop you grabbing a few extra pixels if available, as far as I can see. HD/UHD are full raster standards.
Offline

Andrew Kolakowski

  • Posts: 6842
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 2:00 pm

Steve Fishwick wrote:
Andrew Kolakowski wrote:This has been always in DPP (if I'm correct).
Problem is that in 99% cases when picture extends to 720 active lines it means it's distorted :)
It's even hard and convoluted to make correct 702 lines and then add "rest" picture to remaining 9 lines :)
Also- if you have an old analog footage then it doesn't have those "extra lines", so the only way to fill all 720 lines is to break aspect and stretch those 702 lines (or even less as edges are crap most times).

This statement in real world actually allows (encourage) to create SD masters with bad aspect.


No the DPP derived it's base specs from the national broadcasters, whom it represents, and were largely BBC specs that all broadcasters now share.

We have to distinguish between transmission standards and camera/graphic standards. All that the specs say are that, if there is an SD broadcast of an SD master it will be transmitted at 702 x 576 - picture information may extend beyond that up to 720 pixels (as long as the AR is correct) but the end viewer will not see those extra 9 pixels either side. So you would have to make sure all relevant image and graphics/titles/astons etc. are within that area including safe action.

There is nothing I can find that mandates how we incorporate legacy SD into HD/UHD timelines, apart from avoiding aspect ratio distortion. Therefore unless you absolutely must be faithful to how it was originally broadcast and removing unsightly black borders, there is nothing to stop you grabbing a few extra pixels if available, as far as I can see. HD/UHD are full raster standards.


I would say it's was mostly ITV behind DPP, but don't know for sure. I like idea a lot, but not a fan of DPP standard itself ( neither original creators are now I think ).

You do what you want, but as you said you need to keep correct aspect for 702 area. Problem is that in practice (because you are allowed to fill 720) many SD masters have actually wrong aspect. If spec mandated 702 then this would made people start thinking about it and more likely use correct processing.
Offline

markhimsley

  • Posts: 47
  • Joined: Sun Oct 21, 2018 9:40 am
  • Location: London, UK.
  • Real Name: Mark Himsley

Re: "PAL 16:9" aspect ratio is not accurate

PostTue Nov 24, 2020 6:25 pm

Steve Fishwick wrote:• 702 x 576 pixels in an aspect ratio of 16:9;
• 25 frames per second (50 fields) interlaced - known as 576i/25, top field first;
• colour sub-sampled at a ratio of 4:2:2;
• colour space – ITU-R BT.601.

The SD format is fully specified in ITU-R BT.601.

Note: SD video has a picture area with a minimum of 702 x 576 pixels, where the 702-pixel wide picture must be centred in the active 720-pixel wide line. The picture information may extend the full width of the 720-pixel wide line, providing the image shape is not distorted.[/i]

Thanks Steve. I've had the DPP delivery standard around for so many years I didn't think to re-read it. It is very concise.
Channel 4 Sky BBC ITV

Oh - and the link to the Wayback machine is still working for me. Although the link to the Adobe web page describing how they got it wrong all the way up before After Effects CS4 ends in a 404.
--
Mark Himsley

ATEM Mini
DaVinci Resolve Studio
Intensity Pro 4K Ubuntu 18.04.4 LTS Intel Core i7-2600 CPU + NVIDIA GeForce GTX 1070 Ti
UltraStudio 3D macOS 10.15 Catalina

Return to DaVinci Resolve

Who is online

Users browsing this forum: Google [Bot], murdom and 92 guests