Merged Discussion of femr's video data analysis

They NEVER use the term '60fps' to refer to NTSC broadcast.
But then we're not talking about broadcast.

If people want to argue about whether a single interlaced NTSC frame contains 2 fields, let them go ahead. It does.

If people want to say I'm wrong/lying/misleading when I refer to video data with different terms in different contexts, my response has been seen many times.

It is not incorrect to refer to interlaced NTSC video data as 59.97fps.

So here in North America your fixation to refer to it that way is irrelevant and annoying.
It is a valid reference, regardless of location.

you should refer to 60-field-per-second video as '60i', but never 60fps.
Incorrect. 30i. 60fps is also valid.

That will help to make your use of terminology more appropriate, less exclusive to yourself, and far less annoying to everybody else.
I'm not overly concerned with demands to use someone elses view on how ambiguous terms should be applied.

I'll continue to use appropriate terms in appropriate contexts. I'll probably try and use ips more often, just to reduce the noise...unless someone incorrectly says that a reference is *wrong*.

I know you will :)
Correct.
 
But then we're not talking about broadcast.


It is not incorrect to refer to interlaced NTSC video data as 59.97fps.


It is a valid reference, regardless of location.

Nobody but you uses it. In North America NTSC is referred to as 30fps. See? I told you you were intransigent....for no good reason, you just seem to like doing things differently than everyone else, even if it makes no sense :)


Incorrect. 30i.

No. You are incorrect, sorry. NTSC is 60i, not 30i. Are you just behaving like this because you are an inveterate contrarian? It's silly.
The correct terms are 60i (60 interlaced fields per second) or 30fps (frames per second)


Since you are actually wrong, yes, you should correct the error. That's all there is to it, sir.
 
No. You are incorrect, sorry. NTSC is 60i, not 30i.
When specifically referring to fields, yes, you are correct.

60i fields per second
60 fps
30i frames per second
30 fps

Interlaced NTSC video can be referred to by all four.

Bearing in mind that the (i) suffix applies *interlaced* to the image rate metric, 60i is actually particularly illogical, as there are not 60 interlaced fields per second, as fields are not themselves interlaced. There are 30 interlaced frames per second.

As I've repeatedly said, it's a mix and match minefield, and arguing about it is pointless.

Are you just behaving like this because you are an inveterate contrarian?
See above.
 
When specifically referring to fields, yes, you are correct.

60i fields per second
60 fps
30i frames per second
30 fps

Interlaced NTSC video can be referred to by all four.

Bearing in mind that the (i) suffix applies *interlaced* to the image rate metric, 60i is actually particularly illogical, as there are not 60 interlaced fields per second, as fields are not themselves interlaced. There are 30 interlaced frames per second.

As I've repeatedly said, it's a mix and match minefield, and arguing about it is pointless.


See above.

Femr2 - it doesn't work that way. When you make an incorrect statement, and you are corrected, you don't give a mini-treatise which makes an excuse for you, and muddies the waters to make it appear as though it doesn't matter. I also don't really care if you don't like the terminology - it isn't up to you to decide what the industry uses. One thing I can assure you is that 30fps is not referred to as 30i, NTSC. That dog won't hunt.
If you could find just one video clip from CBS or NBC that was shot in 30i, I'd love to see it. That would only be 15fps. LOL. but go ahead, make my day, and try to find one. And please, just for giggles, try to find a US broadcaster who refers to their broadcast video as 30i.

I find your attitude rather hypocritical, for if it didn't matter, you wouldn't bother trying to 'correct' me and others in the first place.

You can't have it both ways, lecturing us on terminology and then blowing it off when you discover you're talking out of your hat. That's (as has been pointed out to you by others) a double-standard.

Nevermind your baffelgab, 60i and 30fps are the two technical terms which refer to one type of video: North American standard NTSC (Technically 29.97 frames per second). There is no need to cause confusion as you have done.

Capiche?
 
Last edited:
One thing I can assure you is that 30fps is not referred to as 30i, NTSC.
Oh yawn.

Simply google-fu for "30i ntsc"..

Use of 30i NTSC galore.

And please, just for giggles, try to find a US broadcaster who refers to their broadcast video as 30i.
Howsabout an IEEE1394 compatibility table for use with pro HD video editing...
http://pro-av.panasonic.net/en/sales_o/ieee1394/AJ-HD1400P_XpPro52.html

...or Telecommunications and data communications handbook...
http://books.google.co.uk/books?id=dO2wCCB7w9sC&pg=PA604&lpg=PA604&dq=ntsc+30i+-avid&source=bl&ots=OY-edXZ7nO&sig=sbCF5iByBtAyX2244ZtaNpcnSVQ&hl=en&ei=abG-TNTFG-a5jAeMyoHVBg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBMQ6AEwADgU#v=onepage&q=ntsc%2030i%20-avid&f=false

Different arenas use different terminology.

Howabout Broadcast Engineering magazine...
http://broadcastengineering.com/newsrooms/broadcasting_hd_sports_whole/
FOX uses widescreen 480@60p; CBS and NBC use interlaced 1920×1080@30i; ABC and ESPN prefer progressive scan 1280×720@60p

That work on the giggles front ?

NATO any good for you ?
STANAG 4609 DIGITAL MOTION IMAGERY STANDARD
http://www.google.co.uk/url?q=http://www.nato.int/structur/AC/224/standard/4609/4609_documents/STANAG_4609_Ed2.pdf&sa=U&ei=qb--TPrkAt-5jAeGgcW3Bg&ved=0CCAQFjADOB4&usg=AFQjCNHELXDMXpurWoP3W4PxTF5gbaMlXg
(Page 17) Scanned doc, so...
527446921.png



I find your attitude rather hypocritical, for if it didn't matter, you wouldn't bother trying to 'correct' me and others in the first place.
The point is that the terms are used in all manner of contexts. There's no definitive *right* way, no definitive *wrong* way.

As I've also said, I'll probably use ips just to keep the noise down.

You can't have it both ways, lecturing us on terminology
Who is lecturing you on terminology. I'm saying, have been saying, and will continue to be saying that the terms are all used in various ways, in various contexts.

North American standard NTSC (Technically 29.97 frames per second). There is no need to cause confusion as you have done.
Sigh.

Technically ~29.97 INTERLACED frames per second.

(That's not the same as ~29.97 progressive frames per second)

Tell me...

How would you differentiate between 30 INTERLACED frames per second, and 30 PROGRESSIVE frames per second ?

Do you think it might be an idea to suffix the 30 with either (i) or (p) ?
 
Last edited:
Posters, express your opinion about ae's suggestion that this post be moved.

If the majority vote is to move, I'll request that from the mods.


tom
I am not for moving it. It's not directly related to any conspiracy but the results are baseline data that is useful for both sides of the conspiracy discussion, as tfk already proved when using the WTC7 plots. The thread has already some conspiracy-related posts that don't belong into the science forum. The idea of starting a separate thread there sounds more appealing to me, but that doesn't depend on me, and I doubt I would notice anyway unless pointed from here.
 
This whole issue on the use of the term 'frame' is ludicrous and annoying.

Let's say I make a video this way.

I prepare a series of 704x480 pixel pictures which represent different instants of time separated 1/59.94 of a second from each other. I offset every other frame by 1 pixel and downscale all vertically (to 240 pixels). I put the result of this process together into a video file, without interlacing.

I think that noone will contend that it is perfectly correct to say that I have a 59.94 frames/s video. I'll call this video "video X".

Now I take the frames of this video and organize them like this: I take packs of two frames and construct one frame out of them, by taking one horizontal line from the first frame, then one horizontal line from the second frame, then one from the first frame again, then one from the second frame, etc. obtaining in each process an image of 704x480. I put all the images generated by this method together in a video file with a 29.97 frames/s frame rate.

The video generated this way has the characteristics of an interlaced NTSC video, with respect to frame organization and rate. As such, every frame has two fields; the frame rate is 29.97 frames/s or 59.94 fields/s.

Now I take every frame from this video and separate each image into two, by taking every even row of pixels into one image and every odd row into another. I organize the resulting images into a video with 59.94 images per second. If done correctly and losslessly, the resulting video can be byte-by-byte identical to video X.

So, who is to say that the pictures contained in this last video can't be called "frames" just as they could be called "frames" in video X itself, if both are identical? Does the knowledge that it was once part of an interlaced video make any difference?

As femr2 put it,

A field is only a field whilst it is part of an interlaced frame. Once it is separated from the frame, call it whatever you please...field, frame, image, picture. Context depends upon when you refer to the image, and your prior knowledge of it's original container.


Now it's true that the interlacing/deinterlacing process can introduce changes that need to be accounted for, but that's a separate discussion from this stupid frame/field semantic discussion nonsense. The sampling rate for the data is still 59.94 samples per second, whether they are called samples, images, pictures, frames, fields or whatever.
 
The sampling rate for the data is still 59.94 samples per second, whether they are called samples, images, pictures, frames, fields or whatever.

pgimeno,

The terms "field" and "frame" have very clear, specific, individual and incontrovertable meanings and usages and and they have them for a reason. That femr2 (and it would appear yourself) choose to have the same words have multiple meanings depending on wont and (it would seem) phase of the moon consigns meaningful discussion on the underlying subject matter to the tipper. femr2's insistence on trying to force the square word into the round hole casts further doubt on the value of anything else he/she has posted on the matter as the apparent inability (or unwillingness) to accept a commonly understood and accepted technical term on this most basic of concepts suggests that his/her arguments on matters more esoteric and open-to-interpretation is suspect.

I'll amend something I posted earlier:

Just keep calling don't call 1/59.94th of an NTSC second a field frame and I couldn't be bothered with you
Edited by Tricky: 
Edited for rule 12.
 
Last edited by a moderator:
One the subject of a possible move, I would support moving the thread (or parts of it) to SMT; there are a number of people whose input would be useful who don't frequent the CT section.
 
pgimeno said:
This whole issue on the use of the term 'frame' is ludicrous and annoying.
I quite agree. You're on the receiving end of the nonsense now though if you read fitzgibbon's latest post. Sorry 'bout tha'.

Edited by Tricky: 
Edited for response to modded post.
 
Last edited by a moderator:
BTW, there is only one person here, Tony Sz, (but lots of ill-informed truthers around the blogosphere) who has ever said anything about "expecting a building to exhibit a step function in acceleration".

[Tony said, and when questioned, emphasized, that the building went into "immediately free fall". Thereby asserting a step function in acceleration.]

Both NIST (1.75 seconds) and Chandler (0.75 seconds) have a slow onset acceleration before they report approximate "g".

This is a random free hand drawing of what would pass for real free fall acceleration for ~2.25 seconds.

picture.php


As noted, the blue line shows a rapid onset (~0.5 seconds) acceleration, with a fairly constant accel at "g" (-32 ft/sec^2), indicating no viscosity (i.e., "drag") effects.

The green line shows a slow onset (~2 seconds) acceleration, with an acceleration that drops to "g", and then shows a slowly decreasing acceleration as the object speeds up, typical of viscosity or drag effects.

Neither femr's nor my acceleration curves resemble these curves.

My conclusion is that Chandler's statement that the building (or, more correctly, the north wall) are "at free fall acceleration for 2 seconds" is not supported by the data.

My second conclusion is that the north wall of the building did undergo an acceleration that was NEAR "G" for a period of around 1 second. And that there evident dynamics in all the data (NIST's, Chandler's & femr's) that Chandler missed (ignored? suppressed?) by choosing to perform a linear fit to the velocity data.
 
My conclusion is that Chandler's statement that the building (or, more correctly, the north wall) are "at free fall acceleration for 2 seconds" is not supported by the data.
An odd focus, but... agreed.

I assume you would also conclude that the NIST *stage 2* texts are similarly erronious.

My second conclusion is that the north wall of the building did undergo an acceleration that was NEAR "G" for a period of around 1 second.
I think the 1 second metric could do with some refinement, and acceleration curves for additional points should be included before applying the behaviour of the NW corner trace to the entire North facade.

I agree that it's less than the 2.25s NIST and 2s Chandler values.

And that there evident dynamics in all the data (NIST's, Chandler's & femr's) that Chandler missed (ignored? suppressed?) by choosing to perform a linear fit to the velocity data.
I'm not sure either the NIST or Chandler data has enough resolution to make a definite call, but I agree the behaviour was missed.

Could you show me where NIST provided anything other than a linear fit... ?
155958691.jpg

(full report section...http://femr2.ucoz.com/_ph/7/563913536.png)

(Might have missed it, but only see a linear regression.)
 
Oh yawn.

Simply google-fu for "30i ntsc"..

Use of 30i NTSC galore.

Fine. You got me there:o I should have been more clear that I was referring to typical North American parlance as it relates to 2001 vintage North American footage.

We didn't use a lot of progressive-scan in those days, an era when HD was fairly new. Hence there wasn't a need to differentiate between progressive and interlaced video, as there is today.
Certainly if you are concerned with conversion between PAL and NTSC back in 2001 you would be making that distinction, but that isn't what we're doing in this case.
 
Fine. You got me there:o
It is not about *getting you*. If that is your apology for the latest raft of insult laden posts, then apology accepted.

I should have been more clear that I was referring to typical North American parlance as it relates to 2001 vintage North American footage.
You made your position clear in your posts, but I have no interest in wasting my time dredging them back up.

I will request a couple of things from you though...
If you could find just one video clip from CBS or NBC that was shot in 30i, I'd love to see it. That would only be 15fps. LOL. but go ahead, make my day, and try to find one.
Do you now accept that:

a) 99% of video clips from CBS or NBC (complying with NTSC) are validly referred to as having a 30i frame rate ? (More specifically 30i*1000/1001)

b) 30i frame per second video contains 60 ips, not 15.

We didn't use a lot of progressive-scan in those days, an era when HD was fairly new.
The use of the term 30i is not related to HD. Progressive video formats have been around for many years. The (i) is simply a frame rate suffix to denote that each frame is interlaced. It's not used consistently.
 
Last edited:
So...

Please explain, in intelligible detail, how you got this "±0.1 pixel accuracy" from NIST's statement that you quoted.

I thought you *understood* the NIST moire method Tom.

You really should not need this explained to you...


NIST basically determine horizontal motion of the NW edge of WTC 7 by determining the point along the NW edge that matches their criteria, namely that the pixel intensities either side of the NW edge pixel column are equal. An effect they can infer from what is known about moire.

The NIST metric basically states that 100 pixel vertical position change of that point equates to 1 pixel of horizontal movement.

100 +/- 10 pixel vertical accuracy directly translates to... 1 horizontal pixel +/- (10/100 pixels)...

+/- 0.1 pixels.



Do you understand ?
 
Last edited:
So...



I thought you *understood* the NIST moire method Tom.

You really should not need this explained to you...


NIST basically determine horizontal motion of the NW edge of WTC 7 by determining the point along the NW edge that matches their criteria, namely that the pixel intensities either side of the NW edge pixel column are equal. An effect they can infer from what is known about moire.

The NIST metric basically states that 100 pixel vertical position change of that point equates to 1 pixel of horizontal movement.

100 +/- 10 pixel vertical accuracy directly translates to... 1 horizontal pixel +/- (10/100 pixels)...

+/- 0.1 pixels.



Do you understand ?

Yeah, I do.

I understand that there isn't enough info in anything you've written down here to calculate NIST's resolution.

Which leads me to believe that you don't understand how the Moire technique works.

Care to try again?

Or do you want me to explain it ... only to have you subsequently claim "oh, of course I knew that."
 
Yeah, I do.
Given your following text, clearly not.

Remember, this +/- 0.1 pixel metric is not the final positional accuracy metric they state.

This is prior to combination with their scaling metric uncertainty.

I understand that there isn't enough info in anything you've written down here to calculate NIST's resolution.
See above.

Which leads me to believe that you don't understand how the Moire technique works.
Incorrect. I've even chucked a few lines of code together to test it, when I was looking at the low-level SE blob tests. It's really not difficult Tom.

Care to try again?
No need. I can use more and simpler words if that helps you.

Or do you want me to explain it ...
By all means...
 
Last edited:
For your delectation...
NIST NCSTAR 1-9, p683
C.1.4 Conversion of Magnitude from Vertical Pixels to Distance

The magnitude of the motion was estimated using the number of vertical pixels that equated to a single horizontal pixel and a conversion factor between horizontal pixels and actual distance.
The vertical motion of the marker point that equated to a single horizontal pixel width was determined by counting the number of vertical pixels between the studied marker point and the next point along the northeast edge of WTC 7 at which pixel values were equal on each side of the central dark column. The marker point used in the analysis was the intersection of intensities along pixel columns 517 and 519; the marker point one horizontal pixel to the left was the intersection of intensities along pixel columns 516 and 518. Where this marker was available and had not dropped off the top of the northeast edge, the difference between these two points one horizontal pixel apart was found to be 100 ± 10 vertical pixels.
The conversion factor between horizontal pixels and distance along the north face of WTC 7 was obtained by determining the width of this face in both horizontal pixels and in feet. Due to the camera location, points on the north face near the northwest edge were closer to the camera than points near the northeast edge. However, this distortion was small, since the width of the north face was much smaller than the distance of WTC 7 from the camera. The perspective view of the camera looking up at WTC 7 also introduced some error into the measurement of the number of pixels for the width, as did the uncertainty of a couple of pixels in the exact location of the edges defining the north face. Given these sources of error, an estimate for this video of the width of the north face of WTC was 301 ± 4 horizontal pixels.

Since the true dimension of the north face was 329 ft, the conversion factor was 1.09 ft ± 0.02 ft per horizontal pixel. Combining this with the equivalence of 100 ± 10 vertical pixels for each horizontal pixel gave the final conversion factor of 1.1 ft ± 0.1 ft (13 in. ± 1 in.) for each 100 pixels of vertical marker motion.
I've highlighted a few portions for this particular metric. Again, this is prior to combination with scaling metric.

I do not want to hear an "oh, of course I knew that." from you. Failing to track back to original posts is not an excuse...
tfk said:
femr2 said:
NIST said:
100 ± 10 vertical pixels for each horizontal pixel
This effectively translates to a +/- 0.1 pixel accuracy.
Please explain, in intelligible detail, how you got this "±0.1 pixel accuracy" from NIST's statement that you quoted.
 

Back
Top Bottom