Merged Discussion of femr's video data analysis

[femr2]

Was the 2.25 relevant?

Relevant to WHAT ? (I suspect you are yet again talking about your personal viewpoint about the *big picture*. Need I remind you AGAIN about the context ? Are you capable of retaining limited scope in discussion ?)

The *2.25* is wrong.

Did cmatrix have a valid argument for the relevance of precisely 2.25s, rather than 2.24 or 2.26s?

His interpretation of the NIST statement is exactly what I was trying to address by providing him with better data and taking the time to explain why his stance requires a rethink. In this thread you are supposed to be discussing my video data, not cmatrix's world-view.

Your +/-0.01s variance focus is bizarre.

I'm sure the relevance to him is not about the exact period of exact gravitational acceleration experienced by the entire north face of WTC7 by his interpretation of the released NIST information.

Is the <0.1s any more or less relevant, and what is YOUR argument for that?

<0.1s is more accurate. My *argument* for that is that in any such large scale descent of interconnected members suggesting that any portion of it experienced exactly freefall acceleration for any sustained amount of time is *bonkers*

(The trace data derived acceleration profiles also support the *argument* )

Yes, he THINKS, but he is wrong, and it this wrongness that needs to be pointed out, not the irrelevant last digits

Again, remember what thread you are in.

NO-ONE is discussing the last digits. What on earth are you talking about ?

I agree that the *wrongness* needs pointing out, which is what I was doing. How are you doing that ? Educating him by pointing at a picture of a kitten and laughing ? Way to go teach' You must just enjoy the argument. What a miserable existence. Go find a beach.

The refutation lies not in improving on the resolution of g-value and time, the refutation lies in pointing out that free-fall, or anything very near, or above free-fall, is NOT refuting NISTs conclusions and NOT evidence for cmatrix' delusions.

I don't agree. The only way cmatrix will let go of the specific use of the NIST statement is for him to be provided with information and understanding which *debunks* (for want of a better word, that one sucks) his viewpoint. Providing him with the detail totally lacking in the NIST data, and pointing out that the phrases being latched onto are incorrect should remove that particular element from his *pot of stuff*. Will it work ? Who knows. You are not interested in trying to change his viewpoint it seems. You just want to waste my time saying *it woz foire wot dun it* like a blithering buffoon *debunker* who has already admitted he is incapable of refuting the blindingly simple points I have listed I have issue with in the relevant NIST text, even though you say you have issue with them. Nonsense

Chandler's and NIST's data was already good enough to debunk his ridiculous claim of "simultanious loss of support".

Clearly not.

Your improvement on trailing digits has not changed that argument one iota!

My improvement is not *trailing digits*. That is a woeful interpretation.

The only way to pull that tooth is to establish that there is no proof for relevance.

Then do so, but not here. Go talk to cmatrix.

If you have a problem with my data, be specific, be detailed, don't wave your hands.

 

[femr2]

Bored of others bringing issues with cmatrix to my doorstep.

Go talk to him, or do it in the appropriate thread.

So...

NISTs choice of location and methodology for their WTC7 position/time trace is a significant problem for their data because...
a) They misinterpreted initial motion as vertical rather than north-south (as they did not take account of the initial twisting motion visible from the Cam#3 viewpoint).
b) They did not perform perspective correction.
c) They did not perform static point extraction (the removal of camera movement from trace data. Even though the view may look static, it is not.)
d) They did not track a feature at all, but a horizontal position. As the building did not descent completely vertically, but included some east-west movement, their data is actually of a wandering horizontal point, not a feature on the facade.
e) In order to obtain a trace from their initial point to their stated final point they had to *splice* together two traces from completely different horizontal positions, which without taking account of the perspective and distance shearing effects makes the data further skewed.
f) They did not treat the base video data correctly, using an interlaced copy of the video (the actual copy they used is available within the recent FOIA releases. I have the original)
g) They did not perform a per-frame trace, but instead skipped frames, reducing the sampling rate considerably and reducing available data redundancy for the purposes of noise reduction and derivation of velocity and acceleration profile data.
h) They applied their interpretation to the entire north face.
i) It is highly probable they used a manual process to record the trace data, rather than the sub-pixel accurate automated feature tracing methods I employ.

These are some of the reasons their data is shoddy and their method sloppy.

 

[DGM]

Bored of others bringing issues with cmatrix to my doorstep.

Go talk to him, or do it in the appropriate thread.

So...

NISTs choice of location and methodology for their WTC7 position/time trace is a significant problem for their data because...
a) They misinterpreted initial motion as vertical rather than north-south (as they did not take account of the initial twisting motion visible from the Cam#3 viewpoint).
b) They did not perform perspective correction.
c) They did not perform static point extraction (the removal of camera movement from trace data. Even though the view may look static, it is not.)
d) They did not track a feature at all, but a horizontal position. As the building did not descent completely vertically, but included some east-west movement, their data is actually of a wandering horizontal point, not a feature on the facade.
e) In order to obtain a trace from their initial point to their stated final point they had to *splice* together two traces from completely different horizontal positions, which without taking account of the perspective and distance shearing effects makes the data further skewed.
f) They did not treat the base video data correctly, using an interlaced copy of the video (the actual copy they used is available within the recent FOIA releases. I have the original)
g) They did not perform a per-frame trace, but instead skipped frames, reducing the sampling rate considerably and reducing available data redundancy for the purposes of noise reduction and derivation of velocity and acceleration profile data.
h) They applied their interpretation to the entire north face.
i) It is highly probable they used a manual process to record the trace data, rather than the sub-pixel accurate automated feature tracing methods I employ.

These are some of the reasons their data is shoddy and their method sloppy.

Fantastic.

Now please remember to let us know how NIST replies to your concerns.

 

[alienentity]

Bored of others bringing issues with cmatrix to my doorstep.

Go talk to him, or do it in the appropriate thread.

So...

NISTs choice of location and methodology for their WTC7 position/time trace is a significant problem for their data because...
a) They misinterpreted initial motion as vertical rather than north-south (as they did not take account of the initial twisting motion visible from the Cam#3 viewpoint).

Your data in support of this? Your calculations for the degree of error?

b) They did not perform perspective correction.

Your proof of this?

d) They did not track a feature at all, but a horizontal position. As the building did not descent completely vertically, but included some east-west movement, their data is actually of a wandering horizontal point, not a feature on the facade.

Your proof of the tracking point? Do you have their actual input data or are you inferring from their documents?

e) In order to obtain a trace from their initial point to their stated final point they had to *splice* together two traces from completely different horizontal positions, which without taking account of the perspective and distance shearing effects makes the data further skewed.

Specifically how is this so, from a technical perspective?

f) They did not treat the base video data correctly, using an interlaced copy of the video (the actual copy they used is available within the recent FOIA releases. I have the original)

To what degree does this affect the measurements? Precisely?

h) They applied their interpretation to the entire north face.

You've just done the same thing but using the NW corner. Pot meet Kettle.

i) It is highly probable they used a manual process to record the trace data, rather than the sub-pixel accurate automated feature tracing methods I employ.

More speculation. You have not contacted NIST to confirm these claims.

These are some of the reasons their data is shoddy and their method sloppy.

And still irrelevant to the cause of the collapse, as is your nitpicking.

On the relevant subject of irrelevant nitpicking, suppose a blue car runs thru a red light and crashes into a green car, injuring the occupants of the green car. The 'official investigation' gives the velocity of the blue car at '__m/s', based on grainy video taken from a redlight camera.
Years later, an anonymous internet savant remeasures the data, applies different smoothing algorhithms, measures from a different part of the blue car, and then declares the work of the 'official story' 'shoddy and their method sloppy'. He produces graphs showing the velocity at '>__m/s'.

Of course these measurements are irrelevant to the fact that the blue car ran thru a red light and hit the green car.

But the constant doubt, helped by repeated use of adjectives such as 'shoddy' and 'sloppy', feeds directly into the CrashTruth movement started by the owners of the blue car, who are disputing responsibility for the crash, denying that they were even there.

Many internet pundits who follow the movement online claim that the crash evidence was itself faked, and are demanding a new investigation into it. They accuse the authorities of a massive coverup.

etc.....

 

[Oystein]

Relevant to WHAT ? (I suspect you are yet again talking about your personal viewpoint about the *big picture*. Need I remind you AGAIN about the context ? Are you capable of retaining limited scope in discussion ?)

Exactly, to what? That is the mystery here. Is there any little picture, except for the data itself?

The *2.25* is wrong.

Your data is certainly wrong in the very same sense that in theory resolution could be raised again, and that would show your data points to be inaccurate.
I read the other's worries about you not providing an estimate of error ranges, and to that extent, your data is, with mathematical certainty, wrong in every digit.

Which no one criticizes, because, well, it's irrelevant. For anything except the accuracy of the data itself.

His interpretation of the NIST statement is exactly what I was trying to address by providing him with better data and taking the time to explain why his stance requires a rethink. In this thread you are supposed to be discussing my video data, not cmatrix's world-view.

I am following cmatrix in other threads, and he is not about a valid interpretation of NIST's data and conclusions. He is about showing NIST wrong. Your data can be summarized as "NIST's data is wrong", and voilá, cmatrix got the desired result.

Your +/-0.01s variance focus is bizarre.

That's why I posted it. It IS bizarre.

I'm sure the relevance to him is not about the exact period of exact gravitational acceleration experienced by the entire north face of WTC7 by his interpretation of the released NIST information.

So what IS the relevance to him?

<0.1s is more accurate. My *argument* for that is that in any such large scale descent of interconnected members suggesting that any portion of it experienced exactly freefall acceleration for any sustained amount of time is *bonkers*

Of course it is. We didn't need your analysis to know that.

(The trace data derived acceleration profiles also support the *argument* )

? Never mind. I am getting tired, losing context.

Again, remember what thread you are in.

One opened by tfk, not cmatrix...

NO-ONE is discussing the last digits. What on earth are you talking about ?

Inproved accuracy of irrelevant data that stays irrelevant. For anything I can think of, except for lovers of more accurate data.

I agree that the *wrongness* needs pointing out, which is what I was doing. How are you doing that ? Educating him by pointing at a picture of a kitten and laughing ? Way to go teach' You must just enjoy the argument. What a miserable existence. Go find a beach.

Can you link to a laughing/kitten post by me?
You are pointing out the wrongness of the irrelevant data. I am pointing out the wrongness about claims of its relevance (for anything except lovers of accuracy). I do that right here. Now. And whereever and whenever I see cmatrix make a claim that a period of free fall does thermite mean.

I don't agree. The only way cmatrix will let go of the specific use of the NIST statement is for him to be provided with information and understanding which *debunks* (for want of a better word, that one sucks) his viewpoint. Providing him with the detail totally lacking in the NIST data, and pointing out that the phrases being latched onto are incorrect should remove that particular element from his *pot of stuff*. Will it work ? Who knows. You are not interested in trying to change his viewpoint it seems. You just want to waste my time saying *it woz foire wot dun it* like a blithering buffoon *debunker* who has already admitted he is incapable of refuting the blindingly simple points I have listed I have issue with in the relevant NIST text, even though you say you have issue with them. Nonsense

...and giving him a pot of better stuff to misconstrue.
His argument never held water, even with NIST's sloppy wording and limited accuracy, because freefall does not CD mean. Or at least he never made a convincing argument to that effect.

...
Then do so, but not here. Go talk to cmatrix.

Oh - where is cmatrix, anyway? If this thread is for his benefit...? (Maybe that's my misconception)

If you have a problem with my data, be specific, be detailed, don't wave your hands.

Except for a bad feeling about not seeing error estimates, I have no problem with your data.
Outta here

 

[alienentity]

What Femr2 won't do, (he's flatly refused to) is to get the full data from NIST and use it to correlate his work.

He doesn't know what the actual point used by NIST was. He doesn't even seem to care.

He doesn't want to publish his findings in a conventional journal, where they could be attached to his real identity, and perhaps even be brought to NIST's attention.

If he's trying to produce something useful, it's very difficult to see why he's behaving the way he is. Certainly his methods appear woefully inadequate to provoke any meaningful change.

I guess that's why he's still an obscure, anonymous internet guy. No coincidence there.

 

[femr2]

Your data in support of this?

I'll dig you out some links from the911forum, but for simplicity the behaviour is confirmed by comparison of the roofline behaviour between the Dan Rather Viewpoint and the NIST Cam#3 viewpoint.

NIST set their T₀ at the point in time that the colour of a pixel on the roofilne began to lighten. Cross-checking the roofline behaviour with a synchronised copy of the Dan Rather viewpoint shows that early motion does not occur in the vertical direction.

I will go into more detail on this point later.

Your calculations for the degree of error?

Via synchronised Dan Rather viewpoint data...

I estimate their T0 to be off by ~1 second.

Your proof of this?

The NIST report.

Your proof of the tracking point?

The NIST report. They are a bit wooly with the actual location, but clearly state it's a horizontal position within the frame, and not latched to a video feature. Inherent in their method.

Do you have their actual input data or are you inferring from their documents?

The latter.

Specifically how is this so, from a technical perspective?

There is no position on the roofline they could have used which is at the same horizontal location as their end point.

To what degree does this affect the measurements?

Up to ~5% over the vertical height.

Precisely?

Unknown.

You've just done the same thing but using the NW corner.

Nonsense. I am specifically stating results from an individual trace do not apply to the entire face.

speculation.

That is why I use the word *probably*

 

[alienentity]

Femr2, you're glossing over an awful lot of details in terms of what the NIST analysis actually used.

It seems you just don't have a lot of that info and are relying on assumptions and inferences. But you haven't the confirmation in your hands.

I suggest that your next step would be to obtain the actual data.

BTW, I crosschecked 3 different clips which I've used in the past to calculate the fair 'starting point' for the global collapse. They correlate very well with the NIST 5.4s timing.

Instead of using the change of intensity of a pixel, or fixing a particular pixel and tracking it, I magnify the images and scrub thru using a video editor, using my eyes to pick up the macro-changes in the building as it begins to enter global collapse.
One of the clips is shot looking up at the building, another is from a higher perspective. Each one reveals different details as to how the building moved -

My point is that there is no reason to deny that a building is collapsing if it is clearly deforming, even if there is indeed some degree of bowing rather than perfectly vertical motion.
Using those criteria, the 5.4s measurement is valid and very clear to see.

In fact, by using a different method, I've helped to corroborate the NIST findings, independently.

 

[alienentity]

The NIST report. They are a bit wooly with the actual location, but clearly state it's a horizontal position within the frame, and not latched to a video feature. Inherent in their method.

Citation please.

There is no position on the roofline they could have used which is at the same horizontal location as their end point.

I do not agree with this statement, nor (you've admitted it) do you know where the point was.

That is why I use the word *probably*

And why NIST uses the word *approximately*

Maybe they should amend their wording to 'approximately freefall', which is actually what the data in their graphs shows. They graph the data points from which they perform the linear regression, it's fairly elementary to observe the points are not actually linear...... I thought people would understand this, but it seems many are far too literal in their interpretation of prose.....at inappropriate times, that is.

Any road, I might just come out of retirement and make a little vid using your new data, showing that the corner descended faster than freefall. That ought to get the 9/11 bots twittering.
That is if you don't mind me using your graphs...

If you really want to be helpful you might consider using the same methods to trace a couple of real controlled demolitions and see if those accelerate at >G

I don't have the patience or the time to do those m'self.

 

[jay howard]

You don't need to swap the 2.25s for more accurate values. You need to point that either way it's irrelevant, unless he can reasonably argue the relevance! I say you will not convince the likes of cmatrix. His delusion does not hinge on the accuracy of your or NIST's data. Instead, you are pouring water on his mills, because he is convinced that NIST is a fraud, and you are giving him data that he is free to misconstrue as supporting him.

Femr2 has a very good point in response to Oystein's call for relevancy for those looking for a *big picture* assessment of his views:

To whom ? You ? Why ? Because of your onbsession with *the big picture* ? How are you going to change viewpoints without being honest about failings of EVERYONE ?

This really is a puzzling debate, but one thing is clear: there is a real resistance to new information outright. Not after it is properly assessed and sifted from poor information or false information, but before it is even verified.

Now, I am the first to admit I don't have the faintest idea how the technical aspects of this type of pixel analysis work. But it's clear that no one here can find a mistake with femr2's work. And I don't even know why they'd want to, except that by pointing out one single (irrelevant by some accounts) flaw in the NIST analysis of data, they fear the door is open to criticism and re-evaluation of the NIST data.

So instead, they take the Bible model of argumentation.

 

[femr2]

What Femr2 won't do, (he's flatly refused to) is to get the full data from NIST and use it to correlate his work.

Where ? Quote please.

Their data is included in graphical form...

Note the method used for the first graph (12-75)

Note the sparsity of the datapoints in their second (12-76)

Note the sparsity of the datapoints in their third (12-77)

He doesn't know what the actual point used by NIST was.

Correct.

NIST describe it as...

The vertical position of a point near the center of the roofline.

...which implies a whole host of issues, as their lowest point...

when the roofline dropped from view behind the buildings in the foreground

...cannot be in line with their initial chosen point unless they made the even more drastic error of choosing a point at the top of the roof structures rather than the facade parapet wall...

(A) The only region where (unless NIST made the grave error of choosing a point on the roof structure above the parapet wall roofline) their initial point could have been selected.

(B) The region where roofline dropped from view behind the buildings in the foreground.

Note that even selection of a poin in the region (A) suffers from issues due to the distortion from the roof-top structures.

He doesn't even seem to care.

Incorrect.

 

[Reactor drone]

I'll dig you out some links from the911forum, but for simplicity the behaviour is confirmed by comparison of the roofline behaviour between the Dan Rather Viewpoint and the NIST Cam#3 viewpoint.

NIST set their T₀ at the point in time that the colour of a pixel on the roofilne began to lighten. Cross-checking the roofline behaviour with a synchronised copy of the Dan Rather viewpoint shows that early motion does not occur in the vertical direction.

I will go into more detail on this point later.


Via synchronised Dan Rather viewpoint data...
[qimg]http://femr2.ucoz.com/_ph/7/842535832.gif[/qimg]
I estimate their T0 to be off by ~1 second.

What's this supposed to indicate, other than lines look different when you have different vertical scales on them?

 

[alienentity]

Where ? Quote please.

Their data is included in graphical form...
[qimg]http://femr2.ucoz.com/_ph/7/863074218.png[/qimg]

Note the method used for the first graph (12-75)

Note the sparsity of the datapoints in their second (12-76)

Note the sparsity of the datapoints in their third (12-77)


Correct.

NIST describe it as...

The vertical position of a point near the center of the roofline.

...which implies a whole host of issues, as their lowest point...

when the roofline dropped from view behind the buildings in the foreground

...cannot be in line with their initial chosen point unless they made the even more drastic error of choosing a point at the top of the roof structures rather than the facade parapet wall...
[qimg]http://femr2.ucoz.com/_ph/7/2/516330913.png[/qimg]

(A) The only region where (unless NIST made the grave error of choosing a point on the roof structure above the parapet wall roofline) their initial point could have been selected.

(B) The region where roofline dropped from view behind the buildings in the foreground.

Note that even selection of a poin in the region (A) suffers from issues due to the distortion from the roof-top structures.


Incorrect.

Femr2, we've been over this fallacious argument already: The point where the brightness of the pixel was determined is not stated to be the same point where the horizontal position was tracked from. 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.

You and Achimspok keep making the same false assumption about it. (this false either/or business) There is nothing in the NIST wording to support your position, unless you misinterpret the prose.

But you do not have the actual points, therefore you are simply guessing - and guessing wrong, IMO.

Thx for the replies, must leave computer to do other things.

 

[femr2]

Femr2, you're glossing over an awful lot of details in terms of what the NIST analysis actually used.

It seems you just don't have a lot of that info and are relying on assumptions and inferences. But you haven't the confirmation in your hands.

Yawn...
http://femr2.ucoz.com/_ph/7/563913536.png

I suggest that your next step would be to obtain the actual data.

Again, their data is included in graphical form.

BTW, I crosschecked 3 different clips which I've used in the past to calculate the fair 'starting point' for the global collapse. They correlate very well with the NIST 5.4s timing.

Then I suggest you are still making mistakes. Please present your reasoning for the Dan Rather and NIST Cam#3 viewpoints. I have posted you a graph in a recent post containing visual data for the NIST 5.4s time region with perfect frame-sync between my Dan Rather and NIST Cam#3 datasets.

Instead of using the change of intensity of a pixel, or fixing a particular pixel and tracking it, I magnify the images and scrub thru using a video editor, using my eyes to pick up the macro-changes in the building as it begins to enter global collapse.

Then your method is extremely prone to error. I use similar methods myself to gain visual cue understanding. BTW - You should therefore be able to SEE that initial movement from the NIST Cam#3 viewpoint is NOT vertical. NIST simply track intensity changes. They do not make the distinction of direction.

I suggest you acquire one of the available tools to perform feature tracking, as for this purpose your eyes cannot be set against my ~60Hz sub-pixel accurate data in my opinion.

If you insist on using your eyes, use the mpeg version of the Dan Rather clip from xenomorphs site and tell me the timestamp of the frame at which you deem vertical motion to begin. It will make a useful insight into the value of the tracing methods.

My point is that there is no reason to deny that a building is collapsing if it is clearly deforming, even if there is indeed some degree of bowing rather than perfectly vertical motion.

Such data should not be treated as vertical, especially the very sensitive determination of T0.
NIST place that data in a graph titled *Downward displacement*. The earliest moments are not vertical. Skewed data results.

Using those criteria, the 5.4s measurement is valid and very clear to see.

Incorrect. Nearer to 4.4s

In fact, by using a different method, I've helped to corroborate the NIST findings, independently.

No, you've replicated their error with your *eyeball* method.

Come on, you're rejecting empirical data by scrubbing a video, pointing and shouting. Not good.

 

[femr2]

Femr2, we've been over this fallacious argument already

We have indeed.

The point where the brightness of the pixel was determined is not stated to be the same point where the horizontal position was tracked from.

I am not saying that it was. What I am saying is that (because their graph 12-76 begins at their defined T0) either they spliced data from two separate locations together or made the grave error of using a point in line with (B) which would be obstructed by the roofline structure above the parapet wall roofline. Either way, nasty. I suggest they spliced two separate datasets together.

We can of course go into finer detail on this point.

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.

Please upload your trace data.

Roofline structure in the way if you are performing a trace from T0 I'm afraid. No way around it. You cannot trace the parapet wall unless you wait until after descent is well under way and the roofline structure has descended into the building. The NIST graph begins at T0, therefore at best a splice was performed.

You and Achimspok keep making the same false assumption about it. (this false either/or business) There is nothing in the NIST wording to support your position, unless you misinterpret the prose.

Incorrect.

 

[alienentity]

Femr2, I really don't care if you don't agree with my findings. I don't think your objections are valid, because I think you're wrong.

But anyhoo, speaking of yawns, this is the precise reason why I didn't want to get into yet another endless tail-chasing argument with you - regarding the fallacious argument you and Achimspok continue to make, this is just one example.

You are conflating some ambiguous wording by NIST into something which they didn't actually say:
'The initial analysis required two quantities: (1) the distance that some feature of the building descended
and (2) the time it took to fall that distance. The chosen feature was the top of the parapet wall on the
roofline aligned with the east edge of the louvers on the north face.'

The feature chosen for the pixel brightness was indeed aligned with the louvers....

Now then, here's the part you're missing/ignoring:
'the motion of the north face was studied in more detail by tracking the vertical position of a point near the center of the roofline using the same video'

Clearly it's a different point, they don't specify (and hence YOU don't know) except to mention that it is 'near the center'.

End result: You don't know. So I suggest you stop making this false claim. You could, additionally, find out where it actually was by contacting NISt and getting the information.

But you won't, because apparently, ever the supposed stickler for details, you don't seem to want to know about that detail. Kinda weird, but you're a different kind of guy!

Dude, that's all the time I can spend on this, I have work to do.

 

[femr2]

Maybe they should amend their wording to 'approximately freefall', which is actually what the data in their graphs shows.

I quite agree, but they didn't. Note that the purpose for which my data is used is not simply to highlight that wording accuracy issue. I have a feeling you will jump on this point. I suggest you don't.

it seems many are far too literal in their interpretation of prose

They are indeed. Works both ways of course.

Any road, I might just come out of retirement and make a little vid using your new data, showing that the corner descended faster than freefall. That ought to get the 9/11 bots twittering.
That is if you don't mind me using your graphs...

Graphs ? Sure they are published online afterall. Wouldn't you rather use the data ? I may get around to one myself, but I'd be showing the data in the following form synchronised with the video in question...

...to...

...to...

(Note the accuracy of the nine trace points displayed in the third animation segment)

If you really want to be helpful you might consider using the same methods to trace a couple of real controlled demolitions and see if those accelerate at >G

I may consider it. Sourcing the building dimensions and getting static camera viewpoints with decent quality is the problem there. Get me the building measurements (for real-world scaling) and decent video and no problem.

 

[alienentity]

Roofline structure in the way if you are performing a trace from T0 I'm afraid. No way around it. You cannot trace the parapet wall unless you wait until after descent is well under way and the roofline structure has descended into the building.

Incorrect. It is not that difficult. I'm sorry you do not accept simple facts when they are civilly presented to you.

Your chronic denials are a bit annoying, since you're just wrong. I'm not going to waste any further time debating this non-point with you.

If you must know, I did it frame-by-frame and tracked the point manually. Not perfect, but neither is your tracing method.

guess what? Nothing is perfect, not even you!

cheers

 

[ozeco41]

Femr2 has a very good point in response to Oystein's call for relevancy for those looking for a *big picture* assessment of his views:...

There are several key points which, IMO, you have correctly identified in your post jay howard

The theme I have avoided addressing because I have not wanted to stir a potential hornet's nest is the theme of relevance. We have had quite a few members question the "relevance" of femr2's work and those members seem to fall into three camps - maybe more. The three camps are:
1) those members who do not see femr's work as relevant in their own personal frame of reference.
2) those members who seek to impose an inappropriate frame of reference. Including those who mention CD which is not in the scope of the current debate. AND
3) A small group of me and what looks like one or two others who are prepared to see femr's work in the context which femr2 himself puts it.

(Yes - There will be others and some overlap between them.)

What most of those entering this discussion seem reluctant to do is either:
A) B) Define their own frame of reference - because if they did that the reasons for much of the ongoing confusion and apparent differences of opinion would be exposed to the light.
B)Accept femr2's frame of reference which he has explained many times. Many of those who decline to accept femr's frame of reference also claiming falsely that he has not defined it OR they presume some ulterior motive. Even if the latter is true - which I personally doubt - it matters not. There is ample time to debate CD if and only if the topic ever moves on to the point where CD falls within a new scope of discussion.


And the third option is to define an objective frame of reference. There is a natural structure in the issues under debate. We see loosely defined questions about the "big picture" but no acknowledgement that there are layers of levels of 'picture'.

The context within which femr is currently working is a portion of the collapse mechanism for WTC7. He is identifying that certain parts of the building moved in certain directions at certain times. So the relevance of that is that it adds to the evidence which can go to explaining the mechanism of collapse. And, at the risk of verballing femr2, That is the physical context he is currently operating within. And the only relevant bigger picture issue is not about the bigger picture of the collapse. It is about the debate process where his purpose is to respond to certain claims by cmatrix.

End of big picture. For now. If ever he extends the scope to include CD I will be at the head of the queue to join the debate.

But even on that score surely having more evidence is better? And, if the evidence tests our faith in no CD or our faith in NIST or faith in out own long held views surely we are better off facing that evidence rather than denying it by debating trickery such as badly defined claims of "irrelevance"?

...This really is a puzzling debate, but one thing is clear: there is a real resistance to new information outright. Not after it is properly assessed and sifted from poor information or false information, but before it is even verified...

...that is the aspect of most concern to me - lets evade the additional evidence by any debating artifice we can use.

..
Now, I am the first to admit I don't have the faintest idea how the technical aspects of this type of pixel analysis work. But it's clear that no one here can find a mistake with femr2's work....

I'm not sue about that - we have had some discussion of the topic mixed in among the procedural debates.

...And I don't even know why they'd want to, except that by pointing out one single (irrelevant by some accounts) flaw in the NIST analysis of data,...

...where "relevance" is the key issue and I've already written about it above.

they fear the door is open to criticism and re-evaluation of the NIST data.

So instead, they take the Bible model of argumentation.

I'm glad I decided some years back not to take NIST as authoritative - a long story for another time.

 

[femr2]

Femr2, I really don't care if you don't agree with my findings. I don't think your objections are valid, because I think you're wrong.

Please upload your trace data. Differences can be proven.

You are conflating some ambiguous wording by NIST into something which they didn't actually say:
'The initial analysis required two quantities: (1) the distance that some feature of the building descended
and (2) the time it took to fall that distance. The chosen feature was the top of the parapet wall on the
roofline aligned with the east edge of the louvers on the north face.'

The feature chosen for the pixel brightness was indeed aligned with the louvers....

Now then, here's the part you're missing/ignoring:
'the motion of the north face was studied in more detail by tracking the vertical position of a point near the center of the roofline using the same video'

Clearly it's a different point, they don't specify (and hence YOU don't know) except to mention that it is 'near the center'.

It MUST be in region (B).

End result: You don't know. So I suggest you stop making this false claim.

No false claim.

Understand...

Their GRAPH starts at T0 (their defined very earliest moment of motion).

The roofline structures above (B) are STILL THERE at T0.

THEREFORE for their graph to begin at T0 (at best) they spliced together the pixel brightness data from region (A) with data starting at a latter point in time vertically above region (B).

It had to be a latter point in time, because otherwise the roofline structures would still be there.

Do you understand ?