That list looks familiar...
It's getting longer and longer I'm afraid.
That list looks familiar...
Not a great show of competence. Let us hope that a similar raft of issues is not present for other sections of the report. It'll all come out in the wash.
Too bad your posts are not as succinct, as your answer to questions.It's getting longer and longer I'm afraid.
That list looks familiar...
What would your work be without NIST? NIST bashing for what reason?
Do you need to bash NIST to comprehend WTC 7 was a gravity collapse?
How does your analysis of WTC 7 support your claims the official theory is fictional? Does your work coupled with all the available evidence support a gravity collapse?
It's getting longer and longer I'm afraid.
femr, the data points aren't pairs. I just can't think of any other way to say it. They aren't pairs. You called them "pairs." It's unconventional and unclear. NIST plotted the points along a timeline. There was no need for anything else.
'NIST tracked the *roofline* using a single pixel column, rather than an actual feature of the building'
Which affects the data in precisely what way? Femr2 has not quantified this claim at all.'NIST did not perform perspective correction upon the resultant trace data.'
. But of course, he and MT both admit that the building was not moving purely in a horizontal fashion, but also downwards.north-south movement resulting from twisting of the building
Incorrect. The graph shows the sample separation time in a significantly more immediate and clear way than 12-76, of course. That is why I generated the graph.Femr2 has invented his own, less clear way of labeling information that was already plotted on 12-76 by NIST.
Incorrect. I state exactly what it is and where the data originates.Then he pretends it's completely different information, even though of course it isn't - it's just graphed differently.
There is no bullying, and no obfuscation. Making up nonsense like that is really very foolish. The thread content is not going anywhere you know.He doesn't seem to care at all about that fact, but prefers to bully and obfuscate instead. Hey ho...
Incorrect, what you said was...Regarding my own use of Tracker, I simply pointed out to Femr2 something which he already admits, which is that one can manually track a feature of a building.
There is no ambiguity there. You are stating you have tracked a point above region B using motion tracking software. We were specifically discussing my assertion that such a trace cannot be performed from T0 as the rooftop structures are in the way. That is your response.It is perfectly possible to select a point on the parapet wall somewhere more or less directly above the final point using motion tracking software.
I've done it using a couple of different programs myself so I can assure you.![]()
Incorrect.What Femr2 then did was misunderstand my post
No, you tried to wriggle out of being called on yet more of your BS. Please upload your trace data. In fact, upload your Tracker data file. That will also allow me to confirm whether you performed the trace manually or automatically.which I warned him he was doing following that.
Again, you have been caught BS'ing and have been called on it. You are just trying to deflect. I'm afraid it won't work.But he has yet to comprehend where the misunderstanding is, and I have no intention of filling in the blanks for him, because he's acting like such an imperious putz.
I have demonstrated I am more than willing to go into as much detail as necessary for each of the points highlighted, none of which are technobabble. Perhaps things you personally don't understand. If you are struggling there's no shame in asking. What you refer to as spam is the thread topic, femr2's video data analysis. It's a growing list of analysis points.Now, he continues to spam this thread with the same tired list of his assumptions, some of which appear to be technobabble.
I have specifically and repeatedly stated how tracking a single pixel column affects the trace data...Which affects the data in precisely what way? Femr2 has not quantified this claim at all.
...and I have also highlighted perspective here. If you cannot work out that the building moving laterally in the frame affects the vertical position extracted from the video, resulting in an artificaially low value if the building moves left, and artificially high value if the building moves right, then I am not surprised you are struggling (at best).NIST tracked the *roofline* using a single pixel column, rather than an actual feature of the building. This means that the trace is not actually of a point of the building, as the building does not descend completely vertically. This means the tracked pixel column is actually a rather meaningless point on the roofline which wanders left and right as the building moves East and West.
Of course.But of course, he and MT both admit that the building was not moving purely in a horizontal fashion, but also downwards.
Absolute nonsense. If you cannot understand why including positional data from movement not primarily in the vertcal direction on a plot of vertical motion is erronious, then you really need to learn a few things quickly, as you will continue to make such inept statements until you do.Of course neither Femr2 or MT can admit this
That is typical of 911 truth "studies". I can't find a single part of this analysis which support his claims of an inside job. All I can find is a hate of NIST. What does NIST have to do with the gravity collapse of WTC 7? Nothing.Basic technique used by Femr2 - generate a mountain of extraneous data, with little or no proper documentation, tie it into a series of technobabble arguments and hope that average readers will be gullible enough to accept it at face value.
The general message: NIST bad, NIST wrong.
Well, reviewing one small section has revealed...
The NIST data suffers from the following (non-exhaustive) series of technical issues, each of which reduce the quality, validity and relevance of the data in various measures...
- NIST did not deinterlace their source video. This has two main detrimental effects: 1) Each image they look at is actually a composite of two separate points in time, and 2) Instant halving of the number of frames available...half the available video data information. Tracing features using interlaced video is not a good idea. I have gone into detail on issues related to tracing of features using interlaced video data previously.
- NIST did not sample every frame, reducing the sampling rate considerably and reducing available data redundancy for the purposes of noise reduction and derivation of velocity and acceleration profile data.
- NIST used an inconsistent inter-sample time-step, skipping roughly every 56 out of 60 available unique images. They ignored over 90% of the available positional data.
- NIST likely used a manual (by hand-eye) tracking process using a single pixel column, rather than a tried and tested feature tracking method such as those provided in systems such as SynthEyes. Manual tracking introduces a raft of accuracy issues. Feature tracking systems such as SynthEyes employ an automated region-based system which entails upscaling of the target region, application of LancZos3 filtering and pattern matching (with FOM) to provide a sub-pixel accurate relative location of initial feature pattern in subsequent frames in video.
- NIST tracked the *roofline* using a single pixel column, rather than an actual feature of the building. This means that the trace is not actually of a point of the building, as the building does not descend completely vertically. This means the tracked pixel column is actually a rather meaningless point on the roofline which wanders left and right as the building moves East and West.
- NIST used the Cam#3 viewpoint which includes significant perspective effects (such as early motion being north-south rather than up-down and yet appearing to be vertical motion). It also means that each horizontal position across the facade requires calculation of a unique scaling metric, which NIST do not appear to have bothered to do.
- NIST did not perform perspective correction upon the resultant trace data.
- NIST did not appear to recognise that the initial movement at their chosen pixel column was primarily north-south movement resulting from twisting of the building before the release point of the north facade.
- NIST did not perform static point extraction(H, V). Even when the camera appears static, there is still (at least) fine movement. Subtraction of static point movement from trace data significantly reduces camera shake noise, and so reduces track data noise.
- NIST did not choose a track point which could actually be identified from the beginning to the end of the trace, and so they needed to splice together information from separate points. Without perspective correction the scaling metrics for these two points resulted in data skewing, especially of the early motion.
- NIST performed only a linear approximation for acceleration, choosing not to further derive their chosen displacement function.
- NISTs displacement function, if derived to obtain acceleration/time contains a ~1s period of over-g acceleration.
- NISTs displacement function, if derived to obtain acceleration/time does not suggest a 2.25s period of roughly gravitational acceleration.
- The displacement data appears to have been extracted initially from the T0 pixel column, but using the scaling factor determined for a point above Region B, further skewing the displacement data.
Not a great show of competence. Let us hope that a similar raft of issues is not present for other sections of the report. It'll all come out in the wash.
They certainly analysed video, just not very well. Perhaps if they had done so with more care, they would not have produced a report with assertions which do not fit the available video evidence too well.I don't think NIST analyzed videos to reach their conclusion.
They certainly analysed video, just not very well. Perhaps if they had done so with more care, they would not have produced a report with assertions which do not fit the available video evidence too well.
femr, the data points aren't pairs. I just can't think of any other way to say it. They aren't pairs. You called them "pairs." It's unconventional and unclear. NIST plotted the points along a timeline. There was no need for anything else.
*The investigation objectives were to determine (1) why and how WTC 7 collapsed*I think they probably analyzed it enough
*The investigation objectives were to determine (1) why and how WTC 7 collapsed*
If they do not match the visual evidence record, they do not match the how. What then confirms the why ?
An article on tuples in which the word *pair* appears many times. A pair is a legitimate and widely known term in mathematics and computer science.
A pair of datapoints is a datapoint pair.
Perhaps you would be more comfortable with the term 2-tuple instead ?
What page was that on? What were the overall goals?*The investigation objectives were to determine (1) why and how WTC 7 collapsed*
If they do not match the visual evidence record, they do not match the how. What then confirms the why ?
Abstract, paragraph 1. Basically page 1What page was that on?
That was goal numero unoWhat were the overall goals?
Title of the Abstract, number etc. Linky.Abstract, paragraph 1. Basically page 1
That was goal numero uno#1.
Have you actually ever read any of the reports ?![]()
Outstanding beachnut. You have finally discovered the location of the NIST reports. Well done. Really.
I've made no such claim.your inside job claim?
Incorrect.carlitos said:You have no idea what you're talking about.
Correct(ish).NoahFence said:They did NOT do it to YOUR satisfaction.
Please stop pretending to understand math. I am embarrassed for you.Incorrect.
Your inside job claim, when you said the Official Theory was Fictional. No big deal, you don't have any goals or conclusions. Did you erase your Fictional Official Theory statement? Like you changed your web page?...
I've made no such claim.