NIST blew the calculation of the Stage 1 of WTC7 collapse.
Correct. Erronious placement of the elusive T
0. Effectively arbitary placement of Stage 1 end-point.
NIST mistook horizontal motion for vertical motion, resulting in an actual Stage 1 descent of much less than 1.75 seconds.
Correct(ish), though as I've said, the NIST decision to define such "staging" at all was not a good idea. They misinterpreted early motion direction, yes, but there are additional reasons why the 1.75s timing is inaccurate.
And uglypig believes that there was approximately 2 minutes of collapse going on prior to "global collapse" that was measurable from some motion of the external wall(s) of the building.
As you know, East Penthouse descent preceeded release of the NW corner (and North facade) by ~6s. Motion of the building was detectable minutes prior to release...

...and the preceeding few minutes...
Where would you suggest the "start" is ?
Why don't you guys go ahead & make your respective cases.
Further to my previous posts
here, I thought I'd expand, as many folk don't tend to follow enclosed links...
NIST T0 Selection
By usage of the
brightness profile in
NIST Figure 12-75 the exact pixel and (
interlaced) frame that NIST selected was determined...
Source Video | CBS-Net Dub7 47.avi (RAW NIST FOIA - 1Gb DV File)
Pixel | 304, 171
Frame | 5398
That point is the exact start of the NIST Stage 1.
It is also ~6s
after the start of the East Penthouse descent.
The following graph shows motion of the NW corner relative to the NIST T
0 and their East Penthouse release time...
As you can see, relative to NW corner motion, the NIST T
0 looks pretty meaningless.
The NIST release time for the East Penthouse is also inaccurate, but that's not relevant for this thread. (It's much closer to exactly 6s prior to their T
0).
NIST chose that spot with the assumption that detected motion after that point in time was vertical. In fact that motion is initially primarily North->South, as the formation of the "kink" was misinterpreted by NIST to be vertical in nature.
If they had compared the roofline profile of their chosen Cam#3 viewpoint...

...against that seen from the Dan Rather viewpoint...

...it would have been obvious that the "kink" was formed primarily North->South.
There are other ways to prove such, but comparison of the two images above (which are synchronised at the same point in time) is by far the simplest way to present the NIST interpretation error.
So, the start point of NIST "Stage 1" is, at best, flawed.
However, given that T
0 (release) placement is always slightly subjective, that can be put aside, and focus can be placed upon the actual 1.75s "Stage 1" interval...
NIST Stage 1 Interval
Here is a graph of the NIST acceleration profile as derived from the
equation provided, along with the Stage 1 1.75s timing...
Well, it would seem that NIST didn't derive their (time derivative of curve fit) velocity equation for acceleration, as that would put their stage 1 (which is defined by NIST as being terminated when "freefall" was attained) a little later on.
So how did they come up with the time ?
I'd suggest a guesstimate, using eye-balled velocity graph slope as a rough indicator.
Is it therefore surprising that their Stage 1 period is inaccurate ?
A more correct "Stage 1" Timing
If Stage 1 "means" the time between release and the start of the period of approximately freefall descent, then firstly acceleration profile data
must be determined...
...then simply measure the time between release and maximum acceleration...
~1s
(Just before the 12s mark to just before the 13s mark)
If you want to suggest the end-point should be a little earlier (as the maximum acceleration is over "freefall", fine. That would put "Stage 1" period down to ~0.75s.
As you also know, there are a number of additional factors which affect the NIST data...
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 a really bad idea, especially for features changing vertical position. 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 two single pixel columns, 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 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 chose an initial trace location which precluded starting the trace before the East Penthouse had already descended (as the East Penthouse obscured their trace location). Consequently they no way of gathering early motion data, or quantifying long term noise levels.
- NIST chose a trace endpoint which could not be traced from their selected T0 time, and so subsequently merged data from two separate traces together, without accounting for change in scaling metric.
- 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 did not bother to do.
- NIST did not perform perspective correction upon the resultant trace data.
- NIST did not 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. Whilst that in itself is fine, it's at the wrong time, and in their conclusions they ignore it.
- 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.
It'd be, like, you know totally way cool if you could make some statement, after you've made your cases, as to how your interpretation of the timing impacts the question of "CD vs. no CD", or "inside job vs. outside job".
As I have said many times, WTC7 was in motion several minutes prior to release. Those proposing explosives->immediate descent must ask themselves what was causing the early motion.