Merged Discussion of femr's video data analysis

[Carll68]

That is classic.....you know much more than most on this subject TFK and your understanding of those principles once again shows what an outright sham femr is.

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 …


"… 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"?)



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.

But before I go ...

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

 

[femr2]

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

The purpose is for you to realise that NIST did not perform a tfk certified error analysis^TM, nor inclusion of the rough +/- 7 pixel metric you plucked from their pre-automation observations.

This is simple.

Yes, as I said, it is.

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

With the slight correction, yup.

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

Yup.

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

It has pretty severe rounding, but yup.

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.

Yup.

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 studied marker point pixel motion.

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

Yup.

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

Yup.

Yes, very simple.

The resultant final conversion factor is what was used to place the scale on the subsequent graphs...

Using the conversion factor determined in section C.1.3 allowed labeling of the vertical axis in both marker locations by vertical pixel number and in inches of horizontal displacement. The zero point for displacement was chosen to be vertical pixel number 265, the location of the marker point at the time when final oscillations began.

Note that the C.1.3 reference is an error, as no conversion factor was determined in C.1.3, and was instead performed in C.1.4, the factor you just verified.

Now, the germane point is that

The point is that the simple calcs you just verified from C.1.4 are, as you say, good enough for NIST.

I'll bear that in mind when I post the new Cam#3 data

you claimed that you knew the horizontal resolution of NIST's data using just the above numbers.

I have stated that my statement *effectively translates to a +/- 0.1 pixel accuracy* was incorrect. Twice. Three times now.

You were wrong.

Correct.

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

Incorrect.

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

Incorrect.

Their final conversion factor was used as just that. Final. Subsequent metrics, such as...

The maximum range of motion, which occurred after the penthouse had disappeared, totaled about 107 vertical pixels, or about 14 in. ± 1 in.

...also use the same final conversion factor.

"… 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.

Splendid. They didn't go beyond the final conversion factor. That, in your opinion, was good enough for NIST. I'll bear that in mind for future discussion of my own data.

 

[tfk]

The purpose is for you to realise that NIST did not perform a tfk certified error analysis^TM, nor inclusion of the rough +/- 7 pixel metric you plucked from their pre-automation observations.

100% wrong.

I just showed you the calculation that NIST did, in the background so as not belabor a bunch of civilians with a bunch of eye-glazing calculation. And a 3x longer report.

They did these calculations, and their results ended up in two places.

First, it ended up in the vertical motion to horizontal motion conversation factor.

Second, given the ±7 pixel resolution, it ended up as the ±1" horizontal error of the building's movement, which equals the resolution of their moire technique.

the vertical motion of the moire pattern

the vertical motion of the moire pattern studied marker point

Count on you to focus like a laser on something utterly insignificant.

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

It has pretty severe rounding, but yup.

Utterly wrong. Exact right precision. Any less round-off error would be wrong.

What makes you think that it's got too large a round off error, Mr. 13 Significant Figures…?

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.

Yes, very simple.

Yup, real simple when someone else does the work.

But apparently not so simple that you could accurately do it yourself.

The resultant final conversion factor is what was used to place the scale on the subsequent graphs...
http://femr2.ucoz.com/_ph/7/113491748.png

Of course.

Note that the C.1.3 reference is an error, as no conversion factor was determined in C.1.3, and was instead performed in C.1.4, the factor you just verified.

Holy Moly, a typo…!! No doubt they were trying to hide that trivial calculation from everyone…

The point is that the simple calcs you just verified from C.1.4 are, as you say, good enough for NIST.
I'll bear that in mind when I post the new Cam#3 data

Of course they are "good enough for NIST". They are right. Any other calculation would be wrong. And that would NOT be "good enough for NIST".

What, pray tell, do you think would be a "better calculation"??

More significant figures??

you claimed that you knew the horizontal resolution of NIST's data using just the above numbers.

I have stated that my statement *effectively translates to a +/- 0.1 pixel accuracy* was incorrect. Twice. Three times now.

That is just the consequence.

The significant point is that you misunderstood how to calculate the resolution.

And when I asked you to explain how you did so, you launched into an avalanche of crappola. Meaningless numbers thrown left & right.

Along with enough snottiness to equal a 15 year old with the flu.

And you are still doing the same.

Your last post before this one is identical. Full of meaningless gibberish, disguised as calculations.

The person whose credibility you're flushing down the old crapper is your own.

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

Incorrect.

All right. Please explain why it is incorrect. And what you think is correct.

Please show your math.

Their final conversion factor was used as just that. Final. Subsequent metrics, such as...
...also use the same final conversion factor.

Utter gibberish.

"Final conversion factor" does not refer to time.
It refers to a conversion factor that contains all the constituent conversions that allow you to go directly from your desired output (building motion) from your measured input (vertical motion of the moire pattern).

The number that they posted is the right number.
There is no other number that will ever be a "better" number.
Any other number is, by definition, a "worse" number.

So please explain, exactly what do you want them to do to "improve" on this number?

Splendid. They didn't go beyond the final conversion factor. That, in your opinion, was good enough for NIST. I'll bear that in mind for future discussion of my own data.

Yeah, it was exactly good enough for NIST. And good enough for me. And good enough for pretty much all other non-brain-dead engineers who read the report, and got interested enough to delve into this arcana.

"tfk approved" too.

You'd do VERY well to imitate them. Doing a competent error analysis.

 

[femr2]

I just showed you the calculation that NIST did, in the background so as not belabor a bunch of civilians with a bunch of eye-glazing calculation.

They did not use the +/- 7 pixel metric.

Of course they are "good enough for NIST".

Good.

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

Incorrect.

All right. Please explain why it is incorrect. And what you think is correct.

You misunderstand. I am saying that the assertion that they used the +/- 7 pixel metric is incorrect. They did not.

That metric was, as highlighted by us both, a rough eyeball estimation determined during their manual initial run.

Subsequent automation of their technique and application of the third-order polynomial least-squares fit curves for determination of intersection point supersceded that.

Within the automation details (section C.1.5) the use of the conversion factor is reiterated.

So please explain, exactly what do you want them to do to "improve" on this number?

I'm okay with +/- 1 inch. I wouldn't have thought the method used to determine it would meet your full approval, but no worries.

Yeah, it was exactly good enough for NIST. And good enough for me. And good enough for pretty much all other non-brain-dead engineers who read the report, and got interested enough to delve into this arcana.

Splendid.

"tfk approved" too.

Splendid again.

You'd do VERY well to imitate them. Doing a competent error analysis.

It's not particularly extensive, so sure. No worries.

As I've said, new cam#3 data will be done soon, so it's all good, especially having reached this juncture

 

[Dog Town]

This might be the most boring thread, ever! Just say'en...

 

[tfk]

They did not use the +/- 7 pixel metric.

Yes… they… did.

For mysterious reasons, someone had this image removed from imageshack. And is doing it again. Here it is, hosted here:

BTW, here is proof that, while ±1" is the horizontal positional accuracy that NIST can claim, their techniques are capable of movement resolutions down to about ±0.2 inches. When properly employed by experienced, knowledgeable people, of course.

All right. Please explain why it is incorrect. And what you think is correct.

You misunderstand. I am saying that the assertion that they used the +/- 7 pixel metric is incorrect. They did not.

That metric was, as highlighted by us both, a rough eyeball estimation determined during their manual initial run.

Subsequent automation of their technique and application of the third-order polynomial least-squares fit curves for determination of intersection point supersceded that.

Within the automation details (section C.1.5) the use of the conversion factor is reiterated.

First, as soon as I ask you to prove your assertions rigorously, with math, furious backpedaling begins. Typical.

You're all bluster & no substance.

Second, you're wrong again. See above.

They generated interpolation functions & automated the detection of the intersection point.

Even tho you can calculate the intersection point within .01 pixels, that does NOT mean that this is the correct precision of that measurement.

It is evident, from the error bands on the first chart above, that NIST decided that ±7 pixels was a reasonable estimate of the error in the vertical resolution. Even for the automated calculation. And they DID use it.

If you look at the 3rd order polynomial, and compare it to the actual intensity, you can see that ±7 pixels is a reasonable estimate for that error.

So, once again, when you burrow down into the details, you find out that NIST did things right. Reasonably. Judiciously. With justification.

In other words, "Professionally".

I've found this to be the case every single time that I've gone into some detail.

Similarly, I've found truther analyses, with rare exceptions, to be loaded with errors, unreasoned and unreasonable, unjustified and unjustifiable. In other words, "amateurish".

I'm okay with +/- 1 inch. I wouldn't have thought the method used to determine it would meet your full approval, but no worries.

The precision is completely reasonable. The resolution is even better. There is absolutely no need for any greater values of either.

Ergo, they left it at that.

What on earth is your problem with that?

What idiotic purpose is solved by trying to get far more precision than they need for their analyses?

This is EXACTLY one of the most blatant differences between "experienced vs. raw", "professional vs. amateur", "knowledgeable vs. clueless": knowing when you've got the data that you need to answer your questions and competently support your conclusions.

Baby engineers and amateurs of all types go running off on time-wasting wild goose chases all the time. Like twoofers, if you leave them unchaperoened, they'll never reach any conclusions.

You have two choices to get them back on task: place a brightly colored bauble in front of them to distract them back to the real world, or a dope-slap upside the head.

Either one works.

You'd do VERY well to imitate them. Doing a competent error analysis.

It's not particularly extensive, so sure. No worries.

Another clueless comment…

The error analysis that I showed you above was trivial. You are clueless to conclude that this was either typical of, or the extent of, their error analyses throughout the report.

Their error analyses are far more extensive than you realize. As proven, in just one simple example, by the error bands associated with every single number in Table C-1, pg 688 of NCSTAR1-9. And this accompanying text:

For the 6 s period from the beginning of oscillatory motion in the data to when the penthouse began to fall, the harmonic motion was found to have a period of 3.61 s, an amplitude of 1.3 in., and an approximately zero decay rate. The total standard deviation from the nonlinear fit to this data (the square root of the estimated variance) was σ = 0.3 in. The total uncertainty, with a confidence level of 95 percent, equaled twice the standard deviation in both positive and negative directions, or ± 0.6 in.

You've got MILES of catching up to do. With your attitude, you're never gonna get close to what NIST engineers accomplish effortlessly.

 

[tfk]

This might be the most boring thread, ever! Just say'en...

I agree. Mostly.

This thread is a perfect example of a certain truther tactic "simply out-last them".

Femr & others have one characteristic that they can count on: limitless tolerance for stupid.

They have learned well that people that know what they are talking about will rather quickly toss in the towel on the clueless (or obstinate, or obdurate) and go away.

then they claim the battlefield & victory.

So, in every one of these points, femr will always, always, always, post some last comment. Filled with peripherally related irrelevancies.

He thinks whoever gets "the last word" is proven right.

More evidence of his inability to discern substance from fluff.

I've been more, uh, "stubborn" than most about challenging his one last word after another.

It makes things pretty damn boring.

Zero progress.

Hamster wheel.

 

[femr2]

Tom,

First-off, a quick reminder...

your relentless need to portray NIST through rose-tinted spectacles.

In your haste to react to this statement, you make the rather foolish assumption that I'm saying NIST did something wrong. And as usual, you change the context. LMAO.

Yes… they… did.

For that singular graph, absolutely. To determine the stated +/- 1 inch position change uncertainty, nope. No need. The uncertainty of the final conversion factor did them just fine.

BTW, here is proof that, while ±1" is the horizontal positional accuracy that NIST can claim, their techniques are capable of movement resolutions down to about ±0.2 inches. When properly employed by experienced, knowledgeable people, of course.

[qimg]http://img253.imageshack.us/img253/7871/wtc7horizmoveresidual.png[/qimg]

Generated by overlaying a curve and discarding points that didn't fit. Proof of finer movement resolution uncertainty ? Nah. Do I think their method is capable of better than +/- 1 inch ? Probably. Irrelevant.

Even tho you can calculate the intersection point within .01 pixels, that does NOT mean that this is the correct precision of that measurement.

Irrelevant.

It is evident, from the error bands on the first chart above, that NIST decided that ±7 pixels was a reasonable estimate of the error in the vertical resolution. Even for the automated calculation. And they DID use it.

LMAO. That is simply your personal assumption. They made zero indication it was used in the slightest, made the point it was a rough estimate, made the point it was from their pre-automation pass, made the point during the automation details of reiterating the final conversion factor, and made no mention of the +/- 7 pixel rough estimate within the automation details at all.

Yet you, who want them to have used it (which they had no need to) are simply saying that they did, but didn't bother to mention it. LMAO.

The precision is completely reasonable. The resolution is even better. There is absolutely no need for any greater values of either.

And what made you think I disagreed ? Oh yeah..I said you look at NIST through rose-tinted spectacles.

Ergo, they left it at that.

At +/- 1 inch position change uncertainty based upon application of their final conversion factor, sure.

What on earth is your problem with that?

Nowt

What idiotic purpose is solved by trying to get far more precision than they need for their analyses?

Who said they needed more precision Tom ?

This is EXACTLY one of the most blatant differences between "experienced vs. raw", "professional vs. amateur", "knowledgeable vs. clueless": knowing when you've got the data that you need to answer your questions and competently support your conclusions.

Look in the mirror Tom.

The error analysis that I showed you above was trivial. You are clueless to conclude that this was either typical of, or the extent of, their error analyses throughout the report.

I didn't. Speaks volumes about your thought process, that.

Enjoy.

 

[tfk]

your relentless need to portray NIST through rose-tinted spectacles.

In your haste to react to this statement, you make the rather foolish assumption that I'm saying NIST did something wrong. And as usual, you change the context. LMAO.

"Something being wrong with the object observed, but overlooked" is the very essence of the concept of "looking at it thru rose colored glasses".

So this statement is a simple lie.

For absolutely no purpose whatsoever. Except to say "Tom, you're wrong."

What a useless waste of a comment.

Yes… they… did.

For that singular graph, absolutely.

Frustration breeds poor phraseology on my part.

NIST did not "use" ±7 pixels. That implies arbitrariness on the part of NIST.

The video data, plus engineering judgment (i.e., an honest, humble admission of their limitations in being able to assess shades of gray) PRODUCED an uncertainty of ±7 pixels. Which NIST then "reported".

Just as a judicious examination of this graph…

… suggests an error that is also approximately (one should say "at least") ±1". Which is approximately ±7 pixels…

Conclusion: NIST engineers' eyeballs do just as well as exquisitely precise mathematical model of noisy, approximate data.

You cannot determine the horizontal resolution from the scaling factor alone. You MUST know the vertical resolution in order to do so.

For that singular graph, absolutely. To determine the stated +/- 1 inch position change uncertainty, nope. No need. The uncertainty of the final conversion factor did them just fine.

Oh, christ on a bicycle...

You're incompetent.
You're math incompetent. You're error analysis incompetent.

But mostly, you're just fingers-in-your-ears, brain-dead, stubborn, absolutely typical "truther incompetent".

Just admit it, please.

I walked you, like a child, thru this calculation.

I showed you each step along the way. I told you that you were wrong to suggest that the error in the scaling factor was equal to the horizontal resolution. I told you that it was merely an ACCIDENT of numbers that you got close. I showed you that the horizontal resolution would change if the vertical resolution changed. EVEN THOUGH the scaling factor (& its error) did NOT change.

Instead of looking at what I said, instead of thinking for yourself, instead of learning anything, your ****in' ego leaps into action and kicks yourself in the gonads.

Here is a tabulation of the horizontal resolution for different vertical resolutions.

Note that the "±1 inch" error in the final conversion factor DOES NOT CHANGE but the ultimate horizontal resolution DOES change.

Vertical marker point resolution|Final conversion factor|Final conversion factor error|H res min|H res max|Mean Horiz. Resolution|Horiz Res Error|Horizontal Resolution
(± pixels)|(in / 100 vert pixels)|(± in / 100 vert pixels)|(inches)|(inches)|(inches)|(inches)|(inches)
3|13|1|0.33|0.47|±0.40|±0.07|±0.5
7 |13|1|0.76|1.09|±0.93|±0.16| ±1.1
15|13|1|1.64|2.33|±1.98|±0.35|±2.3
30|13|1|3.27|4.67|±3.97|±0.70|±4.7

Now, let's change the

Now, femr, what does this tell you?

Scaling Factor error from ±1 inch to ±3 inches. Notice that the tolerance of the scaling factor is DIFFERENT compared to the previous table, and yet the horizontal resolution is approximately the same (as expected, slightly larger).

Vertical marker point resolution|Final conversion factor|Final conversion factor error|H res min|H res max|Mean Horiz. Resolution|Horiz Res Error|Horizontal Resolution
(± pixels)|(in / 100 vert pixels)|(± in / 100 vert pixels)|(inches)|(inches)|(inches)|(inches)|(inches)
3|13|3|0.27|0.53|±0.40|±0.13|±0.5
7 |13|3|0.64|1.24|±0.94|±0.30| ±1.2
15|13|3|1.36|2.67|±2.02|±0.65|±2.7
30|13|3|2.73|5.33|±4.03|±1.30|±5.3

OPEN YOUR EARS.

The ±1" horizontal resolution is a COINCIDENCE of the scaling factor being its value (13 horiz inches / 100 vert pixels) IN COMBINATION WITH the vertical resolution being its value (±7 pixels).

It's got nothing to do with the ±1" on the scaling factor.

Generated by overlaying a curve and discarding points that didn't fit. Proof of finer movement resolution uncertainty ? Nah.

Pssst, they did not "discard" the points that didn't fit.

They PLOTTED the exact amount by which all points didn't fit.

"Proof of finer resolution"? Yup.

Do I think their method is capable of better than +/- 1 inch ? Probably. Irrelevant.

1. Who cares "what you think"?
2. YES! AGREED! Getting finer resolution than 1" is IRRELEVANT.

You should probably say that sentence to yourself about 100x. And then consider carefully it in relation to your "sub-pixel", "sub-sub-pixel", .002 pixel extravaganza.

Even tho you can calculate the intersection point within .01 pixels, that does NOT mean that this is the correct precision of that measurement.

Irrelevant.

No. Precisely the point. And precisely where you go off track.

But I'm tired of throwing pearls before swine. You can think whatever you want.

LMAO. That is simply your personal assumption. They made zero indication it was used in the slightest, made the point it was a rough estimate, made the point it was from their pre-automation pass, made the point during the automation details of reiterating the final conversion factor, and made no mention of the +/- 7 pixel rough estimate within the automation details at all.

Yet you, who want them to have used it (which they had no need to) are simply saying that they did, but didn't bother to mention it. LMAO.

See above.

And the rest of your post was your usual irrelevant snark.

Totally ignorable.

Which I now shall.

 

[femr2]

The video data, plus engineering judgment (i.e., an honest, humble admission of their limitations in being able to assess shades of gray) PRODUCED an uncertainty of ±7 pixels. Which NIST then "reported".

Indeed.

What you don't seem to be able to fathom, is that it's all fine and dandy for you to write umpteen posts about how the +/- 7 pixel uncertainty could be used to determine accuracy...but NIST didn't perform any of those calcs. They didn't have to.

That is what I've been saying, as I am sure you know (though you choose to wrap all manner of guff around your posts to cloud the issue).

If you want to write to NIST and complain that they didn't perform what you originally described as a competent error analysis, then by all means do so.

As you agreed earlier, they used the final scaling metric as the basis for applying the horizontal displacement scale on their graphs.

The only time they subsequently mention displacement uncertainty is...

The maximum range of motion, which occurred after the penthouse had disappeared, totaled about 107 vertical pixels, or about 14 in. ± 1 in.

...which required nothing more than reference to said scale.

Even the subsequent vibration analysis notes...

The uncertainty values given in this section do not include the conversion uncertainty.

As I've said repeatedly, I'm fine with the stated displacement uncertainty (which is via use of the final conversion factor and graph eyeballing).

You've been having a 3 day hissy-fit for what reason exactly ?

Conclusion: NIST engineers' eyeballs do just as well as exquisitely precise mathematical model of noisy, approximate data.

NIST eye-balls are tfk certified^TM error analysis approved to-boot.

Splendid.

Totally ignorable. Which I now shall.

Okey dokey.

 

[femr2]

And it would seem the discussion has run full circle again.

The NIST method of detecting fine movement exploits a moire pattern behaviour enabling translation of large scale vertical movement of a chosen marker point into small scale horizontal movement within video images.

By translating the resulting fine (sub-pixel) motion from pixels into feet, NIST are able to state horizontal movement of the NW edge of WTC 7 with uncertainty of around +/- 1 inch for the video referred to as "Camera #3".



The methods I use do not rely upon amplification of small movement by way of moire, but instead detect fine (sub pixel) movement via inter-frame pattern matching of a region of the video frame which has been upscaled and filtered.

There is no translation step from vertical marker point to horizontal motion. Pixel values are 1:1.

There is, of course, still noise and error in the resulting raw data, caused by a multitude of factors, and it is necessary to estimate its magnitude. The most appropriate way to do so is to assess the variance of the movement data.


As was performed by NIST, the following graph plots the horizontal displacement of a point on the West edge of WTC 7 against time.

The video used is sourced from NIST, and is the physical video used within their analysis. (Camera #3)

Therefore the pixel-to-inch conversion scale has been set exactly as performed by NIST.

The above is a quick draft, and higher resolution is certainly possible, as shown below, however, it is clear in the above image that displacement variance is similar to that determined by NIST, and so it is reasonable to suggest similar levels of uncertainty, namely around the +/- 1 inch mark.

Note that there has been no static point data extraction from the above data (which minimises camera movement artefacts). NIST did not perform static point data subtraction. Some gradual movement is caused by camera motion.

In pixel units, the above variance equates to around the +/- 0.1 pixel mark.


The trace below indicates the more extreme limits of what is possible...

As agreed earlier, there's no practical purpose in sub-inch metrics, but the forthcoming new Cam#3 data will be generated with as much accuracy as possible.

Assessment of displacement uncertainty will be performed in a very similar manner to that performed by NIST (which I shall assume will not result in complaint)

 

[newton3376]

So, once again, when you burrow down into the details, you find out that NIST did things right. Reasonably. Judiciously. With justification.

In other words, "Professionally".

I've found this to be the case every single time that I've gone into some detail.

Similarly, I've found truther analyses, with rare exceptions, to be loaded with errors, unreasoned and unreasonable, unjustified and unjustifiable. In other words, "amateurish".

This is exactly what I have encountered also....

Every single time I have done some research on a truther claim...whether it is the "explosions" heard or "cell phone won't work at cruising altitude" or this thread by femr of how NIST performed the video analysis....

And other examples...Jones thermite paper...Chandlers papers.....Szamboti...the list goes on and on...

When you dig down into the details of a truther claim...whether you are looking at the math and physics, the full context of cherry picked quotes, the origin of edited photographs, etc.....what you will find is an amateurish approach with misleading and incorrect assumptions.

This thread will stand as another example when someone tried and tried to lead a truther by the hand and explain his errors in detail only to have the truther just keep talking as if he understood things as well as the communities of professionals he challenges.

Leave him to his delusions Tom....as you well know most people in the professional communities just don't care about truthers or their "evidence".

 

[femr2]

Every single time I have done some research on a truther claim...whether it is the "explosions" heard or "cell phone won't work at cruising altitude" or this thread by femr of how NIST performed the video analysis....

Did you actually read any of the thread ?

Doesn't look like you read the thread description (which states who started the thread) or even the OP (which states the purpose).

The thread was started by tfk to discuss the validity of my trace data and methods, and their accuracy.

Chandlers papers.....Szamboti...the list goes on and on...

The data has been used in part to show that claims by both are incorrect. Presence of low magnitude *jolts* and much improved acceleration profile to confirm no sustained period at freefall.

When you dig down into the details of a truther claim...whether you are looking at the math and physics, the full context of cherry picked quotes, the origin of edited photographs, etc.....what you will find is an amateurish approach with misleading and incorrect assumptions.

How ironic that you would make such a statement when the previous graph alone shows the techniques I use are capable of surpassing the accuracy of those used by NIST by a sizeable factor.

This thread will stand as another example when someone tried and tried to lead a truther by the hand and explain his errors in detail only to have the truther just keep talking as if he understood things as well as the communities of professionals he challenges.

No, it stands as an example of how little Tom understood the topic of the discussion he started. How he was desperate to show that the data was invalid in some way, any way. Ultimately it is the similarity to methods used by NIST that has resulted in his withdrawal, details of which he should have known before *picking up his pen*.

If you actually read the thread from the beginning, it makes for a most humerous insight into how his understanding of this arena has evolved over the last couple of months.

What you don't seem to realise is that it is the methods performed by NIST that have been used to validate my data.


Tom lead me by the hand ? That's hilarious.


I suggest you read the thread from the beginning, in fact please do.

 

[tsig]

Did you actually read any of the thread ?

Doesn't look like you read the thread description (which states who started the thread) or even the OP (which states the purpose).

The thread was started by tfk to discuss the validity of my trace data and methods, and their accuracy.


The data has been used in part to show that claims by both are incorrect. Presence of low magnitude *jolts* and much improved acceleration profile to confirm no sustained period at freefall.


How ironic that you would make such a statement when the previous graph alone shows the techniques I use are capable of surpassing the accuracy of those used by NIST by a sizeable factor.


No, it stands as an example of how little Tom understood the topic of the discussion he started. How he was desperate to show that the data was invalid in some way, any way. Ultimately it is the similarity to methods used by NIST that has resulted in his withdrawal, details of which he should have known before *picking up his pen*.

If you actually read the thread from the beginning, it makes for a most humerous insight into how his understanding of this arena has evolved over the last couple of months.

What you don't seem to realise is that it is the methods performed by NIST that have been used to validate my data.


Tom lead me by the hand ? That's hilarious.


I suggest you read the thread from the beginning, in fact please do.

Your arguments amount to worrying about the exact placement of the deck chairs on the Titanic and ignoring the large gash that actually sank the ship.

 

[femr2]

Your arguments amount to worrying about the exact placement of the deck chairs on the Titanic and ignoring the large gash that actually sank the ship.

What arguments would they be ?

Perhaps now that doubt of the methods and accuracy of the data have been effectively reduced to hand-waving, analysis of the data can ensue more productively.

The recent focus upon the fine motion of the NW edge of WTC 7 has also served to confirm some of the NIST data for the same movement. Quite why anyone would have a problem with independant replication of the same graphs is beyond me. Are you suggesting the time spent by NIST on the topic was worthless ?


It's a bit off-topic, but...

ignoring the large gash

NIST managed to severely mess-up the extent of the *gash* on the South side of WTC 7...

Reckon that might have had any effect upon the structural response of the building ?

(Suggest any discussion of it be performed on a separate thread.)

 

[tsig]

What arguments would they be ?

Perhaps now that doubt of the methods and accuracy of the data have been effectively reduced to hand-waving, analysis of the data can ensue more productively.
The recent focus upon the fine motion of the NW edge of WTC 7 has also served to confirm some of the NIST data for the same movement. Quite why anyone would have a problem with independant replication of the same graphs is beyond me. Are you suggesting the time spent by NIST on the topic was worthless ?


It's a bit off-topic, but...


NIST managed to severely mess-up the extent of the *gash* on the South side of WTC 7...
[qimg]http://femr2.ucoz.com/_ph/7/265352478.png[/qimg]
[qimg]http://femr2.ucoz.com/_ph/7/158844021.jpg[/qimg]

Reckon that might have had any effect upon the structural response of the building ?

(Suggest any discussion of it be performed on a separate thread.)

You take my post and characterize all the other posters with it? I don't represent anyone but myself, Tom and others can certainly speak for themselves.


I used the word gash deliberately to see if you would jump on it to derail and you lived up to expectations.

 

[femr2]

You take my post and characterize all the other posters with it?

No, I highlight that without wasting time repeatedly discussing the techniques and accuracy of the data itself analysis of the data can resume. When analysis has been performed and some conclusions posted, then your assertion can be reevaluated I'm sure.

I don't represent anyone but myself, Tom and others can certainly speak for themselves.

I'm sure they can.

I used the word gash deliberately

Good for you.

Are you planning on stating what you thought my arguments were/are ?

 

[beachnut]

No, I highlight that without wasting time repeatedly discussing the techniques and accuracy of the data itself analysis of the data can resume. When analysis has been performed and some conclusions posted, then your assertion can be reevaluated I'm sure.

I'm sure they can.


Good for you.

Are you planning on stating what you thought my arguments were/are ?

I highlight, without sourcing or referencing your methods, techniques or analysis tools, you continue in your pursuit of backing in CD. You will be stuck with the Beam Weapon solution, since thermite and explosives are did not do it, and fire has too much heat energy for you CTers to believe.

Have the error models yet? Do you always set off without a goal? Your goal is CD, like Jones you will make up your study to match your goal. Your web pages remain in a CD client state. Why does 911 truth fail to correct errors? Do, You still have Ross's failed paper up in your not so "technical paper", misleading people page?

In layman's terms, what have you got so far to help prove CD 911 conspiracy theory? Anything?

 

[Jackanory]

Perhaps now that doubt of the methods and accuracy of the data have been effectively reduced to hand-waving, analysis of the data can ensue more productively.

Sadly, the methods and accuracy of the data you supply are not simply handwaved femr2. Some continue to feed your ego and post count as they tediously and routinely show your methodology and data to be false, incorrect, misleading or irrelevant......unless you’re trying to jemmy in a CD or no planes or bombs on planes, lol.

Yep, I know you admitted that your yearlong blustering, methodology and data for 'POD bombs on planes' were all wrong but it didn’t stop you entertaining the gullible on youtube with the same methodology, charlatan ways and amateur data. They sure did lap it up for a while. Seems that the sock of MT has followed you over too, lol. Boo hoo.

I can't help but doubt that I would have been employable in my line of work if I routinely screwed up with explosives. Not much cause for a failed explosives tech who gets his calcs all screwed up. I suppose I could post my failed methods and techniques to the gullible on the internet though. Not much harm can be done and when I am called out as an irrelevant charlatan I can simply backpeddle, become snarky, sulk for a while, call for back up and then post loads of arty graphs and stuff, lol. Cool. Amazing how the self proclaimed superior behave, lol.

With all that superior knowledge and all these post counts and fancy graphs I would have expected someone somewhere to have noticed how right you are femr2. Or for your works to have landed on the desks of those who can do something about it all. Your peers. The authorities. Those western hating countries. Anyone?? Hmmmmmmm. Kinda tellin, lol. Keep it up.

Edited by Lisa Simpson: 

Edited to remove personal remarks.

 

[alienentity]

What idiotic purpose is solved by trying to get far more precision than they need for their analyses?

This is EXACTLY one of the most blatant differences between "experienced vs. raw", "professional vs. amateur", "knowledgeable vs. clueless": knowing when you've got the data that you need to answer your questions and competently support your conclusions.

That's exactly what I've been wondering. The healthy part about producing a thesis with supporting data is that one can publish and move on. If you refuse to do any of those things you can never move on - that is a shame.