Where is the middle of the frame?

farss wrote on 11/22/2008, 1:56 PM
I was watching this video about changes to PAR in CS4. Kind of relevant to all of us as maybe we too have been getting the numbers wrong. I really don't agree with some of the conclusions about cropping off anything outside action safe as there's no fixed definition of Action Safe outside of film and even then....

All of that got me back to an old issue. Where is the middle of the damn frame. I can divide two numbers by two and you'd think that'd be the answer but it's not so easy. Play the result back on the average CRT TV or monitor and the middle isn't in the middle. Not a big issue until you have something at the edge of the frame like a border and then it really sticks out.

Whenever I've captured analog tapes I've also noticed that the side bars are not symetric and yet they are when played back on an analog TV, curious. It seems like the true centre of the frame is a few pixels to the right of the geometric centre of the frame, well at least in analog land. I can see how this problem was created when the DV specs were written, maybe we've just got to live with it and take care not to create things that show it up. Offsetting the centre of the frame to compensate seems to produce the opposite problem on other playback devices (PCs) so there's no simple answer that I can find.

Bob.

Comments

johnmeyer wrote on 11/22/2008, 5:19 PM
It's nice to know that Vegas has been doing it correctly all these years. According to the video you linked to the correct number which Adobe apparently just discovered is 10/11 = 0.909090... instead of 0.9000 that they have been using. I thought it was funny that they decided to round this off for their presentation to simply 0.91, so perhaps they still don't have it right :)

As for the middle of the frame, that's one I have never thought of or had any need to know. Since both PAL and NTSC are an even number of frames (720) as is HD (1920) the middle is going to be between two pixels. You need an odd number of pixels in order for one pixel to land precisely in the middle.

I don't know whether this mathematical fact is at the core of what you are seeing or if it is something else.

As for the analog capture offset vs. how the input displays, I expect that might have something to do with the delay line effect at the analog level before the capture actually happens, but that is purely a guess, and probably not a very good one at that.

Chienworks wrote on 11/22/2008, 5:24 PM
"It seems like the true centre of the frame is a few pixels to the right of the geometric centre of the frame, well at least in analog land."

Yep, i see this regularly. In fact, it's slightly different on each TV/monitor, and can change depending on the channel i tune to, the brightness of the scene, how long the TV/monitor has been on, the room temperature, the temperature of my cup of tea, which drawer i left the lucky rabbit's foot in, etc.

I found it best to simply give up thinking about it.
farss wrote on 11/22/2008, 6:27 PM
"I found it best to simply give up thinking about it. "

Good advice.

JM:
The error in their PAR isn't too hard to deal with or just ignore, that AE thinks that the NTSC frame rate is 30.00 could be a bigger problem.

Bob.
Chienworks wrote on 11/22/2008, 7:26 PM
The 3D animation software i use most often has two frame rate settings: 15.0 and 30.0. Neither of these is very useful and always caused me grief when trying to generate frame accurate timing.

Early on though i discovered that it could export frame sequences as TARGA images, and Vegas could import these sequences as conglomerate events. I set the timing in the animation software based on absolute frames, not on minutes & seconds. That way Vegas assigns the correct 29.97002997... to the clip when imported and all is fine.
johnmeyer wrote on 11/22/2008, 10:38 PM
The error in their PAR isn't too hard to deal with or just ignore, that AE thinks that the NTSC frame rate is 30.00 could be a bigger problemWow, that's unbelievable. What planet have they been living on? Having said that, as a guy who started in the computer industry and then went into publishing, we did a lot of things that made sense from our perspective (computers) that didn't make sense to our customers (people who'd spent their life around printing presses), so the same thing is probably true for the AE people as well.
megabit wrote on 11/23/2008, 1:07 AM
I'm not sure if this is relevant to your question here, but interestingly, cropping the HD frame into the sizes Robert W. advices before converting to Widescreen PAL leaves a very tiny (like 1-2 pixel wide) edge exposed, i.e. something (don't know what, as it is visible not just with a multi-track project ) is peeping through along the right edge.

I guess moving the middle of the frame to the right by 1-2 pixels would cover this leaking.

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

TLF wrote on 11/23/2008, 8:59 AM
The "sidebars" are unequal in analogue video...

Yes, that's right, and when you understand how analogue video signals are composed you'll understand why the middle of the picture isn't where you expect it to be.

I'm not going to give you a detailed explantion, but not all the lines in a television broadcast carry picture information, and a single line of the television signal isn't composed entirely of picture information.

Some of the line/lines carry signal information that tell the television decoder where the line ends/where the field ends.

Those sidebars you see are the 'front porch' and 'back porch' which are part of the line blanking. They are unequal in length.

When you calculate the centre of the picture, you are calculating the centre of the picture based on the entire length of the line/field, not the length of the picture carrying part of the line/field.

Have a look here http://electronics.howstuffworks.com/tv9.htm for more information.