The 9/11 Forum

Hi,

I am doing yet an other collapse calculations of the WTC7 building. The resently emerged collapse video is used. I have done so far less than a second of the video around where the collapse starts. The measurements are taken from windows instead of the roof line (see the marked windows in the picture). The windows of the white house are used as a reference point.

Since the video use zooming, I had to take care of it. The zooming factor is determined by calculating the pixel distance of the upper and lower wtc7 windows group in the picture.

The floor height of 3,886m (12ft 9in) is assumed as reported by NIST.

Average position of vertical pixels weighted by the darkness of the pixels of the window rows are calculated and then straight line is fitted by least squares to them. The middle point of the line is taken as a measurement point and then multiple windows rows are also averaged.

The points in the plot are the results of each frame. I also calculated error range. It is based on detected maximum error between window row distances of non zooming frames of the video (2.5s.. 2.9s, 13 frames). The time is counted from start of the video.

The error range is plotted as two lines in the plot above and below the measured points.

The result of the first frame (2.266s) is set as 0 vertical displacement in the plot. Note, that these are preliminary results and I will have to check it more.

Have a nice new year!

Hi sulifeg:

Nice first post!

Good to see someone try a collapse calculation on a new video.

If I am reading your plot correctly it appears to show a vertical drop of about 1.2 meters in 0.4 seconds in which case, assuming a constant acceleration, we have an acceleration of (2x1.2)/(0.4)^2 = 15 m/s^2. This is surely too fast!

Anyway, it would be helpful if you could plot more data points for a longer drop time to see what that shows......

Welcome, sulifeg. I'm pleased to see another person involved in this sort of effort, and this is a mighty impressive first post. Looking forward to more good stuff.

Looks you coded up your own app to do this. Extra cool.

Why is this thread static ?

NIST have confirmed 2.25s of free-fall.
A period of free-fall very close to the stated 2.25s can be confirmed very easily, by any of us I am sure, regardless of any argument about 'start time'.

The descent of WTC 7 is FUNDAMENTAL to answering 'most' questions relating to 9/11.

I am sure we are all fully aware of the implications of a 2.25s period of free-fall in physics terms.

I will be forming opinion about regular members of this forum who decide to avoid discussion of this point to full completion.

So, to progress this thread, I will be clear:

2.25s of free-fall during the descent of WTC 7 is direct proof that the building was intentionally brought down.

femr2 wrote:Why is this thread static ?

Because the person who started it posted once and left. The measurements weren't that accurate. The thread died.

NIST have confirmed 2.25s of free-fall.

I've not found them to be an entirely credible source.

A period of free-fall very close to the stated 2.25s can be confirmed very easily, by any of us I am sure, regardless of any argument about 'start time'.

Actually, I tried pretty hard and, tentatively, obtained an initial period very close to freefall, a subtly different thing. And only at the NW corner.

I am sure we are all fully aware of the implications of a 2.25s period of free-fall in physics terms.

Yes, if it is freefall and if it represents uniform motion of the majority of the building mass. A basic 1D crush-up formulation indicates a 47 story building would drop mighty fast on a total, simultaneous failure of a lower floor. What are the implications of only an 8x8m square of the NW corner dropping at near freefall?

I'll not claim that freefall is a clever, useful and stooge-ful distraction from the real issue, which is rapid, global failure at the bottom, because I don't believe it - but I'll mention it because it has occurred to me.

I will be forming opinion about regular members of this forum who decide to avoid discussion of this point to full completion.

Form away, I've already written hundreds of posts on the subject, but I may not write any more because (like anything) too much of a good thing goes sour. It's statements like these:

2.25s of free-fall during the descent of WTC 7 is direct proof that the building was intentionally brought down.

that discourage me from further participation in the topic, maybe more than any single factor besides time.

OneWhiteEye wrote:It's statements like these:

2.25s of free-fall during the descent of WTC 7 is direct proof that the building was intentionally brought down.

that discourage me from further participation in the topic, maybe more than any single factor besides time.

I'm sure you can understand why I have written it that way. I hope I made it 'fairly' clear that it was to initiate response. It has. Excellent. Thanks for your view.

Perhaps this full video smearogram may be of use:
http://www.youtube.com/watch?v=rX16SNJEaHw

I shall be producing velocity and perhaps acceleration data from a range of frames, hopefully automatically. From several frames already tested, I find very little difference in acceleration. (The code quite basic at the mo, but it will get better)

I will not be limiting my view to an 8x8 segment. I will be looking at all possible data.

femr2 wrote:I'm sure you can understand why I have written it that way. I hope I made it 'fairly' clear that it was to initiate response. It has. Excellent.

As an attention-grabber and response-provoker, it worked, though I'm more accustomed to it being used in the strictly literal sense. As well, I've generally stopped responding to it, so it's a measure of your credibility that it was not passed on in this case.

Thanks for your view.

You're most welcome, and thanks for your gracious reception of it.

Perhaps this full video smearogram may be of use:
http://www.youtube.com/watch?v=rX16SNJEaHw

That's quite excellent, thanks for putting it up for others to see. I've treated myself to such back at the beginning of the year

http://the911forum.freeforums.org/technical-notes-on-video-motion-analysis-t55-195.html#p1448

but opted not to post the video.

I shall be producing velocity and perhaps acceleration data from a range of frames, hopefully automatically. From several frames already tested, I find very little difference in acceleration.

I believe that, upon more thorough examination, you'll find there's quite a significant variation across the roofline.



http://the911forum.freeforums.org/technical-notes-on-video-motion-analysis-t55-150.html#p1236

Dare I say not all research has found its way to YouTube or the front page of 911Blogger? Some of it is tucked away from casually perusing eyes.

I will not be limiting my view to an 8x8 segment. I will be looking at all possible data.

I pointed you to the 8x8 (roughly - pulled that number out of my ass) because that's the only place the claim (almost) holds true. Confirmation (or refutation) is always welcome. Though, I'm pretty burnt out on the subject in general, and Chandler's results in particular.

OneWhiteEye wrote:I've treated myself to such back at the beginning of the year
http://the911forum.freeforums.org/technical-notes-on-video-motion-analysis-t55-195.html#p1448
but opted not to post the video.

Aha. Cool. Do you have a link to the source video you used ? It would probably be beneficial to use the same source.

I believe that, upon more thorough examination, you'll find there's quite a significant variation across the roofline.

As is my, er, wont, I'm trying to also account for perspective/viewpoint in the code. What with also trying to programatically identify sub-pixel data points automatically too, there's a lot of room for error until I nail the methods. I'm very open to knowing what methods you use for sub-pixel data point identification (I'm basing on overcomplicated FFT eurgh) and also a preferred method to 'convert' velocity to accel in code

I'd really like to get to a point where it's point and click (with the obvious need to map perspective to a 3d shape 'manually'-ish...which will also hopefully sort out the scaling)

http://the911forum.freeforums.org/technical-notes-on-video-motion-analysis-t55-150.html#p1236

Dare I say not all research has found its way to YouTube or the front page of 911Blogger? Some of it is tucked away from casually perusing eyes.

More aha. Long thread I never noticed. Shall have to trawl through it...

I pointed you to the 8x8 (roughly - pulled that number out of my ass) because that's the only place the claim (almost) holds true. Confirmation (or refutation) is always welcome. Though, I'm pretty burnt out on the subject in general, and Chandler's results in particular.

What I hope to achieve is the creation of 'some code' using the smearogram method and some surface fitting that means a whole number of different video's can be processed and 'stacks' of velocity and acceleration data generated without getting my hands dirty, or more specifically, not putting my grubby hands on the data, nor my unavoidable 'bias'.
The end result should be fairly 'definitive' you think ?

Do you have a link to the source video you used ?

I think I got it from einsteen, it was the best to be had for me at the time, but what do you want to bet you already have a better copy? It's the CBS video (NIST camera 3). Still, I'll try to dig it up.

As is my, er, wont, I'm trying to also account for perspective/viewpoint in the code. What with also trying to programatically identify sub-pixel data points automatically too, there's a lot of room for error until I nail the methods. I'm very open to knowing what methods you use for sub-pixel data point identification (I'm basing on overcomplicated FFT eurgh) and also a preferred method to 'convert' velocity to accel in code.

Perspective correction is a very good thing! More power to you in these endeavours. As to sub-pixel methods, I've had success with two very simple methods and a variation on both. The thread I linked to has, interspersed amongst it, comments on the various methods. It always involves a calculation of a weighted geometric center or threshold, whether by intensity or difference, using blob or edge. Seems to work well enough for most things. For edge detection calculations, I use Hornet's Eye (if Ruby) and OpenCV (if C++). Ruby is more handy for me for most little things; speed is not an issue, coding time is.

I'd really like to get to a point where it's point and click (with the obvious need to map perspective to a 3d shape 'manually'-ish...which will also hopefully sort out the scaling)

That would be great - at the very least.

The end result should be fairly 'definitive' you think ?

Definitive as to whether it's correct on any level to claim 2.25 seconds of freefall for WTC7? Yes, I think the analysis will be definitive. I'm satisfied that the claim of freefall is majority false, at least as a gross assessment, if you can appreciate the fuzzy logic of that. I've got the tweezers and microscope out, more so than anyone prior of which I'm aware, and the trail disappears into legitimate ambiguity.

The issue of whether this is 'natural' or not is beyond that, and subject to additional considerations, some of which I'm dimly aware. Enough to believe the root of the observed mechanics is deeper than descent rate, thus with diminishing returns for increasing effort, I've back-burnered the WTC7 motion thing. It is odd, but not as odd as it once seemed. It is nonetheless, to my satisfaction, unexplained.

Good work does not go unappreciated, universally. There may be a small audience of consumers; best to do what you find most useful and revealing for your own purposes.

OneWhiteEye wrote:Definitive as to whether it's correct on any level to claim 2.25 seconds of freefall for WTC7?

Not specifically, more definitive in the sense that the 'output' data is untouched by biased hand on either side of the fence. I'm obviously on the "d" side of the fence, but that's irrelevant.
I'm already aware that the rate is not exactly free-fall, and it's not exactly 2.25s either. Varies all the time, of course.
Spending a bit of time to generate some code that allows automatic generation of, say, 200 velocity and acceleration graphs (and data) per video, which can be re-used on multiple videos and by multiple people seems a better use of time than the tedium of generating even a few of those individual graphs

Good work does not go unappreciated, universally. There may be a small audience of consumers; best to do what you find most useful and revealing for your own purposes.

My view is do what you can do, especially if it hasn't already been done, or if it has, make it better.

femr2 wrote:Spending a bit of time to generate some code that allows automatic generation of, say, 200 velocity and acceleration graphs (and data) per video, which can be re-used on multiple videos and by multiple people seems a better use of time than the tedium of generating even a few of those individual graphs

I totally agree. Especially having gone through the tedium of doing some manually. I got to this point with automation and WTC7:

http://the911forum.freeforums.org/technical-notes-on-video-motion-analysis-t55-255.html#p2159

when I stopped.

...also a preferred method to 'convert' velocity to accel in code.

Given the noisy nature of the position data, the best approach seems to be doing a piecewise fit of that, then take derivates of the resulting analytic representation for v and a. Sort of like what NIST did, only a lot less sloppy and not one-size-fits-all. What is used to fit the pieces depends on what fits best under a variety of mostly subjective criteria.

I apologize my disappearance. I sort of lost interest for this problem. Now I have spend some more time for it. Yes, the curve in the first post is totally wrong. I apologize that crappy work. Two mistakes were made:

Mistake 1.
I assumed that the camera is not rotating so much that it don't affect the results. So I was using directly the y pixel positions from the bitmap as vertical measurement. I was using mid-point of the white house windows and projecting it using same y-level of the bitmap to the WTC7. So when camera rotates then the height of the projection in the bitmap also changes. That of course makes lots of error.

Mistake 2.
I was assuming that the heights of the floors do not change. The new measurements shows that this is not exactly true. It seems that after frame at 2.466s some floors compresses slightly (1 or 2 centimeters/floor). This was no good because I was using these measured floor heights for canceling the zooming-out of the camera.

The new measurements:

Extension of the white house windows-line to the WTC7 is used for horizontal fixed point from which the dropping is measured.

Distances between windows in the white house are used for cancel zooming-out. Fortunately camera stops zooming out after a while. The last zooming frame is at 2.433s and first no zooming frame is 2.466s. So starting at frame 2.466s canceling zooming-out errors is reduced because same zooming canceling factor (average from the rest of the frames) can be used.

The transformation of the pixels to the real world (meters) is done using first frame and measuring pixel distance of the first and the third (last) window row in a 3 window row group (see the picture in the first post). The known floor height of 3.886 m is used. Perspective changes are not calculated which causes some error but not much, since only 1 meter of vertical movement is measured.

Unfortunately white house windows are a bit blurry but I did not found any better reference points. The results are shown as two pairs of curves.

First pair:
The upper pair (blue, green) in the graph is dropping of the lower 3 window-row group in the WTC7 (see the picture in the first post). The blue graph is measured by using upper and the green lower windows row from the white house.

Second pair:
The lower pair (red, magenta) in the graph is dropping of the upper 3 window-row group in the WTC7 (see the picture in the first post). The red graph is measured by using upper and the magenta lower windows row from the white house.

So the variations in the pairs indicates error of measurements from the white house.

The measurements are done relative to the first frame (2.266s) so that the curves starts 0. The height difference between two row-groups are 10 floors. After 2.466s the building between the two groups seems to compress about 15-20 cm which means less than 2 cm per floor.

Speed is calculated using results from one frame before and one after from distance graph.

Acceleration is calculated using results from one frame before and one after from the speed graph.

Unfortunately the speed and acceleration graphs are too "shaky" to be any use. Some smoothing and measurements for longer time is needed.

-Sulifeg

Hi.

Could you include the raw data (in delimited form) please ?

femr2 wrote:Hi.

Could you include the raw data (in delimited form) please ?

I am just wondering wheather the 15-20 cm "drop" at 2.466s is some sort of perspective illusion. It seems that there are at that time longer and faster horizontal movements going on. I am thinking to make slow motion stabilized, enhanced and enlarged video of this to see better how the measurements makes sense.

Here is the numeric data. See the picture of the A,B,Dt0,Dt1,Dt2,Db0,Db1,Db2 locations.

-sulifeg


Raw pixel coordinates:
=====================
Upper windows row in the white house and the left side in the WTC7 (the labeled crosses in the picture).

Time,Ax,Ay,Bx,By,Dt0x,Dt0y,Dt1x,Dt1y,Dt2x,Dt2y,Db0x,Db0y,Db1x,Db1y,Db2x,Db2y

2.26667,155.846,398.405,332.676,422.25,497.959,71.8194,498.089,94.297,498.219,116.585,499.273,297.885,499.408,321.027,499.541,343.93
2.3,159.534,393.383,329.682,416.378,488.697,79.3876,488.825,100.904,488.953,122.342,489.993,297.005,490.125,319.133,490.256,341.211
2.33333,162.862,389.411,326.792,411.32,479.48,86.5632,479.643,107.445,479.804,128.016,481.121,296.03,481.288,317.409,481.456,338.738
2.36667,166.404,385.605,324.483,406.782,471.871,94.1148,472.007,114.068,472.143,134.097,473.246,295.812,473.387,316.518,473.527,337.041
2.4,168.816,381.934,321.312,402.547,463.834,101.101,463.951,120.182,464.068,139.484,465.021,295.602,465.143,315.607,465.265,335.504
2.43333,170.448,380.797,319.563,400.576,458.533,105.696,458.661,124.461,458.789,143.173,459.83,295.999,459.961,315.253,460.093,334.646
2.46667,167.656,381.181,315.246,400.741,453.361,108.463,453.494,127.181,453.625,145.646,454.702,297.257,454.837,316.309,454.974,335.555
2.5,163.132,382.592,310.731,402.174,448.455,110.622,448.579,129.249,448.703,147.862,449.707,298.925,449.833,317.928,449.961,337.149
2.53333,157.849,384.051,305.556,403.736,443.498,112.482,443.602,131.132,443.706,149.681,444.551,300.7,444.658,319.809,444.766,339.077
2.56667,151.829,386.752,299.493,406.642,437.861,115.556,437.936,134.292,438.009,152.714,438.61,303.735,438.686,322.855,438.763,342.085
2.6,145.002,389.125,293.114,409.212,431.751,118.5,431.786,137.088,431.821,155.595,432.105,306.504,432.14,325.44,432.177,344.877
2.63333,138.547,390.963,286.351,411.214,425.677,120.843,425.687,139.427,425.697,158.063,425.78,308.934,425.791,328.012,425.802,347.404
2.66667,132.785,393.785,280.603,414.226,420.514,124.35,420.484,142.892,420.454,161.55,420.209,312.479,420.178,331.524,420.147,350.72
2.7,127.859,395.99,275.573,416.419,415.763,126.663,415.73,145.322,415.698,163.818,415.43,314.881,415.396,333.996,415.362,353.194
2.73333,124.548,398.199,272.018,418.694,412.721,129.613,412.658,148.351,412.595,166.774,412.084,317.78,412.019,336.769,411.955,355.912
2.76667,122.388,400.984,269.97,421.583,410.487,132.737,410.421,151.342,410.355,169.832,409.818,320.755,409.749,339.934,409.682,358.897
2.8,120.675,403.771,268.325,424.281,408.705,135.726,408.644,154.413,408.583,172.832,408.083,323.716,408.02,342.839,407.956,362.108
2.83333,119.846,406.8,267.426,427.334,408.157,139.373,408.08,157.824,408.003,176.387,407.378,327.164,407.299,346.383,407.219,365.645
2.86667,120.189,411.009,267.656,431.913,408.928,144.783,408.831,163.256,408.735,181.8,407.949,332.759,407.849,351.894,407.75,371.004
2.9,122.682,415.077,270.152,436.088,411.77,149.724,411.643,168.167,411.515,186.728,410.475,337.699,410.343,356.819,410.212,375.728


Lower windows row in the white house and the right side in the WTC7 (the non labeled crosses in the picture)

Time,Ax,Ay,Bx,By,Dt0x,Dt0y,Dt1x,Dt1y,Dt2x,Dt2y,Db0x,Db0y,Db1x,Db1y,Db2x,Db2y

2.26667,155.435,427.742,332.505,450.035,576.216,93.0817,576.451,114.996,576.687,137.053,578.577,313.605,578.815,335.813,579.054,358.092
2.3,159.083,421.639,329.298,443.144,563.906,99.9583,564.134,120.972,564.363,142.049,566.208,312.096,566.439,333.351,566.673,354.915
2.33333,162.443,416.67,326.589,437.097,552.04,106.817,552.285,126.457,552.54,146.826,554.587,310.779,554.843,331.271,555.098,351.667
2.36667,166.101,411.848,324.228,431.63,541.59,113.473,541.815,132.735,542.044,152.306,543.889,309.788,544.125,329.875,544.357,349.674
2.4,168.51,407.278,321.192,426.529,531.208,119.71,531.406,138.359,531.606,157.143,533.228,309.439,533.434,328.768,533.635,347.714
2.43333,170.125,405.508,319.484,424.038,524.36,123.728,524.58,141.91,524.804,160.495,526.604,309.247,526.832,328.068,527.06,346.906
2.46667,167.26,405.735,315.41,424.064,518.694,126.38,518.92,144.501,519.151,162.977,520.988,310.243,521.224,329.103,521.455,347.599
2.5,162.752,407.04,310.532,425.383,513.647,129.064,513.86,146.984,514.076,165.163,515.823,312.031,516.046,330.782,516.267,349.395
2.53333,157.483,408.557,305.406,427.01,508.647,130.843,508.832,148.785,509.019,166.862,510.536,313.865,510.729,332.618,510.921,351.203
2.56667,151.405,411.277,299.146,429.829,502.753,133.98,502.937,151.974,503.123,170.198,504.624,317.055,504.816,335.825,505.006,354.415
2.6,144.674,413.699,292.67,432.396,496.508,136.832,496.669,154.903,496.833,173.197,498.148,320.218,498.315,338.872,498.48,357.389
2.63333,137.959,415.467,286.073,434.412,490.431,139.556,490.559,157.533,490.688,175.733,491.729,322.579,491.861,341.294,491.992,359.787
2.66667,132.299,418.36,280.213,437.459,485.109,143.054,485.201,161.016,485.294,179.269,486.042,326.102,486.137,344.842,486.232,363.422
2.7,127.491,420.556,275.505,439.654,480.301,145.619,480.396,163.571,480.492,181.773,481.271,328.565,481.369,347.174,481.468,365.846
2.73333,124.039,422.709,271.784,441.94,477.089,148.405,477.167,166.53,477.244,184.695,477.87,331.474,477.95,350.053,478.029,368.727
2.76667,121.784,425.504,269.644,444.775,474.913,151.601,474.976,169.654,475.04,187.996,475.551,334.57,475.616,353.181,475.681,371.791
2.8,120.037,428.329,268.077,447.508,473.01,154.546,473.103,172.639,473.196,190.95,473.943,337.496,474.039,356.345,474.133,374.786
2.83333,119.243,431.333,267.199,450.566,472.42,158.153,472.497,176.269,472.574,194.512,473.196,341.207,473.275,359.819,473.354,378.366
2.86667,119.571,435.547,267.511,455.206,473.333,163.542,473.374,181.589,473.415,200.016,473.744,346.636,473.786,365.307,473.828,383.941
2.9,121.981,439.63,270.045,459.336,475.911,168.444,475.957,186.369,476.004,204.75,476.38,351.634,476.428,370.255,476.475,388.959

Results:
========
Distance Db (white house lower)
Time, distance(m)
2.26667,-8.1726e-16
2.3,-0.00207901
2.33333,-0.0397954
2.36667,-0.0577452
2.4,-0.0897156
2.43333,-0.112538
2.46667,-0.124887
2.5,-0.194071
2.53333,-0.223853
2.56667,-0.250362
2.6,-0.29607
2.63333,-0.329755
2.66667,-0.38414
2.7,-0.437031
2.73333,-0.506861
2.76667,-0.554747
2.8,-0.642239
2.83333,-0.726634
2.86667,-0.797931
2.9,-0.955329

Distance Db (white house upper)
Time, distance(m)
2.26667,-4.36031e-16
2.3,-0.0196658
2.33333,-0.0368711
2.36667,-0.0686887
2.4,-0.0885402
2.43333,-0.131861
2.46667,-0.144007
2.5,-0.209231
2.53333,-0.251584
2.56667,-0.243302
2.6,-0.284931
2.63333,-0.322439
2.66667,-0.384029
2.7,-0.424399
2.73333,-0.516442
2.76667,-0.540716
2.8,-0.62964
2.83333,-0.721354
2.86667,-0.811777
2.9,-0.940121

Distance Dt (white house lower)
Time, distance(m)
2.26667,-9.01047e-16
2.3,0.0243172
2.33333,-0.0580848
2.36667,-0.107094
2.4,-0.127928
2.43333,-0.159879
2.46667,-0.155607
2.5,-0.353991
2.53333,-0.377091
2.56667,-0.412461
2.6,-0.461984
2.63333,-0.508165
2.66667,-0.560274
2.7,-0.61661
2.73333,-0.706879
2.76667,-0.769049
2.8,-0.85068
2.83333,-0.940919
2.86667,-0.996526
2.9,-1.14458

Distance Dt (white house upper)
Time, distance(m)
2.26667,-6.96853e-17
2.3,0.00637464
2.33333,-0.0551013
2.36667,-0.118259
2.4,-0.126729
2.43333,-0.179593
2.46667,-0.175114
2.5,-0.369457
2.53333,-0.405383
2.56667,-0.405258
2.6,-0.45062
2.63333,-0.500702
2.66667,-0.560161
2.7,-0.603722
2.73333,-0.716654
2.76667,-0.754734
2.8,-0.837827
2.83333,-0.935532
2.86667,-1.01065
2.9,-1.12907

Velocity Db (white house lower)
Time, velocity(m/s)
2.3,-0.59699
2.33333,-0.835076
2.36667,-0.748878
2.4,-0.821968
2.43333,-0.527624
2.46667,-1.22313
2.5,-1.48464
2.53333,-0.844441
2.56667,-1.08335
2.6,-1.19101
2.63333,-1.32118
2.66667,-1.60931
2.7,-1.84101
2.73333,-1.76591
2.76667,-2.03088
2.8,-2.57856
2.83333,-2.3356
2.86667,-3.43076

Velocity Db (white house upper)
Time, velocity(m/s)
2.3,-0.553122
2.33333,-0.735418
2.36667,-0.775113
2.4,-0.947676
2.43333,-0.832092
2.46667,-1.16066
2.5,-1.6138
2.53333,-0.511119
2.56667,-0.500255
2.6,-1.18718
2.63333,-1.48663
2.66667,-1.52956
2.7,-1.98639
2.73333,-1.74492
2.76667,-1.69815
2.8,-2.70985
2.83333,-2.73232
2.86667,-3.28183

Velocity Dt (white house lower)
Time, velocity(m/s)
2.3,-0.871359
2.33333,-1.97137
2.36667,-1.04775
2.4,-0.79185
2.43333,-0.415235
2.46667,-2.91197
2.5,-3.32259
2.53333,-0.877145
2.56667,-1.27352
2.6,-1.4357
2.63333,-1.47449
2.66667,-1.62683
2.7,-2.1993
2.73333,-2.28681
2.76667,-2.15723
2.8,-2.57831
2.83333,-2.18791
2.86667,-3.05528

Velocity Dt (white house upper)
Time, velocity(m/s)
2.3,-0.826603
2.33333,-1.86969
2.36667,-1.07452
2.4,-0.920101
2.43333,-0.725861
2.46667,-2.84824
2.5,-3.45437
2.53333,-0.537079
2.56667,-0.678628
2.6,-1.43179
2.63333,-1.64328
2.66667,-1.54547
2.7,-2.34763
2.73333,-2.2654
2.76667,-1.81777
2.8,-2.71225
2.83333,-2.59265
2.86667,-2.90333

Acceleration Db (white house lower)
Time, acceleration(m/s^2)
2.33333,-2.2782
2.36667,0.196613
2.4,3.31864
2.43333,-6.01714
2.46667,-14.3545
2.5,5.68006
2.53333,6.01897
2.56667,-5.19825
2.6,-3.56726
2.63333,-6.27425
2.66667,-7.79694
2.7,-2.3489
2.73333,-2.84789
2.76667,-12.1891
2.8,-4.57069
2.83333,-12.7824

Acceleration Db (white house upper)
Time, acceleration(m/s^2)
2.33333,-3.32971
2.36667,-3.18372
2.4,-0.854632
2.43333,-3.19461
2.46667,-11.7251
2.5,9.74265
2.53333,16.7024
2.56667,-10.1404
2.6,-14.7948
2.63333,-5.1355
2.66667,-7.49612
2.7,-3.23028
2.73333,4.3235
2.76667,-14.4731
2.8,-15.5118
2.83333,-8.57925

Acceleration Dt (white house lower)
Time, acceleration(m/s^2)
2.33333,-2.64572
2.36667,17.6919
2.4,9.48724
2.43333,-31.8002
2.46667,-43.6082
2.5,30.5209
2.53333,30.7345
2.56667,-8.37795
2.6,-3.01436
2.63333,-2.86681
2.66667,-10.8715
2.7,-9.89919
2.73333,0.630912
2.76667,-4.37231
2.8,-0.460097
2.83333,-7.1542

Acceleration Dt (white house upper)
Time, acceleration(m/s^2)
2.33333,-3.7185
2.36667,14.2432
2.4,5.22954
2.43333,-28.9206
2.46667,-40.9256
2.5,34.6656
2.53333,41.634
2.56667,-13.42
2.6,-14.4691
2.63333,-1.70502
2.66667,-10.5646
2.7,-10.7984
2.73333,7.94737
2.76667,-6.70253
2.8,-11.6226
2.83333,-2.86605

Here is some clarification how the dropping is calculated from the raw bitmap points. See point locations (A,B,Dt0,Dt1,Dt2,Db0,Db1,Db2) from the picture:
http://redirectingat.com/?id=593X1004&u ... 720378.jpg
A fixed height from ground as reference point (F) is calculated by drawing horizontal line A-B and vertical line Dt0-Db2. The intersection of these two lines is the reference point (F).

Zooming
=======

The Zooming-out is eliminated. It assumed that when camera is zooming-out it preserves ration of distances and points which are at same line keeps at same line in zooming (affine transformation).

Average distances of points A and B from two windows rows in the white house for each frame i is calculated as lengthAB[i].

Antizooming factor k[i] for each frame is calculated.
For the first 6 frames (2.266s-2.433s) (camera is zooming out):
k[i] = lengthAB[0] / lengthAB[i]

For the rest 14 frames (2.466s- 2.9s) average lengths are used (camera is not zooming):
k[i] = lengthAB[0] / averageLengthAB

Each point (A,B,Dt0,Dt1,Dt2,Db0,Db1,Db2 and F) is multplied by this antizooming factor k[i].

Now the zooming-out is eliminated and the pixel scales were adjusted as in the first frame.

Dropping
========
The averages (Dt) of points Dt0, Dt1, Dt2 is calculated for each frame.
The pixel size is determined as (2*"floor height") / "Dt0-Dt2 distance". Floor height of 3.886 m is used. The pixel size is calculated only from the first frame (average of all frames is not used because floor heights seems to shorten). Here is a chance for a tiny error if floor heights are already compressed in the first frame so that heights are not exactly 3.886 m any more.

FD[i] = distance from reference point F[i] to Dt[i].
Drop distance relative to first frame: drop[i] = FD[i] - FD[0].

Now the drops can be transformed to real world (meters) by pixel size:
"drop in meters"[i] = "pixel size" * drop[i].

This is now from the left side. The right side is calculated similarly and the results are averaged from the both sides.

The lower group (Db0, Db1, Db2) is calculated similarly.

Note that the reference to the "right side" is a bit misleading. More accurate should be something "mid-right". The results are probably a bit different from the left and "mid-right" sides because left side is nearer to the corner.

Here is actually measured distances to the vertical direction of the building which is not of course exactly vertical because it is "swinging" a bit. However if I understand correctly this causes only tiny fraction of percent error. Also perspective correction is omitted; the drop is only about 1 meter so it should not affect much.

-Sulifeg