The 9/11 Forum

femr2 · by **femr2** on Thu Nov 05, 2009 9:39 pm

We have produced numerous data-sets for the descent of features on the Sauret footage.

Trippy has suggested synchronising them. Sounds like a good idea to me.

Guess step #1 is for links to each piece of source footage to be posted, or the data to all be regenerated from a single video source (former would seem more practical given differences in methodology).

My local processed Sauret footage is 3.5Gb (HuffYuv), so I'll hold off uploading it just at the mo and request links to the OWE, Szamboti and no_body source footage.

Am quite happy to do the actual video synch process.

Trippy · by **Trippy** on Thu Nov 05, 2009 10:05 pm

Great idea, also at this point it would be helpful if you guys could say something along the lines of "This unambiguous event happened between frames Blah and Blah-blah in my data".

I think the example i've used is the expulsion of fire from below the collapse zones, although if you guys can agree on something of shorter duration that's easier to pinpoint, that's fine with me.

Basically, i'm after 'landmarks' in the footage that can be matched up.

femr2 · by **femr2** on Thu Nov 05, 2009 10:07 pm

Trippy wrote:Great idea, also at this point it would be helpful if you guys could say something along the lines of "This unambiguous event happened between frames Blah and Blah-blah in my data".

My plan would be to synchronise each source video to the frame.

Data-sets can then be perfectly frame-aligned.

Trippy · by **Trippy** on Thu Nov 05, 2009 10:19 pm

femr2 wrote:
Trippy wrote:Great idea, also at this point it would be helpful if you guys could say something along the lines of "This unambiguous event happened between frames Blah and Blah-blah in my data".

My plan would be to synchronise each source video to the frame.

Data-sets can then be perfectly frame-aligned.

That would be perfect.

T_Szamboti · by **T_Szamboti** on Fri Nov 06, 2009 1:28 am

femr2 wrote:We have produced numerous data-sets for the descent of features on the Sauret footage.

Trippy has suggested synchronising them. Sounds like a good idea to me.

Guess step #1 is for links to each piece of source footage to be posted, or the data to all be regenerated from a single video source (former would seem more practical given differences in methodology).

My local processed Sauret footage is 3.5Gb (HuffYuv), so I'll hold off uploading it just at the mo and request links to the OWE, Szamboti and no_body source footage.

Am quite happy to do the actual video synch process.

femr2,

I would think the Missing Jolt paper would provide whatever you needed from my side. Or is there anything else you need?

femr2 · by **femr2** on Fri Nov 06, 2009 1:39 am

T_Szamboti wrote:I would think the Missing Jolt paper would provide whatever you needed from my side. Or is there anything else you need?

So long as there's a link for me to get hold of the actual binary footage used, that'll be fine. I'll take a look.

femr2 · by **femr2** on Fri Nov 06, 2009 11:07 am

T_Szamboti wrote:I would think the Missing Jolt paper would provide whatever you needed from my side. Or is there anything else you need?

Splendid.

A copy of the Sauret clip referenced by T_Szamboti can be found here:

http://xenomorph.s3.amazonaws.com/WTC1-Etienne-Sauret3.avi

However, I need Tony to confirm frame alignment between it and the DVD rip he actually used...or more preferrably an upload of that DVD rip (fair use would apply in this case)

From Missing Jolt wrote:For our paper we found we were able to get more accurate measurements by ripping the Sauret
video (from the DVD) using DVD Decrypter. Then the raw video files were converted to mpeg2
using Xilisoft Video Converter 3.The converted files were then imported into Adobe Premiere
Pro CS3. The timestamp was added and the entire segment was exported as a still frame
sequence in .gif format

I would add that I see no reference to Tony having deinterlaced the MPEG2 footage in any way, which in itself introduces some error (as each frame is actually two separate frames merged together). Raw DVD files are already in MPEG2 format, VOB files are MPEG-2, so the initial convertion may have introduced some quality degradation by an unnecessary decode-recode process. And...gif format files are 8bit, so a maximum of 256 colours are present, which loses a great deal of fine colour information. Not ideal.

The version that I work from is fully deinterlaced and lossless codec (HuffYuv) used at all times retaining full 24bit colour information and perfect pixel data from the MPEG-2 original. I generated two sets of trace data accordingly...one for the top field of the interlace frame, and one for the bottom field. I will be working towards merging the two datasets soon in order to produce a double framerate dataset which should really help the purpose. (Double time resolution data)

Here is a link to *one* frame of my version:
http://femr2.ucoz.com/photo/6-0-231-3 (1440x480px/935.5Kb)

The left hand side is the top field of the interlace pair.
The right hand side is the lower field of the interlace pair.

My data-set was generated from a *VideoEnhancer* upscaled crop of the footage, which does a fantastic job of increasing frame detail during upscale by incorporating data from previous frames with a very natty motion tracking algorithm. Nothing is *created* in the process, but mathematically included if it can be determined. A frame of that footage is here:

http://femr2.ucoz.com/photo/6-0-212-3 (752x1008px/838.0Kb)

Point tracking was performed automatically by the *SynthEyes* application, which uses 3dp sub-pixel motion tracking of referenced points. I'm not sure of the exact method it uses, but I imagine it is FFT based (I'll check). This *should* result in much more accurate data than manual readings using tools such as *ScreenCalipers* as used by Tony.

OWE, do you have a link to your copy ?

Have tracked an additional feature (Only one data-set at the mo) and the track was absolutely rock-solid.

http://femr2.ucoz.com/photo/6-0-232-3 (1192x721px/16.4Kb)

Feature Tracked:

Have placed the spreadsheet online for reference:
http://femr2.ucoz.com/load/1-1-0-22

femr2 · by **femr2** on Fri Nov 06, 2009 4:14 pm

Well...had a go at joining two interlace data-sets together...

Note: Velocity (pixels/frame), not position. The positional graphs are super-smooth.

Some amount of manual fitting performed (to synchronise origins)...and advice on how to go about it properly would be appreciated, but...

http://femr2.ucoz.com/photo/6-0-234-3 (1240x725px/18.3Kb)

Note that the combined data is at 59.94fps, and frame number increment is 0.5.

And a comparison between the two interlace frame data-sets:

Note there is a half frame time offset between each image.
Note the similar *peaks*

Trippy · by **Trippy** on Fri Nov 06, 2009 8:26 pm

femr2 wrote:Some amount of manual fitting performed (to synchronise origins)...and advice on how to go about it properly would be appreciated, but...
Note there is a half frame time offset between each image.
Note the similar *peaks*

Advice on which bit?

femr2 · by **femr2** on Fri Nov 06, 2009 8:37 pm

Trippy wrote:
femr2 wrote:Some amount of manual fitting performed (to synchronise origins)...and advice on how to go about it properly would be appreciated, but...
Note there is a half frame time offset between each image.
Note the similar *peaks*

Advice on which bit?

Welllll...

I'll simplify the verbage...

I have 2 sets of tracking data.
One from the video produced from the top field of the interlaced Sauret footage.
The other from the video produced from the bottom field of the interlaced Sauret footage.

This produces two very similar traces.

The latter is half a frame further on in time than the first.

The vertical position of features between each video is slightly offset.

---

I've combined the two sets by setting the frame numbers of the second data set 0.5 on for each frame, resulting in a double length dataset

I've shifted each vertical position on the second data set by 4 pixels, which was done by adding a spin control to excel to dynamically change the offset, with the resultant graph visible, and changing the offset value in 0.01 pixel increments until the *ping pong* between vertical position is minimal (especially on level, non moving sections of the video.

However, graphing the relative difference between each dataset shows a slightly non-linear relationship, which I don't quite understand.

I can go into more detail....

What I'm after is perhaps additional info on ways to combine the data (perhaps there are tools which do the job

)

Trippy · by **Trippy** on Fri Nov 06, 2009 10:54 pm

femr2 wrote:
Trippy wrote:
femr2 wrote:Some amount of manual fitting performed (to synchronise origins)...and advice on how to go about it properly would be appreciated, but...
Note there is a half frame time offset between each image.
Note the similar *peaks*

Advice on which bit?

Welllll...

I'll simplify the verbage...

I have 2 sets of tracking data.
One from the video produced from the top field of the interlaced Sauret footage.
The other from the video produced from the bottom field of the interlaced Sauret footage.

This produces two very similar traces.

The latter is half a frame further on in time than the first.

The vertical position of features between each video is slightly offset.

---

I've combined the two sets by setting the frame numbers of the second data set 0.5 on for each frame, resulting in a double length dataset

I've shifted each vertical position on the second data set by 4 pixels, which was done by adding a spin control to excel to dynamically change the offset, with the resultant graph visible, and changing the offset value in 0.01 pixel increments until the *ping pong* between vertical position is minimal (especially on level, non moving sections of the video.

However, graphing the relative difference between each dataset shows a slightly non-linear relationship, which I don't quite understand.

I can go into more detail....

What I'm after is perhaps additional info on ways to combine the data (perhaps there are tools which do the job )

I've been using R for a lot of the stuff i've done. R and Excell.

At this point, I would be inclined to assume that there is some genuine differences between the data sets.

Don't forget that the vertical displacement of the mast is a continuuous variable, but what we have is a series of discrete samples, taken at different times.

I think at this stage, my advice would be to measure the change in position of some foreground or midground fixed object, and use the difference in it's position between the two data sets as an estimate of the error being introduced by the interlacing.

The half frame thing isn't an issue for me, I can work with that, as long as the displacements are accurate.

What i'm hoping at this point is that if we have several different data sets generated from similar enough locations using different methods, then random noise introduced by methodology will tend to cancel.

I'm also hoping that if we can do some sort of measure for a foreground or midground object of it's position, then we might be able to, to some degree account for issues such as machine noise (the closer the object is to the towers physically, the more useful it will be).

femr2 · by **femr2** on Sat Nov 07, 2009 12:28 am

Trippy wrote:I've been using R for a lot of the stuff i've done. R and Excell.

What is R ?

At this point, I would be inclined to assume that there is some genuine differences between the data sets.

There is. The data-sets need to be *re-interlaced* to form a double time-resolution stream.

Don't forget that the vertical displacement of the mast is a continuuous variable, but what we have is a series of discrete samples, taken at different times.

Of course. That's why I'm trying to increase the timebase resolution.

I think at this stage, my advice would be to measure the change in position of some foreground or midground fixed object, and use the difference in it's position between the two data sets as an estimate of the error being introduced by the interlacing.

I just tried a trace on the forground building, and subtracted it's movement from the first trace.

It does a GREAT job of negating the camera wobble, but *seemingly* very little obvious difference to the variations in the velocity data. Perhaps my data quality is better than I thought

There's a few moving average changes, but they are very slight.

The half frame thing isn't an issue for me, I can work with that, as long as the displacements are accurate.

Hope the description of *re-interlacing* the two sets helps make sure we are on the same page here.

What i'm hoping at this point is that if we have several different data sets generated from similar enough locations using different methods, then random noise introduced by methodology will tend to cancel.

We can but try.

I'm also hoping that if we can do some sort of measure for a foreground or midground object of it's position, then we might be able to, to some degree account for issues such as machine noise (the closer the object is to the towers physically, the more useful it will be).

For the Sauret footage, the only option is the foreground builfing, which is pretty far from the Tower. A point lower in the tower would be useful, but the problem there is that the descending debris cloud obscures the lowest portion of the visible tower before the antenna has dropped out of data scope.

Corrected Velocity (pixels/frame) trace (Upper Field):

http://femr2.ucoz.com/photo/6-0-238-3 (1052x718px/14.3Kb)

Trippy · by **Trippy** on Sat Nov 07, 2009 12:44 am

femr2 wrote:
Trippy wrote:I've been using R for a lot of the stuff i've done. R and Excell.

What is R ?

R-Project is open source statistical software written by statitsticians for statisticians (and originated in the department that I studied statistics at).

femr2 wrote:
At this point, I would be inclined to assume that there is some genuine differences between the data sets.

There is. The data-sets need to be *re-interlaced* to form a double time-resolution stream.

Don't forget that the vertical displacement of the mast is a continuuous variable, but what we have is a series of discrete samples, taken at different times.

Of course. That's why I'm trying to increase the timebase resolution.

Cool.

femr2 wrote:
I think at this stage, my advice would be to measure the change in position of some foreground or midground fixed object, and use the difference in it's position between the two data sets as an estimate of the error being introduced by the interlacing.

I just tried a trace on the forground building, and subtracted it's movement from the first trace.

It does a GREAT job of negating the camera wobble, but *seemingly* very little obvious difference to the variations in the velocity data. Perhaps my data quality is better than I thought

There's a few moving average changes, but they are very slight.

Awesome source - in theory, if we can synch your data stream with OWE's, we should be able to apply the same transformation to it.

femr2 wrote:
The half frame thing isn't an issue for me, I can work with that, as long as the displacements are accurate.

Hope the description of *re-interlacing* the two sets helps make sure we are on the same page here.

What i'm hoping at this point is that if we have several different data sets generated from similar enough locations using different methods, then random noise introduced by methodology will tend to cancel.

We can but try.

Cool.

femr2 wrote:
I'm also hoping that if we can do some sort of measure for a foreground or midground object of it's position, then we might be able to, to some degree account for issues such as machine noise (the closer the object is to the towers physically, the more useful it will be).

For the Sauret footage, the only option is the foreground builfing, which is pretty far from the Tower. A point lower in the tower would be useful, but the problem there is that the descending debris cloud obscures the lowest portion of the visible tower before the antenna has dropped out of data scope.

Forgive me, but I was under the impression that there were buildings closer?
If not, I suppose we could transform the vertical displacement to an angular one, and if we know the distance between the camera and the foreground building backtransform the angular displacement as a vertical displacement at the towers (If that makes sense, and assuming i'm not over-thinking this).

femr2 wrote:Corrected Velocity (pixels/frame) trace (Upper Field):

http://femr2.ucoz.com/photo/6-0-238-3 (1052x718px/14.3Kb)

[/quote]
Even just that data has some interesting features.

David B. Benson · by **David B. Benson** on Sat Nov 07, 2009 12:56 am

Trippy --- Pixel "height" is an angle.

Trippy · by **Trippy** on Sat Nov 07, 2009 1:01 am

David B. Benson wrote:Trippy --- Pixel "height" is an angle.

Huh?

-Confused.

The 9/11 Forum

Sauret Data Synch

Sauret Data Synch

Re: Sauret Data Synch

Re: Sauret Data Synch

Re: Sauret Data Synch

Re: Sauret Data Synch

Re: Sauret Data Synch

Re: Sauret Data Synch

Re: Sauret Data Synch

Re: Sauret Data Synch

Re: Sauret Data Synch

Re: Sauret Data Synch

Re: Sauret Data Synch

Re: Sauret Data Synch

Re: Sauret Data Synch

Re: Sauret Data Synch

Who is online