Merged Discussion of femr's video data analysis

[tfk]

femr,

You do a fine job of cutting & pasting other people's work.

And a very poor job of explaining it. In this case, less than "poor job". More like "incompetent job".

Which, by virtue of its consistency, leads me to think that you don't understand it at all.

Allow me to explain.

And provide you with a VERY brief, simple example of a real error analysis.

The 100 ±10 vertical MOIRE PATTERN pixels / horizontal pixel is a scaling factor. It doesn't tell you the horizontal resolution.

The 1.1 ft/pixel +0.1 ft/pixel is similarly a scaling factor. It doesn't tell you the horizontal resolution either.

The key factor that one needs to know, in order to correctly determine the horizontal resolution, is their VERTICAL resolution of the moire pattern marker band that they are watching in the video.

Then you can convert this vertical resolution into horizontal resolution.
___

Now for a simple error analysis...

One that involves only 3 numbers (vertical resolution, vertical to horizontal scaling factor, horizontal pixels to horizontal feet scaling factor) with their errors.

And watch how fast the errors add up in the final result ...


Suppose NIST were only able to resolve the vertical light or dark band of the moire pattern with a (very poor) resolution of ±(100 ±10 vertical pixels), then their horizontal resolution would be:

±(100 ±10 vertical moire pattern pixels) x (1 horizontal pixel / 100 ± 10 vertical moire pattern pixels) = ±1.06 ±(0.16) horizontal pixel. Which gives you ±(1.06 ±.16 horizontal pixels) x (1.1 ±0.1 ft/horizontal pixel) = ±1.18 ± .26 ft.

THIS is how you do an error analysis. You account for each error at each step of each calculation.

And what you find out is that errors add up far faster than you ever imagine.
___

IF they were able to resolve the vertical moire pattern within a (better) ±(10 ±1 vertical moire pattern pixels), then they would be able to resolve a horizontal resolution of:

±(10 ±1 vertical moire pattern pixels) x (1 horizontal pixel / 100 ± 10 vertical moire pattern pixels) = 0.10 ±(0.02) horizontal pixels. Which gives you a dimensional tolerance of ±(0.10 ±0.02) x (1.1 ±0.1 ft/horizontal pixel) = 0.11 ± .03 ft.
___

Without knowing the vertical resolution of the moire pattern, you have zero idea of their horizontal resolution.

You can NOT get it from just the horizontal to vertical scaling factor.

___

This is exactly the error that I thought you were making. Which is why I asked you about it.

Allow me to paraphrase someone else on this topic: "You really should not need this explained to you, femr."

Please, patronize me again about how "you shouldn't have to explain this to me…"

Maybe Major Tom will add this to his list of your errors...?

 

[femr2]

it does not escape one's attention that you made zero attempt at any explanation for why your adamant, unequivocal assertions go thru these 180° reversals, of course...

It should also not escape anyones attention that whilst I indeed have little interest in derived velocity and acceleration metrics, that I have applied much time to responding to your (increasingly bizarre and disturbing) questions and observations on the topic throughout.

As I've said repeatedly, my use of the data is focussed upon relative movement timing, such as point (A) moves before point (B).

That kind of metric does not suffer from the noise amplification that derived metrics do, of course.

Your perceived reversals are either figments of your imagination or deliberate obfuscation.

The questions posted prior to your bizarre outburst are not going away...

 

[femr2]

The 100 ±10 vertical MOIRE PATTERN pixels / horizontal pixel is a scaling factor.

It is an inferred moire effect, via the equivalence of pixel intensities adjacent to the target pixel column.

It is indeed a scaling factor...between 90 and 110 vertical pixels of movement translates to one horizontal pixel.

By your own standards...

That vertical uncertainty applies to any vertical measurement.

A 50 pixel vertical movement, with the detail provided, still must have the base uncertainty applied... +/- 10 pixels.

Any vertical measurement still has uncertainty of +/- 10 pixels... +/-10% of that ol' 100 pixel base value.

This translates to +/- 0.1 pixel horizontal pixel uncertainty.

The key factor that one needs to know, in order to correctly determine the horizontal resolution, is their VERTICAL resolution of the moire pattern marker band that they are watching in the video.

All measurement of which is also subject to +/- 10 pixels uncertainty.

And watch how fast the errors add up in the final result ...

The conversion from pixels to real-world distances has not been touched at this point.

You account for each error at each step of each calculation.

Indeed.

Without knowing the vertical resolution of the moire pattern, you have zero idea of their horizontal resolution.

You can NOT get it from just the horizontal to vertical scaling factor.

You can get a minimum uncertainty from the base 100 pixel metric uncertainty.

You didn't ignore that by any chance ?

Perhaps you would like to show the calculations applied to...

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.

...to combine the NIST conversion factor (+/- 0.02 ft/pixel) with their equivalence of 100 ± 10 vertical pixels for each horizontal pixel...to arrive at their... final conversion factor of 1.1 ft ± 0.1 ft for each 100 pixels of vertical marker motion.

(You should end up with the same result of course)

 

[tfk]

Hmmm, let' see...

You now assert that it is untrue, and merely "a figment of my imagination", that over the course of the last 3 months …

1. you repeatedly told people, in no uncertain terms, that claiming NTSC video was 30 frames / second was wrong, wrong, wrong?

2. that, in this post above, you now say that NTSC is "60i fields per second" or "30i frames per second"?

3. you repeatedly told people that, according to NTSC specs, "sometimes 1 field = 1 frame"?

4. that, in contrast to what you've claimed, all of YOUR sources - as I cited in a previous post - say that "1 frame = 2 fields"?

All of that is "a figment of my imagination", femr?


I just want to be clear about this…

 

[tfk]

… words, words, words ...

You seem to be confused about the difference between a scaling factor & a measurement.

One thing that they have in common is that both of them have both dimensions & error bands.

100 ±10 vertical moire pattern pixels / 1 horizontal pixel is a scaling factor & it's error.

It is an inferred moire effect, via the equivalence of pixel intensities adjacent to the target pixel column.

Ahhh, an "inferred" moire effect … Why didn't you say so… LoL.

It is indeed a scaling factor...between 90 and 110 vertical pixels of movement translates to one horizontal pixel.

By your own standards...

That vertical uncertainty applies to any vertical measurement.

A 50 pixel vertical movement, with the detail provided, still must have the base uncertainty applied... +/- 10 pixels.

Any vertical measurement still has uncertainty of +/- 10 pixels... +/-10% of that ol' 100 pixel base value.

Ahhhh, so you're "stealing" the error band on the scaling factor, and claiming it is the RESOLUTION of their vertical moire interference pattern measurement.

Not nice to steal like that.

Only one problems: You're missing 2 numbers.

1. Now, you've left your scaling factor without an error band. (Not nice)
2. And you're missing an error band on your (now stolen) vertical resolution. (Not nice)


Nope. You're wrong. That's not how measurements work. Every measurement AND every scaling factor, needs it's own number and it's own error. Can't BOTH Rob Peter & forget to Pay Paul.

NIST means exactly what they say. The conversion factor from vertical moire pattern movement is 100 ±10 pixels / 1 horizontal pixel.

That "±10 pixels" is not the vertical resolution.

NIST explicitly states their vertical resolution (although without an error) as:

The vertical pixel position of the marker point on the vertical axis was higher for movement downward (indicating northwest corner motion toward the east). The red lines at each data point showed estimated uncertainties of ± 7 pixels.
-NCSTAR1-9 pg 683, vol 2 [pdf pg 345]

And your conclusion that NIST's comment that:

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.
-NCSTAR1-9 pg 684, vol 2 [pdf pg 346]

means that NIST is claiming a ±1" resolution is wrong, too.

Let's presume that NIST should have given a ±1 error to their ±7 pixel vertical resolution.

With an uncertainty of ±7 ±1 pixels vertical moire pattern pixels, (final) conversion factor of 1.1 ft ±0.1 ft / 100 vertical pixels = ±0.078 ± .018 ft (= ±0.94 ±0.22 inches).
___

The heart of the matter is that you were wrong. You MUST have the vertical resolution in order to know the horizontal resolution. You simply got lucky that ±7 pixel (real vertical resolution) was close to ±10 pixels (error on the scaling factor).

There is a term for someone who gets something close to the right answer by doing the wrong calculation with lucky numbers. It ain't complimentary.

And when you were wrong, you didn't (and don't) stop to look at things. Or say, "well, hold on, maybe I overlooked something."

You just start blowing smoke.
___

PS. I couldn't catch this in time to correct it in my previous post.

On the last post, I erroneously used the FINAL vertical moire pattern scaling factor (1.1 ±0.1 horizontal ft / 100 vertical pixels, instead of the correct horizontal pixel to horizontal feet scaling factor (1.09 ± 0.02 ft / horizontal pixel).

This would reduce the "IF conditions calcs" (i.e., 100 or 10 vertical moire pattern pixel resolution) and their errors slightly.

As shown here, NIST says that the right number is ±7 vertical pixels, with an unstated error.

 

[femr2]

1. you repeatedly told people, in no uncertain terms, that claiming NTSC video was 30 frames / second was wrong, wrong, wrong?

Incorrect.

2. that, in this post above, you now say that NTSC is "60i fields per second" or "30i frames per second"?

Correct. NTSC can be referred to as either. The 60i is in regular use, though it is illogical. See NATO scan below.

3. you repeatedly told people that, according to NTSC specs, "sometimes 1 field = 1 frame"?

Incorrect. What was at one point a field contained within a frame can indeed be referred to by many names at a latter point in time.

4. that, in contrast to what you've claimed, all of YOUR sources - as I cited in a previous post - say that "1 frame = 2 fields"?

An interlaced frame consists of 2 fields. I have never claimed anything *in contrast* to such.

All of that is "a figment of my imagination", femr?

Correct.

Here, again, is the NATO STANAG 4609 DIGITAL MOTION IMAGERY STANDARD document...
Download PDF
(Page 17) Scanned doc, so...

Please include specific quotes from myself if you pursue any of these claims.

 

[tfk]

... words, words, words ...

... smoke, smoke, smoke ...

 

[femr2]

You seem to be confused about the difference between a scaling factor & a measurement.

Incorrect. I'm applying, as I said your own standards.

I'd put it as +/- 0.0555 + measurement uncertainty myself, but I know you'd complain about that

100 ±10 vertical moire pattern pixels / 1 horizontal pixel is a scaling factor & it's error.

*moire pattern pixels* is not the right term, but other than that, correct.

Ahhh, an "inferred" moire effect … Why didn't you say so… LoL.

I did. They are not tracking a pixel step resulting from moire pattern, but an inferred property, again, the equivalence of pixel intensities adjacent to their target pixel column.

Ahhhh, so you're "stealing" the error band on the scaling factor, and claiming it is the RESOLUTION of their vertical moire interference pattern measurement.

As I said, I applied scaling factor uncertainty to all measurements.

That "±10 pixels" is not the vertical resolution.

Who said it was ?

NIST explicitly states their vertical resolution (although without an error) as:

Here's the full text...

The red lines at each data point showed estimated uncertainties of ± 7 pixels. This was a rough estimation, reflecting an inherent risk of error due to the brighter pixels to the right of pixel column 519 and darker pixels to the left of pixel column 517, as well as to the fluctuation of intensity levels along pixel columns 517 and 519. Despite this, the capability of this method to amplify sideways building vibrations was clear. With this near vertical orientation of the northwest edge of WTC 7 relative to the pixel columns, the marker point of equal intensity moved up and down by a total of more than a hundred pixels.

Which they have based upon what ? I imagine it is the noise variance.

And your conclusion that NIST's comment ... means that NIST is claiming a ±1" resolution is wrong, too.

Jebus. By quoting them, the *claim* is about the final conversion factor of 1.1 ft ± 0.1 ft (13 in. ± 1 in.) for each 100 pixels of vertical marker motion.

Let's presume that NIST

Let's not.

Why don't you show how NIST combined the metrics to arrive at their final conversion factor in...

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.

.

You MUST have the vertical resolution in order to know the horizontal resolution. You simply got lucky that ±7 pixel (real vertical resolution) was close to ±10 pixels (error on the scaling factor).

Where did you add them together ?

If I have misinterpreted your prior assertions that ALL uncertainty must be applied to each value at every step, then, hands up, the +/- 0.1 pixel value is not fully accurate.

That's fine, and will therefore also apply to viewpoints upon my own data. Great.

As indicated above, I'd put scaling factor (by my standards) at +/- 0.0555 pixels per...(I'll add the +/7 value to that in a bit)

However, I will draw your attention to what you are saying...in relation to the values provided by NIST.

Please use their values, and arrive at their final conversion factor.

 

[femr2]

(I'll add the +/7 value to that in a bit)

...which would put it up from +/- 0.1 pixel to +/- 0.12 pixel.

 

[tfk]

1. you repeatedly told people, in no uncertain terms, that claiming NTSC video was 30 frames / second was wrong, wrong, wrong?

Incorrect.

Oh really??

And you adamantly asserted that my TV operates at 60 frames per second.

Yep. It does. As I said to you previously, if you want that terms as 60 images per second, or 60 fields per second, whatever...all the same thing.

It was recorded by a US camera, broadcast on US TV, per NTSC standards.
Standards which use 30 frames/sec.
Not 60 frames/sec.

If you think your TV displays 30fps...lol

Just a couple samples…

Conclusion: you're wrong.
You repeatedly told people who claim that their TV operates at 30 frames per sec that they were wrong. That US TVs actually operate at 60 frames per second.
___

2. that, in this post above, you now say that NTSC is "60i fields per second" or "30i frames per second"?

Correct. NTSC can be referred to as either. The 60i is in regular use, though it is illogical.

Absolutely astonishing…

We are arguing about units of measure.

We are arguing the difference between your claim that NTSC video can be called either 60 frames per second or 60 fields per second, versus mine that NTSC video is 30 frames per second or 60 fields per second …

… and you quote "60i" …

… without putting the unit "fields per second" on it.

… and think that nobody will notice…??

[sarcasm]
Yeah, sure, femr. This is the behavior of someone that is interested in clear, concise communication.
[/sarcasm]




Perhaps you want to complain to … somebody … again… how you're being misquoted.
___

3. you repeatedly told people that, according to NTSC specs, "sometimes 1 field = 1 frame"?

Incorrect.

Incorrect? Let's see...

if you separate those two fields into their correct two separate images, each of them [the fields] is also called a frame.

Yup. You said that "a field is sometimes called a frame".

A picture is an image is a frame is a field (when part of an interlaced frame).

Yup. You called a frame a field here, too.

And you've used the same word, in the same discussion, to mean 1) an assemblage of 2 deinterlaced fields, 525 lines and 2) a single 262.5 lines.

Correctly.

You called a field "a frame". And subsequently defended your use of the term.

If you can't stop yourself from using two terms [field & frame] interchangeably that aren't interchangeable

They are interchangeable in many contexts.

Terms are interchangeable depending upon context.

And I'm sure you've done this another 1/2 dozen times.

But NOW, you are saying that I'm wrong when I claim that you said that "sometimes 1 field = 1 frame".

Conclusion: you are wrong when you say that you haven't said that sometimes a field is called a frame.
___

4. that, in contrast to what you've claimed, all of YOUR sources - as I cited in a previous post - say that "1 frame = 2 fields"?

An interlaced frame consists of 2 fields. I have never claimed anything *in contrast* to such.

You changed the subject. Clumsily.

You have called a field, when it is removed from its frame, "a frame". You have stated explicitly, as I've quoted above, the fact that you have acknowledged that you refer to a field, when separate from a frame, as an image, a picture, or a frame.

I provided quotes from all of the sources that YOU provided. Each one of them states unequivocally that "a frame is made up of two interlaced fields."

Not one of them, other than you, has said that "a frame is sometimes made up of only one field."

Conclusion: you changed the subject, didn't answer the question & tried to slip in the word "interlaced". And hoped that nobody would notice.

Your also wrong, as shown above, in denying that you said that "sometimes 1 field = 1 frame."
___

AND NOW …

… let's watch it happen all over again…!!

Femr's own citations contradict him.

Here, again, is the NATO STANAG 4609 DIGITAL MOTION IMAGERY STANDARD document...
Download PDF
(Page 17) Scanned doc, so...
http://femr2.ucoz.com/_ph/7/527446921.png

Well, let's see. This whole fiasco started over the camera 2 CBS video, which was broadcast in the US.

It is therefore NTSC interlaced broadcast.

Let's see what we see for NTSC interlaced broadcast in your NATO document. (NATO?? WGAS what NATO says?) What matters is what the NTSC specs say.

But, for yuks & giggles, we'll look at your reference. It happens to be right. And utterly contradicts you.

"60p" - progressive scan. Irrelevant.
"60p/1.001" - progressive scan. Irrelevant.
"50p" - progressive scan. Irrelevant.
"30p" - progressive scan. Irrelevant.
"25p" - progressive scan. Irrelevant.
"24p" - progressive scan. Irrelevant.
"24p/1.001" - progressive scan. Irrelevant.


"30i" = 30 Frames Per Second, Interlace Scanned, yielding 60 FIELDS per second.
(Ohhhh, we're getting close, now... so close. so close, you can feel the tension rising…)

"30i/1.001" = 29.97 FRAMES per second ( NTSC Frame rate), Interlace Scanned.
Note this is the frame rate associated with " television" in the United States.

Once again, your own references contradict your nonsense.

And yet, you continue to toss word salad.

Please include specific quotes from myself if you pursue any of these claims.

Happy to. See above.

All of that is "a figment of my imagination", femr?

Correct.

Incorrect.

All the above is simply copied & pasted from your posts.

 

[tsig]

Hmmm, let' see...

You now assert that it is untrue, and merely "a figment of my imagination", that over the course of the last 3 months …

1. you repeatedly told people, in no uncertain terms, that claiming NTSC video was 30 frames / second was wrong, wrong, wrong?

2. that, in this post above, you now say that NTSC is "60i fields per second" or "30i frames per second"?

3. you repeatedly told people that, according to NTSC specs, "sometimes 1 field = 1 frame"?

4. that, in contrast to what you've claimed, all of YOUR sources - as I cited in a previous post - say that "1 frame = 2 fields"?

All of that is "a figment of my imagination", femr?


I just want to be clear about this…

Must be a figment of mine too.

 

[femr2]

1. you repeatedly told people, in no uncertain terms, that claiming NTSC video was 30 frames / second was wrong, wrong, wrong?

Incorrect

Oh really??

Yes.

NTSC video and your TV are not the same thing...

If you think your TV displays 30fps...lol

30fps... 30 fields per second. lol.

All these ambiguous terms Tom. Right annoying, isn't it, if you choose to argue about it.

Your TV doesn't actually display any original NTSC *frames* at all.

That US TVs actually operate at 60 frames per second.

Yup, with the caveat of calling each separate image whatever you please.

A TV is an interlaced display device. As I indicated, 60 frames/fields/images/pictures per second (US). Whatever you want to call them.

A (US) TV displays 60 (what were once called fields in NTSC format) images per second (and you already know I'm flexible on calling each of those images a list of names)

We are arguing

Nope.

you quote "60i" … without putting the unit "fields per second" on it

Yup...

60i implicitly implies fields, and the i suffix is common, but illogical.

As in the NATO values above... *many commercial documents use the term 60i to mean 30i*.

You said that "a field is sometimes called a frame".

Not in terms of NTSC specs Tom.

As I've said, many times...

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.

But NOW, you are saying that I'm wrong when I claim that you said that "sometimes 1 field = 1 frame".

I said *In terms of NTSC specs* you are wrong.

I've called what was once a field...a frame, sure.

You have called a field, when it is removed from its frame, "a frame".

Correct.

You have stated explicitly, as I've quoted above, the fact that you have acknowledged that you refer to a field, when separate from a frame, as an image, a picture, or a frame.

Correct.

I provided quotes from all of the sources that YOU provided. Each one of them states unequivocally that "a frame is made up of two interlaced fields."

An interlaced frame contains 2 fields.

Not one of them, other than you, has said that "a frame is sometimes made up of only one field."

I've never said an interlaced frame contains only one field.

It is therefore NTSC interlaced broadcast.

It is an ms-avi file.
It contains NTSC image data @ ~29.97 interlaced frames per second.

Once again, your own references contradict your nonsense.

Nope.

The terminology is a mix and match minefield.

Surely you must be tired of whining about it by now.

 

[femr2]

It's interesting to point out how you manipulate context in these matters tfk...

2. that, in this post above, you now say that NTSC is "60i fields per second" or "30i frames per second"?

Here is the post...

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.

Note that I make the context clear.

I wrote the words *60i fields per second*, sure, as it is in use, but your portrayal is misleading.

Tsk.

 

[femr2]

Similarly...

And you adamantly asserted that my TV operates at 60 frames per second.

Does US TV use ~30 frames per second, as your reference asserts?

30 interlaced frames per second. (30 fps)
60 images per second. (60 ips)
60 frames per second. (60 fps)
60 fields per second. (60 fps)
etc...

All are valid descriptors.

(All framerates are approximate and should be *1000/1001)

Again, terms in use are often ambiguous and even technically incorrect.

Arguing about it is utterly pointless.

 

[tfk]

Incorrect. I'm applying, as I said your own standards.

I'd put it as +/- 0.0555 + measurement uncertainty myself...

±0.0555 ?? Digital-rectal dimensionless extraction noted.

Your number smells.

As I said, I applied scaling factor uncertainty to all measurements.

gibberish.
I know what you are saying.
I know what you mean.

It's still gibberish.

That "±10 pixels" is not the vertical resolution.

Who said it was ?

You did.
Here:

The 100 ±10 vertical MOIRE PATTERN pixels / horizontal pixel is a scaling factor.

A 50 pixel vertical movement, with the detail provided, still must have the base uncertainty applied... +/- 10 pixels.
…
All measurement of which is also subject to +/- 10 pixels uncertainty.

___

NIST explicitly states their vertical resolution (although without an error) as:

The red lines at each data point showed estimated uncertainties of ± 7 pixels.

Here's the full text...

quoted for no particular purpose. Making no point. Filler.

The red lines at each data point showed estimated uncertainties of ± 7 pixels. This was a rough estimation,

Which they have based upon what ? I imagine it is the noise variance.

Based on a researcher's estimate of how accurate they could get the intensities of the two pixels on either side of the black vertical line to match up, by eyeball.

And your conclusion that NIST's comment ... means that NIST is claiming a ±1" resolution is wrong, too.

Jebus. By quoting them, the *claim* is about the final conversion factor of 1.1 ft ± 0.1 ft (13 in. ± 1 in.) for each 100 pixels of vertical marker motion.

Resolution is not measured in "foot per 100 pixels of vertical marker motion".

It is measured in "feet". Or "inches". With a tolerance.

You get that my multiplying their vertical resolution (±7 pixels) by that scaling factor, and you get exactly what I told you in the last post.

Why don't you show how NIST combined the metrics to arrive at their final conversion factor in...

Easy as pie.

If you assume no error on the ±7 pixels vertical moire resolution, then you get:

(±7 vertical pixels) x (1 horizontal pixel / 100 ±10 vertical moire pixels) x (1.09 ±.02 ft/horizontal pixel) = ±0.077 ± 0.009 feet.

If you assume the vertical resolution is ±7 ±1 vertical pixels, then the nominal value stays approximately the same, but the error increases substantially.

±·(7 ±1 vertical pixels) x (1 horizontal pixel / 100 ±10 vertical moire pixels) x (1.09 ±.02 ft/horizontal pixel) = ±0.079 ± 0.020 feet.

This ain't rocket science. It's as simple as it gets.

Where did you add them together ?

You don't add them together.

If I have misinterpreted your prior assertions that ALL uncertainty must be applied to each value at every step, then, hands up, the +/- 0.1 pixel value is not fully accurate.

You haven't understood what I've said.

It is not because I didn't say it precisely & correctly.

As indicated above, I'd put scaling factor (by my standards) at +/- 0.0555 pixels per...(I'll add the +/7 value to that in a bit)

Doesn't smell any better this time...

However, I will draw your attention to what you are saying...in relation to the values provided by NIST.

gibberish.

Please use their values, and arrive at their final conversion factor.

We don't calculate their final conversion factor.

They give us the final conversion factor (vertical moire motion to horizontal distance).

From that, and knowing the uncertainty in the vertical moire motion, we can calculate their final horizontal resolution.

Which is (if you believe that the ±7 pixels has no tolerence) 0.077 ±.009 feet.

If you accept that the the ±7 pixels has a tolerance of 1 pixel, then the horizontal resolution is 0.079 ±.020 feet.

If you believe that the ±7 pixels is a rough number (as they say it is), then it may have an error as big as 3 pixels.

I've calculated this for 7 ±0 & 7 ±1 pixel on the vertical resolution.

Let's see you do it for ±7 ±3 vertical pixels.

 

[tfk]

And the crappola continues…

You just keep digging, & digging & digging…

More misleading, deception. More snippets that don't mean anything. Or are totally misleading.

NTSC video and your TV are not the same thing...

I never said it was.
Misdirection. Deception.

30fps... 30 fields per second. lol.

Nobody ever said 30 fields per second.
Misdirection. Deception.

All these ambiguous terms Tom. Right annoying, isn't it, if you choose to argue about it.

It's not annoying in the slightest, if you simply agree on the meaning of terms, state those meanings clearly, and stick to them.

Instead of THIS crappola.

Which is a colossal waste of time.

All of this exemplified nicely by:

I said *In terms of NTSC specs* you are wrong.
I've called what was once a field...a frame, sure.

Craptastic hair-split.

You object that I'm misportraying your statements.
And then you re-state exactly what you said I misportrayed.
Only to object again, in the next breath that I misportrayed your statements.


___

Re: the STANAG specs...

For the CBS video, we aren't interested in STANAG 4609.

The 60fps progressive scan info is utterly irrelevant to the discussion of THIS video (CBS Camera 2). It's smoke. It's distraction. It's deception. It's crap.

There is only ONE line in this list that is NOT irrelevant crap, that is directly pertinent to the CBS video. That line is:

"30i/1.001 = 29.97 Frames per second, (NTSC frame rate)"

As in the NATO values above... *many commercial documents use the term 60i to mean 30i*.

Who cares. Some people using the terminology carelessly does not change the specs.

You can call a dog's tail a leg, but that does NOT mean that dogs really have 5 legs.

It is an ms-avi file.

Irrelevant.

It contains NTSC image data @ ~29.97 interlaced frames per second.

Yup, it does.
Because it was an NTSC signal broadcast in the US.

Just like I said about 500 posts ago.

The terminology is a mix and match minefield.

The terminology ain't the minefield. Trying to have a clear or civil conversation with you is.

And now, let's all watch you jump back on that hamster wheel of "you're wrong because I can change the meaning of the words …"

Friggin waste of time ...

 

[dafydd]

Yes.

NTSC video and your TV are not the same thing...



30fps... 30 fields per second. lol.

All these ambiguous terms Tom. Right annoying, isn't it, if you choose to argue about it.

Your TV doesn't actually display any original NTSC *frames* at all.


Yup, with the caveat of calling each separate image whatever you please.

A TV is an interlaced display device. As I indicated, 60 frames/fields/images/pictures per second (US). Whatever you want to call them.

A (US) TV displays 60 (what were once called fields in NTSC format) images per second (and you already know I'm flexible on calling each of those images a list of names)


Nope.


Yup...
[qimg]http://femr2.ucoz.com/_ph/7/527446921.png[/qimg]
60i implicitly implies fields, and the i suffix is common, but illogical.

As in the NATO values above... *many commercial documents use the term 60i to mean 30i*.


Not in terms of NTSC specs Tom.

As I've said, many times...

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.


I said *In terms of NTSC specs* you are wrong.

I've called what was once a field...a frame, sure.


Correct.


Correct.


An interlaced frame contains 2 fields.


I've never said an interlaced frame contains only one field.


It is an ms-avi file.
It contains NTSC image data @ ~29.97 interlaced frames per second.


Nope.

The terminology is a mix and match minefield.

Surely you must be tired of whining about it by now.

How does all this esoteric material prove that Dubya and co. blew up the Twin Towers?

 

[femr2]

Nice try Tom.

I'll deal with your other, er, comments later, but first...


It never amazes me the lengths you will go to to manipulate discussion, and your relentless need to portray NIST through rose-tinted spectacles.

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.

+/- 1 inch.

Please elaborate. Tell me what you think that "±1 inch" means in this context…

The harmonic motion that began 6 s before the penthouse began to fall had an amplitude of nine vertical pixels, equivalent to sideways motion of 0.1 ft, or slightly over one inch in each direction. The maximum range of motion, which occurred after the penthouse had disappeared, totaled about 107 vertical pixels, or about 14 in. ± 1 in.

...which refers to the following...

It is the NIST determination of scaling metric, which they also apply to stated position change metrics, which are both stated to be accurate to +/- 1 inch.

Are you saying that the "± 1 inch" in the "13 in. ± 1 in." defines the ±1 inch positional accuracy?

I am saying exactly what I said in the post you quoted...

It is the NIST determination of scaling metric, which they also apply to stated position change metrics, which are both stated to be accurate to +/- 1 inch.

Typically unresponsive. How unsurprising...

Is there some issue you have with my initial response ?

There should not be, unless your intent is some petty attempt to draw out a different response upon which you can pounce with a derision laced *gotcha*. You should be more than capable of answering your own question.
...
The 13 in. ± 1 in. metric is for their *conversion factor*, what we have referred to on this thread as scaling metric, with their uncertainty being +/- 1 inch.

The 14 in. ± 1 in. metric is for their *maximum range of motion* of the west wall edge in the horizontal direction, with their uncertainty being +/- 1 inch.

Are both +/- 1 inch metrics the same thing, clearly not. I imagine you wanted me to say they were.


The important point though Tom...

NIST are stating position change accuracy to +/- 1 inch.

Why is any of this important ? Well, my own data for the same movement is very similar, and so you would imagine it's reasonable to suggest that it is similarly accurate...

As you know, the methods I use differ from those of NIST, with regular discussion about sub-pixel resolution metrics present throughout this thread (and others).

And so...

100 ± 10 vertical pixels for each horizontal pixel

This effectively translates to a +/- 0.1 pixel accuracy.

...and you, tfk, took the opportunity this statement provided you, and almost managed to make it stick.

Is my last statement above entirely correct ? No.

You then steered the ensuing discussion off course, into discussion about positional accuracy (as you wanted to earlier).

Smart move, bearing in mind that NIST don't state positional accuracy, but only position change error estimation.

And along the way you managed to slip in a healthy dose of context shift...

And your conclusion that NIST ... is claiming a ±1" resolution is wrong

+/- 1" resolution ? No, tom, you sly old dog, I said...

NIST are stating position change accuracy to +/- 1 inch.

It's something you do regularly, and it suits your purposes to do so.

I don't always spot it.

I could list volumous instances of the same thing, but let's not let the grass grow eh...

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.

Please use their values, and arrive at their final conversion factor.

Easy as pie.

If you assume no error on the ±7 pixels vertical moire resolution

Whoa there tom. Careful with the sleight of hand there.

The full text of C.1.4 was provided to you, yet you choose to include a +/- 7 pixel uncertainty metric that they clearly did not use in determination of the final conversion factor.

You then choose to add +/- 1 pixel uncertainty to the +/- 7 pixel uncertainty value that NIST didn't use in the determination of the final conversion factor, with calcs.

Followed by...

This ain't rocket science. It's as simple as it gets.

No tom, it's quite clever.

And then, now that most people reading it have gone +/- blind and rapidly losing the will to live, we get...

We don't calculate their final conversion factor.

Don't we. Oh, and there was me thinking that that was EXACTLY what we are supposed to be calculating...using the values provided by NIST, all of which are in the quoted C.1.4 above.

They give us the final conversion factor.

It's amazing isn't it. How simple it is to try and manipulate and steer outcome.

From that, and knowing the uncertainty in the vertical moire motion, we can calculate their final horizontal resolution.

Not the question.

Which is (if you believe that the ±7 pixels has no tolerence) 0.077 ±.009 feet.

Nothing to do with the question.

If you accept that the the ±7 pixels has a tolerance of 1 pixel, then the horizontal resolution is 0.079 ±.020 feet.

I'm going blind.

If you believe that the ±7 pixels is a rough number (as they say it is), then it may have an error as big as 3 pixels.

This is actually great.

The result of the steer is that focus is now upon applying varying amounts of uncertainty...to values that NIST didn't use in determining the value you are supposed to be generating...to generate values you are not supposed to be generating.

Wonderful.

I've calculated this for 7 ±0 & 7 ±1 pixel on the vertical resolution.

Which reads...I've done this twice, see...it's valid...don't spot the re-steer...

Let's see you do it for ±7 ±3 vertical pixels.

No, tfk, let's not.


Let's see your answer to the original question.

There is reason why I asked it, and you said it was easy as pie. I quite agree, and would ask you to highlight how NIST treated rounding and error. All of the required detail is in C.1.4 above.

So, again, ...


Please use their values, and arrive at their stated final conversion factor.

 

[Carll68]

Femr...the fraud who can not answer a high school level physcis question correct, then, when proven that his answer is wrong, tries to blame the queston...never admitting he was wrong...
Femr...the fraud who developed a 'collapse simulator' then when called on it said it was never a simualtor, then places the energy from collapse into crushing concrete which was not crushed...
Femr..the fraud who called Ryan out on his website but will not engane in a actual debate

...who did not understand the conservaton of momentum
...who said FL175 was not really FL175
...who said the towers structure would act as a huge 'heat sink' for the fires

Now debunks himself again with his FPS nonsense


Hey, genius..why does the source you keep qouting make it very clear that "FPS" in realtion to video means "Frames Per Second"? (see attachment)
Hmmmmmm?

Duuuuuuur!

 

[tfk]

LMAO,

Talk about going blind with layers of irrelevant crap...

This is simple.

The input of this calculation is the vertical motion of the moire pattern (in pixels) & the output is the horizontal movement of the building (in feet).

NIST gives a conversion from vertical motion of the moire pattern to horizontal motion of the building in pixels. (100 ±10 vertical moire pixel movement / 1 horizontal pixel movement of the building).

NIST gives a conversion factor for horizontal movement in pixels to horizontal movement in feet. (1.09 ±.02 feet / pixel)

The final conversion factor (input in vertical pixels & output in horizontal feet) is calculated by simply multiplying these two numbers together, and treating the errors appropriately.

minimum:
(1.07 ft / h pix) x (1 h pix / 110 v pix ) = .0097 ft / v pix = 0.97 ft / 100 v pix

maximum
(1.11 ft / h pix) x (1 h pix / 90 v pix) = 0.012 ft / v pix = 1.23 ft / 100 v pix.

Combining the two for the mean: (0.97 + 1.23) / 2 = 1.10 horizontal feet / 100 vertical pixel movement.

Figuring the error => 1.23 - 1.10 = 0.13

Result: 1.10 ± 0.13 horizontal feet / 100 vertical moire pattern pixel motion.

NIST rounds off to 1.1 ± 0.1 horizontal feet / 100 vertical pixel movement.

All of the above are simply conversion factors, with their errors, which translates vertical moire pattern movement into horizontal movement of the building in feet.
___

Now, the germane point is that you claimed that you knew the horizontal resolution of NIST's data using just the above numbers.

You were wrong. And now you're blowing all kinds of smoke trying to cover it up.

In order to know the actual horizontal resolution of the technique, you ALSO need to know the vertical resolution of the moire pattern (in pixels). Which happens to be ±7 pixels.

When you multiply NIST's stated vertical pixel resolution by the vertical pix to horizontal feet conversion, you get NIST's horizontal resolution (in feet).

Ignoring any error on their ±7 pixel number gives

(±7 pixels) x (1.1 ± 0.1 horizontal foot / 100 vertical pixel) = ± 0.077 ± .007 ft = ± 0.92 ± .09 inches.

Since a resolution is a limit call out, good engineers (like NIST) would use the worst-case number (±(0.92" + 0.09") = ±1.1", which they rounded off to ±1".

This is exactly where they got the ±1" as the tolerance on the horizontal resolution.

The "± 7 pixel resolution" is the factor that you never mentioned. This is the factor that I gave you several opportunities to mention. This is the factor that I referred to when I explicitly told you that you were omitting one factor.

You erroneously just grabbed the ±10 pixels from the conversion factor & applied that.

Wrongo, buckeroo.

And now. let the dancing begin...


___

BTW …

Nice try Tom.
It never amazes me the lengths you will go to to manipulate discussion, and your relentless need to portray NIST through rose-tinted spectacles.

"… portray NIST thru rose-tinted spectacles …"??

LoL.

All the above is remedial error analysis. It's taught to all freshman level engineering & science students. It works for NASA. It works for Toyota. It works for Raytheon. It works for ALL engineers.

And it works for NIST.

Doing accurate error analyses does not portray NIST thru rose colored glasses. It portrays them as competent engineers.

Your inability to understand or appreciate (much less perform) a trivial error analysis portrays your analytic, math & engineering skills in a much, much less complimentary light. (How's that for "delicately put"?)

I've calculated this for 7 ±0 & 7 ±1 pixels on the vertical resolution.
Let's see you do it for ±7 ±3 vertical pixels.

No, tfk, let's not.

LoL. Yeah, I didn't think you could do a simple error band calculation.
___

Now, I've got more important things to do today than to get wrapped up in a discussion with your smoke-blowing, bloviating, mendacious kiester you.

But before I go ...

Gee femr, you REALLY shouldn't have to have something this simple explained to you ...