[Merged] Discussion of femr's video data analysis [Archive]

femr2

13th August 2010, 03:30 PM

The really interesting part (to me) has been the enormous impact on the calculated velocity & acceleration that results from the simple act of increasing the sampling rate.
There's zero impact by increasing the sampling rate at all.

What does change is the way that data must be treated.

People have said before that "computers are the fast way known to generate errors." This may be the purest implementation of that adage that I've ever seen.
Computers just do what they are told to do. They don't really generate errors in this context, but rather reveal errors in procedure rapidly.

I'd like to request that everyone (including me) keep this thread to the engineering. There are plenty of other places that we can express our dissatisfaction with each of our perceptions of the other side's politics, agendas, etc.
No problem, though we're not really discussing engineering. I'll stay technical for sure.

Femr, one of the critical questions that we've argued about is your claimed "sub-pixel resolution", as produced by the SynthEyes program.
Indeed. Had hoped that had been clarified by now, especially given the pure tests provided, but we can go over it until you're satisfied.

Please pick some points on some other buildings (not WTC7) that have definable points that are comparable (in size, distance, spatial frequency & contrast) to the points on WTC7 that you've tracked, and provide tracings of those feature for several seconds.
No problem, though am not sure if you mean on the WTC7 footage or a separate piece of footage. Let me know what footage you want to test.

We've previously discussed the process of static point extraction, which is the tracing of features on separate buildings and extraction of that data from moving feature traces to eliminate frame factors such as frame deinterlace jitter and camera shake. Static point data is in the Cam 3 spreadsheet...
Download (http://femr2.ucoz.com/load/trace_data_nist_camera_3_raw/1-1-0-28)

A couple of tracings of near-to-each-other features (one on WTC7 and one nearby in the frame, but on another building) would be very useful.
Aha. On the WTC 7 footage. See previous comment.

Please make sure that all scaling factors are set the same as in your WTC7 traces.
Haven't included scaling in the cam#3 data yet. It's all in pixels. Will be sorting per-feature scaling metrics over the weekend hopefully.

Wouldn't be able to use the same scaling for features closer or further from the camera though. Would have to make some attempt at accounting for frame position and relative camera orientation.

Presumably, that point on that building will be stationary.
Fairly, yes.

If there are no "sub-pixel" jumping up & down in those traces, it'll go a long way to showing that the bouncing signal are at least associated with WTC7. Perhaps schlieren effects from heat, if not actual motion of the building.
Aha. Sounds like you are looking at the 59.94fps Dan Rather data.

That has been deinterlaced. It is an absolute MUST to take account of deinterlace jitter when using the data. We've been through that before, but can do so again. The alternate frame *bouncing* is not a problem with tracing technique, it's a direct effect resulting from deinterlacing. Not a problem, just has to be handled properly.

First simple step is to use a two sample running average on the data, though there are better methods.

However, if the signal from a non-impacted building is bouncing just like the WTC7 signal is, then it's pretty clear that source of the trace noise is from some other source. Perhaps the software algorithms.
Assuming you've been looking at the deinterlace jitter, then no, it's not a software algorithm problem, it's data knowledge.

femr2

13th August 2010, 03:44 PM

atmosphere errors
Possible.

lens errors
Possible, though traces reveal inter-frame changes in position, minimising the effect of lens distortion. There are other features of SynthEyes which can take account of lens distortion, but from testing there's little point in actually using it for the kind of footage being looked at. Not using it helps other use alternate techniques to replicate the data, as the data accounting for lens distortion is rather complex to handle without actually using SynthEyes.

frame rate error
Possible, but rather unlikely, even for hardware back in the olden days of 2001.

and more errors
The most significant factor I'd suggest.

sub pixel resolution?
Not specifically in this context.

Sub-pixel feature position identification.

Is there a claim you can get more resolution from a set of pixels, than the pixels present?
See previous comment.

The posts here may be instructive...
http://forums.randi.org/showpost.php?p=6114713&postcount=232

femr2

13th August 2010, 03:50 PM

Or maybe very small movements of the camera itself?
There are of course (very) minor variations in camera position, even for footage taken on a tripod. Footage such as Sauret has allowed the technique of static point extraction to be tested with very good results.

I've often wondered how far you could push the resolution of a video taken from a camera that was not attached to an absolutely stable platform. Also how much could "video stabilization" effect these calculations and how would you know?
Important to make the distinction between resolution and feature position. It's possible to extract additional resolution using algorithms such as those within SuperResolution video plugins, but that's not what we're doing. We're peforming sub-pixel accurate feature position tracing, which in my case utilises *8 upscaling and LancZos3 filtering, followed by area-based pattern matching to zero-in on specified features.

Worth reading pages 4-8 of the Physics toolkit thread, rather than going over it all again here.

beachnut

13th August 2010, 03:50 PM

...The posts here may be instructive...
http://forums.randi.org/showpost.php?p=6114713&postcount=232
If only you had sources and references for your claims. Books; degrees, education, who you studied with. Are you making up your stuff? Then source it.

femr2

13th August 2010, 04:44 PM

A quick repost of the basic pure sub-pixel tracing example...

I generated the following animation of a simple circle moving in a circle itself...
http://femr2.ucoz.com/_ph/3/2/26543418.gif

I then downscaled it until the circle is a small blob...
http://femr2.ucoz.com/_ph/3/2/372817686.gif

If we look at a blow-up of the shrunken image, such that we can see the individual pixels, it looks like this...
http://femr2.ucoz.com/_ph/3/2/477542845.gif

Sub-pixel feature tracking essentially works by enlarging the area around the feature you want to track, and applying an interpolation filter to it. Lots of different filters can be used with varying results.

Applying a Lanczos3 filter to the previous GIF, to smooth the colour information between each pixel, results in the following...
http://femr2.ucoz.com/_ph/3/2/371929626.gif

I think you will see that there will be no problem for a computer to locate the centre of the circle quite accurately in that smoothed GIF, even though the circle in the original tiny image was simply a random looking collection of pixels. This process of upscaling and filtering generates arguably more accurate results than simply looking at inter-pixel intensities.

The resulting position determined is therefore clearly sub-pixel when translated back into the units of the original tiny source.

It is a side effect of aliasing that small movements of the object cause slight variation in inter-pixel intensity, saturation and colour.

Tracing the position of the small blob on the tiny version results in the following...
http://femr2.ucoz.com/_ph/3/323039059.png

The raw data is here...
http://femr2.ucoz.com/SubPixelTracing.xls

The graph shows accurate (not perfect) sub-pixel location data for the position of the small blob.

I could go into more detail, but hope that clarifies.

Another test using exactly the same small blob rescale, but extended such that it takes 1000 frames to perform the circular movement. This results in the amount of movement being much much smaller between frames. This will give you an idea of how accurate the method can be...
http://femr2.ucoz.com/_ph/3/156677416.png (http://femr2.ucoz.com/SubPixel1000FrameTest.png)
(click to zoom)

Would you believe it eh.

Here's the first few samples...
0 0
-0.01 0
-0.024 -0.001
-0.039 -0.001
-0.057 -0.001
-0.08 -0.002
-0.106 -0.002
-0.136 -0.002
-0.167 -0.002
-0.194 -0.004
-0.214 -0.005
-0.234 -0.005
-0.251 -0.007
-0.269 -0.008
-0.289 -0.009
-0.31 -0.009
-0.337 -0.012
-0.365 -0.014
-0.402 -0.015
-0.431 -0.018
-0.455 -0.019
-0.48 -0.02
For this example, I'll quite confidently state that the 3rd decimal place is required, as accuracy under 0.01 pixels is clear. There are other sources of distortion, such as the little wobbles in the trace, which are caused by side-effects of the smoothing and upscaling when pixels cross certain boundaries. This reduces the *effective* accuracy. Can be quantified, by graphing the difference between *perfect* and the trace location, but not sure how much it matters.

Now, obviously this level of accuracy does not directly apply to the video traces, as they contain all manner of other noise and distortion sources.

tfk

13th August 2010, 05:30 PM

femr,

There's zero impact by increasing the sampling rate at all.

And I'd say "nonsense" to that.

Using difference equations,

v = (h2 - h1) / (t2 - t1).

the error in t2 - t1 is insignificant compared to the height error. (a good, real approximation, in this case).

If you have two points that are taken 1 second apart, and they measure equal heights, with an error of ±1 foot, then the error in the calculated velocity is

v = 0 ft/sec
V error = ± 1 ft/sec

If you maintain the very same height error, but your sampling rate is now 60 frames per second, then then

v = 0 ft/sec
V error = (±1 foot) / .0167 sec = ± 60 ft/sec.

And the propagating errors into acceleration are going to go as about the square of this.

This is inescapable, and it results EXCLUSIVELY from the fact that you've increased the DAQ rate & you are taking time derivatives of your data.

It is independent of the techniques that one chooses to employ to mitigate those errors.

The lesson that I've learned from this is that, when you are taking derivatives of discrete data, it is crucially important that you decrease measurement errors by a multiplier that is equal to, or greater than, the multiplier at which you increase your acquisition rate.

This is precisely the aspect of this problem that I found to be interesting.

What does change is the way that data must be treated.

The treatment of the data is what this thread will be all about.

Computers just do what they are told to do. They don't really generate errors in this context, but rather reveal errors in procedure rapidly.

There is no such thing as "computer error". It is all "human error".

No problem, though we're not really discussing engineering. I'll stay technical for sure.

Error analysis & data filtering are going to be front & center. Those are engineering disciplines.

Indeed. Had hoped [sub-pixel resolution] had been clarified by now, especially given the pure tests provided, but we can go over it until you're satisfied.

"Asserted", yes.
"Clarified", no.
"Proven", heck no.

And the information that i've been massaging suggests that you do not have sub-pixel accuracy. That is the whole purpose of this thread & discussion.

But hopefully, this thread will help us all find out what is correct. That's what we're all after, right?

No problem, though am not sure if you mean on the WTC7 footage or a separate piece of footage. Let me know what footage you want to test.

The Dan Rather video is, by far, the best video for this purpose. The near perpendicular perspective eliminates all kinds of perspective effects. That's the one we should use.

We've previously discussed the process of static point extraction, which is the tracing of features on separate buildings and extraction of that data from moving feature traces to eliminate frame factors such as frame deinterlace jitter and camera shake. Static point data is in the Cam 3 spreadsheet...
Download

Let's get one from the Dan Rather video.

The Camera 3 video can be a calibration standard that'll help answer the question if we can't get good data from the DR video. (although I don't know any reason that we should not be able to do so.

Also, let's make sure to get some static points RIGHT THRU the collapse, too. This will help rule out camera motion effects, atmospheric effects that are synchronous with the collapse.

Haven't included scaling in the cam#3 data yet. It's all in pixels. Will be sorting per-feature scaling metrics over the weekend hopefully.

Let's stick with the DR Video.

I have seen another video, taken from the north, almost street level, that shows much more of the lower section of WTC7 from the north.
http://video.google.com/videoplay?docid=3664073116607499063#
Do you have a better version of this?

Wouldn't be able to use the same scaling for features closer or further from the camera though. Would have to make some attempt at accounting for frame position and relative camera orientation.

You should (I think) be able to "bracket" the building. And just work in pixels.

With the DR tape, there are several buildings to the right of WTC7 that are prime candidates. The low, white building to the right with the stair stepped roof. One corner that is immediately adjacent to WTC7 maintains a slight gap throughout the collapse. that point would be ideal.

The narrow tall black building to the right of the towers would be excellent.

Sounds like you are looking at the 59.94fps Dan Rather data.

Yes/

That has been deinterlaced. It is an absolute MUST to take account of deinterlace jitter when using the data. We've been through that before, but can do so again. The alternate frame *bouncing* is not a problem with tracing technique, it's a direct effect resulting from deinterlacing. Not a problem, just has to be handled properly.

I am using the data in your files. I assume that you have eliminated the interlace jitter from these numbers.

There is no interlace jitter left in the numbers. If there were, there would be a statistical tendency for every other frame to be either above or below, left or right of every alternate one. This does not appear in the data.

First simple step is to use a two sample running average on the data, though there are better methods.

It sounds here like you are saying that there jitter has not been removed.

Here is a graph of the raw data before the collapse. Every other data point has been shown as a red or blue dot.
http://forums.randi.org/picture.php?albumid=553&pictureid=3537

If there were interlace jitter, there would be a pattern. There isn't one.

Assuming you've been looking at the deinterlace jitter, then no, it's not a software algorithm problem, it's data knowledge.

Nope.

tom

tfk

13th August 2010, 05:33 PM

I've seen this before. There are several reasons that I believe that it does not prove "sub-pixel resolution" in the wtc videos.

Let's get some of that static position data on the DR video, and see what it shows.

tom

femr2

13th August 2010, 07:12 PM

And I'd say "nonsense" to that.
We've been through this before, with additional clarification and agreement by W.D.Clinger.

A few reference posts...
#205 (http://forums.randi.org/showpost.php?p=6110299&postcount=205)
#248 (http://forums.randi.org/showpost.php?p=6120250&postcount=248)
#253 (http://forums.randi.org/showpost.php?p=6120588&postcount=253) (W.D.Clinger)

The accuracy of each individual positional location does not change when increasing the sample rate, it is purely how the resultant data is subsequently treated that has any effect upon derived metrics.

Performing first and second order derivations from noisy data using near-adjacent samples will, of course, result in extreme amplification of that noise.

it results EXCLUSIVELY from the fact that you've increased the DAQ rate & you are taking time derivatives of your data.
Using the same methods as used upon samples a second apart, of course, but as I hope we've already established, that's not a smart (or at all appropriate) thing to do.

It is independent of the techniques that one chooses to employ to mitigate those errors.
Incorrect. Very incorrect Tom.

The treatment of the data is what this thread will be all about.
That's great, but these repeated fundamental errors you keep making must be sorted out first.

I'll upload a spreadsheet with my local Dan Rather data soon (I'll make it a bit more presentable first).

It includes...

* NW Corner Trace
* Static Point extraction
* Deinterlace Jitter treatment
* Velocity and Acceleration derivatives by both wide-band symmetric differencing, and least squares.
* A global single-cell scaling metric, so you can modify the scaling as you wish.
* Various graphs of the above.

There is no such thing as "computer error". It is all "human error".
Agreed. Always a problem between keyboard and seat.

Error analysis & data filtering are going to be front & center.
Fine.

And the information that i've been massaging suggests that you do not have sub-pixel accuracy. That is the whole purpose of this thread & discussion.
Am not at all sure what data you are using. The graph you uploaded tonight seems to have waaay too few points, seeing as the sample rate is 59.94fps.

Here's a copy of my position/time data for Dan Rather (zoomed)...
http://femr2.ucoz.com/_ph/7/981070076.png

But hopefully, this thread will help us all find out what is correct. That's what we're all after, right?
You mean whether the data is validly sub-pixel accurate on position, yes ? If so, sure. Would be more useful for me if noise itself can be quantified, as I'm more than happy with the tracing methods already. Willing to justify the data again of course.

The Dan Rather video is, by far, the best video for this purpose. The near perpendicular perspective eliminates all kinds of perspective effects. That's the one we should use.
I don't agree, but have no problem using it. The quality of the Cam#3 footage is better, but hey-ho. We'll focus on Dan Rather, though I suggest you ensure we're both using the same data once I upload my local spreadsheet copy of the Dan Rather data.

Let's get one (static point) from the Dan Rather video.
Already done. May already be extracted from the data you are using. Not sure.

The Camera 3 video can be a calibration standard that'll help answer the question if we can't get good data from the DR video. (although I don't know any reason that we should not be able to do so.
Not sure I understand.

Also, let's make sure to get some static points RIGHT THRU the collapse, too.
Static point traces are always full clip-length. There's nothing to stop them being so.

This will help rule out camera motion effects, atmospheric effects that are synchronous with the collapse.
Aiii.

I have seen another video, taken from the north, almost street level, that shows much more of the lower section of WTC7 from the north.
http://video.google.com/videoplay?docid=3664073116607499063#
Do you have a better version of this?
What time position ? No use if the camera is not static though. Have to do all sorts of jiggery-pokery to stabilise the footage it the camera is not essentially static.

You should (I think) be able to "bracket" the building. And just work in pixels.
Fine. Is what I;ve done for the Dan Rather static point at this juncture.

With the DR tape, there are several buildings to the right of WTC7 that are prime candidates. The low, white building to the right with the stair stepped roof. One corner that is immediately adjacent to WTC7 maintains a slight gap throughout the collapse. that point would be ideal.
Will find out what point I used and post an image.

I am using the data in your files. I assume that you have eliminated the interlace jitter from these numbers.
From the look of your graph, yes, though the graph looks very odd and have no idea what data you are using. Too few points from what I can see (tho of course I have to go to your profile to see your images. Don't suppose you fancy using a normal image upload service rather than JREF album ?)

tfk

14th August 2010, 03:50 AM

femr,

Look, let's try to avoid walking down our usual path, please.

First thing, please use your own arguments. WD will have every opportunity to express his own opinions here. You're misstating his.

Second, please respond to what I say, not a twisted up version of what I say.

We've been through this before, with additional clarification and agreement by W.D.Clinger.

A few reference posts...
#205
#248
#253 (W.D.Clinger)

The accuracy of each individual positional location does not change when increasing the sample rate, it is purely how the resultant data is subsequently treated that has any effect upon derived metrics.

I didn't say that the position error changed when you speed the sampling rate. I said the exact opposite. I specifically said "If you maintain the very same height error..."

I specifically said that the error ripples into the velocity & acceleration calculations.

Please respond to what I actually say.

Performing first and second order derivations from noisy data using near-adjacent samples will, of course, result in extreme amplification of that noise.

It doesn't "amplify the noise" in the slightest. "Amplifying the noise" would mean "more noise in the position vs time graph".

It amplifies the error in the calculated instantaneous velocity & acceleration. Exactly what I said.

Using the same methods as used upon samples a second apart, of course, but as I hope we've already established, that's not a smart (or at all appropriate) thing to do.

I gave you the illustration of the source of the error. I didn't say that was the right way to do something. We'll get to that the best way to massage the data eventually.

[The source of the error in the time derivatives] is independent of the techniques that one chooses to employ to mitigate those errors.

Incorrect. Very incorrect Tom.

The treatment of the data is what this thread will be all about.

That's great, but these repeated fundamental errors you keep making must be sorted out first.

Please...

In spite of the chubby it gives you to say it, what I said above is not "incorrect, very incorrect, or laced with fundamental errors".

If you'd kindly respond to what I really say, not your misinterpretation of what I say, you'd find that, magically, "I'll suddenly be making far fewer errors"...

Am not at all sure what data you are using. The graph you uploaded tonight seems to have waaay too few points, seeing as the sample rate is 59.94fps.

Here's a copy of my position/time data for Dan Rather (zoomed)...
http://femr2.ucoz.com/_ph/7/981070076.png

If you look at the axes, you'll find that the data I posted is identical to the data that you just posted. Just zoomed to a slightly different time domain.

You mean whether the data is validly sub-pixel accurate on position, yes ? If so, sure. Would be more useful for me if noise itself can be quantified, as I'm more than happy with the tracing methods already. Willing to justify the data again of course.

Quantifying the noise level is exactly where we will be at the end.

I don't agree, but have no problem using it. The quality of the Cam#3 footage is better, but hey-ho. We'll focus on Dan Rather, though I suggest you ensure we're both using the same data once I upload my local spreadsheet copy of the Dan Rather data.

Fine.

Please include a brief text file that outlines what each data set is, and describes any processing that was done to the data.

Please make sure that there is at least one clearly identified data set of the raw data that comes out of the SnythEyes, without any massaging done to it.

Let's get one (static point) from the Dan Rather video.

Already done. May already be extracted from the data you are using. Not sure.

I have been using the data that you posted as being "from the Dan Rather video". It produces the same curves that you post (as the one above).

It starts & ends with:
Time(s) Drop (ft)
0.01668335 0.207940299
0.0333667 0.120656716
0.05005005 0.272119403
...
9.59292626 -332.2381095
9.60960961 -333.7407562
9.62629296 -335.8449751

It is a difficulty when I don't know all the massaging that you may have done (i.e., deinterlacing, motion removal, etc). So that is why I'd like to get a clear description of the various data sets.

The Camera 3 video can be a calibration standard that'll help answer the question if we can't get good data from the DR video. (although I don't know any reason that we should not be able to do so.

Not sure I understand.

We're getting a baseline reference signal to try to measure noise. We need to use a reference point that is not on the building, because points on the building might be moving.

The baseline tells us about noise in the processing, camera motions, atmospheric effects, etc. All motions that might be from a source other than WTC7 motion.

I have seen another video, taken from the north, almost street level, that shows much more of the lower section of WTC7 from the north.
http://video.google.com/videoplay?do...3116607499063#
Do you have a better version of this?

What time position ?

From about 1:04 of that video. But it looks like the resolution is pretty lousy. The've electronically zoomed so far that the building resolution is too coarse.

I am using the data in your files. I assume that you have eliminated the interlace jitter from these numbers.

From the look of your graph, yes, though the graph looks very odd and have no idea what data you are using. Too few points from what I can see (tho of course I have to go to your profile to see your images. Don't suppose you fancy using a normal image upload service rather than JREF album ?)

Is anyone else having problems seeing the images I've posted?

Is this a mac/windows thing? File name problem?

Or is this in femr's set-up?
femr, is it just my images you have trouble with, or everyone's? Or some people & not others?

tom

femr2

14th August 2010, 05:58 AM

Look, let's try to avoid walking down our usual path, please.
No problem. Was just highlighting that when you said *the enormous impact on the calculated velocity & acceleration that results from the simple act of increasing the sampling rate*, that it's how the data is treated that is important.

I assume we agree that generation of derived metrics must not use near-adjacent samples.

what I said above is not "incorrect, very incorrect, or laced with fundamental errors".
To say *It is independent of the techniques that one chooses to employ to mitigate those errors.* is in my opinion wrong. The techniques used are critical. Using, say, 19 sample wide adjacent differencing does not result in such extreme noise amplification.

It's fine to disagree.

Quantifying the noise level is exactly where we will be at the end.
More what I was intending was to quantify the *source* of noise. I'm happy that the tracing techniques are sub-pixel accurate, but there are of course other sources of position variation within the available WTC 7 footage.

One point I think it's worth making at this juncture is that we're basically looking at determining an end-result *effective* positional accuracy, yes ? If the underlying positional accuracy was only integer pixel accurate, then our *effective* accuracy would obviously be +/- a number of pixels, rather than, say, +/- 0.5 pixels. Agreed ?

Please include a brief text file that outlines what each data set is, and describes any processing that was done to the data.
No probs.

Please make sure that there is at least one clearly identified data set of the raw data that comes out of the SnythEyes, without any massaging done to it.
Aiii.

I have been using the data that you posted as being "from the Dan Rather video". It produces the same curves that you post (as the one above).

It starts & ends with:
Time(s) Drop (ft)
0.01668335 0.207940299
0.0333667 0.120656716
0.05005005 0.272119403
...
9.59292626 -332.2381095
9.60960961 -333.7407562
9.62629296 -335.8449751
OK.

It is a difficulty when I don't know all the massaging that you may have done (i.e., deinterlacing, motion removal, etc). So that is why I'd like to get a clear description of the various data sets.
Format of the spreadsheet is similar to the Cam3 data. Raw pixel data comes first. Individual processes are applied over subsequent columns.

We're getting a baseline reference signal to try to measure noise. We need to use a reference point that is not on the building, because points on the building might be moving.

The baseline tells us about noise in the processing, camera motions, atmospheric effects, etc. All motions that might be from a source other than WTC7 motion.
Yes, static point data.

femr, is it just my images you have trouble with, or everyone's? Or some people & not others?
Just yours from what I've seen. I don't use cookies, so my JREF session is through URL session ID. I think that may be the problem, but I just don't *do* cookies :)

W.D.Clinger

14th August 2010, 08:47 AM

I see a lot of violent agreement in this thread.

The really interesting part (to me) has been the enormous impact on the calculated velocity & acceleration that results from the simple act of increasing the sampling rate.
The mathematical reasons for this are covered in the opening pages, specificially sections 1.3 and 1.4, of

R W Hamming. Numerical Methods for Scientists and Engineers. McGraw-Hill, 1962.

Hamming won the Turing Award in 1968, and the book cited above is a standard reference.

There's zero impact by increasing the sampling rate at all.

What does change is the way that data must be treated.
I agree with the second sentence, but I'd quibble with the first: Increasing the sampling rate creates a trap for the unwary. A naive analyst might calculate derivatives via differencing at the full resolution of the sampled data. As tfk observed:
And the propagating errors into acceleration are going to go as about the square of this.

But the following is untrue:

This is inescapable, and it results EXCLUSIVELY from the fact that you've increased the DAQ rate & you are taking time derivatives of your data.

It is independent of the techniques that one chooses to employ to mitigate those errors.

The lesson that I've learned from this is that, when you are taking derivatives of discrete data, it is crucially important that you decrease measurement errors by a multiplier that is equal to, or greater than, the multiplier at which you increase your acquisition rate.

This is precisely the aspect of this problem that I found to be interesting.
No, the increased error can be avoided by downsampling and related techniques. Downsampling is counter-intuitive, of course. Evaluating the tradeoff between error and frequency response takes some sophistication.

We've been through this before, with additional clarification and agreement by W.D.Clinger.

A few reference posts...
#205 (http://forums.randi.org/showpost.php?p=6110299&postcount=205)
#248 (http://forums.randi.org/showpost.php?p=6120250&postcount=248)
#253 (http://forums.randi.org/showpost.php?p=6120588&postcount=253) (W.D.Clinger)

The accuracy of each individual positional location does not change when increasing the sample rate, it is purely how the resultant data is subsequently treated that has any effect upon derived metrics.

Performing first and second order derivations from noisy data using near-adjacent samples will, of course, result in extreme amplification of that noise.
Mostly correct, but the accuracy of sampled data does tend to degrade somewhat when the sampling rate is pushed too high. I think that's a legitimate concern with femr2's data: Since we're going to have to ignore at least some of the extra resolution to keep quantization error (amplified by differencing) within reasonable bounds, does the higher sampling rate really help?

First thing, please use your own arguments. WD will have every opportunity to express his own opinions here. You're misstating his.
Not too badly, but I took advantage of this opportunity to clarify my views.

No problem. Was just highlighting that when you said *the enormous impact on the calculated velocity & acceleration that results from the simple act of increasing the sampling rate*, that it's how the data is treated that is important.

I assume we agree that generation of derived metrics must not use near-adjacent samples.
I certainly agree with that.

femr2

14th August 2010, 09:17 AM

I see a lot of violent agreement in this thread.
:)

Hamming won the Turing Award in 1968, and the book cited above is a standard reference.
Will keep it to hand.

Increasing the sampling rate creates a trap for the unwary.
Fair enough.

Since we're going to have to ignore at least some of the extra resolution to keep quantization error (amplified by differencing) within reasonable bounds, does the higher sampling rate really help?
I'd suggest one thing that helps is that, even with downsamplig of some kind, an averaged value could be used, or a median, or a...we know more about what happens between any points we may *ignore*, and so can determine a *better* value to use at any particular point.

The averaging techniques I use are pretty basic, but am all ears for more appropriate methods.

We're not looking for *jolts* in this context, so there's quite a lot of legroom (headroom) in terms of smoothing the data without negatively affecting the results too much.

Not quite sure how to address Toms intention to verify sub-pixel accuracy. The actual tracing points are certainly sub-pixel (It's easy to simply eyeball attachment to the desired feature in SE, and it's very solid). It's the sources of noise in the video data itself that need quantifying, and it's those that result in variation of the traced position. Dan Rather footage is pretty poor quality, even though it has a good camera location. Hmm...

femr2

14th August 2010, 09:34 AM

A question...

To generate the 59.94fps data, it is necessary to combine deinterlaced video footage into *bob doubled* format.

There are inherent differences between alternate frames as a result of this, and I use simple averaging to account for it.

There are two options available...

We can:

a) Use the 59.94fps data, and be aware of the inherent deinterlace jitter

-or-

b) Use the TWO sets of deinterlaced trace data at 29.97fps

The latter will allow the generation of two separate drop/velocity/accel curves, with the caveat that they are 1/59.94 seconds apart, but the removal of the jitter.

Can do both if y'like...

tfk

14th August 2010, 10:30 AM

WD,

You & I know calculus, derivatives & error analysis. We know what the source of the problem is. But we're talking by each other.

I see a lot of violent agreement in this thread.

A bunch of "Conan the Librarians" around here...

Hardly violent.

The mathematical reasons for this are covered in the opening pages, specificially sections 1.3 and 1.4, of

R W Hamming. Numerical Methods for Scientists and Engineers. McGraw-Hill, 1962.

Thanks for the reference.

This problem brought up the issue of doing error analyses with differential equations. I've not run into that before, and started looking around. I didn't find much.

The simplest way would be to use standard "static equation" techniques with the discrete difference equations. Not exact, but close enough.

And probably more appropriate for discrete data.

But the following is untrue:

This is inescapable, and it results EXCLUSIVELY from the fact that you've increased the DAQ rate & you are taking time derivatives of your data.

It is independent of the techniques that one chooses to employ to mitigate those errors.

The lesson that I've learned from this is that, when you are taking derivatives of discrete data, it is crucially important that you decrease measurement errors by a multiplier that is equal to, or greater than, the multiplier at which you increase your acquisition rate.

This is precisely the aspect of this problem that I found to be interesting.

No, the increased error can be avoided by downsampling and related techniques. Downsampling is counter-intuitive, of course. Evaluating the tradeoff between error and frequency response takes some sophistication.

I said "the error results from simply decreasing the time interval, because the instantaneous velocity is calculated by the slope".

I meant that the SOURCE of the error was simply decreasing the time interval while the positional error stayed constant. And I stand by that.

I didn't say that there were no ways to compensate for it. Or that you had to live with reporting adjacent data points.

Filtering, smoothing & (I came to appreciate) data decimation are all techniques.

The SOLUTION to the problem are all the techniques that you've mentioned.
___

The interesting part of the issue is that one is rarely faced with the "problem" of "too much data".

Mostly this happens because people who set up the data acquisition tune the DAQ rate to the frequency of the effect that they're looking for. Make sure that you've got sufficient rate to meet Nyquist requirements & call it a day.

Having a problem like this arise merely from an embarrassment of data riches is unusual and somewhat fascinating. I'm trying to think of other places where one might run into a similar problem.

Can't think of one at the moment.

tom

femr2

14th August 2010, 12:42 PM

To save some time, I've uploaded a simple copy of the latest Dan Rather Data.

I imagine we'll be using totally different processing techniques on the data, so best not to pollute the given data with too much of mine...

Download (http://femr2.ucoz.com/load/dan_rather_basic_trace_data/1-1-0-29)

Columns:

C/D - Raw pixel data for NW corner

F/G - Raw pixel data for static building

I/J - Pixel data for normalised NW corner (Static point data subtracted)

L/M - Pixel data for de-jittered NW corner (simple two point rolling average)

S/T - De-jittered NW corner data in feet (Uses variable scaling metric source values)

The scaling metrics can be modified, but are based on the building width and the visible distance between NW corner and the building it becomes obscured by.

The vertical distance is based upon NIST values, and I'm inclined to spend some more time on it. It's simply a matter of changing the scalar so I've uploaded the data now. We can agree on refined scaling metrics shortly.

femr2

14th August 2010, 02:11 PM

A question that has been raised is whether the trace data is accurate sub-pixel.

Here is a graph of the horizontal and vertical position traces for the NW corner from the Dan Rather data supplied in the previous post...

http://femr2.ucoz.com/_ph/7/349864523.png

The vertical axis is in pixels and spans +/- 1 pixel, and the horizontal axis spans 13 seconds.

Is there any remaining doubt that the positional data is accurate sub-pixel ?

femr2

14th August 2010, 04:03 PM

femr2

15th August 2010, 05:13 AM

The original source video can be found here...

Download (http://xenomorph.s3.amazonaws.com/WTC7_Dan_Rather_DVD.mpg)

Bear in mind it is in interlaced form, and if you choose to use it, the first thing to do is unfold each interlace field.

Any processing of the video should use a lossless codec such as RAW or HuffYUV.

femr2

15th August 2010, 05:55 AM

A very *loose* curve fit.

The initial polynomial is simply done with excel, then a quick 2nd order plot in Maple...

http://femr2.ucoz.com/_ph/7/761812080.png

Probably useless, but a *start point*. I *very* rarely use Maple, so will dig in and see whether I can use the raw data rather than the poxy excel poly.

tfk

15th August 2010, 11:58 AM

femr2

15th August 2010, 12:09 PM

What value is that equation supposed to represent?

Vertical position vs. time?

Over what domain?

tom
Initial equation is polynomial curve fit of position/time data within excel.

Graph is a second order curve - Acceleration.

x - time (s)
y - ft/s^2

Time is 10 to 17 seconds in the supplied data.

tfk

15th August 2010, 03:55 PM

Initial equation is polynomial curve fit of position/time data within excel.

Graph is a second order curve - Acceleration.

x - time (s)
y - ft/s^2

Time is 10 to 17 seconds in the supplied data.

That's what I thought.

That doesn't demonstrate a particularly astute understanding of curve fitting & function range (+30' to -30' to +30' ?) or domain ...

Overlay your polynomial onto your raw data & you'll see that they look nothing alike. So your empirical equation is pretty useless to giving you velocity & then acceleration values. Which, of course, would be one of the principle reasons for generating that curve in the first place.

BTW, it's a 5th order poly fit. Not a 2nd.

tom

tfk

15th August 2010, 04:17 PM

For reference, here are the trace locations for the data provided...

http://femr2.ucoz.com/_ph/7/2/759212128.jpg

The image is in deinterlaced form, showing both fields.

The size of the box indicates the feature search area.

The large search area used for the static feature trace allows for slightly increased accuracy.

Thanks.

What is the point on the building within large green rectangle that is your static point? (The rectangle's too big to tell.)

Could you do the points that are inside the red boxes as well.

http://a.imageshack.us/img822/7623/staticpointstracereques.png (http://img822.imageshack.us/i/staticpointstracereques.png/)

Uploaded with ImageShack.us (http://imageshack.us)

Also, what the heck is the solid black line that rises up the right side & roof line of WTC7?

Is that in the original CBS video? Why does it look like it is completely fake. Like it's been added after the fact?

tom

femr2

15th August 2010, 04:23 PM

That's what I thought.

That doesn't demonstrate a particularly astute understanding of curve fitting & function range (+30' to -30' to +30' ?) or domain ...

Overlay your polynomial onto your raw data & you'll see that they look nothing alike. So your empirical equation is pretty useless to giving you velocity & then acceleration values. Which, of course, would be one of the principle reasons for generating that curve in the first place.

tom
I said it's a very loose curve (though it's not *that* far off - have you plotted the equation itself ?), and the graph is probably useless (as it's very low order due to max-ing out on the poxy excel poly fit. Am looking at a order 56 plot at the moment, but there's no rush). lol. Bit of a lack of curve fitting tools in this building, and we've done it all before anyway. Call it a prompt to produce...whatever...

As far as my understanding goes, the intention of this thread was your intention to prove claims of sub pixel position accuracy wrong. Post containing the +/- 1 pixel graph a couple of posts ago could do with a response.

btw - Yes, the initial equation is a 5th order poly, however, the graph is a second derivation of it (the diff commands in Maple). If you thought that was a graph of the initial 5th order equation, there's no wonder you're saying it's not a good fit to the position/time data. Note it comes out around the 32ft/s^2 mark at peak ;)

I included the maple commands to make sure that was clear. I might have to include some additional verbage to make sure my posts are simply clear, but please take a little extra time looking at them, rather than assume I'm doing something *stoooopid* eh.

femr2

15th August 2010, 04:28 PM

Could you do the points that are inside the red boxes as well.
Can do.

Uploaded with ImageShack.us (http://imageshack.us)
Ta. Can see it no problem.

Also, what the heck is the solid black line that rises up the right side & roof line of WTC7?
It's simply a high contrast region. It's not an overlay. Have a look at the linked mpeg video zoomed. As I said, the Dan Rather footage is great from a perspective, er, perspective, but the quality is not great. Video artefacts galore.

Is that in the original CBS video?
Yep.

Why does it look like completely fake. Like it's been added after the fact?
Video CCD's do lot's of odd things like that. Am sure the CBS overlay titling doesn't help things either.

femr2

16th August 2010, 05:18 AM

Could you do the points that are inside the red boxes as well.

http://a.imageshack.us/img822/7623/staticpointstracereques.png

A draft vertical trace...
http://femr2.ucoz.com/_ph/7/925179743.png

There is not enough contrast on the background building, and the trace drifts quite badly. So I've omitted it.

tfk

16th August 2010, 05:26 AM

Re: My misreading of your chart explanation: My apologies. It demonstrated my failure to read to the end of your post.

Acceleration makes more sense, but the results are still way off. And this, ultimately, is going to be the cornerstone of my point in this thread: Obtaining a reasonable, plausible result in velocity & acceleration is one of the few objective checks that one can employ to get a sense of accuracy & error in the position vs. time graph.

The extended +30g values at the beginning & end of your acceleration graph don't make any sense whatsoever.

And now, I'm going to jump to the end and may lose you. It's better to go step by step, but I'll post a peek at where we're going.

There are folks who are "leveraging" the calculation of acceleration from position data to sell "controlled demolition".

The motivations are irrelevant to this conversation. What is relevant is not "what results can I get from the data and the analysis?"

What is relevant is "What results are really justifiable & defensible from the data & the analysis?"

In order to do this right, it is imperative to have a sense of the "sensitivity" of the analysis. That is, how sensitive the answer is to different variables.

When one is taking few data points, then the issue of "smoothing the data" (i.e., frequency filtering) is irrelevant. As soon as one starts gathering data higher speeds, then there is a metric that is going to be of the form ∂y * ƒ (where ∂y = position error & ƒ = frequency) which sets a limit on the known accuracy of your results.
___

It's fascinating that this is virtually identical to a statement of the Heisenberg Uncertainty Principle, which of course applies only to atomic scale objects. But the math may well apply in both areas...

WD, I'm certain that there is some fundamental theorem in Data Acquisition that addresses this issue directly. I suspect that your reference in Numerical Methods probably addresses it. Can you put a name to it?

___

The end result of all of this is, right now, "art". As soon as someone can point us to the theory, it'll become engineering, where we can quantify the relationship between DAQ ("Data Acquisition") rate and measurement error.

The engineering says that there is error in all measurements and therefore in all calculations. The art says that there are acceptable & unacceptable levels of error.

The acceleration graph that you produced has a clearly unacceptable level of error. It shows the building having an average of about +10G over the first 1.2 seconds or so. Which, from a zero initial velocity, means that the building would have jumped upwards about 180 feet.

I trust that you agree that this is an unacceptable level of error...

I've found out, by playing with these equations, that it is pointless to bother trying to fit any polynomial to the position data if you are going to do the differentiating for velocity & position. If you set the degree of the polynomial high enough to capture the various characteristics of the position over the whole time interval of the fall, you will inevitably be introducing pure artifacts that will blow up when you calculate the velocity and (especially) acceleration.

Instead you have to use "interpolating functions". Both Mathematica (the program that I use) & Maple have them. These don't try to fit the same polynomial over the whole range, but string a bunch of them together, making sure to match values and derivatives at all "connections" between the curve segments.

You can choose polynomial interpolation (for which you can specify the polynomial order) or spline interpolation.

The spline interpolation is designed to give you continuous 2nd derivatives (no kinks). While splines seem like a natural choice, Mathematica will not integrate spline based interpolation functions. This is a good reality check on your results. Integrate twice back up to get total drop, and make sure that it agrees with the original data.

Getting the right drop is a necessary - not sufficient - check on your acceleration results. You can have higher accelerations for shorter periods of time or lower accelerations for longer periods of time, and achieve the same displacement

Here are the curves that I got with your old Camera 2 (NIST ID, the Dan Rather) video. You said that you couldn't see them before.

This curve is your data (smoothed & decimated) vs. NIST's data after I've adjusted time offset and applied a 0.93 scale factor to your descent. It matches quite well. Small differences at the start of the collapse. Not surprising because you & NIST used different points on the roof line.

I got this scale factor by comparing NIST's drop to your drop over a central (i.e., "constant acceleration") section of the curve. From about 25' drop to about 170' drop). By staying in the middle of the range, I was able to avoid the "where is t0?" question & various dynamics at the end of the drop too.

This is puzzling, and deserves an examination. There is no reason that I can see that your scale factor should be off. Could you re-check it against known points on the building, please.

http://a.imageshack.us/img691/8661/yvstfemrvsnist.png (http://img691.imageshack.us/i/yvstfemrvsnist.png/)

FEMR's drop vs time
Smoothed & decimated

This curve shows just your data, 21 sample smoothed & decimated (every 7th point), along with the interpolation curve that fits the data. You can see that the fit is excellent. Much better than any single polynomial will give you.

http://a.imageshack.us/img718/224/yvst49sec.png (http://img718.imageshack.us/i/yvst49sec.png/)

Velocity (smoothed) vs. time:
From Smoothed drop data

http://a.imageshack.us/img148/7714/vvst49sec.png (http://img148.imageshack.us/i/vvst49sec.png/)

Acceleration (smoothed) vs. time
From smoothed velocity data

http://a.imageshack.us/img571/9646/avst49sec.png (http://img571.imageshack.us/i/avst49sec.png/)

At the end of the day, we're gonna find out that the acceleration results are very sensitive to the filtering & decimation values used. This makes one nervous that your results might not be objective, but merely a reflection of your prejudices regarding "acceptable values".

Which is precisely why I started this thread. To get some feedback from some of the EEs with background in DAQ and/or signal processing. To see if there is a more objective way to determine proper filtering of the data.

Nonetheless, I believe this acceleration data to be "reasonable", which gives a "sanity check" on the filtering.

Final point: You'll see that the curve I've posted only covers 5 seconds, whereas the one you posted covered 7.

BTW: small point. You'll find that (being 2nd derivative of 5th order eqn) that the curve your plotted is a 3rd order poly. (Not particularly important.)

That's enough for now.

More later.

tom

tfk

16th August 2010, 05:44 AM

femr,

Could you post the numerical data on the static points for those other 3 buildings, please.

It's immediately clear that there is a very high correlation between the jitter of all three of those static points. This goes a long way to suggest that the jitter is really in the video, and not in the software algorithms.

Btw, was this data taken from interlaced video? Did you do any "jitter correction" on it?

tom

Do you have a url reference back to an original of the CBS video? (BTW, are you "xenomorph"? I'm just asking if the origins of all those videos is you or someone else.)

T.A.M.

16th August 2010, 05:49 AM

First thread in a while with a plethora of educational material in it. Bump to keep it a top...not that it needs it at this point.

TAM:)

femr2

16th August 2010, 05:52 AM

Acceleration makes more sense, but the results are still way off.
As the initial equation is a 5th order poly, the accel derivation is only order 3, which is why it's the shape it is.

And this, ultimately, is going to be the cornerstone of my point in this thread:
OK.

Obtaining a reasonable, plausible result in velocity & acceleration is one of the few objective checks that one can employ to get a sense of accuracy & error in the position vs. time graph.
Not sure I agree with that. I think I've shown that the positional accuracy is pretty hot, but certainly finding techniques to reduce the noise level for subsequent derivations will be productive.

The extended +30g values at the beginning & end of your acceleration graph don't make any sense whatsoever.
They wouldn't. The vertical axis is in ft/s^2, not G. As I indicated, the *peak* is about 32ft/s^2, which is why I included the graph. Using higher order initial polys still results in over-g accel, but I'm looking at various ways of eliminating noise before I post further accel graphs.

What is relevant is "What results are really justifiable & defensible from the data & the analysis?"
My viewpoint is even simpler...what does the data actually show. Thus far the tracing process for WTC7 has shown that movement spans a wide timeframe, building corner release points can be quantified, that sort of thing...

The acceleration graph that you produced has a clearly unacceptable level of error. It shows the building having an average of about +10G over the first 1.2 seconds or so. Which, from a zero initial velocity, means that the building would have jumped upwards about 180 feet.
See prior comments. ft/s^2, not G.

I've found out, by playing with these equations, that it is pointless to bother trying to fit any polynomial to the position data if you are going to do the differentiating for velocity & position. If you set the degree of the polynomial high enough to capture the various characteristics of the position over the whole time interval of the fall, you will inevitably be introducing pure artifacts that will blow up when you calculate the velocity and (especially) acceleration.
It's a problem, yes. Am looking at the effect of sequential passes of downsampling and interpolation at the moment to smooth it out.

While splines seem like a natural choice, Mathematica will not integrate spline based interpolation functions.
Route forward there would be to generate a new data-set from the interpolation function. Match it to the original sample rate, then use the more basic symmetric differencing on that data perhaps ?

This is a good reality check on your results. Integrate twice back up to get total drop, and make sure that it agrees with the original data.
:)

Here are the curves that I got with your old Camera 2 (NIST ID, the Dan Rather) video. You said that you couldn't see them before.
I see piccys.

There is no reason that I can see that your scale factor should be off. Could you re-check it against known points on the building, please.
Sure, though there is very scant information available on building size metrics.

At the end of the day, we're gonna find out that the acceleration results are very sensitive to the filtering & decimation values used.
Absolutely.

This makes one nervous that your results might not be objective, but merely a reflection of your prejudices regarding "acceptable values".
Oi. Enough of that.

Which is precisely why I started this thread. To get some feedback from some of the EEs with background in DAQ and/or signal processing. To see if there is a more objective way to determine proper filtering of the data.
OK.

BTW: small point. You'll find that (being 2nd derivative of 5th order eqn) that the curve your plotted is a 3rd order poly. (Not particularly important.)
Aiii.

femr2

16th August 2010, 06:00 AM

femr,

Could you post the numerical data on the static points for those other 3 buildings, please.
Sure. Will upload after I've been t'pub. Thirsty :)

It's immediately clear that there is a very high correlation between the jitter of all three of those static points. This goes a long way to suggest that the jitter is really in the video, and not in the software algorithms.
For sure. The pure noiseless video testing (the little rotating blob) allows quantifying the actual tracing algorithm variances. There are many sources of noise in the video itself.

Btw, was this data taken from interlaced video?
No. Unfolded video in the form of the image posted earlier, so there are two traces for each point which are then combined to form the 59.94 sample per second data-set.

Did you do any "jitter correction" on it?
Yes. (n1+n2)/2.

Do you have a url reference back to an original of the CBS video?
No, that's the best I have access to.

are you "xenomorph"?
No.

femr2

16th August 2010, 06:27 AM

Will upload after I've been t'pub. Thirsty :)
Maybe not such a great idea ;)

Here y'are, before I go...

Extra Static Point Data (http://femr2.ucoz.com/load/wtc7_dan_rather_extra_static_points/1-1-0-30)

tfk

16th August 2010, 10:52 AM

First thread in a while with a plethora of educational material in it. Bump to keep it a top...not that it needs it at this point.

TAM:)

In coarse, Hollywood, over-the-top Hispanic accent:
"Do ju know wha' a "plethora" ees?"

Name that movie ...
(& show your age ...)

tom

T.A.M.

16th August 2010, 11:09 AM

I dunno, but i would guess cheech and chong....something or other....lol

As for my age, i'll be 40 in 6 weeks.

TAM:)

tfk

16th August 2010, 12:17 PM

I dunno, but i would guess cheech and chong....something or other....lol

As for my age, i'll be 40 in 6 weeks.

TAM:)

Youngster...!

http://www.daveandthomas.net/2010/03/12/yes-el-guapo-a-plethora-of-pinatas/

:D

tom

DGM

16th August 2010, 12:58 PM

Youngster...!

http://www.daveandthomas.net/2010/03/12/yes-el-guapo-a-plethora-of-pinatas/

:D

tom
That's not an old movie!

It came out ten years after I graduated HS!

;)

W.D.Clinger

16th August 2010, 02:43 PM

What is relevant is "What results are really justifiable & defensible from the data & the analysis?"

In order to do this right, it is imperative to have a sense of the "sensitivity" of the analysis. That is, how sensitive the answer is to different variables.

When one is taking few data points, then the issue of "smoothing the data" (i.e., frequency filtering) is irrelevant. As soon as one starts gathering data higher speeds, then there is a metric that is going to be of the form ∂y * ƒ (where ∂y = position error & ƒ = frequency) which sets a limit on the known accuracy of your results.
___

It's fascinating that this is virtually identical to a statement of the Heisenberg Uncertainty Principle, which of course applies only to atomic scale objects. But the math may well apply in both areas...

WD, I'm certain that there is some fundamental theorem in Data Acquisition that addresses this issue directly. I suspect that your reference in Numerical Methods probably addresses it. Can you put a name to it?

___
The name I would give to it is "forward error analysis of quantization error". Quantization error behaves somewhat like roundoff error, but tends to be much larger in simple calculations such as ours.

Unfortunately, most numerical analysis textbooks concentrate on algorithmic error (aka formula error) and algorithmic stability, discuss roundoff error only in passing, and don't mention quantization error at all. The reason for this, I suspect, is that numerical analysts have historically been less concerned with solving problems given by noisy data than with solving problems expressed by mathematical formulas. The textbooks and research literature of numerical analysis have not fully caught up with the data revolution.

Numerical differentiation via differencing is ill-conditioned. That much is a well-known fact (http://en.wikipedia.org/wiki/Numerical_differentiation#Practical_considerations ):

An important consideration in practice when the function is approximated using floating point arithmetic is how small a value of h to choose. If chosen too small, the subtraction will yield a large rounding error and in fact all the finite difference formulae are ill-conditioned...

What isn't so widely appreciated is that the ill-conditioning of numerical differentiation amplifies quantization error much as it amplifies roundoff error.

Bottom line: For our purposes, calculating accelerations from positions by taking second differences, the error in the accelerations is linear in the position error but quadratic in the sampling rate.

That means femr2's subpixel resolution is helpful, but the higher sampling rates are substantially less helpful.

The end result of all of this is, right now, "art". As soon as someone can point us to the theory, it'll become engineering, where we can quantify the relationship between DAQ ("Data Acquisition") rate and measurement error.

The engineering says that there is error in all measurements and therefore in all calculations. The art says that there are acceptable & unacceptable levels of error.
I think I've explained the theory, and pointed you guys toward some references. Unfortunately, you'll probably have to study up on conditioning and roundoff error, and then figure out how to apply those principles to quantization error.

carlitos

16th August 2010, 02:46 PM

I always learn something in these threads, but the phrase "counting the number of angels dancing on the head of a pin" comes to mind.

tfk

16th August 2010, 06:50 PM

I always learn something in these threads, but the phrase "counting the number of angels dancing on the head of a pin" comes to mind.

The only question is "Is this me or femr ...?"

http://www.youtube.com/watch?v=b2d9TO126EE&NR=1
:D

tom

ozeco41

16th August 2010, 07:03 PM

I always learn something in these threads, but the phrase "counting the number of angels dancing on the head of a pin" comes to mind.

And, If I Recall Correctly, the main reason we are down this track of detailed methodology is because a lot of truther claims are based on the premise that "free fall acceleration" == "demolition"

....that premise is false (Attention Chandler, Szamboti et al)

So determination of freefall or not does not affect the outcome of "was it demolition or not?"

That said the scientific debate is of interest of itself.

All same the "nano thermate residue or paint chips" debate. Interesting but of zero relevance to the question "demolition or not?"

tfk

17th August 2010, 12:36 AM

OZ,

That is absolutely right.

Femr, would you agree with this?

One interesting thing that occurred to me during my look at the numbers is that both Chandler and NIST's early numbers & graphs require not only FFA, but faster than FFA.

viz., If, over the course of ~ 2.25 seconds the AVERAGE acceleration (as given by a Least Squares Linear fit) is substantially equal to "G" [true], and the standard deviation of the data is not equal to zero [also true], then the acceleration at some points in the data set MUST represent an acceleration greater than "G".

There are three possible explanations for this occurrence:

1) The average acceleration is really < G. That is, the error in the average acceleration is sufficient large to allow variations in the instantaneous acceleration such that it never exceeds "G",

2) The average acceleration is really ~"G", but the calculation of instantaneous acceleration has sufficient error that the standard deviation is really approximately equal to zero, and the instantaneous acceleration over the entire interval is really a constant "G", as well.

3) The instantaneous accelerations over some parts of the interval are less than "G", requiring the instantaneous accelerations over other parts of that interval to be greater than "G".

As I looked at the data, it became evident to me that options 1) & 2) were untenable. The only viable explanation is that there were short periods of time when the acceleration was really > "G".

Femr, do you agree with this?

Try telling a truther that this can happen without violating Newton's Laws ...!!

tom

femr2

17th August 2010, 05:53 AM

Femr, would you agree with this?
Depends what *this* is...

the main reason we are down this track of detailed methodology is because a lot of truther claims are based on the premise that "free fall acceleration" == "demolition"
Not from my perspective. My reason for performing the tracing is to determine accurate metrics on building movement. Application of the same methods to early motion of WTC1 has proven very insightful and has highlighted numerous inaccuracies with the NIST analyses. Understanding actual movement can only be helpful in understanding the actual events. Performing similar for WTC7 will help clarify numerous behaviours, such as the timing between corner release points.

So determination of freefall or not does not affect the outcome of "was it demolition or not?"
*freefall* was determined a long time ago, and is not really my focus. I'm more interested in what *else* can be determined by looking at early building motion. The current focus on descent rate has simply evolved out of bits of discussion about the validity of the tracing methods.

It may be that conclusions are more in the form of what did not happen, rather than what did. For example the easily observable (and traceable) *flexing* motion of the facade prior to east penthouse descent would indicate that whatever caused that descent occurred quite a period of time before release of the penthouse itself. May seem like an obvious statement, but there has not been any actual verifiable data on such points to date.

As I looked at the data, it became evident to me that options 1) & 2) were untenable. The only viable explanation is that there were short periods of time when the acceleration was really > "G".

Femr, do you agree with this?
The data does seem to indicate periods of over-G acceleration. A couple of factors not presented are...

a) Scaling metrics. We're at the mercy of very scant building measurements, and even minor error in scaling could result in significant change to derived acceleration data.

b) Camera Perspective. Again scaling related, but there is no treatement of the data wrt perspective. From the Dan Rather viewpoint it won't make a *huge* difference, but if included it would make *some* difference.

c) Other unknowns, such as whether the video framerate is *exact*. Very slight difference between the actual *original* framerate and the available video could skew results.

----

Do you still have any doubts about whether the positional data is sub-pixel accurate ? I'm still comfortable with the suggested +/- 0.2 pixel accuracy.

http://femr2.ucoz.com/_ph/7/349864523.png

----

Are you clear on the units of the previous acceleration graph now ? (ft/s^2 rather than G).

----

Am still looking at scaling metrics, but the biggest stumbling block is a ridiculous lack of building measuement data. The next biggest stumbling block is the low resolution of the videos, which limits the accuracy possible when determining feature measurements. That's further compounded by the fact that we cannot really use sub-pixel positional methods, as they are only useful for determining changes in position, not static position. I've developed procedures to drastically improve static image quality (stacked image summation for example), but there are limitations of course.

Does anyone know where I can find WTC 7 building measuement data ? (That should hopefully include accurate per-floor heights)

femr2

17th August 2010, 09:40 AM

A first stab...

Graph of original distance/time data and order 50 poly fit...
http://femr2.ucoz.com/WTC7DanRatherDropSmall.png

A 5964*3720 pixel version so you can actually see what's occurin...
http://femr2.ucoz.com/WTC7DanRatherDrop.png

Derived Velocity (uses dydx function of PFit Excel Plugin)
http://femr2.ucoz.com/_ph/7/756527984.png

Derived Acceleration (uses ddydx function of PFit Excel Plugin)
http://femr2.ucoz.com/_ph/7/508127617.png

Quick overlay comparison to your acceleration curve...
http://femr2.ucoz.com/_ph/7/446763612.png

Major_Tom

17th August 2010, 10:19 AM

Why are accurate measurements of movement and drop curves important?

In the case of WTC1:

They can show that the collapse initiation for WTC1 happened very differently than what the NIST claimed.

They claim an 8 degree tilt over which all columns initially failed but measurements show it was less than 1 degree.

Multiple drop curves allow us to synchronize the order of observed column failures. For example, if we compare drop curves of 4 anchor points on WTC1 (on the NE corner, the NW corner, the SW corner and on the antenna), we can see that massive failure inside the core is what most probably caused the collapse of WTC1, not the loss of the south wall as the NIST claims.

If we measure correctly we can see that all 60+ columns in the west wall of WTC1 must have failed together within a 0.5 second interval. We will see that the first row of forceful ejections come out from the 98th floor before any point on the perimeter begins to move downward and before the antenna begins to move downward.

We will see that the true sequence of events is totally different from what the NIST report claims.

In the case of WTC7: Order and interval between events can be established using multiple trace points to establish what events are simultaneous or near simultaneous. This can be compared to the NIST description and models to show that the current collapse simulations are a work of total fantasy when compared with the real event.

In short, we will see that we should have been measuring these things years ago to check the NIST's work.

DGM

17th August 2010, 12:08 PM

Major Tom:
Please do not post here unless you can post with the same caliber that has been displayed so far.

Others, This is the first thread in years that shows some promise of being educational. Do not respond to typical "truther" bait.

I have reported Major Tom.

femr2

17th August 2010, 12:26 PM

I have reported Major Tom.
What for ? ozeco41 brought up why tracing was being performed. I brought up it's prior usage for collection of data for WTC 1. MT posted opinion on some of that data.

Perhaps better to leave WTC 1 until *discussion of femr2's video data* has reached the end of the current WTC7 focus, and perhaps better to see what actually falls out the bottom of the WTC7 tracing before predicting the results, but don't see anything there to report.

Much more relevant to the thread than the chin-wag about film titles and poster age a little earlier on.

Suggest we simply all refrain from off-topic posts (which ironically should include this one from me :) )

femr2

17th August 2010, 05:22 PM

tfk

18th August 2010, 09:11 AM

A brief conclusion that I'll post here.

Hopefully tonight or tomorrow, I'll be able to spring the time to write up a summary that shows the effects of various filtering techniques (applied to the raw position vs. time data) on the calculated velocity & position (vs time) curves.

It's actually kinda sorta interesting, and it does seem to converge on a solution that is reliable.

But here's the conclusion:

Acceleration of the WTC7 North Wall compared to Free Fall Acceleration:

http://a.imageshack.us/img820/9636/ffavswtc7northwallaccel.png (http://img820.imageshack.us/i/ffavswtc7northwallaccel.png/)

The results are conclusive: the wall dropped nothing like an object in free fall.

Not for 2.25 seconds.
Not for 1 second.
Not for 0.1 seconds.

It is correct to say that "for about 2 seconds (from 5 to 7 seconds, by this time index), the average acceleration of the wall was close to free fall."

But the claim that "the wall fell at FFA for 2.25 seconds" is not supported by this data.

tom

tfk

18th August 2010, 10:52 AM

Since it's easy to calculate (now that I've got the accel. function), here is a table of the "Average Accelerations over 2.25 second intervals", for start times running from 4.6 sec to 5.6 seconds.

{Interval Start time, Average Acceleration over 2.25 sec interval }

{4.6, -28.6556},
{4.7, -29.5611},
{4.8, -30.2888},
{4.9, -30.8012},
{5.0, -31.0492}, *** max value
{5.1, -30.9424},
{5.2, -30.3447},
{5.3, -29.3036},
{5.4, -28.0272},
{5.5, -26.8454},
{5.6, -26.0467}

One can see that the "average accel over 2.25 sec interval" peaks out for the interval starting at 5.0 seconds (5.0 -> 7.25 second interval) at 31.05 ft/sec^2.

Or about 100 * 31.05/32.18 = 96.5% G.

tom

Note that the above are from femr's previous WTC7 (Camera 2 "Dan Rather") data set.

It'll be easy to run the results on his latest data sets some time in the next couple of days.

tfk

18th August 2010, 10:58 AM

Notes on scaling...

The Dan Rather data is scaled relative to this measurement...
http://femr2.ucoz.com/_ph/3/263595510.jpg

I've set it to 344ft in the spreadsheet data provided, which is based upon the only distance metrics available (to me).

Again, if anyone has information which will allow a more precise distance to be determined, fire away.

I use a metric provided by NIST (242ft - roofline to top of windows on floor 29) with an addition of a multiple of their stated general floor height (12ft 9in) to account for the increased portion visible at the West edge.

I'd suggest that there are too many complications on the roof to know what point NIST is talking about. There is a roof line & also a parapet wall.

I'd suggest that you use the distance from the top of a low story window to the top of an upper story (not the 47th story, perhaps the 45th or 46th floor) window. Again, there are differences in the top floors for mechanical reasons.

beachnut

18th August 2010, 11:08 AM

Where is the camera position? Distance from the tower? What angle is the view from the location to the top of the WTC?

The setup has to be specified or the data is worthless.

jaydeehess

18th August 2010, 12:00 PM

And, If I Recall Correctly, the main reason we are down this track of detailed methodology is because a lot of truther claims are based on the premise that "free fall acceleration" == "demolition"

....that premise is false (Attention Chandler, Szamboti et al)

So determination of freefall or not does not affect the outcome of "was it demolition or not?"

Spot on. It is a very large leap of intuition from a ffa to controlled demolition. Such a leap belies a prejudice in the person making such a leap.

OZ,

That is absolutely right.

.........There are three possible explanations for this occurrence:

1) The average acceleration is really < G. That is, the error in the average acceleration is sufficient large to allow variations in the instantaneous acceleration such that it never exceeds "G",

This was the reasoning for my starting the thread asking about Chandler's (non-)handling of error margins. There was no calculations indicating the accuracy of huis work which makes his work all but useless.

2) The average acceleration is really ~"G", but the calculation of instantaneous acceleration has sufficient error that the standard deviation is really approximately equal to zero, and the instantaneous acceleration over the entire interval is really a constant "G", as well.

3) The instantaneous accelerations over some parts of the interval are less than "G", requiring the instantaneous accelerations over other parts of that interval to be greater than "G".

As I looked at the data, it became evident to me that options 1) & 2) were untenable. The only viable explanation is that there were short periods of time when the acceleration was really > "G".

Which indicates that some other influences are in effect that most certainly cannot be 'explained' away by the introduction of explosives or incindiary devices.

........

Try telling a truther that this can happen without violating Newton's Laws ...!!

tom

Goes back to the prejudices of the persons jumping to conclusions. If one's world view demands large complicated and overly complex conspiracies by secret organizations (in the '50s this would be the 'Commie under every rock' senario, now its the NWO/Illuminatti/Bilderberger/etc.) then such leaps come easy. I, and others, on the other hand require much greater proof of asuch fantastical conspiracy and instead regard this data as inconclusive concerning the cause of the collapse.

That said, is there a handling of the margin of error in the final graph of acelleration vs. time, or has the minute detailing simply reduced such error margin to a degree such that the margins are insignificant?

Do all of the positional points require no movement towards or away from the camera and that all movement be either vertical or lateral wrt to the videio frame? If the structure's measurement points were moving left/right and up/down then they were also moving front back and would not such movement, unmeasurable in a 2-d video rendering, affect the accuracy in the vertical measurements?

(probably answered above , forgive me if you guys lost me )

femr2

18th August 2010, 12:07 PM

Hopefully tonight or tomorrow, I'll be able to spring the time to write up a summary that shows the effects of various filtering techniques (applied to the raw position vs. time data) on the calculated velocity & position (vs time) curves.

It's actually kinda sorta interesting, and it does seem to converge on a solution that is reliable.
Okay, though I'll highlight at this early juncture that our acceleration curves look quite different. I get similarly shaped results from the NIST Cam #3 viewpoint as well, using a few different methods.

Please provide the data/equations which describe the curves, and an R2 value if possible.

But here's the conclusion
Okay, though I think there are many other questions that can be asked of the data. Okay with *a* conclusion ?

It is correct to say that "for about 2 seconds (from 5 to 7 seconds, by this time index), the average acceleration of the wall was close to free fall."
Okay, though think it should be made clear in text that over-G is present, and that it refers to the NW corner, not the wall.

But the claim that "the wall fell at FFA for 2.25 seconds" is not supported by this data.
Agreed, and such a simplistic conclusion could never be true anyway. It's clear that behaviour varies slightly depending upon what point along the roofline is selected.

femr2

18th August 2010, 12:17 PM

Since it's easy to calculate (now that I've got the accel. function), here is a table of the "Average Accelerations over 2.25 second intervals", for start times running from 4.6 sec to 5.6 seconds.
Again, careful Tom. You've generated *an* acceleration function. Mine is slightly different...

I think that going from where we were to where you appear to be now is a leap premature.

We should have spent at least a couple of weeks looking at various smoothing and noise reduction methods.

On that basis, I'm treating your current acceleration curve as *tfk acc #1*, not *the* accel function.

{Interval Start time, Average Acceleration over 2.25 sec interval }
What time interval does each row span ? 0.1s ?

96.5% G.
Obviously results from my accel curve differ to this. (with over 1s averaging over-G)

We will have to thrash the procedures around until we both converge on similar results.

It'll be easy to run the results on his latest data sets some time in the next couple of days.
Would be a tad useful if your processing steps from position/time data are described in detail, along with inclusion of resultant data. Quite happy to do the same of course.

femr2

18th August 2010, 12:25 PM

I'd suggest that there are too many complications on the roof to know what point NIST is talking about. There is a roof line & also a parapet wall.
When applied to their own tracing process, absolutely. In determination of their provided metric, no. They state they determined that from structural drawings of the building. A copy of such would be handy, but...

I'd suggest that you use the distance from the top of a low story window to the top of an upper story (not the 47th story, perhaps the 45th or 46th floor) window. Again, there are differences in the top floors for mechanical reasons.
Have you got any facade measurements for WTC 7 ? Extra details very welcome.

If the NIST 242ft metric is accurate, and the NIST 12ft 9in inter-floor distance for the majority of floors is accurate, then my scaling is fine.

Never going to be *perfect*, but I'd hazard a +/- 0.5% accuracy.

femr2

18th August 2010, 12:31 PM

Where is the camera position? Distance from the tower? What angle is the view from the location to the top of the WTC?
Shall dig it out. Kicking around in my piling system somewhere.

The setup has to be specified or the data is worthless.
No, as long as it's made clear that perspective has not been accounted for it just adds an amount of potential error to results. Quite happy to include an estimation of the effect, but the data is still useful without applying perspective correction. For example, even the NIST Camera #3 footage analysis, which includes far higher levels of perspective, ignored perspective correction completely. I've made quite extensive treatment of my Cam#3 data to account for it. No problem doing so for the Dan Rather viewpoint, though suggest the difference will be marginal.

femr2

18th August 2010, 12:39 PM

Goes back to the prejudices of the persons jumping to conclusions.
As Tom requested, please refrain from these more generalised kind of thought trains on this particular thread.

has the minute detailing simply reduced such error margin to a degree such that the margins are insignificant?
No, the error margin is significantly amplified through derivation of acceleration data from noisy position/time data. What I hope results from this thread more than anything else is clear progression towards methods which deal effectively and accurately with significantly reducing the noise inherent in the raw data, making derived velocity and acceleration much more accurate.

Do all of the positional points require no movement towards or away from the camera and that all movement be either vertical or lateral wrt to the videio frame? If the structure's measurement points were moving left/right and up/down then they were also moving front back and would not such movement, unmeasurable in a 2-d video rendering, affect the accuracy in the vertical measurements?
Perspective has not been taken account of, though it probably will be. It's omission does of course affect the *accuracy* of the data, though from the Dan Rather viewpoint I would suggest the effect is quite small. Modifiers would lekely be linear, so the *shape* of derived data should not be seriously affected.

tfk

18th August 2010, 01:14 PM

Where is the camera position? Distance from the tower? What angle is the view from the location to the top of the WTC?

The setup has to be specified or the data is worthless.

You can actually get around that if you know the dimensions of various features in your image. And that building is such a metal & glass Cartesian coordinate system, that it'd be pretty easy to be pretty darn accurate.

For example, if you know the actual window to window index height (12' 9" or whatever it might really be), then you can measure it on the image.

You can't assume that all scaling factors are constant, but if you get several points, you can generate a (usually linear) transform between pixels & height.

For example, if you measured the pixel location for the top of, say every 2nd window as near to as possible the fall line that you'll be measuring, then you'll get a good transform between pixels & height.

Even for way off-axis camera shots, like the Camera 3 video.

If you enter the vertical scale factors for vertical lines along the left edge, the center & the right edge, (along with their respective x- coordinates), you'd have a 2 dimensional transform matrix that would allow you to go pretty easily from pixels -> absolute position, velocity or acceleration anywhere on the image.

You gotta know actual dimensions on the building, tho.

tom

tfk

18th August 2010, 01:51 PM

Again, careful Tom. You've generated *an* acceleration function. Mine is slightly different...

I think that going from where we were to where you appear to be now is a leap premature.

We should have spent at least a couple of weeks looking at various smoothing and noise reduction methods.

On that basis, I'm treating your current acceleration curve as *tfk acc #1*, not *the* accel function.

What time interval does each row span ? 0.1s ?

Obviously results from my accel curve differ to this. (with over 1s averaging over-G)

We will have to thrash the procedures around until we both converge on similar results.

Would be a tad useful if your processing steps from position/time data are described in detail, along with inclusion of resultant data. Quite happy to do the same of course.

You are where I was a week ago.

You aren't gonna get there from here with a single polynomial function of any degree.

That approach fights itself. You add more degrees to the polynomial to try to capture more detail, but it just adds more non-existent artifacts when you do the differentiations. You'll generate wildly oscillating curve that tries to pass itself thru all (or most of) the data points. This is the opposite of what low-pass filtering does. What you'll find is that the acceleration calculation becomes way, way too sensitive to slight changes in your polynomial. And it becomes almost impossible to tame.

The right way to do it with discrete data is to use the discrete interpolation function. This fits a relatively low order polynomial (say 5th to 7th order) to successive sets of data points, making sure to match the absolute value, and 1st (and for spline fits) 2nd derivatives at the blend points between the polynomials.

This techniques works well, and can be tamed. Plus, it allows the function to follow the actual data thru zones where different effects are predominant. The single high order polynomial technique that you are using doesn't follow the displacement curve into the "pre-collapse" zone at all. The interpolation function approach handles this easily.

I've run thru sufficient permutations of filtering to feel comfortable that the curves I've posted will be very close to best practice.

You want to use the minimum amount of filtering that tames the noise, while preserving as much frequency response as possible.

I've worked my way down from lots of filtering, and worked my way up from very little filtering to find out where there is a pretty good compromise.

And I also found out that the results did, in fact, converge. I wasn't sure at first that they would.

tom

femr2

18th August 2010, 02:27 PM

You are where I was a week ago.
Nah. Have been looking at trace data, and the various ways of treating the noise for many months.

You aren't gonna get there from here with a single polynomial function of any degree.
The order 50 poly behaves very well, and results in very similar curve shape to one done with more simplistic sequential symmetric differencing and moving average smoothing.

That approach fights itself. You add more degrees to the polynomial to try to capture more detail, but it just adds more non-existent artifacts when you do the differentiations. You'll generate wildly oscillating curve that tries to pass itself thru all (or most of) the data points.
The resultant curves are not wildly oscillating at all Tom...

Velocity...
http://femr2.ucoz.com/_ph/7/2/756527984.jpg

Acceleration...
http://femr2.ucoz.com/_ph/7/2/508127617.jpg

I included the huge position/time image to show clearly how close the poly fit was to the underlying data. It's pretty good. Again it would be useful if you could provide the data for your derived velocity and acceleration plots so a subjective comparison can be made. A picture without the underlying numbers is not much use at this point.

This is the opposite of what low-pass filtering does. What you'll find is that the acceleration calculation becomes way, way too sensitive to slight changes in your polynomial. And it becomes almost impossible to tame.
That's not what I find though Tom. I find velocity and acceleration curves which are very similar with all of the smoothing methods I'm using, and also similar results between the Dan Rather data and the NIST Cam #3 data.

From simple observation of your graph it looks like it's showing it's low-order basis quite clearly. I'm sure you would agree that that behaviour is very unlikely to be a true representation of the actual event. Our graphs are not *that* different, but the oscillation in mine is certainly less *wild*.

The right way to do it with discrete data is to use the discrete interpolation function.
Again, I don't think it's appropriate to make such conclusions on the *right* way to this. There are literally hundreds of methods available to smooth data, and without looking at a wider range (here) there's no subjective right way yet. Most of this thread should really be dedicated to developing and justifying the variable *correctness* of various techniques, not jumping to *this is the way*.

It's easy to generate velocity and accel graphs with simple averaging techniques, though they contain more noise than the smoothed results. If the output of a set of smoothed results don't *fit* the average based derivations, then I'm inclined to bin that curve.

The single high order polynomial technique that you are using doesn't follow the displacement curve into the "pre-collapse" zone at all.
The Dan Rather data has a rather annoying pre-release *wobble*, but I've generated the derived graphs from the peak immediately pre-release, so it's not affecting the curves. I agree that poly-fitting has problems with the very earliest moments.

I've run thru sufficient permutations of filtering to feel comfortable that the curves I've posted will be very close to best practice.
Me too, though for mine. Oh, what to do... :)

You want to use the minimum amount of filtering that tames the noise, while preserving as much frequency response as possible.
Absolutely, which is why I've compared symmetric differencing and high order polys. Both result in a similarly shaped acceleration curve, without the obvious low-order oscillations you're resulting with. I've looked at numerous other methods too and the next step is to split the curve into overlapping segments and redo them all again. If the end result is yet again similar to my current accel curve I'm going to tend towards being a bit more rigid on that.

I've worked my way down from lots of filtering, and worked my way up from very little filtering to find out where there is a pretty good compromise.
I guess we'll have to look at ways of qualifying each procedure eh.

I'll gather a few methods' velocity and accel data together, and suggest you do likewise.

tfk

18th August 2010, 02:31 PM

femr2

18th August 2010, 02:38 PM

This has got / to have something to do with interlacing, right?
Correct. Unfolded interlaced video results in two half-height images per interlaced frame.

jaydeehess

18th August 2010, 02:50 PM

As Tom requested, please refrain from these more generalised kind of thought trains on this particular thread.

Difficult as that is,
I'll do so.

No, the error margin is significantly amplified through derivation of acceleration data from noisy position/time data. What I hope results from this thread more than anything else is clear progression towards methods which deal effectively and accurately with significantly reducing the noise inherent in the raw data, making derived velocity and acceleration much more accurate.

What good is the whole exercise if the error margin is increased? Goes to tfk's senario #1 above and my first questioning the ffa that Chandler's own hacking about found. FFA in a first order approximation would indicate a margin of error at least as large as the difference between the acelleration and 'g'. I understand that there are situations that can have parts of an object moving with ffa but that is not being dealt with in any of this handling of the data. Istead we are simply being told, with greater detail, the same thing that Chandler said, that there was faster than free fall. The only difference is that Chandler assumed that ffa was impossible and that by waving his hands he could claim that it indicated at least free fall.
BUT
How then can you or tkf now say that, yes, the NW corner did experience a short period of ffa if you do not quantify the margin of error? Why can the margin or error not be large enough to have the acelleration of the NW corner never exceed 'g'?

Perspective has not been taken account of, though it probably will be. It's omission does of course affect the *accuracy* of the data, though from the Dan Rather viewpoint I would suggest the effect is quite small. Modifiers would lekely be linear, so the *shape* of derived data should not be seriously affected.

I should have said 'precision' rather than 'accuracy' perhaps?

A quick calc indicates that at 500 meters distance between camera and wall point that a difference of a one meter depth (to/from camera)would create a 0.002 meter error in height(two centimeters, less than one inch) measurement so I suspect you will be right. Though how a slight change in the angle of the object will affect the depth of colour of a pixel and thus affect the SE handling of that pixel is also of interest.
If a line of pixels changes colour due to tilting away from the camera might not SE assume that that point has moved downward more than it actually has?
You might be able to track the difference between two rows of windows to try to take this into account, if that distance changes it indicates a tilting, except it could also indicate a crushing or deformation of the floor.

Can you understand that my original question about the margin of error has simply not been answered yet, nor, from, my perspective, does it seem that anyone with the wherewithal to quantify it , will be getting to that point soon?

tfk

18th August 2010, 02:54 PM

Let me try to phrase it in terms of "degrees of freedom".

When you use a single polynomial to try to describe the entire curve, small adjustments in one location (to try to get a better fit) will produce changes all along the curve. The algorithm is trying to get a "best fit", but every term has an effect everywhere along the curve.

When you use an interpolation function, the algorithm only worries about fitting the curve locally. Adjustments to get a better fit in one area have no effect on the curve fit anywhere else along the curve. You have in essence relaxed a boatload of constraints. You've got lots more degrees of freedom to adjust your constants to fit the LOCAL data points.

Which means that you can do so with a relatively low order polynomial.

I am also saying that you cannot quantify "by eye" the quality of fit 2 derivatives away. Saying that it fits the displacement "pretty darn good" does not give a valid metric for the local accelerations.

Which is what this exercise is all about.

After all, the results that you are getting is a step up from Chandler's - where he FORCED the acceleration model to be a constant. A single horizontal line. He did this by creating a model with rigid constraint: it had to fit a linear velocity profile.

You've relaxed some constraints to allow your curve to follow the actual data. But you've still got a bunch of constraints jerking your curve around.

We'll see when we get there.

tom

femr2

18th August 2010, 03:08 PM

What good is the whole exercise if the error margin is increased?
There's no way to avoid amplification of raw data error when performing first and second order derivations of that data I'm afraid. It's a mathematical certainly. W.D. Clinger made a good post a while back providing good detail on the point. I'll dig it out.

What we can do, if we can agree an amount of error for the position/time data, is generate a good estimation of error magnitude at first and second order derivation levels.

Why can the margin or error not be large enough to have the acelleration of the NW corner never exceed 'g'?
There has to be significant error in the derived data to make significant changes to the derived accel data, but it's a reasonable question. Suggest step 1 is to agree the noise level in the position/time data. I'm comfortable with +/- 0.2 pixels.

Can you understand that my original question about the margin of error has simply not been answered yet
Yep.

, nor, from, my perspective, does it seem that anyone with the wherewithal to quantify it , will be getting to that point soon?
I'm sure suitable estimations will be provided in time.

jaydeehess

18th August 2010, 03:17 PM

femr,

In your excel spreadsheet, you've got > 2:1 difference in horizontal vs. vertical scaling factors. (3.44 ft/pixel vertical / 1.63 ft/pixel horizontal).

This has got something to have something to do with interlacing, right? Such that the effective vertical scaling becomes 1.72 ft/pixel after interlacing?

You can't possibly have a 2:1 aspect ration in the finished video.

tom

Correct. Unfolded interlaced video results in two half-height images per interlaced frame.

Aspect ratio should be 4:3 in the interlaced video should it not? With 1.63 feet per pixel horz, that would give a vert of 2.17 feet per pixel then.

Each feild then is a line of pixels 2.17 feet per pixel but only half as many lines.
There is half as much information per feild.
Properly each feild is a same height picture but with blank lines (no information)between each row. feild one begins at top left of screen while the second feild begins one line down from top left of screen, and 1/59.94 of a second later in time.

femr2

18th August 2010, 03:25 PM

When you use a single polynomial to try to describe the entire curve, small adjustments in one location (to try to get a better fit) will produce changes all along the curve. The algorithm is trying to get a "best fit", but every term has an effect everywhere along the curve.
Aiii.

When you use an interpolation function, the algorithm only worries about fitting the curve locally.
Sure, though of course you're at the mercy of the particular decimated points used, and the data inbetween is effectively ignored.

Adjustments to get a better fit in one area have no effect on the curve fit anywhere else along the curve.
Adjustments ? Manually ?

You have in essence relaxed a boatload of constraints. You've got lots more degrees of freedom to adjust your constants to fit the LOCAL data points.

Which means that you can do so with a relatively low order polynomial.
Yep, though I'd be interested with seeing the results of a range of decimation intervals compared.

I am also saying that you cannot quantify "by eye" the quality of fit 2 derivatives away. Saying that it fits the displacement "pretty darn good" does not give a valid metric for the local accelerations.
Of course, though it would be perhaps useful to compare R2 values between my order 50 poly and your interpolation functions. Will have to dig it out, but it's above 0.999999 if my memory serves.

Which is what this exercise is all about.
Indeed. Hopefully more than just us-two will throw methods into the pot for comparison.

We'll see when we get there.
Cool.

femr2

18th August 2010, 03:29 PM

Aspect ratio should be 4:3 in the interlaced video should it not?
Depends. The metrics provided are relative to known building measurements horizontally and vertically, and so are independant of aspect ratio. Accounting for camera perspective is another kettle of fish of course.

Properly each feild is a same height picture but with blank lines (no information)between each row. feild one begins at top left of screen while the second feild begins one line down from top left of screen, and 1/59.94 of a second later in time.
In terms of live projection, kinda true, yes, however in this context the scaling methods employed are fully appropriate.

tfk

18th August 2010, 03:52 PM

femr,

This is the key:

I agree that poly-fitting has problems with the very earliest moments.

This is exactly right. It cannot follow the discontinuity (going backwards in time) from "falling" to "not falling".

But, guess what...

It is not only at the earliest moments that the polynomial has a problem. It is anywhere that there is a discontinuity in the forces applied. The polynomial can't easily follow local discontinuities, because it is nailed to the entire curve.

ETA: Can't follow it as easily as an interpolation function.

From simple observation of your graph it looks like it's showing it's low-order basis quite clearly. I'm sure you would agree that that behaviour is very unlikely to be a true representation of the actual event.

First off, I'm not sure of any such thing. I don't have any expectation that this is unlikely behavior.

Do you have a basis for this assertion?

This is expressing a bias in what you want to see. It doesn't matter what we think is right or wrong or expected. What matters is "what does the data show?"

And it is tempting, but poor technique, to fiddle with parameters until we see what we want.

That's not what I find though Tom. I find velocity and acceleration curves which are very similar with all of the smoothing methods I'm using, and also similar results between the Dan Rather data and the NIST Cam #3 data.

Similar results with the other Cameras is a VERY good thing. One would say, "required".

Now let's see if it's real, or merely an artifact of our technique.

Our graphs are not *that* different, but the oscillation in mine is certainly less *wild*.

Wild does not equal right or wrong.
Neither does tame.

Again, I don't think it's appropriate to make such conclusions on the *right* way to this.

I am not drawing conclusions yet. I've got (surprise) strong feelings for where this is headed.

I'll gladly go where ever the analysis takes us.

The Dan Rather data has a rather annoying pre-release *wobble*, but I've generated the derived graphs from the peak immediately pre-release, so it's not affecting the curves.

That's not "an annoying wobble". It's a real motion of the building.

tom

tfk

18th August 2010, 03:54 PM

femr,

What does "Aiii" mean?

femr2

18th August 2010, 04:06 PM

It is not only at the earliest moments that the polynomial has a problem. It is anywhere that there is a discontinuity in the forces applied. The polynomial can't easily follow local discontinuities, because it is nailed to the entire curve.
I think we're dealing with diminishing variance as the order increases, but sure. There's a different set of problems with interpolated curves though, and again I suggest a good way to quantify is to look at the actual poly-v-interpol data itself and compare it to the base position/time data. I have a few graphs ready but will upload them at a more appropriate juncture.

First off, I'm not sure of any such thing. I don't have any expectation that this is unlikely behavior.

Do you have a basis for this assertion?
Yes. The correlation between the shape of the curve for the high-order poly function and the simple averaging/differencing curve shape. Very similar. Again I have some graphs but will do some prep before uploading.

This is expressing a bias in what you want to see. It doesn't matter what we think is right or wrong or expected. What matters is "what does the data show?"
Not at all. I have no reason to *want* to see anything at all in the accel curve. Near-g, at-g, above-g, whatever. Makes little difference to me to be honest. I'm after a kickin' way of reducing the noise. Preferably a way which makes my poor old PC emit steam for a while whilst it works out the absolute bestest approximation curves.

And it is tempting, but poor technique, to fiddle with parameters until we see what we want.
Absolutely. Though I do think that trying many different methods and comparing the results is a good thing to do.

Similar results with the other Cameras is a VERY good thing. One would say, "required".
Agreed.

Now let's see if it's real, or merely an artifact of our technique.
Okay.

I'll gladly go where ever the analysis takes us.
Okay.

That's not "an annoying wobble". It's a real motion of the building.
Hmm. Are you sure ? Tis not the same in the Cam#3 data. More likely a video artefact at the beginning of movement. As I said earlier, I moved on from the Dan Rather data to the Cam#3 data as it is of justifiably higher quality.

ETA: Aiii = Yes.

Major_Tom

18th August 2010, 10:52 PM

tfk, in the OP you mention your problem with femr's claim to sub-pixel resolution.

Have you changed your mind or do you still have a problem with that?

Has femr explained it well enough?

pgimeno

19th August 2010, 04:09 AM

Aspect ratio should be 4:3 in the interlaced video should it not? With 1.63 feet per pixel horz, that would give a vert of 2.17 feet per pixel then.

Image aspect ratio is not to be confused with pixel aspect ratio. A 4:3 picture usually has 4/3 times more horizontal pixels than vertical (e.g. 640x480, 1024x768), so that the pixel aspect ratio is 1:1, i.e. the pixels are square. For DVDs that's not usually the case, though: the image is usually 720x480 projected in 4:3 format (ETA: i.e. it has 1.5 times more pixels horizontally than vertically, not 1.333), meaning an 8:9 pixel aspect ratio, or 704x480, meaning 10:11 pixel aspect ratio. For example, 1.63 ft/hpx translates to 1.83 ft/vpx with 8:9 pixel aspect ratio. See http://en.wikipedia.org/wiki/DVD_Video#Frame_size_and_frame_rate for common DVD video formats.

Deinterlaced images, on the other hand, double the vertical part of the aspect ratio. In that case, the pixel aspect ratio is 8:18 for originally 8:9 pixels, or 10:22 for originally 10:11 pixels.

Anyway, as femr2 said, in this case he calibrates both dimensions separately, which should allow for better accuracy provided the real world measures are accurate. I am thinking that that would be a good way to estimate how accurate they actually are. I don't think perspective distortion is playing a significant role in the Dan Rather video, so a comparison of the theoretical and practical aspect ratios of the vertical vs. horizontal ft/px can give information about how accurate they are (unless they both are biased by the same proportion, which I doubt).

E.g. if the image is 720x480 (I haven't looked at the actual resolution yet) and the horizontal ft/px ratio is 1.63 ft/px, how close to 1.83 ft/px are the vertical ft/px?

I think that can help in establishing figures for the errors in the measurements.

femr2

19th August 2010, 05:42 AM

Image aspect ratio
Always a minefield.

Here is some good lower-level technical information on digital video aspect ratio...
http://www.iki.fi/znark/video/conversion/

a comparison of the theoretical and practical aspect ratios of the vertical vs. horizontal ft/px can give information about how accurate they are (unless they both are biased by the same proportion, which I doubt).
I can post some numbers, but there are so many variables between the original source equipment and the resultant mpeg-2 file format video instance I'm using that it'll be impossible to say what is correct. Anyway...

Output Video resolution (my copy of the video) - 704*480 (dvd)

Assuming the original camera adhered to standards (ITU-R BT.601)...

Pixel Aspect ratio (x/y) - 4320/4739

Active picture size - 710.85 * 486

The first issue there is that one would expect a 704 pixel width post-convert format from a 625 line system, and so a 576 pixel vertical output. Instead our output video has a 480 pixel vertical output, which corresponds to a 525 line system and would therefore be expected to have a 720 pixel output horizontal resolution (so that the full 710.85 pixels of the actual active picture size can be captured).

I'll have a look at the most probable convertion procedure if it's of enough interest. i.e. asked for by a few folk.

There's an effective 16 pixel (10+6) black border on the output video, which further complicates determining the conversion process, and it looks like there was a slight pixel clock timing issue between interlace fields (as there is noticable combing of vertical features).

Then we'd have to decide if the video container was intended for 4:3 or 16:9 output...

I suggest folk simply check the actual distance measurement-to-pixel values provided.

For example, the 100 pixel mesurement provided for vertical could be 100 +/- 1/8 (or even higher), but I've kept the value to integer pixels to indicate that I'm not suggesting sub-pixel accuracy.

http://femr2.ucoz.com/_ph/7/2/125286220.jpg (http://femr2.ucoz.com/_ph/7/125286220.png)
(A single interlaced frame unfolded - click for actual size)

Minefield.

Quick additional note whilst I remember it's there...59.94 Hz is only a conventional approximation; the mathematically exact field rate is 60 Hz * 1000/1001.

pgimeno

19th August 2010, 06:21 AM

Always a minefield.

You've convinced me.

I'll have a look at the most probable convertion procedure if it's of enough interest. i.e. asked for by a few folk.

I'm not interested any longer. There are many more hidden variables than I expected. It would probably be futile for a determination of error.

tfk

19th August 2010, 09:23 AM

tfk, in the OP you mention your problem with femr's claim to sub-pixel resolution.

Have you changed your mind or do you still have a problem with that?

Has femr explained it well enough?

What's your hurry? You got a stagecoach to catch?

Has he explained it well enough? Hell no.

Perhaps the response of a perfect geometric shape, against a perfectly white background, with a total of 4 shades of gray, with perfectly balanced geometry (equal, 100% white on all sides of the black dot), represented in a way that incorporates none of the features of how a CCD actually gathers & process light info convinces you...

As usual, I've got my suspicions. But we've still got a few things to sort out.

tfk

19th August 2010, 09:39 AM

Always a minefield.

Here is some good lower-level technical information on digital video aspect ratio...
http://www.iki.fi/znark/video/conversion/

I can post some numbers, but there are so many variables between the original source equipment and the resultant mpeg-2 file format video instance I'm using that it'll be impossible to say what is correct. Anyway...

Output Video resolution (my copy of the video) - 704*480 (dvd)

Assuming the original camera adhered to standards (ITU-R BT.601)...

Pixel Aspect ratio (x/y) - 4320/4739

Active picture size - 710.85 * 486

The first issue there is that one would expect a 704 pixel width post-convert format from a 625 line system, and so a 576 pixel vertical output. Instead our output video has a 480 pixel vertical output, which corresponds to a 525 line system and would therefore be expected to have a 720 pixel output horizontal resolution (so that the full 710.85 pixels of the actual active picture size can be captured).

I'll have a look at the most probable convertion procedure if it's of enough interest. i.e. asked for by a few folk.

There's an effective 16 pixel (10+6) black border on the output video, which further complicates determining the conversion process, and it looks like there was a slight pixel clock timing issue between interlace fields (as there is noticable combing of vertical features).

Then we'd have to decide if the video container was intended for 4:3 or 16:9 output...

I suggest folk simply check the actual distance measurement-to-pixel values provided.

For example, the 100 pixel mesurement provided for vertical could be 100 +/- 1/8 (or even higher), but I've kept the value to integer pixels to indicate that I'm not suggesting sub-pixel accuracy.

[/URL][URL]http://femr2.ucoz.com/_ph/7/2/125286220.jpg (http://femr2.ucoz.com/_ph/7/125286220.png)
(A single interlaced frame unfolded - click for actual size)

Minefield.

Quick additional note whilst I remember it's there...59.94 Hz is only a conventional approximation; the mathematically exact field rate is 60 Hz * 1000/1001.

Thanks.

That is the most detailed description that I've seen you give of the raw video file.

You are the one who has spend countless hours analyzing these videos. Those questions asked are very sensible questions for someone wanting to follow along with your work.

If you are considering publishing your data, you would be smart to have all of those questions (& any other that anyone could think of - the value of collaboration) readily & conveniently answered in an appendix to your paper.

It is really annoying to read thru a paper, only to find that a bunch of obvious questions are not addressed. Gets you pissed at the authors. And then thinking that he has something to hide. (I'm NOT saying this about you. You've been forthcoming with your data.)

There is a spectrum of rigorous to sloppy. Better to err on the former side.

tom

PS. I'd like to see those questions answered.

tfk

19th August 2010, 02:36 PM

femr,

A couple of questions about your data.

You've described it as "assuming it adhered to ITU-R BT.601". Having been broadcast in the US, would it not originally have been in NTSC-M? From what you can tell, was the original source taken from a recording of a broadcast? Frame rate of original broadcast?

This chart shows your static points, NormY & DJ_Y. (What do "Norm" & "DJ" stand for?)

http://a.imageshack.us/img84/2141/staticpointsnormydjy.png

I understand that you're getting rid of jitter by averaging points.

Couple of questions:

I assume that your program takes data points from both frames, has a built in factor that gives an "interlace offset Y" value that it adds to one frame's data, to calculate an accurate "interlaced" resultant Y.

1. Looking at your NormY graph, the jitter is mostly about 0.5 pixel. But occasionally reduces to about 0.1 pixel. Any reason for that?

2. If that "jitter" goes to 0.1 pixel periodically, does that mean that the interlace offset is correct, and the excess "jitter" is related somehow to the algorithm that picks out the feature?

I've got a couple of other questions, but they depend on that first assumption being correct. So I'll ask if you can just describe the process that SynthEyes uses to determine these points.

tom

femr2

20th August 2010, 08:08 AM

femr,

A couple of questions about your data.
Okay.

You've described it as "assuming it adhered to ITU-R BT.601".
I've provided someaspect ratio data with the assumption that the camera adhered to that standard.

Having been broadcast in the US, would it not originally have been in NTSC-M?
It would originally be in the format recorded by the camera. The copy I use is correctly interlaced, so the original must have been a (highly probable) 59.94fps. NTSC-M is a 30 (29.97) fps format.

From what you can tell, was the original source taken from a recording of a broadcast?
No. As it's correctly interlaced it has to be a digital copy. I'd hazard a guess that it was provided in digital form to the folk that made the DVD it was taken from.

Frame rate of original broadcast?
The DVD data is 29.97fps interlaced. It's unlikely that there has been any framerate resampling. The video shows no signs of pulldown, frame duplication or missing frames.

What do "Norm" & "DJ" stand for?
Norm - normalised - static point data subtracted from NW corner data.

DJ - simple 2 point moving average DeJitter.

I understand that you're getting rid of jitter by averaging points.
Yep, but the untreated data is there if you want to use a different method.

I assume that your program takes data points from both frames
Traces are performed on both frames, yes.

has a built in factor that gives an "interlace offset Y" value that it adds to one frame's data, to calculate an accurate "interlaced" resultant Y.
No, though you could do so manually if you like. Both datasets are *zeroed*, so the assumption is that the first samples from each dataset are at the same height.

1. Looking at your NormY graph, the jitter is mostly about 0.5 pixel. But occasionally reduces to about 0.1 pixel. Any reason for that?
No, but will have a look at the visual trace to see if there is a reason.

2. If that "jitter" goes to 0.1 pixel periodically, does that mean that the interlace offset is correct, and the excess "jitter" is related somehow to the algorithm that picks out the feature?
See previous comment re offset. Will have a look at the visual trace and make a few comments on jitter a bit later.

So I'll ask if you can just describe the process that SynthEyes uses to determine these points.
Not sure what you mean. I choose the initial point (region). SynthEyes tracks that region on subsequent video frames.

femr2

20th August 2010, 09:07 AM

As usual, I've got my suspicions. But we've still got a few things to sort out.

I'm not sure what the doubt is.

The vertical trace remains within ~+/- 0.2 pixel margin for 12s.

The test video (the blob) showed that SynthEyes is technically capable of determining position to the third decimal place.

The West edge trace on the Cam#3 footage was comparable with NISTs (imo) dodgy moire method...
http://femr2.ucoz.com/_ph/3/89078455.png

Note the vertical axis on my data is from a *2 upscaled video, so it's actually +/- 1 pixel range, not +/- 2. Very similar to the NIST results (better imo) and well sub-pixel.

So, what is the question ? Is it whether SynthEyes is capable of tracking feature position to sub-pixel accuracy, or whether the noise in the video results in an over 1 pixel margin ?

I think it's been made clear that SynthEyes is more than capable of sub-pixel positional accuracy, and the variance in traces of WTC7 is low. There are all manner of siources of noise which could result in the trace position varying, but they are nothing to do with SynthEyes. It simply determines the location which best matches it's reference image. An example of what I'm talking about there is the draft NE corner trace. That showed the NE corner gradually descending over a long period. In reality the corner didn't move, but the *bleed* of the image data reduced. As SynthEyes was told to track that location, it did exactly what it said on the tin. Changing the trace location to the windows near the NE corner negated that particular video artefact.

Is there something specific I could do that would end the doubt ?

tfk

20th August 2010, 01:01 PM

femr2

20th August 2010, 01:37 PM

this link doesn't work (for me, anyway).
Still fine for me.

Do you have another?
Here's a fresh copy...
http://www.megaupload.com/?d=L2DVLPX5

pgimeno

20th August 2010, 01:37 PM

femr,

this link doesn't work (for me, anyway).

Do you have another?

Highest possible quality...

tom
Hopefully this link will work, since I think you've already seen images from this site:

http://www.formauri.es/personal/pgimeno/temp/WTC7_Dan_Rather_DVD.mpg

(Same file)

femr2

20th August 2010, 06:37 PM

the jitter is mostly about 0.5 pixel. But occasionally reduces to about 0.1 pixel. Any reason for that?
Had a look at the video, and I think it may be due to slight bleed variation of the bottom field roofline.

Might be prudent to try a slightly different trace point for that field to see if I can eliminate it.

The jitter on the other points (static) is quite even, so, yes, probably a problem with the bottom frame initial trace region location.

Can redo it, but it'll mean dropping the trace region down a bit, so it won't be centered on the corner itself, but would include the bottom edge of the *black line* that delineates the roofline.

Sabretooth

20th August 2010, 08:39 PM

ozeco41

20th August 2010, 10:10 PM

With all due respect to everyone posting, why is it necessary to debate the collapse speed of WTC7? As we studied some of the videos of the collapse in firefighter training, I can't see where the speed it fell is of any consequence. My instructors, whom are both trained in fire science and engineering, both explained rather in-depth as to why the structure failed. No CD, no thermite, etc.

Seeing that the building took serious damage from the fall of towers 1 and 2, in addition to the fact that the fires burned uncontrolled on multiple levels of 7 for many hours, it's a minor miracle that 7 lasted as long as it did.

Why expend the time on such a moot point?

Again, not looking to ruffle feathers, just looking for an honest clarification. Maybe I'm misinterpreting the point?
I have lost track of the details but I am pretty sure the origin of this type of discussion was the "truther" false claim that free fall must mean demolition. That claim is, of course, completely false.

Some people seeking to address such a claim set out to test whether or not there was free fall. It is a point of possible interest in its own right. But a complete waste of time if your interest is the base question "Demolition or not?" There was no demolition so whether there was free fall or not does not change the answer to "Demolition or not?"

There has been a similar situation with discussion of Thermite and derivatives. Particularly the Jones Harrit paper on allegations of nano-thermxte at ground zero.
The question has interest in itself as a matter of scientific curiosity.

BUT to a person like me whose focus is "Demolition or not?" the discussion of the pros and cons of the Jones Harrit allegations is a waste of time. There was no demolition.
...THEREFORE there was no use of thermite or any derivative to assist demolition ...
...THEREFORE I wouldn't care if there was a ten tonne stockpile of thermxte on site it wasn't used.
(And all that despite the simple fact that the extraordinary claims made for heating by nano-thermxte are simply impossible. e.g. The commonest implicit claim that a paint film on steel will develop enough heat to melt the steel. Ridiculous.)

Similarly the discussion in this thread has interest of itself BUT it is absolutely irrelevant to the question "Demolition or not?"

So the origin may be in the falsehood many truthers rely on. They state either explicitly or by implication that "FreeFallAcceleration == CD" and expect gullible people to fall for it. Surprisingly many seem to accept it and then try to disprove FFA but that is a side track for my current comments. Again surprisingly it is rare for debunkers to "call" the truthers on the "FFA == CD" claim. Why we let them get away with it I don't know.

femr2

21st August 2010, 05:54 AM

why is it necessary to debate the collapse speed of WTC7?
The OP is fairly clear on the purpose of the thread, and it's not about freefall/not freefal, rather, analysis of the techniques I use for tracing video features.

I have lost track of the details but I am pretty sure the origin of this type of discussion was the "truther" false claim that free fall must mean demolition.
Assuming you have taken the time to read the thread, it has already been made clear that is not the origin of this discussion. The OP also made it very clear that posts should remain focussed upon the technical details, not the usual rambles.

Again, so it's perfectly clear...

"Discussion of femr2's video data analysis [techniques]"

Not freefall/no freefall/faster than freefall.

I have not really performed any analysis of the resultant trace data yet, and so what is actually being discussed is whether the trace data is *valid*, what level of accuracy can be claimed, how inherent noise can be reduced, where noise originates...all that sort of thing.

Please ensure any posts you make on this thread remain within the technical domain, as requested in the OP.

tfk

21st August 2010, 08:11 AM

Hey Sabre,

With all due respect to everyone posting, why is it necessary to debate the collapse speed of WTC7? As we studied some of the videos of the collapse in firefighter training, I can't see where the speed it fell is of any consequence. My instructors, whom are both trained in fire science and engineering, both explained rather in-depth as to why the structure failed. No CD, no thermite, etc.

Seeing that the building took serious damage from the fall of towers 1 and 2, in addition to the fact that the fires burned uncontrolled on multiple levels of 7 for many hours, it's a minor miracle that 7 lasted as long as it did.

Why expend the time on such a moot point?

Again, not looking to ruffle feathers, just looking for an honest clarification. Maybe I'm misinterpreting the point?

Since I'm the one of the guys (on our side) perpetuating this conversation, I guess I've gotta pick up this question.

First, let me ask you a question. Do you find it (pick your adjective) annoying, vexing, bothersome, pissing you off, that I am in this conversation?

The reason that I'm in this is a couple of (interesting to me, doubtless snore-inducing to most) engineering points, and a couple of important philosophical ones.

The philosophical ones are the same one that supports the real engineering debate that still goes on about some fine details about the collapse of the buildings:

1. "There are a few details that are unknown about those events, and the big picture of what happened has nothing to fear by addressing them. (e.g., the work of Dr. Quintiere regarding the frailty of thin trusses in fires.)

2. Even though a bunch of truther pudknockers are almost certain to take honest, lively debate and twist it into "see, they still can't tell you this tiny detail, therefore how can we trust them about anything", you can't let this inconsequential annoyance toss a wet blanket on real inquiry or open discourse. That would give them a power & influence way, way beyond their significance.

The best analogy for me is that we've got one of those 10,000 piece jig saw puzzles. It's 98% finished. It shows a cohesive, consistent picture of, say, a schooner at anchor in some beautiful South Pacific Lagoon.

There are some pieces that we just haven't figured out, & appear to be several missing pieces, and a couple of pieces that look like they'll never fit.

The fact is that there are obvious pedestrian answers for the ones we haven't figured out (just a matter of time), the missing pieces (ever lived in a house with a couple of ferrets running free?) and even the ones that look like they'll never fit (I've got relatives whose "prankish nature" is one wild hair short of torture ... and they have access to paint).

The point is that, no matter what the reasons for the few anomalous pieces, no matter whether or not we ever figure out those reasons, there is no way that we're going to disassemble the whole puzzle, start over and end up with, say, a climber summitting Mt. Everest.

The big picture is simple far too complete for that to ever happen.

You can have the (mostly Hollywood fantasy) situation of "pulling one thread & the whole garment unravels". But only when you're dealing with 2% knowledge & 98% ignorance of the whole story.

You can't have that situation when you have 98% knowledge & 2% ignorance.

Last point: when you adopt the position that "there ain't nothing to fear by looking at any aspect of the story", you can't just say it & be convincing. You have to be willing to do it.

Reasonable?

tom

tfk

21st August 2010, 08:34 AM

... oh yeah, and the technical points relate to what femr said above.

tom

ozeco41

21st August 2010, 08:46 AM

I answered a question by commenting on what led to "this type of discussion" viz: I have lost track of the details but I am pretty sure the origin of this type of discussion was....
Then commented (twice):
...The question has interest in itself as a matter of scientific curiosity...
I have no problem with your detailed discussion of a technique of scientific analysis.
But you are posting in the 9/11 conspiracies forum and that carries the implication that the discussion is linked somehow to 9/11 matters.

femr2

21st August 2010, 09:06 AM

Tom,

Is it approaching time for you to be willing to make some conclusions about the technical aspects of the tracing methods ?

I think I've made the case for the levels of accuracy attainable, along with making the limitations fairly clear. You might not agree, and if not, I think now is the time to be clear as to why.

When compared to other methods used to generate positional data from video from others, I think it's fair to say my data is of clearly superior quality, and comparable with the NIST moire method in accuracy attainable.

That the NIST moire method can only be used for one single point and my method can be used anywhere on the frame leads me to suggest that I'm generating the best quality positional data for the other building locations that there has been presented thus far. It is not clear at all how NIST performed their roofline positional data, but it's description suggests it was not great quality (their described initial point cannot be determined accurately, and there's no way to determine where the roofline actually is near their described location). There's then the fact that they used a point somewhere around the mid-point of the building width in the Cam#3 footage, which has the implication that they've interpreted the flexing and twisting motion as vertical movement, and ignored perspective correction. All these issues can be cleared up by using better, and public, trace data.

If you can accept the validity of the tracing methods, we can move forward into interpretation of the various traces that have been performed.

For WTC7 that will mean quantifying things like...

a) Was there vertical kink of the roofline ?
b) Did the NE and NW corners release at the same time ?
c) How early did movement begin ?
d) How early did vertical movement begin ?
e) Implications for NIST report...
etc, etc.

Following that, it'll be the turn of WTC1, with a plethora of traceable observations possible.

So, happy with the tracing methods, or not ?

---

ozeco41,

As above, once the hurdle of agreeing trace method accuracy has been crossed, there will be many-an observation dropping out of actually analysing some of the data. Freefall or not is not really one of those, but it's a useful excercise to calibrate the measurements at the moment.

For instance, the same tracing methods have been used on WTC 1 videos, and indicate that south wall failure was not the event which triggered initiation, rather that core failure came first. Until the methods have been explored to satisfaction of some others it's not appropriate to throw that sort of thing in the pot. Shall be done later tho.

tfk

21st August 2010, 09:47 AM

femr,

Let's use only one definition of the word "frame", please. (I am skeptical that the industry uses the same word to mean two separate things. I've never seen anyone but you make that claim. If you have a reference to anyone doing so, I'd love to see it.)

Two (fields upper & lower) make up one frame.

"fps" = frames per second.

I also finally dug up the correct definition of the term "deinterlacing".

The terminology, as you stated it, made no sense (to me, anyway). Now it does.

Deinterlacing is the process of eliminating interlace artifacts when interlaced video is shown on a progressive scan display.

Apparently deinterlacing can be done with hardware (keeping the elements on for a longer period, or line doublers or filters) while sending the interlaced video to a progressive display.

Or it can be done by "reinterlacing" the fields into frames, before sending them in a progressive format to "p" type displays.

So, in essence, you can deinterlace ("eliminate interlace artifacts") by reinterlacing (weaving the two fields back together into one frame, before sending it in p-format to a progressive scan display).

Having been broadcast in the US, would it not originally have been in NTSC-M?

It would originally be in the format recorded by the camera. The copy I use is correctly interlaced, so the original must have been a (highly probable) 59.94fps. NTSC-M is a 30 (29.97) fps format.

I understand that NTSC-M is 30 fps.

What I was saying is: the camera that recorded that video belonged to CBS, an American company, and broadcast it to American TVs.

Do American TV stations record at 60 fps, and then broadcast at 30 fps?

Please note that your own reference (http://lipas.uwasa.fi/%7Ef76998/video/conversion/) refers to a "525-line systems with a 59.94 Hz field rate". (Not frame rate)

No. As it's correctly interlaced it has to be a digital copy. I'd hazard a guess that it was provided in digital form to the folk that made the DVD it was taken from.

Any chance that you could go back to the source to find out these details?

Frame rate of original broadcast?

The DVD data is 29.97fps interlaced. It's unlikely that there has been any framerate resampling. The video shows no signs of pulldown, frame duplication or missing frames.

And this is where it gets squirrely.

A minute ago, you said 60 fps. Now you say that it is 30 fps.

There are two answers that make sense:
The data is streaming at 60 fields per second, producing 30 frames per second.
Or the data is streaming at 120 fields per second, producing 60 frames per second.

Please don't tell me that it is streaming at 60 frames per second, producing 30 frames per second.

I understand that you're getting rid of jitter by averaging points.

Yep, but the untreated data is there if you want to use a different method.

Would you post the raw data for the static locations, please. It's clear from the curves that you posted the DJ points previously.

I assume that your program takes data points from both frames

Traces are performed on both frames, yes.

I think both of us meant "both fields of a given frame".

Does it assemble the fields into one frame first, and then do its analysis?
Or does it do the analysis on each field separately?

Both datasets are *zeroed*, so the assumption is that the first samples from each dataset are at the same height.

Clarify what you mean by this, please.

the jitter is mostly about 0.5 pixel. But occasionally reduces to about 0.1 pixel. Any reason for that?

Had a look at the video, and I think it may be due to slight bleed variation of the bottom field roofline.

Clarify, please.

___

For the record, one of the engineering points goes beyond "can Syntheyes track to sub-pixel resolution".

It goes to the use of this information: What are the correct ways to determine velocity & acceleration from this data?

Which is, of course, the ultimate purpose for which the data was generated.

tom

alienentity

21st August 2010, 10:08 AM

As a lurker on this thread, I've been trying to follow the discussion, mainly curious about the measurements of acceleration.
Very pleased that TFK has chosen to take on the Femr2 data and examine it - I do think this is constructive (peer-review, after all). But as always when one starts getting into deeper engineering or technical discussions, one inevitably gets further and further away from any notion of 'conspiracy', and consequently it seems less and less relevant to be posting this on a conspiracy forum.

Don't get me wrong, I think this is a 'good thing' - there really is no evidence of a conspiracy to demolish the WTC buildings anyway, so naturally a serious discussion of any aspect of the collapses is nothing more than an engineering or technical one.

But should it even be on this forum? I think only as a citation or reference in a conspiracy discussion.

The conspiracy-related question, whether FFA = CD has still not been addressed by the truthers who made the claim, but it would be helpful if TFK and Femr2 would turn their attention to an actual controlled demolition and make the same kinds of measurements.
There are many to choose from, perhaps you gents would care to pick one and do your excellent analysis on it. :)

Sabretooth

21st August 2010, 10:37 AM

First, let me ask you a question. Do you find it (pick your adjective) annoying, vexing, bothersome, pissing you off, that I am in this conversation?

tom

No, not at all.
I guess the reason I asked is that I'm concerned this will most likely resolve nothing. The truthers will still believe what they want to believe, regardless of whatever facts and evidence we present to them.

I guess I just see it as a waste of your time...to put it bluntly.

femr2

21st August 2010, 10:39 AM

Let's use only one definition of the word "frame", please. (I am skeptical that the industry uses the same word to mean two separate things. I've never seen anyone but you make that claim. If you have a reference to anyone doing so, I'd love to see it.)

Two (fields upper & lower) make up one frame.

"fps" = frames per second.
Thought we'd been through this before, but...

What *frame* means is entirely dependant upon context.

A frame of a video which contains two interlaced fields is called a frame.

But if you separate those two fields into their correct two separate images, each of them is also called a frame.

Deinterlacing is the process of eliminating interlace artifacts when interlaced video is shown on a progressive scan display.
I don't agree. There are many ways of deinterlacing video, many of which are borne from the desire to retain as much vertical resolution as possible. However, the purest meaning of deinterlacing is simply the separation of the two fields into their correctly separate frames. They are, after all, two separate images taken at separate times. The only reason they are interlaced in the first place is a hangover from old broadcast bandwidth limitations, and the fact that human eyes are not as sensitive to vertical resolution as they are to horizontal resolution. One thing to do on that front is look at digital TV from the top of the telly. Looks awfully odd when you make the height of the image shrink.

Apparently deinterlacing can be done with hardware (keeping the elements on for a longer period, or line doublers or filters) while sending the interlaced video to a progressive display.
Best to simply focus on the basic premise of what is contained within an interlaced frame, ie two separate frames (called fields only when part of the interlaced frame), rather than get into all the various ways that software (even if running on some hardware) is used to *attempt* to retain as much vertical detail as possible. There's all manner of assumptions that occur when *blending* interlace fields in any kind of way, with varying levels of success. None of them are, however, *correct*.

Or it can be done by "reinterlacing" the fields into frames, before sending them in a progressive format to "p" type displays.
No. You're talking about either blending interlace fields there, or DEinterlacing them. They are already interlaced. If you deinterlace, then reinterlace, you're back where you started.

So, in essence, you can deinterlace ("eliminate interlace artifacts") by reinterlacing (weaving the two fields back together into one frame, before sending it in p-format to a progressive scan display).
No.

I understand that NTSC-M is 30 fps.

What I was saying is: the camera that recorded that video belonged to CBS, an American company, and broadcast it to American TVs.

Do American TV stations record at 60 fps, and then broadcast at 30 fps?
Yes. Your TV then deinterlaces the signal and shows you it at 60fps :)

Any chance that you could go back to the source to find out these details?
Can try, but not sure it's at all necessary.

There are two answers that make sense:
Okaaay...

The data is streaming at 60 fields per second, producing 30 frames per second.
Yes(ish).

Or the data is streaming at 120 fields per second, producing 60 frames per second.
No, definitely not.

Please don't tell me that it is streaming at 60 frames per second, producing 30 frames per second.
:) Okay I won't, but that's what's occurring. 60 separate images are generated by the camera. If the camera outputs interlaced video data, it takes two of those images and combines them into one interlaced image, then outputs 30 images per second.

Seemples :)

Would you post the raw data for the static locations, please. It's clear from the curves that you posted the DJ points previously.
Already did yonks ago...
http://femr2.ucoz.com/load/wtc7_dan_rather_extra_static_points/1-1-0-30

Does it assemble the fields into one frame first, and then do its analysis?
No. That's exactly what we start with, unless you're suggesting one of the dodgy field blending methods, again, none of which are at all correct for use in this context.

Or does it do the analysis on each field separately?
Yes, because I make it do so, and for very good reason.

Clarify what you mean by this, please.
Er, probably. Each location is traced twice. One for the upper field, another for the lower. Each trace value has the initial pixel location subtracted from all data points, so the first one is always zero (you should be able to see this in all of the data provided to you). I don't apply an interlace offset to the second field data, as it is simply assumed that the first samples specify the same height. Subsequent value changes are all relative to the zero, so offset is not necessary. Clear(ish) ? :)

Clarify, please.
Er, what isn't clear about the statement... is probably the easiest way to remove confusion.

It goes to the use of this information: What are the correct ways to determine velocity & acceleration from this data?

Which is, of course, the ultimate purpose for which the data was generated.
Absolutely not. The purpose for which the data was generated has nothing to do with determining velocity and acceleration. They are certainly valid questions if the data is used for that purpose, but is not why the data was generated at all. The list of additional questions as provided above should give some indication that derivation of the data is not necessary to answer quite a few reasons for generating the data.

Think there may be some word salad in this post, but it's a bit offputting to be presented with such odd interpretation of interlaced video again. Ho hum. We'll get there.

beachnut

21st August 2010, 01:32 PM

the fact that human eyes are not as sensitive to vertical resolution as they are to horizontal resolution. ...
... Why?
Source?

Where was the camera position for the video, lens focal length? The camera stand was? Where is your paper published? Where are the details for the setup?

Where did you go to school for video? Who did you study under? Why are you qualified? And how does this fit into the CD delusion? What is the conclusion of this video data analysis? What video expert (like one who has a PhD) has peer reviewed your analysis? Do you have a PhD?

femr2

21st August 2010, 02:02 PM

Why?
Perhaps a clearer statement...persistance of vision and the timing between interlaced frame display, along with better horizontal FOV than vertical FOV results in the eyes percieving less vertical artefacts than horizontal ones. Better to display interlaced video as alternate horizontal lines than vertical ones. Consider it a personal opinion if y'like. Not interested in a protracted discussion of human eye sensitivities.

Where was the camera position for the video
Have already told you I'll dig it out. Patience.

lens focal length?
No idea and unlikely to find out. Not going to make any appreciable difference either. Could see if SynthEyes can solve the scene and determine it, but there's probably not enough resolution.

The camera stand was?
Not fixed.

Where is your paper published?
What paper ?

Where are the details for the setup?
What setup ?

Stick to the technical detail beachnut. OP is clear on this request. Please don't continue with your usual rhetoric. If there is an element of information on video data you think is wrong, by all means question it.

Carll68

21st August 2010, 03:52 PM

Why?
Source?

Where was the camera position for the video, lens focal length? The camera stand was? Where is your paper published? Where are the details for the setup?

Where did you go to school for video? Who did you study under? Why are you qualified? And how does this fit into the CD delusion? What is the conclusion of this video data analysis? What video expert (like one who has a PhD) has peer reviewed your analysis? Do you have a PhD?

Of course he doesn't have a PhD! He likely does not have have any degree whatsoever. The charlatan fraud does not even understand high school level physics:

Read this gem: http://forums.randi.org/showthread.php?postid=4644501#post4644501 - Conservation of Momentum escapes him.

http://forums.randi.org/showthread.php?postid=6157496#post6157496 can't understand a simple elasticity problem

http://www.physicsforums.com/showthread.php?p=2815761&posted=1#post2815761 still doesn't get it

That the discussion has gone this far is actually disappointing.

femr2

21st August 2010, 07:25 PM

That the discussion has gone this far is actually disappointing.
The OP was very clear that this thread should not be used for your kind of, er, posts. Reported.

I fully admitted the CoM gaff I made a year or so ago within about 2 days of it occurring, so whatever personal purpose you may have is rather out of date. Very boring.

It was my interpretation of the system definition that caused the brain fart...treating a rigid body as excatly that, rigid and undeformable. Oops. Of course perfectly rigid bodies do not actually exist...

...ironically the very same kind of thing you still, after over a year, have not managed to grasp with your ramblings on your cut and paste elastic thread question.

The answer in your C&P text is the theoretical limiting case. It's the one value that cannot be reached exactly in the real world. Pretty funny really.

It would be useful for someone other than myself to assert that Fo/2 is an unattainable limiting case to close the book on the whole ramble.
I agree that the Fo/2 is a limiting case that only occurs when c = 0. You won't find that with any real-world material.

As you will clearly have nothing useful to contribute to this thread carlly/bigc, please refrain from further posting here. I am sure that given the clear requests made from OP onwards the mod team will have no issue dealing with further interruptions.

Carll68

21st August 2010, 07:36 PM

you will clearly have nothing useful to contribute to this thread carlly/bigc, please refrain from further posting here. I am sure that given the clear requests made from OP onwards the mod team will have no issue dealing with further interruptions.

Nothing useful except to expose your uneducated charlatan presence to everyone, in hopes they they will realize they are investing there time arguing with a fraud who can not grasp simple physics....but claims to be an expert...who holds nary a degree...but presents himself as an authority....

You still don't get it, do you?

This whole useless video analysis --where you are trying to somehow prove your senseless CD dreams - is about as useless as the collapse 'model' you created that matured into a complete laughing stock .. (all the energy goes to crushing the concrete...LOL)...

Much like your previous UFO hoaxes kid.... you are a fraud

femr2

22nd August 2010, 11:57 AM

There doesn't seem to be much input relating to noise treatment methods, which from my perspective is the main purpose of this thread.

There's also been very little progress in terms of opinion on data quality. Not quite sure why. Graphs have been presented which are in good agreement with the NIST moire method, showing horizontal movement down to inch accuracy. Inch, not feet :eye-poppi

The focus on second order derivations of the data is fine up to a point, as it's there where noise levels can be amplified if the data is not treated appropriately.

However, the majority of points I intend on analysing do not require derived data plots, but instead use position/time data comparisons between various points to describe order and scale of movement, not rate of movement. An example of this would be using trace data to determine the angle through which *tilt* of WTC1 progressed before *release* of all four corners (and so the transition to vertical drop).

Worth noting the strange additional focus on my *analysis* of the data...which I haven't really done here yet. The extent of *claims* at this point is simply suggesting a +/- 0.2 pixel accuracy for the Dan Rather position/time data. Of course that value will vary depending upon what footage is being traced.

So here's some NIST Cam#3 data...
Download (http://femr2.ucoz.com/load/trace_data_nist_camera_3_raw/1-1-0-28)

Will begin some analysis of the data soon ;)

GlennB

22nd August 2010, 12:25 PM

Will begin some analysis of the data soon ;)

What might be achieved by this analysis in terms of 9/11 CT (which, after all, is where this thread currently resides) ? If we're looking at pure science - for the joy of science - it should be in the science sub-forum. If not, then surely any conclusions that might be drawn from the video analysis are fair game for generalised counter argument, CT-wise, no?

In which case, afaics, the terms and conditions of the o/p are unreasonable. Rather like calculating whether the health of my cattle appeared to improve through homepathic treatment while arbitrarily banning any discussion of homeopathy.

Meanwhile, there is a perfectly functional pm system if a (very, in this case) few people wish to exchange private communications. Or email.

femr2

22nd August 2010, 12:53 PM

What might be achieved by this analysis
Methinks it sensible to actually do the analysis first eh :)

any conclusions that might be drawn from the video analysis are fair game for generalised counter argument
Generalised ? No, of course not. Counter argument specific and directly related to the conclusion in question, sure. What an odd thing to ask.

there is a perfectly functional pm system if a (very, in this case) few people wish to exchange private communications. Or email.
You are very welcome to ignore the thread. You're not obliged to participate you know.

TexasJack

22nd August 2010, 01:07 PM

What might be achieved by this analysis in terms of 9/11 CT (which, after all, is where this thread currently resides) ? If we're looking at pure science - for the joy of science - it should be in the science sub-forum. If not, then surely any conclusions that might be drawn from the video analysis are fair game for generalised counter argument, CT-wise, no?

In which case, afaics, the terms and conditions of the o/p are unreasonable. Rather like calculating whether the health of my cattle appeared to improve through homepathic treatment while arbitrarily banning any discussion of homeopathy.

Meanwhile, there is a perfectly functional pm system if a (very, in this case) few people wish to exchange private communications. Or email.

I agree, there's no CT here and this thread should be moved to the science forum. You'll probably get more attention there from other people that are adept in these fields. Posting it here and stating I don't know if it is a CT or not doesn't cut it.

femr2

22nd August 2010, 02:17 PM

there's no CT here
So you wouldn't classify refudation of multiple NIST conclusions under that moniker then ? That's interesting.

stating I don't know if it is a CT or not doesn't cut it.
CT ? I'm afraid not everything falls under such convenient tag-lines. I guess you'd brand MIHOP as a CT, which is just weird seeing as MIHOP includes nothing whatsoever about pointing fingers, simply mechanism. Interesting.

Perhaps you should examine tfk's motivation for starting the thread. I get the impression there's a fair few locals, such as yourself, that really don't want to have to spend any time or effort employing those ol' critical thinking skills, and simply enjoy getting a fix of *twoofer baiting*, or some other quasi-fetishist negative discourse banter.

If you are not interested in the content of the thread, simply ignore it. There are numerous threads within this category that are far from, how you say, CT related. They'd all have to go as well of course ;)

Now, there is an established dialogue occurring, and it would be appreciated if you have nothing useful to contribute that you simply post nothing at all.

TexasJack

22nd August 2010, 03:15 PM

So you wouldn't classify refudation of multiple NIST conclusions under that moniker then ? That's interesting.

If you ever get around to a "refudation" you still have to tie it into a CT. Simply nitpicking mistakes that NIST has made, doesn't invalidate their findings. You must come up with an alternative CT hypothesis that is relevant this forum. You have failed to do this. Why are you reluctant to have this moved to a more appropriate forum, where you can get the peace and quiet you keep complaining about? You will also get more input from that forum.

I get the impression there's a fair few locals, such as yourself, that really don't want to have to spend any time or effort employing those ol' critical thinking skills, and simply enjoy getting a fix of *twoofer baiting*, or some other quasi-fetishist negative discourse banter.

Ah, look who's doing the baiting, good job hypocrite.

If you are not interested in the content of the thread, simply ignore it. There are numerous threads within this category that are far from, how you say, CT related. They'd all have to go as well of course ;)

The subject is this thread; your speculation on other threads is irrelevant.

Now, there is an established dialogue occurring, and it would be appreciated if you have nothing useful to contribute that you simply post nothing at all.

Please don't tell me what I should or shouldn't do, this is not your forum. If you noticed, I was responding to Glenn's post. If you don't like a post, report it, instead of whining about it. I will do you a favor, I'll put you on ignore, and leave it up to tfk if he wants this thread moved to Science, Mathematics, Medicine, and Technology, where IMO I think it belongs.

femr2

22nd August 2010, 03:39 PM

If you ever get around to a "refudation"
Have to agree on method validity first.

Simply nitpicking mistakes that NIST has made, doesn't invalidate their findings.
So if they got it wrong, they got it right ? Splendid.

You must come up with an alternative CT hypothesis that is relevant [to] this forum.
No I don't. I'm responding to the the thread topic.

Why are you reluctant to have this moved to a more appropriate forum
What gave you that impression ?

where you can get the peace and quiet you keep complaining about? You will also get more input from that forum.
The ignore coming up is the perfect solution ;)

Ah, look who's doing the baiting, good job hypocrite.
We can all get frustrated with pointless interruption. Numerous posts now that are completely off topic, regardless of where the thread is located. Annoying, and dilutes the usefulness of the thread for anyone who may be interested in its content.

The subject is this thread
Should be, but at the moment it's where you think it should be located.

your speculation on other threads is irrelevant.
And yours on this one is off topic.

Please don't tell me what I should or shouldn't do, this is not your forum.
I haven't. I've politely suggested what would be appreciated.

If you noticed, I was responding to Glenn's post. If you don't like a post, report it, instead of whining about it.
I respond to most posts I'm afraid.

I will do you a favor, I'll put you on ignore, and leave it up to tfk if he wants this thread moved to Science, Mathematics, Medicine, and Technology, where IMO I think it belongs.
Excellent. Laters.

Carll68

22nd August 2010, 05:25 PM

I agree, there's no CT here and this thread should be moved to the science forum. You'll probably get more attention there from other people that are adept in these fields. Posting it here and stating I don't know if it is a CT or not doesn't cut it.

TJ, this charlatan uneducated fraud simply doesnt get it. It is a bad investment of time to discuss this analysis, as it is both flawed in it's 'opinion related' conclusion and lacking in accuracy. Lil femr - this kid without a degree - is simply trying new ways to slip in his delusions of CD.

femr--do you think either 1, 2 or 7 was a CD?

Yes or no?

If no, then what is your point? Should this whole elementary exerciser not be moved to the science forum, where it can be accurately assessed and your flaws pointed out? Remember the Physics forum where your diluted incorrect answer to the high school physics question I asked got posted, and you were soon told how incorrect you were? It took a total of 2 posts.

If yes, then what evidence do you have to support your delusions? We all know it's 'Yes', after all, not too long ago, you were arguing that there was no energy from the collapse to hurl the WTC debris to Winter Garden roof. So, since it is Yes....where, from this flawed SynthEyes program incorporation, are you looking to derive your evidence?

beachnut

22nd August 2010, 09:03 PM

Perhaps a clearer statement...persistance of vision and the timing between interlaced frame display, along with better horizontal FOV than vertical FOV results in the eyes percieving less vertical artefacts than horizontal ones. Better to display interlaced video as alternate horizontal lines than vertical ones. Consider it a personal opinion if y'like. Not interested in a protracted discussion of human eye sensitivities. why mention it … it was your opinion based on BS. No source.
Phosphor

Have already told you I'll dig it out. Patience. Take your time; 8 years have passed. What is another 8 years to 911 truth?

No idea and unlikely to find out. Not going to make any appreciable difference either. Could see if SynthEyes can solve the scene and determine it, but there's probably not enough resolution. no focal length? No lens or camera details? Any tech info on the setup?

Not fixed. The camera is flying?

What paper ? No paper? What is goal?

What setup ? The setup. position of camera, focal length, etc… Without the setup the science is not there. Makes this effort equal to bar talk.

Stick to the technical detail beachnut. OP is clear on this request. Please don't continue with your usual rhetoric. If there is an element of information on video data you think is wrong, by all means question it. I have tried to get tech info; you don’t know. What is the goal of the work? Will your work support CD? How? Simple technical questions. Do you have a goal?

dafydd

22nd August 2010, 10:29 PM

The OP was very clear that this thread should not be used for your kind of, er, posts. Reported.

I fully admitted the CoM gaff I made a year or so ago within about 2 days of it occurring, so whatever personal purpose you may have is rather out of date. Very boring.

It was my interpretation of the system definition that caused the brain fart...treating a rigid body as excatly that, rigid and undeformable. Oops. Of course perfectly rigid bodies do not actually exist...

...ironically the very same kind of thing you still, after over a year, have not managed to grasp with your ramblings on your cut and paste elastic thread question.

The answer in your C&P text is the theoretical limiting case. It's the one value that cannot be reached exactly in the real world. Pretty funny really.

As you will clearly have nothing useful to contribute to this thread carlly/bigc, please refrain from further posting here. I am sure that given the clear requests made from OP onwards the mod team will have no issue dealing with further interruptions.

We take it that you have no qualifications.

femr2

23rd August 2010, 07:03 AM

it was your opinion based on BS
Nope, but such a trivial point it's not worth arguing about.

The camera is flying?
No, it's on a tripod, but not fixed. If you'd even bothered to watch the video you'd know this.

Without the setup the science is not there. Makes this effort equal to bar talk.
NIST did not look at the *setup* for any of their positional data, and regardless, the effect upon results is trivial. Perhaps you'd like to quantify the pixel-scale effect of various lenses and focal lengths on the resulting image data and derived metrics ;) Best use reasonable values though. There was a limited range of professional broadcast cameras used by the media in that place on that day yeah.

What is the goal of the work?
The work ? Read the OP. That outlines the purpose of the thread.

We take it that you have no qualifications.
You can take whatever you like, and assume whatever you like dafydd, but may I remind you to address the topic. If there is an error you want to highlight, by all means say so and provide a correction...

beachnut

23rd August 2010, 07:32 AM

Nope, but such a trivial point it's not worth arguing about.

No, it's on a tripod, but not fixed. If you'd even bothered to watch the video you'd know this.
...

No goal. Perfect. Why can't you state a goal of the work. What about your CD theory? How does this work dovetail with your CD theory?

BTW, it is BS when you say it is trivial. Why bring up trivia when you know it is talk you make up based on your opinions? If you have no goal your work is trivial, and is not worth arguing about. No purpose.

What is your goal of your work, your purpose.

The work ? Read the OP. That outlines the purpose of the thread.
You read the OP, and come up with your purpose; or is it a trivial point? Your work, the purpose of your work? How does it support your CD theory?

femr2

23rd August 2010, 07:40 AM

it is BS when you say it is trivial.
Quantify the pixel level effect of your suggested additional factors, then also approach NIST and present the same information to them.

What is your goal of your work, your purpose.
I have stated the purpose of performing the tracing many times in several threads. An example...
Post #94 (http://forums.randi.org/showpost.php?p=6251104&postcount=94)

If you cannot be bothered to read the thread content, you will continue to have a blinkered viewpoint.

beachnut

23rd August 2010, 07:49 AM

Quantify the pixel level effect of your suggested additional factors, then also approach NIST and present the same information to them.

I have stated the purpose of performing the tracing many times in several threads. An example...
Post #94 (http://forums.randi.org/showpost.php?p=6251104&postcount=94)

If you cannot be bothered to read the thread content, you will continue to have a blinkered viewpoint.
You never stated your qualification and education to conduct this blinkered work. No over all goal noted. I have read your BS about NIST, and you don't even have a position for the camera, you have no tech data on lens and equipment. blinkered? lol

I see why this will not be published past the Internet. No goal.

femr2

23rd August 2010, 08:24 AM

I have read your BS about NIST
Really ? What *BS* would that be ? Feel free to point out mistakes Beachnut.

you don't even have a position for the camera
Yet again, incorrect. It's kicking around in my piling system somewhere. By all means go find it for yourself, and then quantify the specific technical reason you think you need it, then quantify the effect on the data.

you have no tech data on lens and equipment.
Almost true, yes. And again, you need to quantify the effect of the additional distortions before complaining about it.

Oh, and am I right in suggesting that you think all of the NIST video analysis is useless as they have not taken account of any of the factors you suggest ?

I see why this will not be published past the Internet.
What is it that you think should be published beachnut ? lol. If at the end of trace data analysis I find something interesting, I'll make it known. Said it before many-a-time. It's really not my concern that your blinkered view of my intentions leads you to make such blinkered conclusions, but, well, there you go ;)

beachnut

23rd August 2010, 11:25 AM

Really ? What *BS* would that be ? Feel free to point out mistakes Beachnut. Read the thread; it was clear you posted BS. Feel free to go back and source your statement, which you failed to source and admitted was trivial talk, IE BS.

Yet again, incorrect. It's kicking around in my piling system somewhere. By all means go find it for yourself, and then quantify the specific technical reason you think you need it, then quantify the effect on the data. Add elevation when you find the exact location. Better add all tech data on the camera and lens. How far away. Will you model the errors? Will you use a Kalman filter with the error analysis?

Almost true, yes. And again, you need to quantify the effect of the additional distortions before complaining about it. You need to do this, it is your analysis. Not knowing the additional distortions is due to what? Lack of knowledge, or no expertise in this field? What is your degree in?

Oh, and am I right in suggesting that you think all of the NIST video analysis is useless as they have not taken account of any of the factors you suggest ? What does your work have to do with 911 conspiracy theories? What does this have to do with your CD delusion? What does this have to with debunking the crazy 911 conspiracy theories; the sub-forum topic?

You don't know what NIST has for tech data on their analysis; you said so.

What is it that you think should be published beachnut ? lol. If at the end of trace data analysis I find something interesting, I'll make it known. Said it before many-a-time. It's really not my concern that your blinkered view of my intentions leads you to make such blinkered conclusions, but, well, there you go ;)
You have no goal to apply this to 911 conspiracy theories? Then what is the goal; no goal? Is this suppose to support 911 truth's failed CD theory?

femr2

23rd August 2010, 11:41 AM

Read the thread; it was clear you posted BS.
No Beachnut, you said *your BS about NIST *. Now out with it...what *BS* would that be ?

Add elevation when you find the exact location. Better add all tech data on the camera and lens. How far away. Will you model the errors? Will you use a Kalman filter with the error analysis?
Perhaps.

You need to do this, it is your analysis.
No I don't. Feel free to do so if you like though. The raw data is freely available.

Not knowing the additional distortions is due to what?
The scale of the resultant distortions would be trivial, which is why I'm really not at all concerned. Again, if you want to pop off and quantify such, by all means feel free.

You don't know what NIST has for tech data on their analysis
Incorrect. NIST make it clear what factors they accounted for. They also shockingly state that even for the Cam#3 footage traces they didn't even bother to apply perspective correction. :eek:

They most certainly did not account for lens distortion, camera optics...nowt. They didn't even bother to account for camera shake...no static point extraction.

But beachnut, you're going to have to wait. I haven't done the analysis yet. If there's something I want you to know, I'll let you know ;)

beachnut

23rd August 2010, 12:09 PM

... I haven't done the analysis yet. If there's something I want you to know, I'll let you know ;)
No source for your BS; got it ;)

No goal; and your work is not related to anything about 911 conspiracy theories. Got it. ;)

When compared to other methods used to generate positional data from video from others, I think it's fair to say my data is of clearly superior quality, and comparable with the NIST moire method in accuracy attainable.

I think your data is not better than others. You have not qualified your background or sourced your methods. It is clear there is no science in your overall approach. You dismiss the errors, skip them. Then you think you can make up data from video which lacks the accuracy you come up with.

I think your data is worse after your efforts to "analysis" it. What undergraduate studies did you have in this area?

jaydeehess

23rd August 2010, 03:46 PM

So you wouldn't classify refudation of multiple NIST conclusions under that moniker then ? That's interesting.

.

Actually wrt to WTC 7, no it does not constitute evidence of any conspiracy.

NIST was not attempting a foresic conclusion about the short duration of FFA. Others however are trying to do exactly that and stating that NIST's not doing so is the CT.

Fact is that this very thread indicates that a conclusion about the detailed cause of the FFA period has little or no use in determining what minute details of the overall collapse caused this short duration of FFA. The whole exercise is pretty much irrelevent then and simply indicates why NIST would not go down such a path and waste more time and tax payer's money.

femr2

23rd August 2010, 04:25 PM

NIST was not attempting a foresic conclusion about the short duration of FFA.
Neither am I. NISTs moire method should however be classified as forensic, as it involved determining building movement to inch accuracy.

Others however are trying to do exactly that
I'm not interested in what others are trying to do.

Fact is that this very thread indicates that a conclusion about the detailed cause of the FFA period has little or no use in determining what minute details of the overall collapse caused this short duration of FFA.
I have made it repeatedly clear that I'm not really interested in freefall, near freefall or over freefall. The purpose of the thread, started by tfk, primarily to examine my suggestion that the positional data is +/- 0.2 pixel accurate.

I think your data is not better than others.
What you think it not really relevant beachnut. You say many things, none of which you provide any reason for. By all means provide your reasoning for making such a claim, including specific detail for *others*. I shall of course respond with as much detail as necessary.

You have not sourced your methods.
Incorrect. I have explained my methods in great detail.

You dismiss the errors, skip them.
Incorrect. The entire purpose of this thread is for tfk to examine the ability to produce sub-pixel accurate positional data. Determination of error has been the primary focus of the topic, until the obstructive and rather pointless influx of recent posts from members such as yourself.

Then you think you can make up data from video which lacks the accuracy you come up with.
Incorrect. The data is not made up in the slightest, and full detail has been provided for anyone to replicate the same data. If you wish to suggest an alternate noise level estimation, then by all means do so. The links to the data are provided earlier in the thread. Dan Rather data is what you'll be-a-wantin there.

I think your data is worse after your efforts to "analysis" it.
What ? Haven't presented any analysis of the data yet beachnut. Again, what you think is irrelevant and substanceless. By all means qualify what you are attempting to say, though if you could ensure it makes sense it would be appreciated. Thanks pal ;)

metamars

23rd August 2010, 06:38 PM

. You say many things, none of which you provide any reason for.

It's an infrequent event when beachnut writes anything worth reading. I suggest that you put him on ignore. That's what I did.

femr2

24th August 2010, 05:23 AM

The entire purpose of this thread is for tfk to examine the ability to produce sub-pixel accurate positional data.

A slight correction...

The purpose of this thread is for tfk to examine the ability to produce sub-pixel accurate data for change in position of specified features in video.

It is important to make that distinction.

carlitos

24th August 2010, 05:27 AM

Actually, none of this is important, because you have no hypothesis about the events of 9/11, but by all means carry on.

dafydd

24th August 2010, 07:01 AM

Actually, none of this is important, because you have no hypothesis about the events of 9/11, but by all means carry on.

Very true.I have been a member here for two years and no truther has ever put forward anything even remotely resembling a hypothesis.Still,one lives in hope.

femr2

24th August 2010, 10:10 AM

tfk,

It seems the thread is heading towards a potentially unrecoverable tangent of substanceless and off topic posts from others. Quite how folk have so much free time as to be motivated to comment on threads they clearly have no interest in is beyond me. Bizarre.

However, there's always hope that they simply choose to ignore topics they have nothing to contribute to, allowing the thread to continue without the dilution of focus and increase in noise that such interruptions result in. Let's hope that's not the actual intention eh. I'm partially surprised that actions from moderators have been conspicuous by there absence, but whatever.

Assuming such folk decide to go and do something they are interested in, rather than make noise here...

1) Are you satisfied that position change trace data can be sub-pixel accurate ?

http://femr2.ucoz.com/_ph/3/2/89078455.jpg

http://femr2.ucoz.com/_ph/7/2/349864523.jpg

If not, why not ?

2) Do you require any further detail on the treatment of the actual video data, such as deinterlacing ?

3) Are you planning on presenting any position/time or derivative data smoothing methods in detail ?

4) Are you planning on presenting the error analysis previously mentioned, which if I recall included quantifying the various sources of noise ?

5) Have you managed to download the video yet ?

6) Have you found any additional building measurement data for building elements, to assist in refining scaling metrics further ?

7) Have you applied your derivation methods to the Cam#3 data ?

jaydeehess

24th August 2010, 10:34 AM

I agree that the expressed purpose of this thread does not include discussion of the how and why of the period of free fall or faster than free fall acelleration of the north side of WTC 7.
I suggest that those whp wish to pursue that line start a new thread
"If a portion of WTC 7 achieved free fall or faster than free fall, how relevent is it?"

tfk

24th August 2010, 10:53 AM

TJ, this charlatan uneducated fraud simply doesnt get it. It is a bad investment of time to discuss this analysis, as it is both flawed in it's 'opinion related' conclusion and lacking in accuracy. Lil femr - this kid without a degree - is simply trying new ways to slip in his delusions of CD.

femr--do you think either 1, 2 or 7 was a CD?

Yes or no?

If no, then what is your point? Should this whole elementary exerciser not be moved to the science forum, where it can be accurately assessed and your flaws pointed out? Remember the Physics forum where your diluted incorrect answer to the high school physics question I asked got posted, and you were soon told how incorrect you were? It took a total of 2 posts.

If yes, then what evidence do you have to support your delusions? We all know it's 'Yes', after all, not too long ago, you were arguing that there was no energy from the collapse to hurl the WTC debris to Winter Garden roof. So, since it is Yes....where, from this flawed SynthEyes program incorporation, are you looking to derive your evidence?

Sorry guys,

I've been caught up in work the last week. Very little spare time.

Carl, you're opinion is well known. Please keep it elsewhere. It doesn't help the conversation.

Thanks.

tom

beachnut

24th August 2010, 11:04 AM

Neither am I. NISTs moire method should however be classified as forensic, as it involved determining building movement to inch accuracy.

I'm not interested in what others are trying to do.

I have made it repeatedly clear that I'm not really interested in freefall, near freefall or over freefall. The purpose of the thread, started by tfk, primarily to examine my suggestion that the positional data is +/- 0.2 pixel accurate.

What you think it not really relevant beachnut. You say many things, none of which you provide any reason for. By all means provide your reasoning for making such a claim, including specific detail for *others*. I shall of course respond with as much detail as necessary.

Incorrect. I have explained my methods in great detail.

Incorrect. The entire purpose of this thread is for tfk to examine the ability to produce sub-pixel accurate positional data. Determination of error has been the primary focus of the topic, until the obstructive and rather pointless influx of recent posts from members such as yourself.

Incorrect. The data is not made up in the slightest, and full detail has been provided for anyone to replicate the same data. If you wish to suggest an alternate noise level estimation, then by all means do so. The links to the data are provided earlier in the thread. Dan Rather data is what you'll be-a-wantin there.

What ? Haven't presented any analysis of the data yet beachnut. Again, what you think is irrelevant and substanceless. By all means qualify what you are attempting to say, though if you could ensure it makes sense it would be appreciated. Thanks pal ;)
I was interested in your qualifications to do the work; I assume you have zero since you post opinions which are wrong and not based on reality.

You can't source your work to specific qualified research. Or you would.

You can't source your qualifications. Your data is not an improve data set, and you can't prove it because you are not using methods which would improve the accuracy of the data, you are waving your hands and making up methods to make the data look better to you.

How does this relate to any Conspiracy! This is a CT sub-forum. Connect the dots.

femr2

24th August 2010, 11:55 AM

I was interested in your qualifications to do the work
I have exactly zero intention of posting any personal details, and that is never going to change.

I assume
You can assume whatever you please beachnut.

Your data is not an improve data set
As opposed to which other available "Dan Rather footage" point trace dataset would that be beachnut ?

And please sort out the grammar.

you are not using methods which would improve the accuracy of the data
Improve the accuracy ? What are you talking about ? I use procedures to ensure the best trace accuracy possible, which I've explained in detail. But you are, er, delusional if you think any subsequent post-processing changes the data accuracy. It's possible to filter or smooth noise, sure, but it sounds like you're talking out of your proverbial.

you are waving your hands
I suggest you have a serious look in the mirror beachnut.

Connect the dots.
There's an idea. Am sure your local newsagent will have several colouring books with suitable pictures. You may even get a free pen.

Enough of your nonsense beachnut. You have no interest in this thread. Simply ignore it. Thanks matey.

tfk

24th August 2010, 12:25 PM

femr,

Sorry, real life intrudes... And it will continue to intrude for about a week.

1) Are you satisfied that position change trace data can be sub-pixel accurate ?

I am satisfied that it CAN be done.

I am not satisfied that you have demonstrated that level of precision in these data sets.

I am not saying that you have not. I am saying that I'm not yet convinced.

http://femr2.ucoz.com/_ph/3/2/89078455.jpg

http://femr2.ucoz.com/_ph/7/2/349864523.jpg

If not, why not ?

I am not simply rejecting your claim for capricious reasons.

The fact is that it is up to you to prove two things:

1. that SynthEyes can generate subpixel resolution.

2. that it can generate them IN THESE VIDEOs (given the unknowns of source, the camera motions, heat refraction, etc.)

This is why I asked you for static points on the other buildings.

BTW, you gave me "2 point averaged" static points. Not the individual field static points.

Could you post the individual field data, please.

Also, btw, looking at the video, just outside the heavy black lines that outline the building is a border of extra light, translucent pixels. It looks about as wide as the black line. Does this look like a compression artifact to you?

2) Do you require any further detail on the treatment of the actual video data, such as deinterlacing ?

No thanks. I found it.

I gotta say, your explanations kinda suck.

After a significant amount of searching, I found ONE source (out of about 100) that referred to fields as frames.

And that one source was careful enough to clarify that a) it's a holdover term used in analog signals, and (MOST important) b) that definition of Frame means 262.5 lines. Not 525 lines.

[You could have cleared a bunch up with this simple comment. Sometime I get the impression that "clearing things up for others" is not your top priority.]

The other 99% of references (INCLUDING YOUR OWN) refers to the individual fields as fields, and define 2 fields per frame. Your source refers to "525-line systems with a 59.94 Hz FIELD rate."

3) Are you planning on presenting any position/time or derivative data smoothing methods in detail ?

Yup. Planning on it. Soon as I get time.

4) Are you planning on presenting the error analysis previously mentioned, which if I recall included quantifying the various sources of noise ?

Nope. That's your job. I'm not going to do it for you. I can not do it for you, because there are far too many details about your analysis that are obscure & not well explained.

5) Have you managed to download the video yet ?

Yup.

6) Have you found any additional building measurement data for building elements, to assist in refining scaling metrics further ?

Nope.

7) Have you applied your derivation methods to the Cam#3 data ?

Yup. But only looked at it momentarily.
__

I'll get this stuff posted as soon as it's finished. I won't just delay for any reason.

But my other work takes precedence.

Your work does not depend on anything that I do.

It's your job to provide all the information required to convince anyone who reads your work.

The information that you've provided thus far does not convince me. Part of that is my inability to decipher what you are saying. A big part of that is having to go back to you to get your definition of terms, trying to pry details out of you (IMO), etc.

Plus you & I don't communicate all that great in the first place.

tom

W.D.Clinger

24th August 2010, 01:25 PM

4) Are you planning on presenting the error analysis previously mentioned, which if I recall included quantifying the various sources of noise ?
Although that was addressed to tfk, I have a couple of comments.

The forward error analyses I have offered provide bounds for the worst case quantization error in the calculated acceleration, as a function of the worst-case quantization error in the position and the sampling rate used to calculate the acceleration. It is easy to prove that an extreme worst-case signed quantization error cannot persist throughout the entire data set, and possible (but not quite so easy) to prove that the expected quantization error is much smaller than the worst case.

There's a very easy practical check on the error in femr2's data:

Discard every other data point, because the deinterlacing led to some obvious bias in at least one data set.
Downsample the remaining data to a sampling rate at which the worst-case quantization error is reasonable.
Let's say we downsample from 30 Hz to 5 Hz. That means we get 6 independent downsampled data sets, each offset by 1/6 second. Compute accelerations for all 6, and compare the differences.

If there's a lot of error in each position, then the 6 computed accelerations will look pretty different, even if their average (smoothed) acceleration is about the same. If the 6 computed accelerations look similar, with the differences dominated by the 1/6-second phase shifts, then there can't be much independent error in each position sample.

That check can't rule out systematic error, but it could eliminate lingering doubts about subpixel resolution.

femr2

24th August 2010, 01:56 PM

real life intrudes
No worries.

I am satisfied that it CAN be done.
Okay.

I am not satisfied that you have demonstrated that level of precision in these data sets.
Darn. Okay, we'll get there in the end.

1. that SynthEyes can generate subpixel resolution.
Think it's important to make sure we are both speaking da same lingo yeah :) SynthEyes tracking sub-pixel position CHANGE of tracked features, yes ? I hope that's been pretty much nailed with the *blob* trace...
http://femr2.ucoz.com/_ph/3/156677416.png

Do you accept that the blob trace shows that SynthEyes tracks position change to a sub-pixel accuracy ? I'd say the data behind that trace shows SE is possible of determining movement down to ~0.002 pixels ;)

2. that it can generate them IN THESE VIDEOs (given the unknowns of source, the camera motions, heat refraction, etc.)
The first thing to highlight here is the difference between the noise level in the blob trace and the noise level in the WTC7 trace.

As far as I am concerned, the difference in noise levels is a very good way to quantify the variance added by most of the elements you mention.

The technical method employed to track the feature is exactly the same between the two of course, and the potential accuracy shouldn't change, only the video data quality itself changes.

Would it help your perspective if I said...

The traces show the change in position of the specified feature on the video to sub-pixel accuracy. That does not necessarily mean that *in the real world* the pixelised feature video data represents the exact position of that feature. The tracking method cannot *make up* movement. When SynthEyes determines that the pixelised feature has moved left 0.1 pixels, the upscaling, filtering and pattern matching algoriths employed are reporting true shift in pixel data.

BTW, you gave me "2 point averaged" static points. Not the individual field static points.

Could you post the individual field data, please.
Can do.

Does this look like a compression artifact to you?
It looks more like a halo to me.

I gotta say, your explanations kinda suck.
We speak in slightly differing tongues I rekn. Perhaps it's that things like interlaced video are a bit trivial to me, and I can't really see how there can be any confusion.

After a significant amount of searching, I found ONE source (out of about 100) that referred to fields as frames.
But Tom, Tom, Tom....it's just a word. What I've been saying about a frame being called a field of an interlace frame only when it's treated as part of that interlace frame is correct. A picture is an image is a frame is a field (when part of an interlaced frame). It's all just terminology, so as long as you understand how I've been treating the data, it's all cool.

that definition of Frame means 262.5 lines. Not 525 lines.
Absolutely not. How many frames are there on your old analogue camera film ? How many lines are there on a 4k HD video frame ? etc, etc. Frame is a universal word with many meanings even within the video arena. We're all clear though I hope. Not splitting hairs, but I'll probably use the word frame in numerous contexts as appropriate.

Nope. That's your job. I'm not going to do it for you. I can not do it for you, because there are far too many details about your analysis that are obscure & not well explained.
No problem on retracting the analysis you said you were going to provide, but the rest is a bit ridiculous.

Get SynthEyes (or equivalent)
Get the video.
Unfold it.
Trace the NW corner in both frames (fields if you will)
Export the traces.
Open in excel.
Save.
Upload.

Job done.

That's about the extent of the *analysis* you say is not being explained. Easy as pie. You'll then have generated the raw data and published it. Anything there obscure or difficult to understand ?

It's your job to provide all the information required to convince anyone who reads your work.
That's fine up to a point. You stared this thread with a purpose. Have you achieved it ? If not, is that because you think I've not provided information of some sort ? If so, what ? Really can't think of much that could be missing. Generating the data is a piece of pie. The only processing I've done in the data supplied to you is to *zero* it and combine both fields traces into a single timeline. Bit-o jitter treatment, sure.

The information that you've provided thus far does not convince me. Part of that is my inability to decipher what you are saying. A big part of that is having to go back to you to get your definition of terms, trying to pry details out of you (IMO), etc.
Well you know I'll provide you with answers. Whadaya need ?

Plus you & I don't communicate all that great in the first place.
That's true. Agreement ;) Woot, woot.

femr2

24th August 2010, 02:01 PM

That means we get 6 independent downsampled data sets, each offset by 1/6 second. Compute accelerations for all 6, and compare the differences.
Couldn't agree more. Have the results sitting in the wings, though I've left the data as it's two separate field traces and done 3-per. (3/29.97s interval)

Will get some graphs done and post them a bit later.

pgimeno

24th August 2010, 03:17 PM

After a significant amount of searching, I found ONE source (out of about 100) that referred to fields as frames.

femr2, for tfk's and maybe someone else's ease following your use of the words "field" and "frame", please let me know if your use matches this description:

- A field is a subimage of an interlaced image, but it is called field only as long as it is part of such interlaced image.
- After an interlaced video is deinterlaced, what were fields are now promoted to full frames and you get a doubled-framerate video made only of non-interlaced frames in which there's no concept of field.
- For treatment with SynthEyes, you use deinterlaced video, meaning you talk about frames all the time. However, they come from upper or lower fields and that distinction is significant in some cases.

That's what I understand, and I think that tfk was trying to refer to the frames in the deinterlaced video as fields too. For what I've seen, that seems to have been the cause of confusion.

femr2

24th August 2010, 03:28 PM

femr2, for tfk's and maybe someone else's ease following your use of the words "field" and "frame", please let me know if your use matches this description:
Okay.

- A field is a subimage of an interlaced image, but it is called field only as long as it is part of such interlaced image.
Yes.

- After an interlaced video is deinterlaced, what were fields are now promoted to full frames and you get a doubled-framerate video made only of non-interlaced frames in which there's no concept of field.
Yes. That is termed a bob-doubled form. I leave the deinterlaced video in unfolded form though, like this...
http://femr2.ucoz.com/_ph/7/2/125286220.jpg

- For treatment with SynthEyes, you use deinterlaced video, meaning you talk about frames all the time.
Yes, though in unfolded form as described above.

That's what I understand, and I think that tfk was trying to refer to the frames in the deinterlaced video as fields too. For what I've seen, that seems to have been the cause of confusion.
Hope we're all clear :)

jaydeehess

24th August 2010, 03:31 PM

femr2, for tfk's and maybe someone else's ease following your use of the words "field" and "frame", please let me know if your use matches this description:

- A field is a subimage of an interlaced image, but it is called field only as long as it is part of such interlaced image.
- After an interlaced video is deinterlaced, what were fields are now promoted to full frames and you get a doubled-framerate video made only of non-interlaced frames in which there's no concept of field.
- For treatment with SynthEyes, you use deinterlaced video, meaning you talk about frames all the time. However, they come from upper or lower fields and that distinction is significant in some cases.

That's what I understand, and I think that tfk was trying to refer to the frames in the deinterlaced video as fields too. For what I've seen, that seems to have been the cause of confusion.

Does this all not presume that the original video was presented to a digital recording device from a digital camera?
If either one was an analogue device then each feild was originally 262.5 lines with an equal number of blank lines (no information) between each line. Furthermore a couple dozen of those lines would contain no image information as they are merely placeholders in the vertical blanking interval.

If each feild contained a full raster then there is no "feild/frame" distinction and it is not interlaced video it is progressive.

Myriad

24th August 2010, 03:32 PM

femr2

24th August 2010, 03:37 PM

However, they come from upper or lower fields and that distinction is significant in some cases.
Yes.

The reason I leave the video in unfolded form is that, as there is an inherent *shift* in vertical position between each field, the *shape* of small features is much more consistent between consecutive upper fields and consecutive lower fields.

Performing two traces, one for the feature on the upper field, and another for the same feature on he lower field yields higher quality positional data.

It's then a simple matter of combining both zeroed sets of trace data to obtain the full double framerate trace data.

femr2

24th August 2010, 03:50 PM

Does this all not presume that the original video was presented to a digital recording device from a digital camera?
Not specifically, but I know where you're coming from.

I strongly suggest that the video in question was digital, as there is no apparent leakage of interlace field data.

If transferred from, say, interlaced VHS, the bleed and leakage over field boundaries should be noticable.

Either that or an original analogue video source was digitally interlaced.

If either one was an analogue device then each feild was originally 262.5 lines with an equal number of blank lines (no information) between each line.
The video being used is of course digital, and the interlacing is very clean. No overscan or blank-retrace present, though the timecode lines are present.

Furthermore a couple dozen of those lines would contain no image information as they are merely placeholders in the vertical blanking interval.
Yes, but that form is very rarely put into consumer video form. The source used is extracted directly from DVD without recode.

If each feild contained a full raster then there is no "feild/frame" distinction and it is not interlaced video it is progressive.
It's interlaced MPEG-2 704*480 - 30*1000/1001 fps.

pgimeno

24th August 2010, 04:07 PM

Yes. That is termed a bob-doubled form. I leave the deinterlaced video in unfolded form though, like this...
http://femr2.ucoz.com/_ph/7/2/125286220.jpg

So the frame rate is still the original, I understand.

And do you also call each of the halves a frame? Because that would indeed be confusing. To me that format is in some way a "weirdly interlaced image" in the sense that the concept of a field is somewhat valid, though it's "left field" and "right field" instead.

femr2

24th August 2010, 04:13 PM

Regarding the question of sub-pixel accuracy, I think it's important to make a careful distinction between the accuracy of a measured change in position of an image within a video frame, and the accuracy of a measured change in the position of the real object in space that generated the image.
Agreed.

For the former, I'm pretty thoroughly convinced that sub-pixel accuracy has been shown.
Cool.

But this:

- The position of images in the frame can be measured to +/- y pixel accuracy.
- Measurement of the image size (of e.g. a number of building floors) relative to the known dimensions of the object (building) yields a scale factor of s meters per pixel.
- Therefore, changes in the position of the object can be measured to +/- s*y meter accuracy.

... does not necessarily follow. Noise and error occur in the process of projecting the image from the object onto the camera sensor. Camera movement and heat refraction shimmer are among the obvious possible sources. These are not represented in any stage of the moving-dot test.
Correct. The moving dot is a test case to try and show the sub-pixel precision possible when supplied with ideal video data.

For the WTC7 traces, I perform static point tracing and subtraction to try and reduce the effect of camera movement as much as possible.

No specific perspective correction has been performed for the Dan Rather data yet, but for the Cam#3 footage I have performed quite a bit of additional work to account for it as much as possible.

You will probably be able to reduce the camera movement artifacts by subtracting out position data from fixed objects in the scene.
Yes.

Especially if you can make, and justify, the simplifying assumption that all of the camera movement is due to changes in the camera's orientation, rather than changes in the camera's absolute position in space, on the basis of the former having a much greater influence (due to the distance) on the position of the image in the frame.
Yes. Footage is selected where there is the highest probability of the camera being on a tripod.

Heat distortion is more problematic, because there is probably no definite separation between the characteristic frequencies of heat distortion and camera shake, nor between the characteristic frequencies of heat distortion and the movement you are measuring.
It is unlikely that with the relatively low resolution footage in use that separation of heat/smoke distortion could be distinguished from other noise sources. Perhaps comparison of multiple static point traces may assist, but there is then the problem that such distortion is unlikely to be consistent in different regions of the frame.

When characteristics of both your signal and your noise sources are unknown, there are limits to how much certainty you can achieve or claim.
Agreed. The suggested noise level is simply based on rough deviation from *zero* over the period of time the building feature is essentially static in the following trace...
http://femr2.ucoz.com/_ph/7/2/349864523.jpg (http://femr2.ucoz.com/photo/7-0-485-3)
...which is a zoomed view of the full trace...
http://femr2.ucoz.com/_ph/7/2/427976133.jpg (http://femr2.ucoz.com/photo/7-0-493-3)

You cannot even be sure low-pass filtering (smoothing) isn't clobbering a real component of your signal (e.g. vibrations or shock waves in the building frame during the collapse) unless you've analytically ruled out the possibility of those having occurred.
Yes. Many methods were applied to similar data when looking for *mini jolts* in the sauret footage, with reasonable success. For first and second order derived data I am of the opinion that it's okay to smooth out the wobbles...there's unlikely to be a way of separating them from the noise. Definitely so for second order data.

More sophisticated filtering affecting lower frequencies (e.g. when looking for "jolts" in the wtc tower collapses) are even more problematic.
Pretty good results were attained, but that was with much better quality video...
http://femr2.ucoz.com/_ph/6/2/378476413.jpg
(Will need some explanation, but I'll add it when asked)

With those caveats, I applaud your efforts so far.
Ta.

femr2

24th August 2010, 04:17 PM

So the frame rate is still the original, I understand.

And do you also call each of the halves a frame? Because that would indeed be confusing. To me that format is in some way a "weirdly interlaced image" in the sense that the concept of a field is somewhat valid, though it's "left field" and "right field" instead.
It's a minefield of terminology :) I only leave it in that form for convenience. I'm okay calling them fields. I'm okay calling them sequential images. Prior discussion evolved out of tfk stating that each image in normal deinterlace form was still called a field. I'll call 'em fields whenever I remember to do so :)

femr2

24th August 2010, 07:32 PM

Heat distortion is more problematic, because there is probably no definite separation between the characteristic frequencies of heat distortion and camera shake, nor between the characteristic frequencies of heat distortion and the movement you are measuring.
An additional note that's been made before but relevant here...

SynthEyes is used in a mode where a rectangular region is traced, rather than a single pixel.

Focus on a particular feature, such as the NW corner, is obtained by moving the initial region such that the NW corner is in the centre of the region (though it doesn't have to be, and there are sometimes good reasons not to make it so.).

Region placement can be performed to sub-pixel accuracy.

SE then scans a larger defined region centered on the same location, using pattern matching of the region with *8 upscaling and LancZos3 filtering applied, for a best fit match in the next frame.

It provides a Figure of Merit metric for each frame region match (0 perfect to 1 no match), which is included in the data made available.

Next frame region is of course automatically re-centered on the newly found sub-pixel location.

Subsequent matches are performed using the initial pattern, or, when keyframing is selected, it updates the base pattern every (n) frames to handle time based variations. I can explain the benefits/drawbacks of using keyframing if necessary.

Where I'm going with this is...

As a region is used, SE can use numerous pixels to determine feature location. As the region is upscaled, this translates to many pixels, even with a small region size.

I use regions as large as is practical for the purpose in hand. This is a subjective process, and region size selection and shape is pretty intuitive with experience of performing the traces.

For example, I use a larger region size when tracing static features, and a smaller region size when tracing features such as the NW corner to provide more *focus* and negate the effect of background features and suchlike.

The localised effect of elements such as heat and smoke is, imo, minimised by...

a) Using region based tracing in the first place

and

b) Making the regions as large as possible.

Here is an example image which shows relative region sizes...

http://femr2.ucoz.com/_ph/7/759212128.png

tfk

24th August 2010, 09:14 PM

femr,

A lot of this is fine detail stuff.

But when you're pushing the limits of what is possible (0.2 pixel), all the tiny details really matter.

Do you accept that the blob trace shows that SynthEyes tracks position change to a sub-pixel accuracy ? I'd say the data behind that trace shows SE is possible of determining movement down to ~0.002 pixels

2/1000ths of a pixel? Where did you get that number?

My problem with this is that it is unrealistic when compared to real video info.

Most significantly, it doesn't capture any of the features of how video cameras digitize continuous spatial info into discrete pixels.

I'll be more impressed if you take a non-symmetric color shape, bounded on one side only, apply a non-uniform blur, place it over a variable background, mimic how video CCDs digitize that info, pull out every other line and then watch SE do its stuff on THAT digitized info.

I'll be more impressed if you do some actual, proper calibration: using a test set-up where you KNOW what the motion is, and compare that to what SE gives you when you run thru the same algorithms.

But I supposed that's out of the question, and we're stuck with trying to pull what info we can out of this video.

The answer for me is going to reside within the static point data. Precisely because we KNOW that those points are not moving. You cannot tell for certain if the points on the WTC7 roof line are changing because the building is moving or if they are moving because the algorithm is giving you variable results.

You also can't tell with a single reference point. That's why I asked for multiple ones.

Let me give you a couple of other things to consider:

1. You use a reference point to compensate for camera motion. The absolute error in your position is going to now be twice the error of any given point: the errors add.

2. You have mentioned only a single static reference point from which you subtract all your data.

Using one reference point, you cannot compensate for rotational variations. You'd need to use at least two reference points.

3. Let's assume that you use only one field of data. If you have a really well defined edge (assume that it transitions within a single pixel, with no edge blur), then as the edge moves down in 0.25 pixel steps thru the field, this is how it appears to the video output (assuming a perfect input/output transform:

Actual position / Apparent position
0.00 0.00
0.25 0.25
0.50 0.50
0.75 0.75
1.00 1.00 (this scan line is missing from this field)
1.25 1.00 |
1.50 1.00 |
1.75 1.00 V
2.00 1.00 (reaches, but doesn't encroach into pixel)
2.25 2.25
2.50 2.50
2.75 2.75
3.00 3.00
3.25 3.00 (pixel not in this field)
3.50 3.00
3.75 3.00
4.00 3.00
4.25 4.25

This is the transform out of which you're trying to get sub-pixel location.

Of course, this just applies to a point, or a line parallel to the pixel layout. In an unusual twist, points that have edge blurs that extend at least 2 pixels can actually improve your resolution.

As I said at the beginning, all of the above are fine points. But when you're claiming 0.2 pixel accuracy, then every possible source of error matters. And watching things like, for example the camera panning back & forth (not hard mounted), leave me very skeptical.

One thing that I got to do several days ago was to watch some motion tracking programs attempt to track points in videos. I was underwhelmed. The people who were doing the video work had to manually adjust the reference point (establish key points) every (it appeared) 20 frames or so.

Perhaps SE has much better algorithms than those programs. Again, something that needs to be proven.

The first thing to highlight here is the difference between the noise level in the blob trace and the noise level in the WTC7 trace.

As far as I am concerned, the difference in noise levels is a very good way to quantify the variance added by most of the elements you mention.

You'd have to prove this correlation.

And "quantify" doesn't mean "it kinda looks like that to me".

The technical method employed to track the feature is exactly the same between the two of course, and the potential accuracy shouldn't change, only the video data quality itself changes.

You're asserting that the accuracy doesn't depend on the local "video data quality". I find that hard to believe. Proof would help.

It looks more like a halo to me.

A halo due to ...?

Care to elaborate on what halo might do to SE's interpolation algorithms. Care to prove it?

I don't know the various compression algorithms that may (or may not) be applied to standard TV broadcasts. But I'd be really surprised if there are none. Care to elaborate?

But Tom, Tom, Tom....it's just a word. What I've been saying about a frame being called a field of an interlace frame only when it's treated as part of that interlace frame is correct. A picture is an image is a frame is a field (when part of an interlaced frame). It's all just terminology, so as long as you understand how I've been treating the data, it's all cool.

femr, femr, femr. The words are how we attempt to communicate. And using the same word to mean two completely different things doesn't help.

And you've used the same word, in the same discussion, to mean 1) an assemblage of 2 deinterlaced fields, 525 lines and 2) a single 262.5 lines.

Absolutely not. How many frames are there on your old analogue camera film ? How many lines are there on a 4k HD video frame ? etc, etc. Frame is a universal word with many meanings even within the video arena. We're all clear though I hope. Not splitting hairs, but I'll probably use the word frame in numerous contexts as appropriate.

We weren't talking about camera film, etc. We were talking about video frames in THIS application.

No problem on retracting the analysis you said you were going to provide, but the rest is a bit ridiculous.

I'm not retracting anything. I never said that I'd do an error analysis for you.

I said that I thought that I could demonstrate that you weren't getting accuracies down in the fractional pixel range. That I thought that they were up close to a full pixel.

I'll continue that discussion.

Get SynthEyes (or equivalent)
Get the video.
Unfold it.
Trace the NW corner in both frames (fields if you will)
Export the traces.
Open in excel.
Save.
Upload.

Job done.

What are you talking about? Replicating your study is not on my agenda.

Well you know I'll provide you with answers. Whadaya need ?

How about the original data (not the 2 point averaged) on those static points.

tom

beachnut

24th August 2010, 09:39 PM

I have exactly zero intention of posting any personal details, and that is never going to change.

You can assume whatever you please beachnut.

As opposed to which other available "Dan Rather footage" point trace dataset would that be beachnut ?

And please sort out the grammar.

Improve the accuracy ? What are you talking about ? I use procedures to ensure the best trace accuracy possible, which I've explained in detail. But you are, er, delusional if you think any subsequent post-processing changes the data accuracy. It's possible to filter or smooth noise, sure, but it sounds like you're talking out of your proverbial.

I suggest you have a serious look in the mirror beachnut.

There's an idea. Am sure your local newsagent will have several colouring books with suitable pictures. You may even get a free pen.

Enough of your nonsense beachnut. You have no interest in this thread. Simply ignore it. Thanks matey.
What training have you had in video as it relates to your attempt to get data accuracy that is not there? Any goal yet Any chance under the sky that you can relate this work to one of the delusional 911 truth CT claims?

Have you had a course on sampling theory? Any engineering courses? Any video analysis courses? I only ask this because your work seem to be complete BS made up by yourself; not a single reference to academic work to corroborate your claims. I mean you might think you are making video with better resolution, but looking good is not better accuracy, and you are making major errors and leaving out extensive background information that is important.

This is not make it look better deal, it is a stuck with bad resolution, and not much you can do about it. Generation…

You know the sub-forum subject - debunking 911 truth idiotic claims, not attacking NIST and other reality based works.

Use the ignore button; you and Major Tom need to use the buttons. But your best forum for you opinion based analysis is where lies are weighted equally with reality; ATS, or that forum you and Tom can go unchallenged as you post nonsense about 911 attacking NIST, Bazant and other reality based work you don’t understand. And believe me you don’t understand NIST, and proof is in the thread; and you have no idea what I refer to.

Use the ignore button, Luke

My opinions? (your work is opinion) Lol, I would show your work to a PhD expert in video analysis, but he would laugh at me for bringing in such obvious nonsense. This is why you guys never publish, because it is all BS and worthless. It as if you are studying my father collapsing to figure out he had a stroke, or a heart attack. You are studying the façade of a building abandoned by the interior support, due to interior collapse, evidenced by the penthouse falling through the interior of 7 seconds before collapse; making the total collapse of 7 twice as slow as freefall. My goodness, you are studying the wrong junk.
Any chance you can tie this great junk to 911 conspiracy theories?

femr2

25th August 2010, 01:54 AM

you might think you are making video with better resolution
This shows your utter lack of understanding. I am not making video at all.

you are making major errors
What errors ?

and leaving out extensive background information that is important.
What information ?

Use the ignore button
No.

And believe me
lol

you don’t understand NIST, and proof is in the thread; and you have no idea what I refer to.
Show me.

I would show your work to a PhD expert in video analysis
Go ahead.

femr2

25th August 2010, 03:04 AM

femr,

A lot of this is fine detail stuff.

But when you're pushing the limits of what is possible (0.2 pixel), all the tiny details really matter.
Fine, though 0.2 pixels is far from pushing the limits in technical terms.

2/1000ths of a pixel? Where did you get that number?
Thought you might question that :)

It's from the blob trace data. I posted the first few samples a while back. First few y values increment in 0.001 pixel increments as expected. I'll post the full dataset if y'like.

My problem with this is that it is unrealistic when compared to real video info.
You've missed the purpose. It's purpose is to highlight the level of accuracy possible with SE. Call it the limiting case.

Most significantly, it doesn't capture any of the features of how video cameras digitize continuous spatial info into discrete pixels.
Not entirely true, as it's still pixelated. And it's not supposed to. Limiting case test video ;)

I'll be more impressed if you
That's fine, but as I've indicated the blob test has a purpose. I can perform additional tests, and was going to suggest that you produce a video within which you already know the sub-pixel movements of a feature, then it can be blind-tested, yeah ;) (A video from W.D.Clinger would be trusted more personally though tbh) But it's the attitude that grates a bit. Ho hum...

take a non-symmetric color shape
Okay
bounded on one side only
What do you mean ? Trace only one side/section of it ?

apply a non-uniform blur
Hmm. How about adding random noise instead ? Or I suppose I could blend some smoke over the top ?

place it over a variable background
Okay.

mimic how video CCDs digitize that info
Doesn't make much sense.

pull out every other line
Makes no sense at all. You mean replicate the result of deinterlacing an interlaced video of similar format ?

and then watch SE do its stuff on THAT digitized info.
Okay.

I'll be more impressed if you do some actual, proper calibration: using a test set-up where you KNOW what the motion is
Already have. Blob test. I assume you mean some video footage of something ? If so, it can be done, but it's all manner of hassle ensuring movement is *known* and I'm not at all sure you'd trust the results anyway.

But I supposed that's out of the question
Not out of the question, but all getting a bit ridiculous for what is really rather simple. The problem as I see it is still about trust and the fact that this is far from your arena than impartial skepticism. But ho hum...

and we're stuck with trying to pull what info we can out of this video.
Nope.

The answer for me is going to reside within the static point data. Precisely because we KNOW that those points are not moving. You cannot tell for certain if the points on the WTC7 roof line are changing because the building is moving or if they are moving because the algorithm is giving you variable results.
The purpose of the blob test is to show that SE is capable of detecting position change far finer than +/- 0.2 pixels. There's always going to be some noise after static point subtraction, of course. I can look at the blob test in more detail of course, and provide a clearer picture of the higher levels of accuracy attainable. I've suggest a figure, which is maximum sensitivity. There are a few obvious deviations from that during the blob test, reasons for which should be fairly obvious. I'll explain in more detail, but I do request that you have a stab at suggesting what those deviation may be caused by first. I'm not really here to teach you from the ground up about all this stuff.

You also can't tell with a single reference point. That's why I asked for multiple ones.
I have provided you with multiple static point data.
There are issues using multiple static points, but in principle I have no issue including further static points in the resultant data. Indeed I already have for certain tasks not being discussed here. The data has been provided to you with a single static point to keep the spreadsheet manageable. If I provided you with a spreadsheet with 50 static points and 16 NW corner traces, you'd have a hissy, complaining about being swamped with data. Sigh.

Let me give you a couple of other things to consider:
You are too gracious...

1. You use a reference point to compensate for camera motion. The absolute error in your position is going to now be twice the error of any given point: the errors add.
And the variance is STILL only +/- 0.2 pixels. Good, innit.

2. You have mentioned only a single static reference point from which you subtract all your data.
See above.

Using one reference point, you cannot compensate for rotational variations. You'd need to use at least two reference points.
True, though cutting through the noise between separated static point traces to determine a rotational variable would MOST probably introduce more error than leaving it as it is, which is clearly not rotating to any great extent, and assuming it's on a tripod (which it really does appear to be) the likelyhood of rotation is very slim, and verly slight otherwise. By all means have a go at totally negating noise from two separate static point traces and determining rotation ;) (It's much easier when using to moving points, for obvious reasons ;) )

3. Let's assume that you use only one field of data. If you have a really well defined edge (assume that it transitions within a single pixel, with no edge blur), then as the edge moves down in 0.25 pixel steps thru the field, this is how it appears to the video output (assuming a perfect input/output transform:

Actual position / Apparent position
0.00 0.00
0.25 0.25
0.50 0.50
0.75 0.75
1.00 1.00 (this scan line is missing from this field)
1.25 1.00 |
1.50 1.00 |
1.75 1.00 V
2.00 1.00 (reaches, but doesn't encroach into pixel)
2.25 2.25
2.50 2.50
2.75 2.75
3.00 3.00
3.25 3.00 (pixel not in this field)
3.50 3.00
3.75 3.00
4.00 3.00
4.25 4.25

This is the transform out of which you're trying to get sub-pixel location.
I'm not using one field. There's a valid point in there, sure, but there are no *jumps* in the output data, as expected. Are you sure that each interlace field discarded alternate lines ? :)

Of course, this just applies to a point, or a line parallel to the pixel layout. In an unusual twist, points that have edge blurs that extend at least 2 pixels can actually improve your resolution.
See prior post on regions.

As I said at the beginning, all of the above are fine points. But when you're claiming 0.2 pixel accuracy, then every possible source of error matters. And watching things like, for example the camera panning back & forth (not hard mounted), leave me very skeptical.
Being skeptical is fine, but a lot of this comes from this not being a field you are experienced in. That's fine, but it would be appreaciated if you chill out a bit. I'm willing to do the leg work, but there's a limit :)

One thing that I got to do several days ago was to watch some motion tracking programs attempt to track points in videos. I was underwhelmed. The people who were doing the video work had to manually adjust the reference point (establish key points) every (it appeared) 20 frames or so.
Perhaps they need some tips :) I perform zero manual adjustment.

Perhaps SE has much better algorithms than those programs. Again, something that needs to be proven.
SynthEyes should be paying me for this. lol.

You'd have to prove this correlation.
Okay. First intention would be variance from the perfect known movement.

You're asserting that the accuracy doesn't depend on the local "video data quality". I find that hard to believe. Proof would help.
No I'm not. I'm saying that if you accept tha SE is capable of detecting movement of +/- 10 pixels, then if the noise level in a trace is +/- 100 pixels, then that additional noise is caused by noise in the video, not noise in the detection alrogithms.

A halo due to ...?
Impossible to say for sure. Probably the edge contrast. Makes me think you don't know what I'm talking about though.

Care to elaborate on what halo might do to SE's interpolation algorithms. Care to prove it?
:) Read up on what halo effects in video are. It shouldn't affect trace whose region includes such data as it's consistent across frames.

I don't know the various compression algorithms that may (or may not) be applied to standard TV broadcasts. But I'd be really surprised if there are none. Care to elaborate?
There are definitely compression artefacts. I don't think the feature you mentioned is such, as I said.

femr, femr, femr. The words are how we attempt to communicate. And using the same word to mean two completely different things doesn't help.
My usage of the words has been correct.

And you've used the same word, in the same discussion, to mean 1) an assemblage of 2 deinterlaced fields, 525 lines and 2) a single 262.5 lines.
Correctly.

We weren't talking about camera film, etc. We were talking about video frames in THIS application.
In context, we were talking about you not understanding the variable correct contextual use of the word frame. As I've said, to make things easier on ya, I'll try and use the word field more often. I might also say, sod it, I'm tired of the attitude, and call them all images instead.

I'm not retracting anything. I never said that I'd do an error analysis for you.
Incorrect, but no matter.

I said that I thought that I could demonstrate that you weren't getting accuracies down in the fractional pixel range.
Have you ?

That I thought that they were up close to a full pixel.
And now ?

I'll continue that discussion.
Okay.

What are you talking about? Replicating your study is not on my agenda.
You said *there are far too many details about your analysis that are obscure & not well explained*. I just provided you with the procedure to perform *my analysis* in full.

How about the original data (not the 2 point averaged) on those static points.
Again, no probs.

pgimeno

25th August 2010, 05:29 AM

I'm not using one field. There's a valid point in there, sure, but there are no *jumps* in the output data, as expected. Are you sure that each interlace field discarded alternate lines ? :)

Again, for the sake of clarity, let me know if this is correct.

The interlaced image comes from a double speed (59.94 fps in this case) source, after applying an interlacing technique. It doesn't matter much who does the interlacing, be it the camera or the DVD maker. The point resides on how the interlacing is done.

The interlacing process does not involve erasing every other row of each frame, but downsampling the original frame to half the height of the final video's resolution (to 240px in this case), maybe with a 0.5 pixel offset. The result is then put into the interlaced frame as a field, in a process that can be better defined as an encoding than as a composition, in the sense that it can be decoded (deinterlaced) again to obtain the downsampled image without loss of information, and that's what the TV does when reproduced.

If that's the case, it should be clear that due to the downsampling process, SE's algorithms can be applied without problems to the result of deinterlacing.

As an aside, since the interlacing process seems to have been done digitally from a digital source, I'd be curious to see the difference in trace results between the "bob-doubled" form and the unfolded form. No need to satisfy my curiosity, though, because that's beside the point, but maybe you already tried and can briefly comment on the results.

femr2

25th August 2010, 07:17 AM

The interlaced image comes from a 59.94 fps source
Yes. (I've edited your sentence a little)

It doesn't matter much who does the interlacing, be it the camera or the DVD maker. The point resides on how the interlacing is done.
Yes.

The interlacing process does not involve erasing every other row of each frame, but downsampling the original frame to half the height of the final video's resolution (to 240px in this case), maybe with a 0.5 pixel offset.
It's not always done this way, but yes.

The result is then put into the interlaced frame as a field
Yes.

it can be decoded (deinterlaced) again to obtain the downsampled image without loss of information, and that's what the TV does when reproduced.
Minefield. Differing DVD players will treat the data in a multitude of ways. Some taking account of frame flags, some not. Some TV's will also treat the input signal in various ways.

Essentially, most modern devices will make attempts to either reconstruct the image into a correct form, or display the interlace frames in a way which preserves as much vertical resolution as possible.

If that's the case, it should be clear that due to the downsampling process, SE's algorithms can be applied without problems to the result of deinterlacing.
Yes. Jumps over pixel boundaries would be detectable if this was not the case.

As an aside, since the interlacing process seems to have been done digitally from a digital source, I'd be curious to see the difference in trace results between the "bob-doubled" form and the unfolded form. No need to satisfy my curiosity, though, because that's beside the point, but maybe you already tried and can briefly comment on the results.
No problem. I've got a bit of a backlog of *tasks* on this thread, but I'll get there.

femr2

25th August 2010, 09:11 AM

when you're pushing the limits of what is possible (0.2 pixel)
Fine, though 0.2 pixels is far from pushing the limits in technical terms.

Thought I'd pre-empt the inevitable *disbelief* that my response is bound to provoke.

Consider a single white pixel feature on a black background.

If that feature moves left by one pixel, gradually, the aliasing end result is that the intensity of the original pixel drops, and the intensity of the adjacent pixel increases.

Assuming simple 8-bit greyscale colour depth, that alone allows for detection of 255 positions, translating to 1/255th of a pixel (0.0039 pixel accuracy if you will).

Ramp this up with...

a) Full 24bit RGB colour (3 planes of 8 bit data)
b) Region based pattern matching (normally involving well over 64 separate pixels. Hundreds in the case of static point traces)
c) *8 upscaling
d) LancZos3 filtering

...and I hope you can appreciate that potential technical sub-pixel position change determination accuracy can be...awesome :)

beachnut

25th August 2010, 09:58 AM

Thought I'd pre-empt the inevitable *disbelief* that my response is bound to provoke.

Consider a single white pixel feature on a black background.

If that pixel moves left by one pixel, gradually, the aliasing end result is that the intensity of the original pixel drops, and the intensity of the adjacent pixel increases.

Assuming simple 8-bit greyscale colour depth, that alone allows for detection of 255 positions, translating to 1/255th of a pixel (0.0039 pixel accuracy if you will).

Ramp this up with...

a) Full 24bit RGB colour (3 planes of 8 bit data)
b) Region based pattern matching (normally involving well over 64 separate pixels. Hundreds in the case of static point traces)
c) *8 upscaling
d) LancZos3 filtering

...and I hope you can appreciate that potential technical sub-pixel position change accuracy determination can be...awesome :)
You think you are getting more accurate? You are not. You can't source any of this nonsense.

Source your nonsense. Pixel moves, does the Sun rotate around the earth? lol - When will you reveal how this relates to 911 CT.

You make up your analysis as you go. Like a BS artist talking it up. Why are you qualified to make up this analysis. Please explain your studies and courses. Degrees. Engineering degree?

But most of all reference actual scientific work which backs up your claims.

Next of all, reference the 911 CTs your work refutes or tries to support.

What was the original camera and specs for it.
The lens.
The position and elevation.
The temperature.
The wind.
The weather conditions.
What generation is the video you are using.

Which PhDs in this field have you worked with, and what do they say? What CT was this about? What errors? Did you realize what you are doing to the data? lol - you are making the data worse - you are making it pretty, not more accurate. Source your methods and verify why it makes more accuracy as you make pretty pictures, not better data. Major problems - you can't source your methods as ways to do what you are doing. In your analysis, it is like you are taking 5.5 and rounding it to 4 sometimes and 7 other times. This is funny stuff if you think about it. You are studying the facade of building which is collapsing internally. That is funny as you are looking at the wrong things and using a method/means which is limited, and you don't realize why.

carlitos

25th August 2010, 10:04 AM

You are studying the facade of building which is collapsing internally. This is a great point.

tfk and femr2, at the risk of piling on, can either of you tell me what any of this has to do with 9/11 Conspiracy Theories? I reported the thread, and it didn't get moved to Science, so may I assume that there is / was some conspiracy afoot that sub-pixel resolution will ultimately reveal?

femr2

25th August 2010, 10:23 AM

This is a great point.
Not really. This thread is examining tracing techniques. Those techniques are used for many purposes, primarily for WTC 1 rather than WTC 7 to date. There are many implications which will be presented over time once those skeptical of the methods have been satisfied of their validity. This thread is an offshoot of threads related to things like *jolts*, NIST Initiation sequence for WTC 1, WTC 7 failure propogation, ROOSD. All that sort of thing.

femr2

25th August 2010, 10:48 AM

You can't source any of this nonsense...Source your nonsense...reference actual scientific work which backs up your claims...Source your methods...you can't source your methods...
Try NIST :)

The fact that you continually ask for *someone else* to provide you with information about a subject you clearly do not understand, in the slightest, speaks volumes. Am sure I've heard the phrase *appeal to authority* before somewhere. This is not rocket science. It's all quite simple really. A rather obscure field, perhaps, but fundamentally simple.

I have no desire to hear anything further from you at all, but if you must insist on *wearing a funny hat and stepping into the room shouting nonsense* please be very specific about what you believe I have gotten wrong, prove so, and provide correction. I'm afraid I'm going to report further similar posts from yourself.

Cheers matey. x

jaydeehess

25th August 2010, 11:02 AM

Yes. That is termed a bob-doubled form. I leave the deinterlaced video in unfolded form though, like this...
http://femr2.ucoz.com/_ph/7/2/125286220.jpg

Here is why I have trouble with the way you utilze these feilds.

The two images above are in (approx) a 2:3 height to width ratio whereas the full raster we see on TV is 4:3. Obviously half the height is missing, gone, not there, in both feilds yet you seem to treat each pixel in each feild as if it represents full height when in fact it represents half of the full height, the other feild containing the other half (and removed in time by near 1/60th of a second)

carlitos

25th August 2010, 11:07 AM

There are many implications which will be presented over time...
Again, with due respect, I don't believe you. No implications will be presented. No conclusions will be drawn. You and yours will whinge about anomalies with NIST or whatever until the end of time, just like the JFK people. In the meantime, life goes on, building codes get revised, new skyscrapers have concrete cores, etc.

If this discussion is purely technical, it belongs in Science and Technology, because you refuse to state the "conspiracy" involved.

ETA - never has the phrase "counting the number of angels dancing on the head of a pin" been more apt.

femr2

25th August 2010, 11:08 AM

you seem to treat each pixel in each feild as if it represents full height
Incorrect. I apply separate vertical and horizontal scaling metrics when translating from pixel to real world units, as has been discussed numerous times during this thread.

beachnut

25th August 2010, 11:31 AM

Try NIST :)

The fact that you continually ask for *someone else* to provide you with information about a subject you clearly do not understand, in the slightest, speaks volumes. Am sure I've heard the phrase *appeal to authority* before somewhere. This is not rocket science. It's all quite simple really. A rather obscure field, perhaps, but fundamentally simple.

I have no desire to hear anything further from you at all, but if you must insist on *wearing a funny hat and stepping into the room shouting nonsense* please be very specific about what you believe I have gotten wrong, prove so, and provide correction. I'm afraid I'm going to report further similar posts from yourself.

Cheers matey. x

Does this mean you have qualification to do this work?
Does this mean you can't find the major errors and lack the funds to hire a real reality based engineer to fix your BS opinion analysis?
Does this mean you can't reference or source your claims?

It means you don't care your methods are making the data less accurate, you don't care about it because you are making this up as you go.

Does this mean you can't do better to tie this to refuting the delusional CTs of 911 truth better than the BS you posted above.

You have major problems with your work. You can't find them on your own, you will need help.
It is very valid that you are looking at the facade when the real collapse is going on internally. This is a fact, your work is a waste of time and does not relate in any reality form to 911 CTs; it does relate to 911 CTs in the fact you have a CD delusion you are afraid to announce and explain.

Seriously, you have posted major problems with your work and you don't understand what they are. You are using methods which are not helping with accuracy.

Any chance you can source or reference your claims? Any chance you are qualified?

femr2

25th August 2010, 11:47 AM

femr2

25th August 2010, 12:40 PM

Tom,

Additional static point trace data without dejitter...

Download (http://femr2.ucoz.com/load/0-0-0-31-20)

beachnut

25th August 2010, 02:38 PM

I see you are indeed incapable of highlighting any errors beachnut.

Given the specific and repeated requests for you to do so, as indicated I have reported your post.

Yawn.

I am sure other posters here are tired of your inane posts, and would request that they also request you go and do something more useful with your time, or better still for your interruptions to be split to a separate thread.
I would report my post, it points out your claims can't be sourced, proved, or backed up with references. Please source your claims, with references to other work, and prove the claims you are making are true.

It would be nice to know your qualifications. Are you an engineer?

As an engineer, I find your efforts are not getting better data, but the opposite. Ask another non-911-truth engineer.

Please tie this work to 911 conspiracy theories; or maybe you should move the thread to the pseudoscience, aka barroom science, sub-forum. You must source your claims. You have to have references. Why can't you cite other work similar in nature?
I found some.
XJZ9l74mkqw
Now 911 truth can add thermite to the WTC complex. What does your work have to do with 911 conspiracy theories? It can be used to back in complex delusions made up by Gage?

femr2

25th August 2010, 03:12 PM

your claims
What claims ?

I find your efforts are not getting better data, but the opposite.
You are talking absolute nonsense. Better than what ?

maybe you should move the thread
Not my thread Einstein.

Why can't you cite other work similar in nature?
NIST beachnut, NIST.

---

Tom,

Feel like continuing this discussion at the911forum, where there won't be such an influx of stupid ? Again, I don't mind doing the leg-work implied by your requests, but the environment is pretty pathetic. W.D.Clinger would be very welcome I am sure. Other constructive contributors to this thread are already members.

femr2

25th August 2010, 06:28 PM

Am having a few issues generating the promised variance data for the blob test video, as there's no way to export the actual 3dstudio path movement, and as the tiny blob test video was a downscaled version of a rendered video from 3ds, there are a few translation phases between the *perfect* path movement and the resultant tiny video anyway...

I have however been able to generate rough variance dat, though not *correct*, so posting the full dataset would be in error.

Bit of a surprise...

The variance shows some interesting patterns, and reaches ~0.06 pixels at times (as opposed to my earlier suggested sensitivity value - a different metric)

Higher than expected, but not too shabby.

I may look at how to regenerate the test case making sure these results can be definitively determined.

femr2

26th August 2010, 09:01 AM

Okay, new blob test variance results...

http://femr2.ucoz.com/_ph/7/138110862.png

Quite interesting. Shows the error across pixel boundaries (which makes sense), and the *drift* given circular movement (which is slightly surprising, but about a third of the pixel boundary scale, so may also make sense). Also shows variation in the oscillating frequency dependant upon rotation angle (which makes sense), and flattened, non-oscillating regions at 180 degree intervals (which again makes sense).

A useful image, and should assist in defining trace accuracy considerably.

Will look at the same thing with a square object, and then again with linear movement, rather than circular.

femr2

26th August 2010, 01:40 PM

Behaviour for square and linear movement is very similar to that of circular movement.

So, from simple observation of the variance graph, I would suggest...

a) The highest accuracy is attained when movement in parallel to the axis being traced.
b) The highest accuracy is maintained when on-axis movement is < 1/4 perpendicular-to-axis movement. < 1/4 gradient. Within this margin for the example equates to within +/- 0.01 pixel accuracy.
c) The highest *drift* is attained when movement is at maximum velocity.
d) *drift* is recovered when velocity reduces.
e) On such small regions (49 pixels) inter-pixel transitions can result in oscillating positional error of up to 0.06 pixels. It is expected that this will reduce as region size increases (and will be tested)
f) Pixel transition error oscillation period is obviously related to movement velocity.
g) Error does not appear to favour an axis.
h) For pure on-axis movement, for a 7*7 region, minimum positional error lies within +/- 0.005 pixels.
i) Interestin' :)

femr2

26th August 2010, 04:41 PM

Thought it would be useful to test a trace of a box corner in perfect freefall...

It's nearish the same scale as the Dan Rather drop distance (both fields). Sample rate is 59.94fps in relative terms.

http://femr2.ucoz.com/_ph/7/486459962.png

The x position of the test does not change at all, so the variance is purely SE *noise*...

http://femr2.ucoz.com/_ph/7/200661381.png

Previous observations seems to hold true...

a) Vertical variance of around 0.06 pixels.
b) Variance narrows around frame 350, which I imagine is due to the velocity, and so inter-pixel state harmonics.
c) Vertical variance oscillation rate increases as velocity increases, as expected.
d) Drift shifts *downwards* as velocity increases. Will have to double-check if that is a leading or trailing shift, as it will either increase or decrease apparent velocity.
e) Horizontal variance is pure *noise*. +/- 0.001 pixels. No obvious pattern.

fitzgibbon

26th August 2010, 07:22 PM

Here is why I have trouble with the way you utilze these feilds.

http://femr2.ucoz.com/_ph/7/2/125286220.jpg

The two images above are in (approx) a 2:3 height to width ratio whereas the full raster we see on TV is 4:3. Obviously half the height is missing, gone, not there, in both feilds yet you seem to treat each pixel in each feild as if it represents full height when in fact it represents half of the full height, the other feild containing the other half (and removed in time by near 1/60th of a second)

Incorrect. I apply separate vertical and horizontal scaling metrics when translating from pixel to real world units, as has been discussed numerous times during this thread.

And there is just one reason why beachnut's challenging of you isn't for nought. For your values to be of any worth, they have to maintain the aspect ratio. The images that you're citing are clearly compressed on the vertical (as jay was pointing out). You toss this off as if it doesn't matter when clearly it diminishes any movement in the axis by 50%.

Not a small factor.

If you don't recognise why this is, you should stop what you're doing before you appear even more foolish.

Then you're comparing a point in field 1 of an NTSC image with what you think is the same point in field 2 even though field 2 is sampling a different spot at a different time. You don't see this as a problem. A field is a 1/60th of a second slice of half of a frame raster of a standard-definition NTSC video camera. A field is never a frame and field-doubling doesn't change that.

You also use a best-case scenario with the motion your white dot on a black background and declare victory even though your source video is shades of grey down I-can't-begin-to-guess-how-many-generations-and-compressed-I-can't begin-to-guess-how-many-ways. This is not a meaningful comparison. You should be moving a grey target around a background of a slightly different shade of grey for this to be at all relevant.

Your playing around with SynthEyes in this context is meaningless because of the low resolution of the video used, not knowing whether the frame order has been compromised by repeated consumer-grade compression/decompression and clear misunderstanding on your part of what the difference is between a field and a frame in an NTSC environment.

And I'm a broadcast television editor (since '91) and a cameraman for 8 years before that.

HTH
Fitz

Myriad

26th August 2010, 07:47 PM

femr2

26th August 2010, 08:03 PM

For your values to be of any worth, they have to maintain the aspect ratio.
No. When translating from pixel units to real world units, separate horizontal and vertical scalars are used. This is detailed numerous times in the thread.

it diminishes any movement in the axis by 50%
Both fields are used.
It is utterly incorrect to leave the video interlaced, as you should well know. There is no option but to deinterlace.
You should already know this if you have either a) read the thread, or b) know what you are talking about.

Then you're comparing a point in field 1 of an NTSC image with what you think is the same point in field 2 even though field 2 is sampling a different spot at a different time.
No. Same spot (within reason). Different time, yes, absolutely, and absolutely necessary. Separated field traces are subsequently interleaved. Read the thread in full.

You also use a best-case scenario with the motion your white dot on a black background
Absolutely.

and declare victory
No. The best-case is exactly that, as is clearly explained earlier in the thread. It's purpose is to determine the limits of accuracy possible, in order to correctly quantify the increase in noise in the WTC 7 traces.

even though your source video is shades of grey
I prefer the Cam#3 footage. If you have a better quality version of the Dan Rather viewpoint, please let me know.

not knowing whether the frame order has been compromised by repeated consumer-grade compression/decompression
Quality will most definitely have been compromised. You mean field order by the way, and it's been checked and is fine.

and clear misunderstanding on your part of what the difference is between a field and a frame in an NTSC environment.
Not in the slightest.

And I'm a broadcast television editor (since '91) and a cameraman for 8 years before that.
Good. Then you should understand that a field of an interlaced frame is only a field whilst it's associated with that interlace frame. When, to use your words, I take those two images out of the NTSC environment, I simply have two images. If I put them in a video, they are frames. To hammer the point home...If I deinterlace an interlaced video, sort out the aspect ratio and stick it out there as a non interlaced video, each frame is a frame. There is no longer any association with interlacing, and no fields. Compromised video quality, depending upon how the original was interlaced, and how I deinterlaced to produce my shiny new video, sure :)

fitzgibbon

26th August 2010, 08:18 PM

And there is just one reason why beachnut's challenging of you isn't for nought. For your values to be of any worth, they have to maintain the aspect ratio. The images that you're citing are clearly compressed on the vertical (as jay was pointing out). You toss this off as if it doesn't matter when clearly it diminishes any movement in the axis by 50%.

Not a small factor.

If you don't recognise why this is, you should stop what you're doing before you appear even more foolish

I disagree with this point. There's no need to maintain the original aspect ratio, as long as separate appropriate (preferably directly measured) horizontal and vertical scale factors are applied when converting from image raster lines or pixels to real world spatial positions. Which is exactly what femr2 has stated he is doing.

There's no reason to be compressing the video in one axis and not the other especially when one is using a low-resolution version off the Internet.rowing away resolution only introduces more potential for error and/or compounding existing errors.

Maintaining the original aspect ratio would require either throwing away half the horizontal resolution (to squeeze it down to match the vertical), or restoring the original vertical size by interpolating to add extra lines (uselessly confusing the tracking issue), both of which sound like bad ideas.

If this were referring to an original field of NTSC SD (standard definition) video, you'd see that each field has active lines separated by a line of black which corresponds to line that will be read in the next field. For measurement to be useful requires maintaining the greatest amount of original, unimpinged, unmediated data from which to draw your conclusions from.

It also requires in this instance knowing the difference between field 1 and field 2 of an NTSC frame and the understanding to know what should be happening in a given circumstance.

There shouldn't be any need for interpolation because interpolation at anything other than the final stage needlessly muddies the final result.

Far from "a real hoot," I find it rather disheartening, to come into a thread and read what appears to me to be unthoughtful criticism arising from careless and uncharitable reading.

My criticism is far from unthoughtful. femr2 is making grand-sounding assertions that could flumox a layman while betraying a lack of understanding of even the most basic building block of video .

I tend not to wade in on many 9/11 topics as there are plenty of others here better versed than I. But when it comes to television-related ones, I pay special heed because it's what I do for my daily bread.

This is not a lack of charity on my part. It's being blunt about the Emperor's choice in fashion.

femr2

26th August 2010, 08:31 PM

There's no reason to be compressing the video in one axis and not the other especially when one is using a low-resolution version off the Internet.
There is no compression occurring in the slightest. The change in aspect ratio is due to unfolding the interlaced frame. You really should know this.

Throwing away resolution only introduces more potential for error and/or compounding existing errors.
No resolution is being thown away in the slightest.

If this were referring to an original field of NTSC SD (standard definition) video, you'd see that each field has active lines separated by a line of black which corresponds to line that will be read in the next field.
You are blinded by environment. You are talking about the form implied by displaying the field on an interlaced projection device, such as a television. It would be utterly stupid to introduce the blank scanlines. Subsequent tracing of the separated fields would be impossible. If you do not understand, I'll explain, but read the thread in full first.

For measurement to be useful requires maintaining the greatest amount of original, unimpinged, unmediated data from which to draw your conclusions from.
Absolutely.

It also requires in this instance knowing the difference between field 1 and field 2 of an NTSC frame and the understanding to know what should be happening in a given circumstance.
Absolutely.

There shouldn't be any need for interpolation because interpolation at anything other than the final stage needlessly muddies the final result.
There is no interpolation of image data. Indeed, the image data is unaffected from the source video entirely (unfolding does not change any data). If I catch where you misunderstood, I was referring to the separated field traces data being interleaved. That is joining the separate traces such that the original field timing is reconstructed, and so producing a 60*1000/1001 fps feature trace dataset from an interleaved 30*1000/1001fps video.

My criticism is far from unthoughtful.
However, it is far from correct.

femr2 is making grand-sounding assertions that could flumox a layman while betraying a lack of understanding of even the most basic building block of video.
Incorrect, and I suggest you make sure you understand both my answers and read the full thread in order that you do not continue to make incorrect assertions.

I tend not to wade in on many 9/11 topics as there are plenty of others here better versed than I. But when it comes to television-related ones, I pay special heed because it's what I do for my daily bread.
As I said, it is easy to be blinkered by environment. Please take heed.

This is not a lack of charity on my part. It's being blunt about the Emperor's choice in fashion.
Being blunt then...take your time. You are not bathing in glory right now.

fitzgibbon

26th August 2010, 09:23 PM

For your values to be of any worth, they have to maintain the aspect ratio.

No. When translating from pixel units to real world units, separate horizontal and vertical scalars are used. This is detailed numerous times in the thread.

WTF do you mean "real world units? You're measuring something. Throwing away half your data is a quick invitation to enhance inaccuracy.

it diminishes any movement in the axis by 50%.

Both fields are used.
It is utterly incorrect to leave the video interlaced, as you should well know.

:eye-poppi

You either maintain an interlaced image from the get-go or you end up with a dog's breakfast that provides you with meaningless data. As I said I in my reply to Myriad, you maintain clean data to the end. You've got the dog's breakfast of progressive video and you seem happy to draw conclusions from it and wonder why the likes of me think you don't know what you're talking about.

There is no option but to deinterlace.
You should already know this if you have either a) read the thread, or b) know what you are talking about.

A) I have
B) I do
C) You're trying to pull an Ace Baker. He didn't know what he didn't know either.

No. Same spot (within reason).

On that length of lens? Not bloody likely! Unless your definition of "within reason" is far looser than mine. I'd ballpark a field's difference in the original video from that range to be roughly 6' (not to mention the temporal differentiation) And that's just an educated, experience guestimate.

Different time, yes, absolutely, and absolutely necessary. Separated field traces are subsequently interleaved. Read the thread in full.

Read it. Field 1 =/= field 2 and field doubling doesn't create an accurate full frame.

You also use a best-case scenario with the motion your white dot on a black background

Absolutely.

and declare victory

No. The best-case is exactly that, as is clearly explained earlier in the thread. It's purpose is to determine the limits of accuracy possible, in order to correctly quantify the increase in noise in the WTC 7 traces.

You're comparing an apple and an orange and quailing that I call you on the difference? Your comparison might have had some validity had you been dealing with a test with grey-on-grey as I suggested in my previous post. Your analogy's closer to saying that you're capable of driving at 200kph on an open-road straightaway and then comparing that to your to drive through rush hour traffic.

It doesn't wash

I prefer the Cam#3 footage. If you have a better quality version of the Dan Rather viewpoint, please let me know.

I'm sure you'd have no problem licensing a much higher resolution copy of the footage from any reputable footage library. The problem in this equation is that it costs money. You're the one trying to make a silk purse; pony up or be prepared to be called on short-comings of your footage.

Quality will most definitely have been compromised.

Yet you draw all kinds of informed-sounding opinions based on compromised data?

You mean field order by the way, and it's been checked and is fine.

My bad. Typing too quickly. And just how did you determine the validity of the field order? By experienced eye and judgement?

and clear misunderstanding on your part of what the difference is between a field and a frame in an NTSC environment.

Not in the slightest.

ORLY?

And I'm a broadcast television editor (since '91) and a cameraman for 8 years before that.

Good. Then you should understand that a field of an interlaced frame is only a field whilst it's associated with that interlace frame.

You see, this is where you demonstrate your lack of understanding of what a field is. It's 1/59.94th of a second in an SD NTSC world. It's the capture of that moment in time only and on those particular field lines only.

Doubling it doesn't make it 2/59.94ths anymore than holding a freeze of it for an hour makes it an hour-long documentary. It always is a field and only has relevance in terms of measuring something when you team it up with all the fields that properly precede it and follow it in their proper order.

Trouble is from where I sit is that you seem happy to throw away accuracy and misrepresent what a field actually is, something that flies in the face of what presumably was the intent of this thread.

When, to use your words, I take those two images out of the NTSC environment, I simply have two images. If I put them in a video, they are frames.

There are duplicates of the fields but for the intent of this thread they don't magically become frames. You've been throwing terms around that clearly you don't understand in any meaningful way and just because you may have a copy of an editing program doesn't mean you actually understand what it's doing.

[QUOTE=femr2;6270174]
To hammer the point home...If I deinterlace an interlaced video, sort out the aspect ratio

The aspect ratio needn't have needed any sorting out. That it did so (in your opinion) speaks more to operational shortcomings. And that you 'sorted it out' was clearly evident to two television professionals. Any properly extracted field should've been maintained it's original aspect ratio.

and stick it out there as a non interlaced video, each frame is a frame.

But herein you've made it (and whomever you sourced your video from) something that it wasn't without realising the shortcomings of your process. It's just a little bit of a headscratcher that you seem pleased by this.

There is no longer any association with interlacing, and no fields. Compromised video quality, depending upon how the original was interlaced, and how I deinterlaced to produce my shiny new video, sure :)

None so blind....

femr2

26th August 2010, 10:07 PM

WTF do you mean "real world units?
Feet and inches.

You're measuring something.
Yes.

Throwing away half your data is a quick invitation to enhance inaccuracy.
I am not throwing away any data at all. What is it about the need to deinterlace that you don't understand ? The frame CANNOT be left interlaced for the purposes of tracing.

You either maintain an interlaced image from the get-go or you end up with a dog's breakfast that provides you with meaningless data.
Absolutely not.

I am tracing very fine movement of image features. Leaving the frame interlaced is fine for everything EXCEPT moving features. That leaves each and every interlace artefact in place. An absolute no-no for the purpose in hand.

As I said I in my reply to Myriad, you maintain clean data to the end.
Absolutely.

You've got the dog's breakfast of progressive video
You are suggesting leaving the frame interlaced, and so attempting to trace a moving feature in an interlaced form containing the position of that feature in two different places at two different times.

You clearly do not understand the purpose in hand. Feel free to ask, or... read the thread.

and you seem happy to draw conclusions from it
Not many conclusions thus far, but sure.

and wonder why the likes of me think you don't know what you're talking about.
I'm afraid it's not me who sitting in that chair right now.
It is necessary to understand what implications interlaced video has for the purpose of tracing to understand why leaving the video in interlaced form is UTTERLY stupid.

I've been trying to give you some slack, but get a grip. You may well (possibly) be versed in broadcast video implications, but you clearly don't know jack about what I'm doing with the video data. Read the thread. Ask questions. Stop making yourself look silly.

I fully understand the preference in broadcast terms of retaining the full frame height, but it is not appropriate here.

On that length of lens? Not bloody likely! Unless your definition of "within reason" is far looser than mine. I'd ballpark a field's difference in the original video from that range to be roughly 6' (not to mention the temporal differentiation) And that's just an educated, experience guestimate.
Traced feature position changes are relative, and are based upon a region of the image. Initial trace region center location between fields does not have to be identical. Again, be aware of the change in environment. You are not trying to broadcast an episode of Friends here.

Read it. Field 1 =/= field 2 and field doubling doesn't create an accurate full frame.
I am not field doubling.

You're comparing an apple and an orange and quailing that I call you on the difference?
No. The purpose of the test case is to determine the noise level in traces under ideal circumstances, as I've already told you personally, and has been stated repeatedly in the thread (which you claim to have read).

Your comparison might have had some validity had you been dealing with a test with grey-on-grey as I suggested in my previous post.
No, the purpose is clear. It is not a comparison.

Your analogy's closer to saying that you're capable of driving at 200kph on an open-road straightaway and then comparing that to your to drive through rush hour traffic.
No. The purpose is to determine the level of noise in in ideal circumstances, and in the case of the freefall test horizontal axis, SynthEyes internal algorithms, as opposed to noise in the tracked feature position in WTC7 video traces from other sources.

You're the one trying to make a silk purse; pony up or be prepared to be called on short-comings of your footage.
Complain about the quality of the footage as much as you like. I agree. It's not great. If you have a better one, please let me know.

Yet you draw all kinds of informed-sounding opinions based on compromised data?
It's the best quality version of that viewpoint I have available. Again, if you have a better, say so. I would remind you that this thread is not about a particular video, but techniques used to trace moving features.

My bad. Typing too quickly. And just how did you determine the validity of the field order? By experienced eye and judgement?
Easy to do, isn't it :) Flag extraction was not possible, so tedious bob-double format jitter inspection.

ORLY?
Yes.

You see, this is where you demonstrate your lack of understanding of what a field is.
No, it is not.

It's 1/59.94th of a second in an SD NTSC world.
It represents that slice of time, absolutely.

It's the capture of that moment in time only and on those particular field lines only.
In interlaced form, absolutely.

Doubling it doesn't make it 2/59.94ths anymore than holding a freeze of it for an hour makes it an hour-long documentary.
2/59.94 ? You've gone off into some tangent plane son.

You are forgetting that an interlaced frame contains 2 fields, in a video container at half framerate... 30*1000/1001fps.

You're going in the wrong direction.

Any properly extracted field should've been maintained it's original aspect ratio.
You are blinkered by environment again.

For the purpose of tracing...

Interlaced video MUST be deinterlaced.

Deinterlacing CANNOT use and blend, weave or any other technique which attempts to merge data from the separated fields together.

Restoring aspect ratio by line doubling CANNOT be performed.

If you do not understand why, ask.

femr2

27th August 2010, 06:43 AM

a) Vertical variance of around 0.06 pixels.
This seems to be fairly constant in numerous test conditions.

I'll hazard a guess at a reason...

It's clearly linked to pixel transition, as can be seen by it's oscillatory nature, and that frequency increases with velocity.

Assuming a base hpix (half-pixel) start point, it is also of note that *8 upscaling is applied to the trace region.

0.5/8 = 0.0625

It's conjecture, but it does seem possible that the blending between two pixels can cause cyclic lagging which would be related to upscale multiplier.

It's not a baseless assertion, and it's useful to see how upscaled pixel transitions actually look before dismissing the suggestion. Here's an animated GIF to (hopefully) illustrate the point.

http://femr2.ucoz.com/_ph/7/2/880831943.gif

pgimeno

27th August 2010, 07:59 AM

femr2, what do you know about the stream itself?

Is it taken verbatim from the DVD stream, without any reencoding, or has it been recoded somehow?

If the latter, do you know the original bit rate?

carlitos

27th August 2010, 08:04 AM

In 2001, wouldn't it have likely been Beta first?

Here (http://forums.randi.org/showthread.php?postid=6228475#post6228475) femr links to the "original" source video. The "original" wouldn't have been an mpeg or a DVD, but a piece of videotape, right?

femr2

27th August 2010, 08:13 AM

femr2, what do you know about the stream itself?
In terms of chain of custody, not a lot, though of the many versions of the same clip kicking around, it is by far the highest quality I'm aware of.

Is it taken verbatim from the DVD stream, without any reencoding, or has it been recoded somehow?
In personal discussion with the file uploader it was stated that it was taken directly from the DVD stream without recode.

femr2

27th August 2010, 08:18 AM

In 2001, wouldn't it have likely been Beta first?
Probably DV. Very unlikely to be beta. It was not a piece of amateur footage. It would have been at least a semi-pro camera.

The "original" wouldn't have been an mpeg or a DVD, but a piece of videotape, right?
Original, as in the actual video file I used, not a similar version of the same footage.

It is of course not the *original* footage.

For a start it has passed through a titling system for the overlays to be added.

That is one reason why it is very unlikely that it was non-digital from at least that point.

If you are aware of a better quality copy from the same viewpoint, please let me know.

carlitos

27th August 2010, 08:21 AM

Why don't you get an original archive tape from CBS?

femr2

27th August 2010, 08:32 AM

Why don't you get an original archive tape from CBS?
If you feel like doing so, by all means ;)

I don't think the *original* will be much better to be honest.

I'd rather NIST let me get my hands on the full-length and full quality copy of the Cam#3 footage (before they messed with the contrast), even though that was transferred from tape, as it's a lot closer view, and spans 7 minutes prior to descent.

I've matched the inch-accurate position extraction stated by NIST from my current version of that footage, so it's really just the extra footage time that would be most useful there.

carlitos

27th August 2010, 08:35 AM

When you asked NIST for the Cam #3 footage, what did they say?

femr2

27th August 2010, 08:42 AM

When you asked NIST for the Cam #3 footage, what did they say?
NIST stopped responding to me a long time ago :)

Perhaps someone else will have more success.

carlitos

27th August 2010, 09:45 AM

So to sum up:
You have no alternative hypothesis to explain the events of 9/11/01
You refuse to state any credentials for video expertise or error analysis
You are conducting extensive analysis of a video of one of the building collapse, but can't be bothered to attest for its provenance beyond "a guy told me it's from some DVD"
You can't be bothered to get the original footage, or even to get someone else to do it for you
You refuse to state how this analysis will fit into the big picture

Got it. I don't suppose you have proof that you ever asked NIST for anything, including their responses?

femr2

27th August 2010, 09:51 AM

As suggested by W.D.Clinger, a look at the data with multiple graphs based on sample interval.

http://femr2.ucoz.com/_ph/7/45980309.gif

The image alternates between fields.

Each image includes three graphs, each with a 3 sample interval.

Shows the clear difference between field traces, and as each interval graph is very consistent, shows why I trace each field separately.

Vertical shift between fields is as expected, roughly half pixel.

Shows a few jumps on one of the fields (which is not the fault of SynthEyes, but video quality).

I'll sort out the velocity and acceleration derived views later.

Will be wanting to move over to the better quality Cam#3 footage pretty soon, but happy to respond to technical quesries beforehand.

DeJitter processing has been deliberately very simple to date, to make released spreadsheet data simple, but may begin using more advanced techniques. No complaints about more complex spreadsheet data once I do though please ;)

beachnut

27th August 2010, 10:27 AM

http://femr2.ucoz.com/_ph/7/45980309.gif

... please ;)

How will you model atmosphere errors? Why do you block people who post comments on your videos and expose your implied lies on 911? Censoring the truth?

How much does the atmosphere affect the accuracy? If you model the distortion from the atmosphere what method will you use?

Distance from camera? Any chance on modeling the lens errors?

femr2

27th August 2010, 10:40 AM

How will you model atmosphere errors?
It is very unlikely that I will.

How much does the atmosphere affect the accuracy?
Not a lot. A lot less than noise due to low video resolution.

Distance from camera?
Yet again, patience.

Any chance on modeling the lens errors?
Possibly.

You are repeating yourself beachnut. Please do not continue to do so.

jaydeehess

27th August 2010, 10:55 AM

A point that shows up in feild 1 on a line and then in the next FRAME it has moved out of that line will NOT be on the next line down in the same feild. IF the camera is solid, and IF no atmospherics distort the view then that point has moved to the next line down in feild 2.
It has NOT moved a half pixel, it has moved one pixel.

Further complicating matters is that the next line down on alternate feilds are separated by approx 1/60th of a sec
In fact the top line in any feild was traced for a time that preceeds the bottom line trace by about 1/65 of a second.

To see exactly what the effect is one need only reverse the feilds (top feild first interlaced versus bottom feild first interlaced) and notice how balls-up the resultant video is if anything at all moves in the image.

jaydeehess

27th August 2010, 11:06 AM

If the camera was digital then the video would likely NOT have been sent to the studio in DV pro format. It would be converted to either ASI or SDI, with or without embedded audio. There, if it was being stored digitally and tapeless, it would be converted to mpeg , mov or avi format. Which one would depend most likely on what editor system the station uses. For instance if the station uses Final Cut and since Final Cut runs on PowerMacs they would likely store .mov files, whereas Leitch Velocity is much better off with mpegs. It might also depend on what video server they are using for instance if its a Grass Valley running on a PC OS then its likely mpeg

However, in 2001 there were still a lot of analogue Betacams around. We still have 2 BetacamPro recorder/players and still use them since some archives are on Beta.

Digibeta is now the standard with many studios rather than DVPro so if it were being stored on tape it would be either fed to a DigiBeta or DVPro machine.

femr2

27th August 2010, 11:18 AM

A point that shows up in feild 1 on a line and then in the next FRAME it has moved out of that line will NOT be on the next line down in the same feild.
That depends upon how the fields are constructed.

IF the camera is solid, and IF no atmospherics distort the view then that point has moved to the next line down in feild 2.
Again, that depends upon how the fields are constructed, and, of course, features are very rarely a single pixel in size, and so will affect multiple pixels over multiple lines.

It has NOT moved a half pixel, it has moved one pixel.
I didn't say it had. It's a half pixel jitter... Alternating +/- 0.5 pixel.

Further complicating matters is that the next line down on alternate feilds are separated by approx 1/60th of a sec
That's not a complication, it's great for the purpose in hand.

In fact the top line in any feild was traced for a time that preceeds the bottom line trace by about 1/65 of a second.
No. You are confusing primitive analogue interlaced display retrace time with camera shutter time.

To see exactly what the effect is one need only reverse the feilds (top feild first interlaced versus bottom feild first interlaced) and notice how balls-up the resultant video is if anything at all moves in the image.
Field order has been checked, as stated earlier.

All this waffle about video format is becoming rather tedious.

femr2

27th August 2010, 11:24 AM

If the camera was...
All rather irrelevant. Live broadcast environments were most likely using realtime processing via rack-mount hardware. Digital or analogue is also fairly irrelevant.

The video being used is what it is. It's a good quality version, compared to many other versions of the same footage, and as it has some timecode overlaid, it's probably closer to an *original* version than many other kicking around on t'interwebb.

Which, again, is fairly irrelevant.

alienentity

27th August 2010, 12:05 PM

All rather irrelevant. Live broadcast environments were most likely using realtime processing via rack-mount hardware. Digital or analogue is also fairly irrelevant.

The video being used is what it is. It's a good quality version, compared to many other versions of the same footage, and as it has some timecode overlaid, it's probably closer to an *original* version than many other kicking around on t'interwebb.

Which, again, is fairly irrelevant.

Reading thru this discussion, I think it's fair to say that Femr2 is dismissing a number of criticisms made by video professionals, but is not successfully defending the accuracy of his techniques in doing so.

From my perspective I'm skeptical that this data are capable of proving anything much of value vis-a-vis a conspiracy discussion.

I certainly don't see why this thread is on a conspiracy forum, and it doesn't build confidence in Femr2 to see him dismiss the opinions of professionals. Doesn't seem to be much point to any of it.

ETA I suspect that the graphs Femr2 is generating will be used as some kind of 'proof' of controlled demolition by his 'inside job' friends - they certainly look impressive and sciency, not unlike the nice graphs produced by Jones/Harrit et al. which 'prove' the presence of nanothermite.

carlitos

27th August 2010, 12:14 PM

However, in 2001 there were still a lot of analogue Betacams around. We still have 2 BetacamPro recorder/players and still use them since some archives are on Beta.

Digibeta is now the standard with many studios rather than DVPro so if it were being stored on tape it would be either fed to a DigiBeta or DVPro machine.

Thanks. I was dating myself a bit with the reference, but back then I actually used to do a fair bit of video work*, and thought we were mostly using Beta. I still have a few Beta tapes of original footage kicking around.(*Meaning that I hired people to make and edit videos, not make them myself)

Doesn't seem to be much point to any of it.
No, for many of the reasons I listed above. Counting the angels dancing on the head of a pin. femr's latest obsession isn't much different from the various other one trick ponies on this forum, with the added non-bonus that he won't make any assertion at all.

alienentity

27th August 2010, 12:18 PM

I do realize there is a strong agenda operating on the 9/11 forum, from which much of this discussion has originated, to find fault with anything and everything that NIST did and discredit NIST as much as possible.

But it's strange that while Femr2's work on WTC1 seems to be central to their attack on NIST, the work on WTC7 doesn't seem to do anything but perhaps reinforce the 2008 NIST report on it.
And, as usual, WTC2 is M.I.A. for this group since it fell in a substantially different way, yet from a similar affliction. So it will be extremely difficult, if not impossible, for this group to demonstrate how a demolition mechanism could rationally be applied in all 3 cases, backed up by any serious engineering analysis.

Because any serious analysis is going to lead right back to --- gravitational collapse induced by fires and plane damage. Because that's the best fit for all the data, regardless who generates it.

The CD/Conspiracy stuff is literally spinning its wheels while stuck deep in the mud of reality. The smart, honest truthers will continue to leave, and only the charlatans and truly misguided will remain.

I predict Femr2 will also abandon 9/11 Truth and for the right reasons.

femr2

27th August 2010, 12:20 PM

I suspect that
By all means highlight any technical errors, and provide corrections. If you cannot, your suspicions are baseless, and your post rather pointless.

femr2

27th August 2010, 12:27 PM

I do realize there is a strong agenda operating on the 9/11 forum
If that's what you think, become a member and sort it out then. I'll buy you a drink (one) when you arrive :)

But it's strange that while Femr2's work on WTC1 seems to be central to their attack on NIST, the work on WTC7 doesn't seem to do anything but perhaps reinforce the 2008 NIST report on it.
You clearly do not have the capacity to consider the phrase *honest research* :)

Please stay on topic.

Carll68

27th August 2010, 12:31 PM

By all means highlight any technical errors in the NIST reports, and provide corrections that support your uneducated insane CD delusions. If you cannot, your suspicions are baseless, and your post's rather pointless.

carlitos

27th August 2010, 12:31 PM

The CD/Conspiracy stuff is literally spinning its wheels while stuck deep in the mud of reality. The smart, honest truthers will continue to leave, and only the charlatans and truly misguided will remain.

I predict Femr2 will also abandon 9/11 Truth and for the right reasons.I hope that you are right. I forget who, but someone here has a signature quote about google removing context automatically. That's why I encourage people to place their pet issue in the context of the larger situation. Most refuse to do so, which indicates to me that they realize the whole thing is a delusion, and they are just wasting time.

femr2

27th August 2010, 12:33 PM

Oi, if you two want to have a chat, do it somewhere else please.

And whilst I'm about it...

WTC2 is M.I.A.
There is plenty of information on WTC 2 at the911forum.
There is more footage of WTC 1 of better quality that for WTC 2, which may be the cause of your confusion. Just looking at the pictures ?

The purpose of this thread is basically about technical issues related to acceptance of the techniques.

There are many areas for which these techniques are used, which have significant results.

You will have to be patient. It took NIST a while to create the WTC 7 report. There's no rush ;)

Now, if you would kindly remain on topic and restrict yourselves to the technical domain please.

Carll68

27th August 2010, 12:36 PM

If that's what you think, become a member and sort it out then. I'll buy you a drink (one) when you arrive :)

You clearly do not have the capacity to consider the phrase *honest research* :)

Please stay on topic.

And, who is doing honest research? Not you, with the error filled mess spewing over the pages. However, you are clearly implying that NIST did 'dishonest research'..now, get to backing this up kid...why not let your video analysis (scoff) do the scientific talking for you...cuz' thus far' its just mumbling.......

carlitos

27th August 2010, 12:47 PM

Oi, if you two want to have a chat, do it somewhere else please.
.....
Now, if you would kindly remain on topic and restrict yourselves to the technical domain please.

Yeah, how dare we discuss how your video analysis relates to 9/11 conspiracy theories.... :rolleyes:

http://forums.randi.org/imagehosting/thum_334674c7815e5050a5.png (http://forums.randi.org/vbimghost.php?do=displayimg&imgid=20904)

Again, you'd be better served by skipping all of this nonsense and just taking a logic course.

femr2

27th August 2010, 01:06 PM

(deleted. noise returned.)

alienentity

27th August 2010, 01:28 PM

If that's what you think, become a member and sort it out then. I'll buy you a drink (one) when you arrive :)

You clearly do not have the capacity to consider the phrase *honest research* :)

Please stay on topic.

I'm already a member, thanks. And I disagree about the capacity to do honest research, and i'm as entitled to my informed opinion as you are, sir.

Please note that this is a conspiracy forum, and that measurement of pixels is not relevant in any tangible way to any conspiracy, that I am aware of.

I guarantee you that no amount of your measurements is going to prove or disprove the presence of controlled demolition explosives, the central theme to 9/11 Conspiracy theories.

Now if only you could understand what is relevant.......;)

alienentity

27th August 2010, 01:37 PM

Sure, let's get to a technical matter: How does the measurement of pixels relate to 9/11 Controlled demolition conspiracies?

I posit that it does not, as I've noted above. Therefore my opinion stands that this discussion does not really belong on this forum in the first place - and further that insisting that it should be included in conspiracy theories reduces it to a red herring.

Again my conclusion, based on what I've seen on the 9/11 forums, is that this is simply another way to inject the CD conspiracy agenda into an area where it has no relevance at all. Inappropriate and irrelevant.

Further note: Femr2 made a direct reference to the NIST reports 'You will have to be patient. It took NIST a while to create the WTC 7 report. There's no rush'
But the NIST report is a technical and engineering report, not a conspiracy investigation.

Again, by linking your work to the NIST engineering, you are further demonstrating that this is not a conspiracy subject at all, and as such does not belong on this forum.

You can't have it both ways, if you want to be intellectually honest. You've disqualified your own premise.

femr2

27th August 2010, 01:40 PM

I'm already a member, thanks.
What user ?

measurement of pixels is not relevant in any tangible way
It is what the techniques are subsequently used to determine that is the point. And that can only come once said techniques are fully understood, their limitiations and accuracy. Thus this thread :)

I guarantee you that no amount of your measurements is going to prove or disprove
Noted. Surprised that you include both prove and disprove.

insisting that it should be included in conspiracy theories
I have said no such thing, and it's not my thread.

You have indicated you are a member at the911forum. Why have you not raised your opinion on this topic there ?

pgimeno

27th August 2010, 01:44 PM

ETA I suspect that the graphs Femr2 is generating will be used as some kind of 'proof' of controlled demolition by his 'inside job' friends - they certainly look impressive and sciency, not unlike the nice graphs produced by Jones/Harrit et al. which 'prove' the presence of nanothermite.

Data is data. It can be used by both sides of the discussion. E.g. Jim Hoffman has put a load of information which has been useful to both sides; the Pentagon eyewitness testimony comes to mind as an example. I don't see why it has to be different in this case.

alienentity

27th August 2010, 01:44 PM

I humbly suggest that, were Femr2 interested in maintaining the relevance of this thread to conspiracy topics, and wanted to demonstrate that the WTC7 collapse was indeed true to the model of explosive controlled demolition, that he would offer his pixel-perfect analysis of several known controlled demolitions as comparisons.

Why has he not attempted this? Why in heaven's name would this not be relevant?

For example, if Femr2 could show a typical controlled demolition, and graph the acceleration, and it looked almost identical to the progressive collapse of WTC7, then his data would be very relevant to proving something.

However, most of us will quickly realize that he will never find any such CD to match WTC7, and surely he must realize this as well. One therefore becomes skeptical that his inquiry is actually an honest attempt to determine the facts, as they relate to controlled demolition theories of 9/11 Truth. (remember, that's the point of this forum)

carlitos

27th August 2010, 01:46 PM

Just to be fair, tfk started the thread here, not femr2.

alienentity

27th August 2010, 01:47 PM

What user ?

You have indicated you are a member at the911forum. Why have you not raised your opinion on this topic there ?

Why will you not show how your discussion is even vaguely relevant to 9/11 Conspiracy theories? Seems a lot more important than what my username is on another forum. I'm just sayin'

alienentity

27th August 2010, 01:49 PM

Just to be fair, tfk started the thread here, not femr2.

Yup and I made the same comment to him. ETA And I believe he already apologized for the pixel-geek discussion :)

Femr2 is questioning the relevance of our input and observations, it seems only fair to raise the question of this thread's relevance to conspiracy once again.

femr2

27th August 2010, 01:53 PM

Data is data. It can be used by both sides of the discussion.
Agreed.

offer his pixel-perfect analysis of several known controlled demolitions as comparisons
No problem doing so, for any video, once the techniques have been discussed to everyones satisfaction.

and graph the acceleration
Acceleration is pretty trivial to the uses of tracing techniques. Please read the thread, and you will find examples of other metrics it has/will be used to determine.

what my username is on another forum
I am femr2 both here and there. Is there any reason to not say what your username on the911forum is ?

Femr2 is questioning the relevance of our input and observations
Regardless of where it is located, you should all adhere to the wishes of the OP, and refrain from non-technical discussion. Only polite.

femr2

27th August 2010, 01:56 PM

Tom,

A quick summary of recent posts (cutting through the background noise)...

Consider a single white pixel feature on a black background.

If that feature moves left by one pixel, gradually, the aliasing end result is that the intensity of the original pixel drops, and the intensity of the adjacent pixel increases.

Assuming simple 8-bit greyscale colour depth, that alone allows for theoretical detection of 255 positions, translating to 1/255th of a pixel (0.0039 pixel accuracy if you will).

Ramp this up with...

a) Full 24bit RGB colour (3 planes of 8 bit data)
b) Region based pattern matching (normally involving well over 64 separate pixels. Hundreds in the case of static point traces)
c) *8 upscaling
d) LancZos3 filtering

...and I hope you can appreciate that theoretical sub-pixel position change determination accuracy can be...pretty awesome.

Additional static point trace data without dejitter...
Download (http://femr2.ucoz.com/load/0-0-0-31-20)

New blob test variance results...

http://femr2.ucoz.com/_ph/7/138110862.png

Shows the error across pixel boundaries (which makes sense), and the *drift* given circular movement (which is slightly surprising, but about a third of the pixel boundary scale, so may also make sense). Also shows variation in the oscillating frequency dependant upon rotation angle (which makes sense), and flattened, non-oscillating regions at 180 degree intervals (which again makes sense).

Behaviour for square and linear movement is very similar to that of circular movement.

So, from simple observation of the variance graph, I would suggest...

a) The highest accuracy is attained when movement in parallel to the axis being traced.
b) The highest accuracy is maintained when on-axis movement is < 1/4 perpendicular-to-axis movement. < 1/4 gradient. Within this margin for the example equates to within +/- 0.01 pixel accuracy.
c) The highest *drift* is attained when movement is at maximum velocity.
d) *drift* is recovered when velocity reduces.
e) On such small regions (49 pixels) inter-pixel transitions can result in oscillating positional error of ~0.06 pixels.
f) Pixel transition error oscillation period is obviously related to movement velocity.
g) Error does not appear to favour an axis.
h) For near on-axis movement, for a 7*7 region, minimum positional error lies within +/- 0.005 pixels.
i) Interestin'

Thought it would be useful to test a trace of a box corner in perfect freefall...

It's nearish the same scale as the Dan Rather drop distance (both fields). Sample rate is 59.94fps in relative terms.

http://femr2.ucoz.com/_ph/7/486459962.png
The x position of the test does not change at all, so the variance is purely SE *noise*...
http://femr2.ucoz.com/_ph/7/200661381.png

Previous observations seems to hold true...

a) Vertical variance of around 0.06 pixels.
b) Variance narrows around frame 350, which I imagine is due to the velocity, and so inter-pixel state harmonics.
c) Vertical variance oscillation rate increases as velocity increases, as expected.
d) Drift shifts *downwards* as velocity increases. Will have to double-check if that is a leading or trailing shift, as it will either increase or decrease apparent velocity.
e) Horizontal variance is pure *noise*. +/- 0.001 pixels. No obvious pattern.

Vertical variance of around 0.06 pixels.

This seems to be fairly constant in numerous test conditions.

I'll hazard a guess at a reason...

It's clearly linked to pixel transition, as can be seen by it's oscillatory nature, and that frequency increases with velocity.

Assuming a base hpix (half-pixel) start point, it is also of note that *8 upscaling is applied to the trace region.

0.5/8 = 0.0625

It's conjecture, but it does seem possible that the blending between two pixels can cause cyclic lagging which would be related to upscale multiplier.

It's not a baseless assertion, and it's useful to see how upscaled pixel transitions actually look before dismissing the suggestion. Here's an animated GIF to (hopefully) illustrate the point.

http://femr2.ucoz.com/_ph/7/2/880831943.gif

As suggested by W.D.Clinger, a look at the data with multiple graphs based on sample interval.

http://femr2.ucoz.com/_ph/7/45980309.gif

The image alternates between fields.

Each image includes three graphs, each with a 3 sample interval.

Shows the clear difference between field traces, and as each interval graph is very consistent, shows why I trace each field separately.

Vertical shift between fields is as expected, roughly half pixel.

Shows a few jumps on one of the fields (which is not the fault of SynthEyes, but video quality).

I'll sort out the velocity and acceleration derived views later.

Will be wanting to move over to the better quality Cam#3 footage pretty soon, but happy to respond to technical quesries beforehand.

DeJitter processing has been deliberately very simple to date, to make released spreadsheet data simple, but may begin using more advanced techniques. No complaints about more complex spreadsheet data once I do though please.

jaydeehess

27th August 2010, 02:46 PM

Here's the thing, and I have stated it before in this and related threads;
it really does not matter if femr manages to get a precise plot of the velocity of several points on the structure other than to say "NIST should have done all this too". NIST was not concerned, nor would there be any reason to be, with the minutia of the final moments of collapse. Determing , to an exacting degree(if possible) the precise behaviour of this structure, approx 15 seconds into its collapse that took just under 17 seconds in total is never going to allow anyone to determine what caused the collapse.(which began 15 seconds prior to this much dissected few moments)

YES, once the last phase of collapse began it went rather fast. No doubt about it but that does not constitute any evidence of nefarious mis-doings.

tsig

27th August 2010, 05:04 PM

Tom,

Additional static point trace data without dejitter...

Download (http://femr2.ucoz.com/load/0-0-0-31-20)

At the end of the day all you have is "looks like".

pgimeno

27th August 2010, 06:28 PM

I'd like to request that everyone (including me) keep this thread to the engineering. There are plenty of other places that we can express our dissatisfaction with each of our perceptions of the other side's politics, agendas, etc.

Here, let's stick to engineering, please.

Bump from the OP.

beachnut

27th August 2010, 08:15 PM

The collapse of WTC 7 starts with internal collapse. Does the tracking work on the deformation in the building facade to give some insight into the massive internal failures.

The collapse of WTC 7 was in motion internally for many seconds prior to the facade falling. Except the penthouse fell into the WTC 7 due to interior failures. What does the tracking of the penthouse reveal? Was the acceleration of the penthouse indicative of massive internal failure, or slower and some sort of incremental failure; and which would match the NIST model of collapse.

Since there were no explosives or thermite used on 911 to destroy the WTC complex; will this tracking give a signature for gravity collapse vs CD; or is the fact gravity is the primary energy source for CD and gravity collapse would that be impossible?

Are you going to analyze the penthouse collapse, or ignore the entire collapse?

femr2

27th August 2010, 09:22 PM

Does the tracking work on the deformation in the building facade to give some insight into the massive internal failures.
It will be possible to suggest probable internal behaviours from analysis of such low level external feature positional change data, yes.

WTC 7 was in motion internally for many seconds prior to the facade falling.
Access to the 7 minute Cam#3 footage NIST have would be very handy.

What does the tracking of the penthouse reveal?
Until the techniques are accepted, it is not appropriate to begin making conclusions. Basic raw trace data for the East Penthouse descent is contained within the Cam#3 dataset if you wish to analyse it.

Was the acceleration of the penthouse indicative of massive internal failure, or slower and some sort of incremental failure; and which would match the NIST model of collapse.
Until the techniques have been accepted, and scaling metrics agreed, ...

I'm not avoiding the question, it's fine and valid. But until there can be acceptance that traces can be performed with positional accuracy (x), derived acceleration accuracy (y) and scaling metric accuracy (z), it is not time to state results.

Are you going to analyze the penthouse
Yes. Again, some data is already there if you choose to jump ahead.

An easier way to progress is...

Do you accept the validity of the tracing techniques to determine accurate metrics on specified building feature movements ?

If so, what levels of accuracy are you prepared to accept for...

a) position error, in pixels
b) scaling metric error, in pixels/ft (footage dependant)
c) velocity error, in ft/s (footage dependant)
d) acceleration error, in ft/s^2 (footage dependant)

I do not actually expect you to be able to answer these questions at this point.

There is work to be done first.

tsig

27th August 2010, 09:45 PM

It will be possible to suggest probable internal behaviours from analysis of such low level external feature positional change data, yes.

Access to the 7 minute Cam#3 footage NIST have would be very handy.

Until the techniques are accepted, it is not appropriate to begin making conclusions. Basic raw trace data for the East Penthouse descent is contained within the Cam#3 dataset if you wish to analyse it.

Until the techniques have been accepted, and scaling metrics agreed, ...

I'm not avoiding the question, it's fine and valid. But until there can be acceptance that traces can be performed with positional accuracy (x), derived acceleration accuracy (y) and scaling metric accuracy (z), it is not time to state results.

Yes. Again, some data is already there if you choose to jump ahead.

An easier way to progress is...

Do you accept the validity of the tracing techniques to determine accurate metrics on specified building feature movements ?

If so, what levels of accuracy are you prepared to accept for...

a) position error, in pixels
b) scaling metric error, in pixels/ft (footage dependant)
c) velocity error, in ft/s (footage dependant)
d) acceleration error, in ft/s^2 (footage dependant)

I do not actually expect you to be able to answer these questions at this point.

There is work to be done first.

Great! Get to it.

alienentity

27th August 2010, 10:21 PM

Until the techniques are accepted, it is not appropriate to begin making conclusions.

Until the techniques have been accepted, and scaling metrics agreed, ...

I But until there can be acceptance that traces can be performed with positional accuracy (x), derived acceleration accuracy (y) and scaling metric accuracy (z), it is not time to state results.
.

But haven't y'all been making conclusions about WTC1 already, as outlined by Captain Tom's 'OOS collapse propagation model' and the '
Re: Missing Jolts found ???; film at 11' threads?

I think you ought to just state your case for the accuracy of your measurements, give your calculations for error, and be done with it. People can either accept your methods or reject them, based on their own perceptions and expertise.

It seems a bit late for you to be pulling back all your conclusions at this point.

alienentity

27th August 2010, 10:23 PM

'a) position error, in pixels
b) scaling metric error, in pixels/ft (footage dependant)
c) velocity error, in ft/s (footage dependant)
d) acceleration error, in ft/s^2 (footage dependant)'

Again, go ahead and give those estimates for your data.

femr2

28th August 2010, 06:05 AM

But haven't y'all been making conclusions about WTC1 already, as outlined by Captain Tom's 'OOS collapse propagation model' and the '
Re: Missing Jolts found ???; film at 11' threads?
Indeed. Perhaps I should have said...

Until the techniques are accepted, it is not appropriate to begin making conclusions here.

The current situation has arisen due to certain folk, tfk in particular, disputing the accuracy attainable through the tracing methods employed.

The trigger for this entire thread was my suggested positional accuracy of +/- 0.2 pixels for the Dan Rather footage, which tfk disputed, and still does.

The discussion is ongoing, with me providing more and more detail about the methods, folk delving into lower and lower scale sources of noise and distortion, and very few folk announcing...okay I'm happy that your tracing methods have been suitably explained and are accurate to (x) precision.

Whilst it's been made perfectly clear that the methods have been used extensively for WTC 1, that is not the case for WTC 7, and so, as I have been doing *this*, I have not really begun the process of analysing WTC 7 trace data.

The conclusions drawn from trace data usage can be quite complex, and so it is necessry for such methods to be understood, and accepted. Otherwise it is too easy for those skeptical of the proposed conclusions to simply dismiss such by blaming what they perceive to be invalid methods (ie sub-pixel accurate feature movement trace data analysis).

I think you ought to just state your case for the accuracy of your measurements, give your calculations for error, and be done with it. People can either accept your methods or reject them, based on their own perceptions and expertise.
As far as I'm concerned, I have. It is the fact that others will disagree, but then do not provide alternate accuracy details or reasoning, that's the problem. I do not want anyone to have any justifiable reason to *reject* them.

It seems a bit late for you to be pulling back all your conclusions at this point.
I'm not. I'm simply saying that I want to progress to general acceptance of the methods and accuracy before presenting conclusions here.

femr2

28th August 2010, 07:41 AM

Go ahead and give those estimates for your data.

a) position error, in pixels

Dan Rather footage - +/- 0.2 pixels

b) scaling metric error, in pixels/ft (footage dependant)

+/- 1 pixel

For WTC 7 there is limited building measurement data available, so with the caveat of accepting the scant NIST provided values...

Vertical scaling metric 3.41 to 3.47 ft/pixel
Horizontal scaling metric 1.64 to 1.66 ft/pixel

Note that these are global metrics over the full distance, and do not affect the positional error metric.

Scaling Metrics for the Cam#3 footage are of higher accuracy, as the footage is of higher quality and resolution (which is why I stated to tfk at the beginning of our discussion that I'd prefer to use that footage)

c) velocity error, in ft/s (footage dependant)

There has been no agreement of noise reduction or smoothing process. Until there is *some* agreement, it's too early to state.

d) acceleration error, in ft/s^2 (footage dependant)'

There has been no agreement of noise reduction or smoothing process. Until there is *some* agreement, it's too early to state.

tfk

28th August 2010, 07:55 AM

Thought I'd pre-empt the inevitable *disbelief* that my response is bound to provoke.

Consider a single white pixel feature on a black background.

If that feature moves left by one pixel, gradually, the aliasing end result is that the intensity of the original pixel drops, and the intensity of the adjacent pixel increases.

Assuming simple 8-bit greyscale colour depth, that alone allows for detection of 255 positions, translating to 1/255th of a pixel (0.0039 pixel accuracy if you will).

Ramp this up with...

a) Full 24bit RGB colour (3 planes of 8 bit data)
b) Region based pattern matching (normally involving well over 64 separate pixels. Hundreds in the case of static point traces)
c) *8 upscaling
d) LancZos3 filtering

...and I hope you can appreciate that potential technical sub-pixel position change determination accuracy can be...awesome

Yeah, sure. And, in principle, my 3rd grade ruler can measure to nanometers, because...

Let's cut to the chase.

There are two types of errors to consider: static errors (how good is SynthEyes at locating some non-moving feature anywhere in the image) and dynamic errors (how good is it at locating a moving feature at a given instant). The dynamic error has nothing to do with SynthEyes, of course, but everything to do with video's usual motion artifacts.

The total error in the reported location of any moving object with respect to any stationary feature is going to be the sum of those two errors. (One static error & one dynamic error.) The lower bound for this error is 2 times the static error.

Your own data doesn't support those levels of precision.

You gave me 3 additional static points. I compared the reproducibility of SynthEyes to locate those static points.

All of those static point should be stationary with respect to each other. The errors associated with the tracking of those static points is a good lower bound for the accuracy of your tracking.

Here's the result:

This chart shows the 4 static points, with the traces artificially displaced by 1 pixel for clarity.

http://a.imageshack.us/img820/2484/staticpointyvariation.png

The average position (the "DC" component) variations are due mostly to camera motion. They track each other well in the 4 plots. So those aren't the problems.

The differences in the magnitudes of the alternating part of the curves are a problem. The errors associated with just variations in the tracker picking up the static reference point can be quantified.

The errors associated with these numbers are an accurate reflection of SynthEyes ability to reliably locate a fixed reference point at several places around the image.

Here is the result, comparing the Y locations of each of the three new static points to the original ("Static Y") value.

Note that these values were calculated after doing your "2 point smoothing". (Without this technique, the errors were about 50% higher.)

Note that the second group was calculated after the gross slueing of the camera (that occurred between 3 & 10 seconds) stopped.

|Ref 9/16|Ref 11/17|Ref 13/15|RMS Errors
Errors 0 - 17 sec||||
Avg|0.10|0.16|0.16|0.14
StDev|0.07|0.09|0.09|0.08
Avg + 2 Sigma|0.24|0.33|0.33|0.30
Avg + 3 Sigma|0.30|0.42|0.41|0.38
|
Errors 10 - 17 sec||||
Avg|0.15|0.23|0.23|0.20
StDev|0.05|0.06|0.06|0.05
Avg + 2 Sigma|0.25|0.34|0.34|0.31
Avg + 3 Sigma|0.30|0.39|0.40|0.37.
This is a fair metric of the reproducibility of SynthEyes to track a stationary feature.

The RMS value is just the "mean of the means" of the individual errors and the individual standard deviations.

Note that I could only run these numbers for the Y point, since that's the only info that you provided with your new static points. It might get a little better, or a little worse, once the X values are included.

Now, when I'm justifying my test results to "the customer's in-house representative" (aka, the QA department), if he is in a good mood, he could be persuaded to allow me to claim the "3 sigma RMS value" accuracy (0.37 pixels/location).

If he's in a bad mood, he'll jump right to the worst case 3 sigma value (0.42 pixels/location).

And then it's obvious that you've got that error for each location (the reference point & the tracked roof line point), so the best that I can claim is twice this value (around 0.8 pixels).

This IS the lesson of this sort of data analysis. Errors are a bitch. And they accumulate fast.

I'll be anxious to hear WD's critique.
___

I also exchanged an email with Russ Andersson, the inventor/programmer for SynthEyes. Here are a couple of the questions I asked & his replies:

We would like to track locations within video that we've downloaded from archived (pre-2002) TV broadcast video (broadcast in US, NTSC, standard definition, 525 line interlaced). Most of the video is taken from tripod mounted cameras. Some of them are from hand held cameras.

Note that an awful lot of such unintended video will not contain the camera motion needed to determine 3-D parameters.
Also, interlaced video has only half vertical resolution (ie around 240 usable) which makes achieving decent accuracy harder.

.
We would like to be able to track several points within the video better than about 0.5 pixels.

RMS errors in the 0.2-0.4 range are fairly typical on reasonable (solved 3D) shots. Lens distortion and other problems can easily blow this number out.

.

To what extent does the motion & contrast within the video affect the tracking accuracy. For example, some of the videos will be "disaster videos", and there is frequently fire & smoke wafting in front of our desired reference points. Will this likely be a problem?

Certainly you can degrade the imagery in ways that will affect accuracy. This is artist-controlled --- ultimately you are limited by the skill/accuracy/time of your tracking artist.

.

I assume that video compression of the files (before we have access to them) will reduce our precision. Can you direct me to some reference that would help me to begin to quantify what I can expect?

No, sorry. That's not something that normally needs to be quantified explicitly. SynthEyes is a visual effects tool, not a surveying tool.

tom

tfk

28th August 2010, 08:54 AM

PS. Sudden thought...

But the accuracy above might be significantly improved with improved (better than 2 point average) filtering.

We'll see...

tom

femr2

28th August 2010, 09:19 AM

PS. Sudden thought...

But the accuracy above might be significantly improved with improved (better than 2 point average) filtering.

We'll see...

tom
Indeed. Must point out that the 2 point moving average is simply the simplest, most primitive, way to reduce the deinterlace jitter.

Better methods are definitely available, such as shifting one field dataset up by half a pixel, or shifting both towards each other by a quarter pixel. All measurements are relative to a start point, so the shifting of data is valid.

If you are considering looking at the effect on accuracy of smoothing, it should be in a 2 step process....treat interlace jitter, then smooth.

tfk

28th August 2010, 09:51 AM

Indeed. Must point out that the 2 point moving average is simply the simplest, most primitive, way to reduce the deinterlace jitter.

Better methods are definitely available, such as shifting one field dataset up by half a pixel, or shifting both towards each other by a quarter pixel. All measurements are relative to a start point, so the shifting of data is valid.

If you are considering looking at the effect on accuracy of smoothing, it should be in a 2 step process....treat interlace jitter, then smooth.

1. The deinterlace jitter is not the only source of error. It is not the predominant one in two of the traces.

2. The "smoothing algorithm" (2 point average) that I used for the results above is exactly the one on which you based your previous results. Denigrating it at this point doesn't help your case.

3. You might consider addressing the principle (setting aside for a moment the numbers) pointed out in that long post.

Which is: "Your error in the reported position of a moving feature can not be less than twice the error in your ability to calculate static points."

tom

tfk

28th August 2010, 09:59 AM

femr,

You've expressed a strange (to my way of thinking) interest in the "maximum possible resolution of SynthEyes". This is irrelevant. The important question is "what is the MINIMUM resolution that I can prove?"

For that matter, I am not interested at all in the theoretical performance of SE, per se. My interest is ONLY as it relates to its ability to determine position vs. time for the collapse times.

As far as I am concerned, the "blob tests" are irrelevant to the question that I find pertinent, because they ignore all the myriad errors that real optics & real video can introduce into your data. Someone else may be interested in them. I skip them.

It will be possible to suggest probable internal behaviours from analysis of such low level external feature positional change data, yes.

I find this to be a VERY bold statement.

I'd find it bold coming from a structural engineer. But, of course, I'd listen carefully to his explanations.

WTC 7 was in motion internally for many seconds prior to the facade falling.

Access to the 7 minute Cam#3 footage NIST have would be very handy.

Why do you do this: intentionally misrepresent, and then evade, comments? Beach is clearly talking about the several seconds prior to the start of the facade falling. You HAVE that video data. NIST has not withheld it.

You could have addressed his comment directly, instead of a less-than-brilliant attempt at NIST-slapping.

tom

PS. I'm just catching up over brunch. I've got a ton of work in the next 5 days. I'll be MIA for a bit.

femr2

28th August 2010, 11:02 AM

You've expressed a strange (to my way of thinking) interest in the "maximum possible resolution of SynthEyes". This is irrelevant.
The reason for performing the SE tests is in part due to you suggesting that the SE algorithms were responsible for some of the dataset noise.

In addition, performing the tests has allowed better understanding of where, and of what magnitude, tracing mechanics noise actually arises, namely the identified ~0.0625 pixel variance due to pixel transitions, velocity related *drift* probably due to harmonics in pixel state transition, etc... SE *noise* itself has been shown to be in the 0.001 pixel range.

Quantifying these metrics allows clearer understanding of noise source, and may also allow for more advanced noise reduction to be applied to post-processing the datasets.

Understanding that velocity has a slight effect, and that the 0.0625 pixel variance is transition related is very useful.

The important question is "what is the MINIMUM resolution that I can prove?"
That's fine, but I will highlight that the position variance over 13s of the Dan Rather data, sampled at 59.94Hz, and with no non-jitter based smoothing remains within ~+/- 0.2 pixels.

It is not valid to add static point variance to position variance, as the entire point of static point tracing is to determine camera shake. How would you propose separating static point trace *noise* from valid camera movement ?

For that matter, I am not interested at all in the theoretical performance of SE, per se. My interest is ONLY as it relates to its ability to determine position vs. time for the collapse times.
Fine, though it must be made very clear that all of the metrics you are looking at relate to the Dan Rather viewpoint video, not *position vs. time for the collapse times*. All of the error ranges change when using the Cam#3 footage for instance.

As far as I am concerned, the "blob tests" are irrelevant to the question that I find pertinent, because they ignore all the myriad errors that real optics & real video can introduce into your data. Someone else may be interested in them. I skip them.
That's your perogative. However, I think it is safe to say that I have proved that SE is more than capable of determining sub-pixel feature position, and indeed quantified to what level it is capable of doing so. I assume there will be no further suggestion that sub-pixel feature position change determination cannot be performed accurately.

A primary reason for performing the blob tests is to prove what level of error is introduced by the tracing mechanism, and which is caused by other noise sources.

Again, all error range data being discussed applies only to the Dan Rather video instance.

Happy with 0.0625 pixel variance due to tracing mechanism behaviours ?

I find this to be a VERY bold statement.
We'll see :) The data for vertical propogation (bottom to top) is quite interesting, but later...

Why do you do this: intentionally misrepresent, and then evade, comments?
It's not an evasion in the slightest. That is your pre-determined viewpoint coming out. The reason I'd like the full length Cam#3 footage is that building movement is ocurring from the very start of my copy, and, from the low resolution graphs provided by NIST, it's clear that movement began much earlier. I'd like to see it.

The Cam#3 data shows early movement. It's ridiculous to suggest I'm evading such.

You could have addressed his comment directly, instead of a less-than-brilliant attempt at NIST-slapping.
Quite how you make up that interpretation is beyond me.

Oh, and whilst we're there...you know the *kink* ? NIST treated it as vertical movement. It's not. It's primarily due to the pre-descent flexing, and is not vertical in nature, but rather north/south, but, again, later...

(My previous paragraph is NIST slapping.)

femr2

28th August 2010, 11:06 AM

1. The deinterlace jitter is not the only source of error. It is not the predominant one in two of the traces.
How have you separated camera movement from noise ?

2. The "smoothing algorithm" (2 point average) that I used for the results above is exactly the one on which you based your previous results. Denigrating it at this point doesn't help your case.
I've said from day one that the dejitter process was deliberately simple. There's nothing negative about using a better process at all. Surprised no-one has mentioned it before. There are numerous ways of dealing with it. Reasoning for keeping it simple has already been stated.

3. You might consider addressing the principle (setting aside for a moment the numbers) pointed out in that long post.

Which is: "Your error in the reported position of a moving feature can not be less than twice the error in your ability to calculate static points."
Again, how have you separated camera movement from noise ?

And...

I thought we all understood and accepted that there was noise in the data.

What would have been more useful for me personally is all manner of input on various different viewpoint on treating that noise.

If you choose to focus on *how bad can we make it*, rather than *how good can we make it*, that's fine.

I'll be applying more of my time to testing smoothing techniques than the former.

femr2

28th August 2010, 12:45 PM

There are two types of errors to consider: static errors (how good is SynthEyes at locating some non-moving feature anywhere in the image) and dynamic errors (how good is it at locating a moving feature at a given instant). The dynamic error has nothing to do with SynthEyes, of course, but everything to do with video's usual motion artifacts.
Agreed, though that's one reason why I've performed the blob tests, to get an idea of the effect of underlying motion error (0.0625 pixel mechanical variance + velocity slew)

Also must reiterate that static point traces are done to detect camera movement, and there's no perfect way of separating camera movement from noise in those traces. Can be estimated, sure, but that involves using all of the available smoothing and noise reduction processes. (Averaging multiple static points is also useful of course)

The total error in the reported location of any moving object with respect to any stationary feature is going to be the sum of those two errors. (One static error & one dynamic error.) The lower bound for this error is 2 times the static error.
Yes, but it's how the static feature error is determined that complicates that.

The errors associated with the tracking of those static points is a good lower bound for the accuracy of your tracking.
For the footage being used, sure. I'd focus on differences between each static point trace.

This chart shows the 4 static points, with the traces artificially displaced by 1 pixel for clarity.
I assume that without jitter treatment.

The differences in the magnitudes of the alternating part of the curves are a problem.
Could be due to variable distance from camera.

The errors associated with just variations in the tracker picking up the static reference point can be quantified.
Fine.

The errors associated with these numbers are an accurate reflection of SynthEyes ability to reliably locate a fixed reference point at several places around the image.
Fine.

Here is the result, comparing the Y locations of each of the three new static points to the original ("Static Y") value.
Happens to be the the one with most variance, and the largest general offset. I'd have thrown that trace away and used some new ones. Looking at all four static point traces overlaid shows me that the initial one might need looking at, or rejecting. I have no problem doing MORE additional static point traces :)

And then it's obvious that you've got that error for each location (the reference point & the tracked roof line point), so the best that I can claim is twice this value (around 0.8 pixels).

This IS the lesson of this sort of data analysis. Errors are a bitch. And they accumulate fast.
Unsmoothed variance over 13 seconds of the NW corner trace is around +/- 0.2 pixels. How would you explain this ? SE managed to get it at half your estimate 60 times a second for over 10 seconds.

I'll be anxious to hear WD's critique.
Me too.

tfk

28th August 2010, 12:46 PM

femr,

How have you separated camera movement from noise ?

All the static points were subject to the same camera movement.

The difference in their reported (by SE) location is the error (not just "noise") in SE's tracking ability of static features.

In other words, camera motion is automatically eliminated from this analysis.

Again, how have you separated camera movement from noise ?

See above.

I thought we all understood and accepted that there was noise in the data.

True. Doesn't change anything I've said.

What would have been more useful for me personally is all manner of input on various different viewpoint on treating that noise.

Again, "noise" is only one component of error. There are others.

There comes a point where you run out of options in "treating" (i.e., reducing) error, and are left saying "this is the limit of accuracy of my equipment, data & analysis".

Every experiment reaches this point.

If you choose to focus on *how bad can we make it*, rather than *how good can we make it*, that's fine.

Wow. Read what I said again. You're misstating.

This statement does not demonstrate a fluency with the fundamentals of experimental technique or analysis.

I'll be applying more of my time to testing smoothing techniques than the former.

Fine.

ETA [delete]

tom

femr2

28th August 2010, 01:16 PM

All the static points were subject to the same camera movement.
Agreed.

The difference in their reported (by SE) location is the error (not just "noise") in SE's tracking ability of static features.
Pretty much.

In other words, camera motion is automatically eliminated from this analysis.
Please explain.

There comes a point where you run out of options in "treating" (i.e., reducing) error, and are left saying "this is the limit of accuracy of my equipment, data & analysis".
Absolutely.

Wow. Read what I said again. You're misstating.
It's just that position variance is roughly +/- 0.2 pixels, and your suggested error is 0.8 pixels.

alienentity

28th August 2010, 01:29 PM

tfk

28th August 2010, 01:46 PM

femr,

Agreed, though that's one reason why I've performed the blob tests, to get an idea of the effect of underlying motion error (0.0625 pixel mechanical variance + velocity slew)

We use the work "mechanical" in completely different meanings...

"... underlying motion errors ..." ?

I've read some of your blob test stuff. It

Also must reiterate that static point traces are done to detect camera movement, and there's no perfect way of separating camera movement from noise in those traces. Can be estimated, sure, but that involves using all of the available smoothing and noise reduction processes. (Averaging multiple static points is also useful of course)

All the static points were subject to identical camera motion. This eliminates camera motion from being a source of error in this analysis.

That's also why I provided a 2nd data set for when the camera settled down.

It was simple to get the statistics for the 3-10 second interval. (Looking at the "Static X" values, you can see that this is the period where the

The average static errors turn out to be actually less while the camera is moving. While it is a significant percent difference, this may be just chance.

|Ref 9/16|Ref 11/17|Ref 13/15|RMS Errors
Errors 0 - 17 sec||||
Avg|0.10|0.16|0.16|0.14
StDev|0.07|0.09|0.09|0.08
Avg+2 Sigma|0.24|0.33|0.33|0.30
Avg+3 Sigma|0.30|0.42|0.41|0.38

Errors 10 - 17 sec||||
Avg|0.15|0.23|0.23|0.20
StDev|0.05|0.06|0.06|0.05
Avg+2 Sigma|0.25|0.34|0.34|0.31
Avg+3 Sigma|0.30|0.39|0.40|0.37

Errors 3 - 10 seconds||||
Avg|0.08|0.15|0.13|0.12
StDev|0.05|0.05|0.06|0.05
Avg+2 Sigma|0.19|0.25|0.24|0.23
Avg+3 Sigma|0.24|0.31|0.30|0.29

The errors associated with the tracking of those static points is a good lower bound for the accuracy of your tracking.

For the footage being used, sure. I'd focus on differences between each static point trace.

That's exactly what I'm posting: the differences between the static points.

I assume that without jitter treatment.

The graph: yes, without jitter treatment.

The spreadsheet calculations that I've tabulated here:

As I said before, I posted the "with 2 point averaging" results.

I calculated the "without 2 point averaging" results too. Those errors are about 50% higher.

The differences in the magnitudes of the alternating part of the curves are a problem.

Could be due to variable distance from camera.

Nope. Because the differences are insignificant to begin with. They are all - optically - at the same distance: infinity. And those distances don't change one iota over the course of the video, but the DIFFERENCES between reported locations does change.

Here is the result, comparing the Y locations of each of the three new static points to the original ("Static Y") value.

Happens to be the the one with most variance, and the largest general offset. I'd have thrown that trace away and used some new ones. Looking at all four static point traces overlaid shows me that the initial one might need looking at, or rejecting. I have no problem doing MORE additional static point traces

Nope. The "Static Y" tracing is the most stable of the 4. Look at the purple curve in my post 225 above.

[quote=femr2;6275512]
Unsmoothed variance over 13 seconds of the NW corner trace is around +/- 0.2 pixels. How would you explain this ? SE managed to get it at half your estimate 60 times a second for over 60 seconds.

All kinds of possible explanations. All (for the moment) irrelevant.

Question for you: how do you explain these variations in stationary point info in the data if SE can determine positions with the accuracies that you've claimed?

___

A point that is pertinent: If you want to post the Y data associated with the 3 new static points, I'll be able to see if that improves or degrades the accuracy. I'll also be able to give you a metric for the rotation of the image.

AND (bonus) accurate distance calculations (not just x & y values) for the roof feature drop locations from each static point.

This will take a bit. Again, way busy for the next several days.

tom

tfk

28th August 2010, 01:53 PM

tfk wrote 'I assume that video compression of the files (before we have access to them) will reduce our precision. Can you direct me to some reference that would help me to begin to quantify what I can expect?'
Russ Andersson replied
'No, sorry. That's not something that normally needs to be quantified explicitly. SynthEyes is a visual effects tool, not a surveying tool.'

What does he mean?

My suspicion is that he means "I run a small business. Surveying is not my market, and I don't have the time to spend going into detail that is irrelevant to my business. And any statement I make regarding its absolute accuracy could come back to bite me in the butt. "

I think his program, if properly used, has the potential to do "surveying".

The two points that he made that caught my eye were:

1. "Need the 3D camera to object location info to solve really accurately."
2. "Accuracy depends on the diligence of the operator."

We don't have the 3D camera info.
femr has said that his analysis are done with none of his intervention.

tom

femr2

28th August 2010, 02:10 PM

The two points that he made that caught my eye were:

1. "Need the 3D camera to object location info to solve really accurately."
2. "Accuracy depends on the diligence of the operator."

We don't have the 3D camera info.
I have the camera location kicking around somewhere in my piling system, but I assume you are aware of the three dimensional scene *solving* algorithms of SynthEyes ? (Determines 3D position ofver time by solving multiple 2D positional data changes)

femr has said that his analysis traces are done with none of his intervention.
Absolutely. Zero intervention.

femr2

28th August 2010, 02:25 PM

We use the work "mechanical" in completely different meanings...

"... underlying motion errors ..." ?
As long as we're talking about error that is solely the fault of SE, lets call it SE-error.

I've read some of your blob test stuff. It
Gonna leave me hanging ? :)

percent difference
Percent ? Please elaborate.

That's exactly what I'm posting: the differences between the static points.
Okay.

Nope. Because the differences are insignificant to begin with. They are all - optically - at the same distance: infinity. And those distances don't change one iota over the course of the video, but the DIFFERENCES between reported locations does change.
I may need to recheck for trace lock issues. Will take a while.

Nope. The "Static Y" tracing is the most stable of the 4. Look at the purple curve in my post 225 above.
I'm pretty sure that trace is dejittered.

What I was saying though, is that if you remove the offsets, then that trace has a noticable offset of it's own, which will skew your results.

All kinds of possible explanations. All (for the moment) irrelevant.
I'll ask again later then.

Question for you: how do you explain these variations in stationary point info in the data if SE can determine positions with the accuracies that you've claimed?
Video quality and camera movement.
Video quality encompasses lots of noise sources, such as compression artefacts, CCD artefacts, lens distortion, atmospheric distortion, focus, resolution, interlace jitter, ...

A point that is pertinent: If you want to post the Y X data associated with the 3 new static points, I'll be able to see if that improves or degrades the accuracy. I'll also be able to give you a metric for the rotation of the image.
Okay. I guess you'll want the region center-points too then :)

AND (bonus) accurate distance calculations (not just x & y values) for the roof feature drop locations from each static point.
Ah. If you're okay with them using the same scaling metric as used for WTC 7, no problem. Otherwise it means a whole load of faffing about.

femr2

28th August 2010, 04:40 PM

A hack at static point trace variance...

http://femr2.ucoz.com/_ph/7/874369222.png

I've applied some processing to the data.

1) Aligned separate traces by either +0.1 or -0.1 pixels relative to t9/16
2) Normal 2 point moving average for jitter treatment.
3) Average of all four traces taken as root.
4) Variance as subtraction of each trace from root.
5) 7 point moving average on variance data (just to simplify the display).

Am sure there will be opinion :)

femr2

30th August 2010, 08:09 AM

Jackanory

30th August 2010, 10:00 AM

Noticed some discussion of the NIST 5.4s interval.

Here is that interval using the Dan Rather dataset...

http://femr2.ucoz.com/_ph/7/842535832.gif

Make of it what you will.

I think they were a little early (as they treated flexing behaviour in the Cam#3 footage as vertical movement).

I'd suggest (using specific frame numbers to calculate) they were 0.467s too early, making the 5.4s metric more like 4.93s.

Yet another set of pretty data Femr2. 5.4s down to 4.93s woooooooooooooo.

Post #1 asked a very specific question. Post #31 too. You have danced ever since. Pick a spot out of any one of the videos you use. Just one spot and do as Tom has asked. Stop dancing with your 'BS' baffles brains sketch and your fancy garbage in/out data and pretty graphs. Pick a spot, show Tom, and lets see if your pixels and interlaced jargen differ. Lets see if your fence sitting works. Same camera, same distance, same light, same angles, same cameraman, same time etc etc etc. Put up or STFU.

Major_Tom

30th August 2010, 11:05 AM

tsig

30th August 2010, 11:12 AM

Jackanory

30th August 2010, 11:43 AM

It is pretty obvious from this thread that there is an anti-intellectual element within this forum that is allowed to harass at will.

Femr is introducing a tracking tool to measure actual building movement of any of the 3 towers with surprising accuracy.

If we want to see the correct order of events during collapse initiation, or look for any detectable deformations leading up to each collapse, why wouldn't suchn a tool be welcome?

Instead, femr is forced to endure an absurd amount of abuse from people who clearly know much less about this tracking tool than he does.

This sickening level of abuse is allowed here.

It seems encouraged through a pack, group mentality.

Do you really need femr to explain why accurate measurements of early deformation and collapse initiation are important to the subject of CD or natural collapse?

What I want is a straight forward response to the questions raised by Tom in the OP and reiterated throughout this thread. femr2 is versed in the dance. femr2 has used the same dance time and time again.

The methodology and tactic used here by femr2 is the same used elsewhere. The very same technology, terminology, trickery and 'BS' was used by femr2 to attempt to convince the kids at uboob that an anomaly of a 'POD' was attached to the aircraft that struck WTC. femr2 attempted to use the same camera jargen, pixel jargen, interlaced, interpolated jargin top convince the kids that this anomaly was infact a bomb. femr2 used his 'tech knowledge' of all things camera and pixel in much the same manner. femr2 used all manner of 'BS' to attempt to convince the kids. Was it an anomaly? NO. Did it really require such terminology, pixel explanation, interlacing jargin etc etc NO! Did it require hundreds of post, many threads, countless graphs, videos and stills? NO!!!!

Turns out that the 'POD' was infact the fairings that housed the undercarriage and wheels. In femr2's world it was a bomb.

So I make absolutely no appology to you or anyone else for the manner in which I respond to such a charlatan.

femr2 is pulling your chains. It does not require hundred of tech posts to tell me that. If Tom wishes to humour himself then that is Tom's perogative. Edited for rule 12.

beachnut

30th August 2010, 12:56 PM

It is pretty obvious from this thread that there is an anti-intellectual element within this forum that is allowed to harass at will.

Femr is introducing a tracking tool to measure actual building movement of any of the 3 towers with surprising accuracy.

If we want to see the correct order of events during collapse initiation, or look for any detectable deformations leading up to each collapse, why wouldn't suchn a tool be welcome?

Instead, femr is forced to endure an absurd amount of abuse from people who clearly know much less about this tracking tool than he does.

This sickening level of abuse is allowed here.

It seems encouraged through a pack, group mentality.

Do you really need femr to explain why accurate measurements of early deformation and collapse initiation are important to the subject of CD or natural collapse?

All for no reality based goal, the goal seems to be to back in CD. It is called failure Tom, you have to have a goal tied to reality in the real world, so this work is nonsense and a waste of time. BTW, tracking algorithms that are much better exist but you can't have them unless you buy them. This is total nonsense since there is no real goal, and in reality it only pertains to 911 because you and ferm2 have delusions about CD and can't figure out 911.

When the work is done and published it will show a gravity collapse, either with better fidelity, or worse, some smoothed out version that looks good and could be used to show the point of interest in some cartoon as an subject with added background. This stuff works great for making up movies and not using blue screen. Super stuff. But the world of tracking is orders of magnitude past this basement hobby application to prove woo.

In the real world steps can be sourced and referenced, not just made up and pushed as being correct. Ask him to source and reference his work, the points/claims/steps/methods/results/etc, it will not happen.

When will you guys publish anything like Heiwa did with his letter?