The 9/11 Forum

I hope I didn't make any mistakes! My apologies to anyone with a slow or expensive connection. Being all on the same host, the pages may take some time to load.

I stopped at column 560 because it's obviously different, and things are more interesting. This is at the NW corner, and the horizontal motion is evident in the wavy line formed by the sharp edge at the corner. Going too close to the corner makes getting data from the smear more difficult, but it's more intriguing to simply look at.

I will be posting a few more now that will be sequential columns moving to the right - 561, 562 and 563. This traverses the near vertical edge made by the NW corner. As shown earlier, the graph of horizontal motion published by NIST is directly observable in the smearogram as a subregion of the dark wavy streak.

The series represents different slices of the building projection and is geared toward vertical measurement, but the corner slices capture lateral motion as well. The last smear shows NIST's horizontal curve, and does so because it reflects the same basis as their technique used.

NIST favors moire interpretation for their precise hard data, and they're quite good at it. Their technique involves tracking a given edge color vertically in a pixel column and scaling to the horizontal distance represented by the pixel width. The smear above shows information equivalent to what they used - actually quite a bit more - directly to your eye.

One can do simple threshold extraction and average the top and bottom edges of that dark band to duplicate their data. I did duplicate their data (need to post that, too) earlier but it was by an entirely different technique. What's funny is, after you have the numeric data, the first thing you do is make a plot and it looks just like that smear above.

This is why smearograms are unsurpassed for quick look data. Someday I may post the video made by putting all the smears together as 308 frames, it's... different.

einsteen wrote:Here as promised the primitive method to create smearograms...

http://www.megaupload.com/?d=JNMLLCLW

I repost this because it's way back on page three and is quite important. einsteen made this video to show a way to create smearograms and convert them into numbers. More important than the specifics are the basic principles of each operation, but the video is specific enough to take you through the entire process showing even the applications to be used.

Future career in film-making?

einsteen's video (hope the link is still good) shows a particular set of tools for this process. There are a few things that are almost indispensable but good free software is available for just about every purpose. Some useful items:

AVI editing, conversion, rescale and filtering
Virtualdub - http://www.virtualdub.org/

Image viewing and basic manipulation
IrfanView - http://www.irfanview.com/

Media conversion
SUPER © - http://www.erightsoft.net/SUPER.html
Rad Video Tools - http://www.radgametools.com/bnkdown.htm

Vector drawing (helpful for all sorts of things, including measurement)
Inkscape - http://www.inkscape.org/

Engauge Digitizer (have used this occasionally for manual digitizing)
http://digitizer.sourceforge.net/

Separating the pixels of interest is the first step. It is useful to think in terms of edges, corners, and regions, both simple and complex - even though these are not such precise descriptions. Software can easily discriminate between groups of pixels satisying certain conditions, and there are a number of ways the groups can have position assigned to them.

I've recently started to work with OpenCV (http://opencv.willowgarage.com/wiki/), an open source machine vision library in C++. It provides a lot of very advanced features like subpixel feature tracking and is obviously quite useful for this sort of thing. Pleasantly enough, and unlike many free libraries, it built and ran without a hitch. Useful image processing in only a few lines of code! I was just getting the hang of the edge and corner detection when that particular machine went belly up.

Unfortunately, because of that, I currently can't access the results of the Sobel operator (http://en.wikipedia.org/wiki/Sobel_operator) applied to the CBS video frames. There were a number of parameters to play with and the results were promising but variable.

Tomorrow I'll explain this, my own edge detection algorithm. Does make the roofline jump out, doesn't it? Might give a nice smear, but is not yet so useful to produce numbers:

That was horizontal edge detection by means of partition of neighboring vertical differences into quartiles, by channel. It's very simple and works quite well but I haven't figured out how to express the resulting numbers in a way that preserves the notion of position and motion of the roofline. That goes for edges in general, not just from this method.

There are several standard methods for edge detection. The Canny algorithm is very common but I was hesitant to go that route because the first step is application of gaussian blur to eliminate noise peaks. I'm beginning to appreciate why that might be a positive in this case, even though irreversibly corrupting the data as a first step is certainly non-intuitive. More on the standard methods later, here's another edge detection output, this time from the ImageMagick library, I suspect it's based on Canny but I'd have to check:



This has edge detection in both dimensions. Not as well-discriminated roofline as my own algorithm. Nevertheless, here's something interesting, an animation of the first 100 frames focused on the NW corner, horizontal stretching employed:



Very subtle deformational activity going on while the penthouse is starting to descend. Can't say I see this in the regular frames, but I'll have to look again.

Great work OWE. Do you have the numerical data for the above smears?

Thank you. No, not yet. I'll probably run a script on (some of) them soon but it will only be pixel resolution. Sub-pixel resolution will have to wait until a few more ducks are in line.

As soon as I have numbers, though, I'll put them up.

Great work OWE

....

Raw pixel data would be great,... I was never a big fan of cooked data!

P.S: OWE, do you have an alter ego who goes by the nom de plume/guerre ORE by any chance?

Dr. G wrote:

Great work OWE

....

Raw pixel data would be great,... I was never a big fan of cooked data!

Boy, did you just open the spillgates on my mouth! Ha ha, you'll see!

P.S: OWE, do you have an alter ego who goes by the nom de plume/guerre ORE by any chance?

Yeah, that one. It's not as nice as me.

I know... what am I thinking?!?!? It's a little bit of fun for now, but I'm sure it will grow old. What do you want to bet I'll be banned for being Balsamo, anyway? It's just surreal. My mind is reeling.

Dr. G wrote:Raw pixel data would be great

Careful what you ask for because, technically, you've already got it. It just happens to look like pictures to the naked eye! If I were to dump the pixels to numbers as they are, it would be over 200,000 records of five fields each, for each smear.

Did you mean something like einsteen's process? That's what I meant by running a script to produce pixel-resolution data. Even that is cooking, be it just a flash in the pan. As proof, I'll ask you now for the threshold value for creating the mask: give me a number between 0 and 255, or specify default to accept whatever value the software chooses (this was einsteen's choice, but he uses different stuff). Then I can run. Do you see what I mean?

Practically, there will be a narrow range of threshold values that adequately characterize the edge we seek to digitize. Within that range, different thresholds produce different output values. As you saw with the artifact in einsteen's data, the situation can be improved by a better choice of threshold. In the absence of any criteria to judge fitness, from a numeric standpoint, all edges traced by the applicable range of thresholds are equally valid. You just happened to get one (arbitrary) set with einsteen's data. The one with artifact minimized was a different 'cooking' of the exact same data.

Since all are valid, why not combine the results of all thresholds into a single value, using equal weights? Giving sub-pixel resolution, although brutally crude.

Well, now we're cookin'...