The 9/11 Forum

Intelligent and evidence-based discussion of 9/11 issues

Skip to content

v
Welcome
Welcome!

Our vision is to provide a home to sincere 9/11 researchers free from biased moderation and abusive tirades from other members.

You are currently viewing our boards as a guest, which only gives you access to view the discussions. Feel free to register to request membership. By joining our free community, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content, and access many other special features. All potential members will be subject to an interview via email and only sincere and responsible researchers will be approved. See the forum guidelines for more information.

Technical notes on video motion analysis

Other 9/11 topics of a technical nature.

Re: Technical notes on video motion analysis

Postby Dr. G on Tue Sep 23, 2008 2:00 am

OneWhiteEye,

Thanks, ..... yes, ... my latest estimate is that 1 pixel in your height data is ~ 0.3 meters, but I am not entirely happy with this result, ............. yet ..........

By the way, have you seen Appendix C of NCSTAR 1-9, especially Figure C-4, .... interesting stuff!
Dr. G
 
Posts: 495
Joined: Thu Jul 10, 2008 5:29 pm

Re: Technical notes on video motion analysis

Postby OneWhiteEye on Tue Sep 23, 2008 2:15 am

Dr. G wrote:OneWhiteEye,

Thanks, ..... yes, ... my latest estimate is that 1 pixel in your height data is ~ 0.3 meters, but I am not entirely happy with this result, ............. yet ..........

By the way, have you seen Appendix C of NCSTAR 1-9, especially Figure C-4, .... interesting stuff!

I'm checking everything manually now, just to be sure. The 1 second animation slices (generated as a by-product) with a dot placed at the calculated location looked good yesterday, but I need to be sure that this initial drift is real. It isn't camera motion but it can be visual distortion; it is a really big feature and technically the result can wander anywhere inside the bounding box.

I've revised my scaling to 0.04484 stories/pixel, based on measurement down the centerline of the rectangle. Works out to 0.166m/px if a story is 3.7m. I'm curious as to the 0.3 figure?

Checking Appendix C now.
OneWhiteEye
 
Posts: 1220
Joined: Sat Jul 05, 2008 9:40 pm

Oh noooo

Postby OneWhiteEye on Tue Sep 23, 2008 5:59 am

Waste no more time, I've simply got to do better. The rectangle, which is way too large, is on a surface that starts curving, there is some variation in luminousity, thermal, smoke, compression, etc. Let's can that one in favor of something else. Sorry if it was a time drain.

This is the place to explain how these magic numbers are obtained, especially appropriate after reading some of Appendix C. They're very clever, those NIST people. Me, not so. To know what I'm doing is to understand the shortcomings and see why there's no reason to expect this last data posting to be all that good - for anything. The rest here is explanation (optional reading).

The dark rectangle is distinguishable from the surrounding pixels by the values of its color intensities. I selected pixels belonging to it by doing the following:

For each pixel
- calculate simple average intensity: (R+G+B)/3
- calculate inverse: (255 - average)
- discard pixels with inverse intensity of less than 180
- discard pixels with blue < red (eliminates dark roofline satisfying intensity)

This does a reasonably good job of picking out the pixels belonging to the dark rectangle, and only those. Once this group is collected for a given frame, some meaningful number must be assigned for position. The most crude means is to form a bounding box from the integer pixel locations of the minima and maxima in each coordinate, then calculate the center as an average of the extremes. This gives half-pixel resolution but obviously reflects the 'jumpiness' of the edges. Of interest is that each min/max pair is simlar to the method of obtaining curves einsteen used recently on his smearograms, namely masking into two regions based on a threshold and getting the pixel location of the boundary.

A good choice of threshold is essential. I go through every few frames and sample the colors to get an idea of how the target colors change over time. In the case of the rectangle, the rules specified above were good enough over the whole range, though I can specify keyframes and interpolate linearly between setpoints when necessary. More complicated selection rules involving individual color channel ranges and combinations are also possible, though I've tended to stick to intensity over or under a certain value. Note as well there are several ways to calculate intensity, I do equal weight color average for simplicity.

Another way to get position is to calculate the mean center of luminosity, which I used perhaps inappropriately. This is an entire subject unto itself, for another post, but consider it analagous to calculating (x,y) CM location from elevation data grids. It is a very good method when the group is small (less than 15 pixels) but requires enclosure by a contrasting background. In the worst case, it can't give a value outside the bounding box, so small features are better. The ideal is 1 - 2 pixels' extent in the measured dimension. The dark rectangle, unfortunately, is 70 pixels high so isn't well suited unless the video is super quality... which it's not. Yhe reason for choosing the rectangle was again simplicity; there are plenty of dots (windows) but they're very close together and thus are hard to separate, even with additional spatial clustering.

Concluding the steps with center of luminousity:

For each pixel
- subtract 180 from inverse intensity to give adjusted intensity
- calculate (position)*(adj. intensity) for each coordinate
- add to group sum for each coordinate
At end
- divide each sum by pixel count of group

The result was what was plotted earlier; here it is shown between the bounding box min/max corves (in red):

Image


It may be the lower bound is a more true curve; it's mostly flat until a decisive drop. The bounding curves hint that the carnage above is affecting the shape and apparent luminosity of the upper portion more than the lower.

What I need to do is find a nice small region, or use an entirely different 1D approach with edge detection on the roofline. This is what I described early on in this thread but haven't written all the code. The attempt to take a shortcut with the rectangle was not beneficial.
OneWhiteEye
 
Posts: 1220
Joined: Sat Jul 05, 2008 9:40 pm

Re: Technical notes on video motion analysis

Postby Dr. G on Tue Sep 23, 2008 4:33 pm

OneWhiteEye:

I am sorry you are questioning your own data so soon! I thought it looked pretty good and, besides, I know you are a careful researcher! I can see that taking a point on the north face of WTC 7 could give a somewhat different result to using a point at the northwest corner of the roofline, for example, but I wouldn't expect it to cause a major change in the results.

On the scaling factor for the vertical axis I was simply assuming the descent curve covers a drop of about 30 meters which corresponds to about 90 pixels; hence we have 1 pixel = 30/90 ~ 0.3 m/px.

If you are saying the factor is about half of this we are looking at a drop of only about 15 meters, so I am confused.....

Right now all I can say is that I was very intrigued that your data fits an exponential function so well. An exponential descent curve is characteristic of a tipping motion. Interestingly NIST detected some swaying of WTC 7 in the period just before global collapse, although it was from east to west, not north to south. I wonder what started the building swaying......
Dr. G
 
Posts: 495
Joined: Thu Jul 10, 2008 5:29 pm

Oh yesss! -- Maybe?

Postby OneWhiteEye on Wed Sep 24, 2008 5:16 am

I am sorry you are questioning your own data so soon!

I'll throw it away without batting an eyelash if it's junk, and it looks that way. Easy come, easy go.

I thought it looked pretty good...

So did I, that's why I put it up here. At least it wasn't in a high visibility location. I was fooled into a false sense of quality, I guess because it didn't look like crap and the verification animation looked OK. In trying to sync the two videos einsteen posted, I did some manual measurements on the rectangle edges that looked more like the other curves, and suggested there was some wandering in the automated data. Then, when you had difficulties fitting it and the same run on the Sauret video produced a curve that looked more like the others, I had to check more thoroughly. Yes, it does seem it's crap. When faced with qualifying its badness, or where it comes from, there's no doubt time is better spent getting some good stuff.

I know you are a careful researcher!

Thank you! Scatter-brained might be closer to it. You see, the choice of the dark rectangle was unwise, but then I threw the baby out with the bathwater, saying I needed to write code to do edges, blah, blah. The existing program will probably do just fine. I forgot that 1D is just half of 2D! Geez. All I have to give up is simultaneous x and y measurement and then an edge (roofline) becomes a viable target in this scheme.

I can see that taking a point on the north face of WTC 7 could give a somewhat different result to using a point at the northwest corner of the roofline, for example, but I wouldn't expect it to cause a major change in the results.

For the wandering, I don't know (without reviewing carefully frame-by-frame) whether it's smoke or video artifact or what. My manual measurements confirm the rectangle drops farther than the NW corner, not surprising when you see the angle the roofline develops over time.

On the scaling factor for the vertical axis I was simply assuming the descent curve covers a drop of about 30 meters which corresponds to about 90 pixels; hence we have 1 pixel = 30/90 ~ 0.3 m/px.

If you are saying the factor is about half of this we are looking at a drop of only about 15 meters, so I am confused.....

Yes, I see. I've made a number of measurements of the floor heights and am fairly confident but I will check again. The video is (now that I look at it) 30fps... but acts like 15fps... hmmm... half-speed? Did I really get taken in by that? If it's not real time it's of little use. A shame, but what else could it be?

Right now all I can say is that I was very intrigued that your data fits an exponential function so well. An exponential descent curve is characteristic of a tipping motion. Interestingly NIST detected some swaying of WTC 7 in the period just before global collapse, although it was from east to west, not north to south. I wonder what started the building swaying......

I was hoping to get some detail from these videos; now I think I just need to get some videos.
OneWhiteEye
 
Posts: 1220
Joined: Sat Jul 05, 2008 9:40 pm

Bad floor measurement

Postby OneWhiteEye on Wed Sep 24, 2008 6:02 am

What was that you said about careful? I usually have a lot of frames open at once, some enhanced, some enlarged... apparently I carefully measured floors on an enlargement, because I just measured below the center of the building again and got:

12 floors = 175 pixels
=> 0.0686 fl/px
if 3.7 m/fl => 0.254 m/px

The same regular 12 floors measured near the NW corner come to 179 pixels.
12 floors = 179 pixels
=> 0.0670 fl/px
if 3.7 m/fl => 0.248 m/px

Much more reasonable, and correct. (I just repeated the last measurement and got 180 pixels, but close enough...)

The video (despite having 'NIST' in the filename) does not run at half speed; it shows the same fall rate when played as the 50fps Naudet. So the video is OK, it's me that's goofed up. Thanks for catching that, Dr. G. Stick around through the parade of errors and there may be something worthwhile!
OneWhiteEye
 
Posts: 1220
Joined: Sat Jul 05, 2008 9:40 pm

Oh, for god's sake

Postby OneWhiteEye on Wed Sep 24, 2008 7:58 am

The very careful and correct floor measurements given in the previous post were for the Naudet video, not the NIST video!

The NIST video does measure 13 floors = 300 pixels. Given how screwed up I am when looking right at the frames, it's natural to suppose the script read frames from the wrong directory. I don't think so, though. Time for a sanity check.

These numbers just in from manual measurement of the NW corner in both videos, very carefully done:

Code: Select all
Frame  pix    m    disp
------------------------

Naudet (50fps)
F000   132  32.74   ---
F050   133  32.98   0.24
F100   162  40.18   7.44
F150   232  57.54  24.80
F200   334  82.83  50.09

NIST (30fps)
F263    13   2.08   ---
F293    15   2.40   0.32
F323    58   9.29   7.21
F353   163  26.11  24.03
F383   330  52.87  50.79


Ok, there is excellent agreement between the two videos for the displacements as shown in meters in the rightmost column. Pretty good choice of NIST frame 263 as the start time of the Naudet video, eh? So it's clear that both videos are real time with the correct frame rate and scale factors.

What about the dark rectangle? Manual measurements of the upper right corner in NIST video:

Code: Select all
NIST (30fps)
F000    56   9.21   ---
F263    56   9.21   0.00
F293    66  10.85   1.64
F323   107  17.60   8.39
F353   209  34.37  25.16
F383   370  60.84  51.63


For these last, 12 floors is 270 pixels at that horizontal location, so instead of 0.0433 fl/px as in the corner, the conversion is 0.0444 fl/px or 0.164 m/px. Is 3.7m correct for a regular floor?

In any case, the upper right of the rectangle starts moving about the same time and matches the displacement of the NW corner very closely, i.e., at least half of the face is falling uniformly at the top.

From the automated data on the 'center' of the rect, or rather the rect as a whole:

Code: Select all
NIST (30fps)
F263   91.41    15      --
F293   99.25    16.3   1.3
F323  143.63    23.6   8.6


Up to this point, there is good agreement between all of the datasets! The total pixel travel by frame 334 is 87.1px, and a manual measurement gives 86px travel for the upper right rect at that frame. For the most part, everything agrees. I am puzzled. Where is the error???
OneWhiteEye
 
Posts: 1220
Joined: Sat Jul 05, 2008 9:40 pm

Re: Technical notes on video motion analysis

Postby Dr. G on Wed Sep 24, 2008 3:41 pm

OneWhite Eye (and Einsteen):

I am unable to resolve some of the outstanding issues associated with deriving collapse curves from the various videos we have been discussing, (but I do appreciate all the time and effort you guys have been putting into this!).

Nevertheless, I can answer one important point: NIST gives the height of WTC 7 as 610 feet = 186 meters, (See NCSTAR 1-9 Chapter 5, page 98). For 47 stories the average floor height would then be 3.96 meters. These are the values I have been using in my calculations. There are some problems with this because the first 5 floors were atypical and the 47th floor was slightly higher than the rest. Nonetheless, I think a floor height of 3.96 meters is a very good approximation to the true value.

Unfortunately there is still some uncertainty connected with the height of WTC 7 as described in NIST's Draft Report. Thus on page 595 of NCSTAR 1-9 we read that the top of the building "parapet wall" was at an elevation of 925 feet and the first floor lobby was at 309 feet which gives a building height of 616 feet. However, this discrepancy is resolved if the parapet wall is assumed to be 6 feet tall so the roof was at 610 ft.
Dr. G
 
Posts: 495
Joined: Thu Jul 10, 2008 5:29 pm

Re: Technical notes on video motion analysis

Postby OneWhiteEye on Thu Sep 25, 2008 9:24 pm

Dr. G wrote:OneWhite Eye (and Einsteen):

I am unable to resolve some of the outstanding issues associated with deriving collapse curves from the various videos we have been discussing, (but I do appreciate all the time and effort you guys have been putting into this!).


You're welcome. The details are quite intriguing.

Nevertheless, I can answer one important point: NIST gives the height of WTC 7 as 610 feet = 186 meters, (See NCSTAR 1-9 Chapter 5, page 98). For 47 stories the average floor height would then be 3.96 meters. These are the values I have been using in my calculations. There are some problems with this because the first 5 floors were atypical and the 47th floor was slightly higher than the rest. Nonetheless, I think a floor height of 3.96 meters is a very good approximation to the true value.

Unfortunately there is still some uncertainty connected with the height of WTC 7 as described in NIST's Draft Report. Thus on page 595 of NCSTAR 1-9 we read that the top of the building "parapet wall" was at an elevation of 925 feet and the first floor lobby was at 309 feet which gives a building height of 616 feet. However, this discrepancy is resolved if the parapet wall is assumed to be 6 feet tall so the roof was at 610 ft.

Thank you, this clarifies a lot for me. Until now, I didn't know how the overall height (which has been disputed as you note) related to the height of regular, uniform floors. The choice of 3.7m was not based on anything other than being typical for the towers; I thought maybe it was a standard or a minimum for office space. It's a major reason why I'm reluctant to explictly convert from pixels to meters. The information you've provided assists greatly in relieving the uncertainty of this aspect. NIST obviously has to know these details to do their simulations, but I gather it's not included in the report (I haven't looked but I'm sure you have).

Given a height of 186m, 41 regular stories, and one story being taller:

Image

Subjective, yes, and not very meaningful. Conservative in one direction while extreme in the other, perhaps. Having seen a few interior shots of the towers, 3.65 - 3.7m seems claustrophobic, and I'm guessing is probably as small as the designers could get away with, so I'm going to arbitrarily adjust the minimum regular floor up from 3.5 to 3.7m. I suspect all irregular stories are greater in height, but I've no basis for that. A reasonable figure might be 3.9 +/- 0.2 meters.

Using 3.96 instead of 3.7 improves the situation a bit but does not resolve it. Four floors in the vicinity measure 87-88 pixels, call it 87.5 pixels. So 4(3.96)/87.5 = 0.181 m/px and does not fix the problem. Invoking maximum floor height error can account for 10%, but it's not a good choice especially falling so far short. If 0.3 m/px, at a minimum, is expected based on other reliable measurements, the 40% disrepancy must be resolved in some other way.

In the next post I'll suggest t0 adjustment as a remedy.
OneWhiteEye
 
Posts: 1220
Joined: Sat Jul 05, 2008 9:40 pm

Re: Technical notes on video motion analysis

Postby Major_Tom on Thu Sep 25, 2008 11:01 pm

Floor elevations of WTC 1, 2 at the following link.

http://www.sharpprintinginc.com/911/ind ... on=158:158


This info was not given by NIST but was apparently sneaked out of a law office and made public.

Top secret stuff. National Security.

So the floor heights of WTC 7 are top secret, too?
Major_Tom
 
Posts: 970
Joined: Wed Jul 09, 2008 5:04 pm

t0 adjustment (short: 8.77+ sec, not 7 sec)

Postby OneWhiteEye on Thu Sep 25, 2008 11:09 pm

I'm not flipping again and upholding the automated data but, once drop begins, net displacement compares well to trustworthy data for a proper choice of t0. While there's no need to defend the accuracy of discardable data, it's almost imperative to know why it fails one test and passes another to gain a better understanding of the process. The discrepancy in pixel conversion cannot be ignored since some of the data actually appears to be good.

The drift seen prior to the time NW corner motion begins (about 4 pixels peak to peak) has been all but refuted by further examination. At the very least, the upper right of the dark rectangle has no discernable net motion when comparing frame 0 and 263 manually. Two pixels of drift error at 80 pixels' deflection is only 2.5% but, early on, it could overwhelm the signal. If the motion from 5 to 8.5+ seconds is all drift, as manual measurements suggest it is, then the slope of that drift must be considered as the dominant effect going into drop initiation. Likewise, the true t0 must be later than 7 seconds into the data.

Refer back to the third graph posted (http://i37.tinypic.com/23wuusw.jpg), the data in the 5-9 second range. Assume the rect is actually stationary until manual measurements show motion at frame 263 (8.77s). There is a gradual decline of about a pixel and a half prior to descent initiation, looking quite exponential, or sinusoidal over a limited range. Whatever it is, variation in reflectivity, bad choice of threshold, etc., it does not involve the upper right which only begins moving at 8.77s. From there until the end of data 2.36 seconds later, the total displacement correlates well with manually obtained motion data, including NW corner motion, from both videos.

Trimming the first 8.77 seconds won't fix the curve fit because the drift has non-zero slope at t0 and would have to be subtracted from t0 forward, and there's no way to know what that is. So, the data gets discarded as expected. But this does affect scale determination, if the total displacement is used to compute a constant average acceleration and that, in turn, is used to obtain scale.

When measuring floors for the vertical centerline towards the top, I noticed the height of the first four regular-looking stories was 87-88 pixels. That's very close to the travel of 87.1 (automated) and 86 (manual) pixels over this time period, meaning the rectangle dropped about four stories over the 2.36 second span, regardless of conversion factor. However, the conversion factor of 0.181m/px gives a distance traveled of 15.8m which, in conjunction with the revised time of 2.36 seconds, leads to an equivalent average acceleration of about 5.7 m/s^2, or 0.58g.

The figures you mentioned, Dr. G, were 30m and 4.13s. Plugging them in, the average acceleration I get is about 3.5m/s^2. Am I doing this right? From stationary, 1g over the time 4.13 seconds (from t0=7) would be about 83.5m, correct? Is this indeed the low figure you expect, are you trying to stretch to meet my bad data halfway, or am I screwing up my calculations?
Last edited by OneWhiteEye on Thu Sep 25, 2008 11:21 pm, edited 1 time in total.
OneWhiteEye
 
Posts: 1220
Joined: Sat Jul 05, 2008 9:40 pm

Re: Technical notes on video motion analysis

Postby OneWhiteEye on Thu Sep 25, 2008 11:12 pm

Major_Tom wrote:Floor elevations of WTC 1, 2 at the following link.

http://www.sharpprintinginc.com/911/ind ... on=158:158


Excellent! Thank you, Major_Tom, I'll check that out. I tried finding such info last year with no success.

Edit: I thought you said WTC 1, 2 and 7. Guess I should read! It was 7 that I was looking for and couldn't find, guess that's still to be the case.

This info was not given by NIST but was apparently sneaked out of a law office and made public.

Top secret stuff. National Security.

So the floor heights of WTC 7 are top secret, too?


Strange, indeed.
OneWhiteEye
 
Posts: 1220
Joined: Sat Jul 05, 2008 9:40 pm

New einsteen data

Postby OneWhiteEye on Thu Sep 25, 2008 11:18 pm

I see einsteen has put some new data up. I need to compare what I have with what he has.
OneWhiteEye
 
Posts: 1220
Joined: Sat Jul 05, 2008 9:40 pm

Re: Technical notes on video motion analysis

Postby Dr. G on Fri Sep 26, 2008 2:34 am

OneWhiteEye:

Perhaps we are going around in circles a bit on this and I may be part of the problem (because of my flip-flopping with this scaling issue), ..... however, the best choice for t(0) is also a problem.....

So let's see if we can agree on a few points and take it from there:

The CBS video we, (and NIST!), are (mostly) working with was taken about 0.63 km north of WTC 7 near Harrison and West Streets. The white stepped building in front of WTC 7 is 101 Barclay which is 100 meters tall at its highest point. This allows one to see only floors 30 - 47 of WTC 7. This is 17 stories although NIST claims you can see 18 stories, ..... so let's compromise and say it's 17.5! So, if we take the average floor height of WTC 7 to be 3.96 meters, 17.5 floors is 69 meters.

NIST has a useful set of images from the CBS video on page 279 of NCSTAR 1-9. These images are nine stills taken 0.5 seconds apart. Looking at these images I would say that we can take t(0) to be ~ 7.5 seconds and the roofline disappears from view at ~ 11.5 seconds. So we have an average acceleration = (2 x 69)/ (4^2) = 8.6 m/s^2.

I think we should all take this as a starting point and try to refine the starting time to get an agreed-to collapse curve (Einsteen, I hope you are reading this too!). I think the NW corner is the best place to measure the collapse motion although other locations would be useful to consider later on.

One other point: if you follow the movement of the NW edge of WTC 7 as it descends I think you can detect some "wandering" or wobble. This is also apparent in David Chandler's work on the AE911truth website although he uses a different video.

http://www.youtube.com/watch?v=gC44L0-2zL8&NR=1

Take a look at the path David draws for the motion of the NW corner of WTC 7 at 1 minute and 45 seconds into the video. It is not a straight line! I am not sure if the CBS video shows this effect but it should, since the angle of view is not that different between the two videos.

Anyway, I wonder what this sort of slight curvature does to a smearogram.....
Dr. G
 
Posts: 495
Joined: Thu Jul 10, 2008 5:29 pm

Re: Technical notes on video motion analysis

Postby OneWhiteEye on Fri Sep 26, 2008 5:04 pm

Perhaps we are going around in circles a bit on this and I may be part of the problem (because of my flip-flopping with this scaling issue),

No, it's all good. Everything needs to be consistent and sensible.

This allows one to see only floors 30 - 47 of WTC 7. This is 17 stories although NIST claims you can see 18 stories, ..... so let's compromise and say it's 17.5!

The top of the building confounds me. I do not know whether there are 17.5 or 18.5 stories visible. I tend to agree with you, but I think it would require the top TWO floors to be irregular:

Image

Those are just stabs. There are at most 15 on the NW corner. I haven't been using the upper floors for scaling, only those below the dark rect.

NIST has a useful set of images from the CBS video on page 279 of NCSTAR 1-9. These images are nine stills taken 0.5 seconds apart.

I must take time to read the report, had no idea any of this was in there.

Looking at these images I would say that we can take t(0) to be ~ 7.5 seconds...

Yes, according to their pictures, it looks like 7.5s is a good choice for the onset of downward motion. That would be frame 225 if this copy starts at the same time as theirs. Running through frame by frame confirms there is a slight position difference on the east side in the first second that continues on into drop. Below are sections from frames 225 and 255, a second apart. The left side is the earlier frame mirrored about the vertical axis, obvious differences highlighted in yellow. This is not as nice a technique as the differencing by NIST; still, the differences are visible.

East center
Image

NE corner
Image

What's not apparent from comparing these two frames side by side is that you might see similar relative motion when comparing any two earlier frames. There is pulsation, sagging, rocking, recovery and lurch in the visible exterior starting almost from the beginning of the video. What's different about this is the apparent continuous transition to collapse and true drop. The first motion of the NW corner is lateral.

NW corner in the same two frames
Image

I think you can detect some "wandering" or wobble.

All the way through the video, from penthouse collapse until the roofline is almost gone.

Anyway, I wonder what this sort of slight curvature does to a smearogram.....

Next post, or one soon after. einsteen should weigh in on that one, and I see you've pointed him to here on t0 discussion. He's also mentioned making a video to explain his technique, which should be good. It's what got me into this in the first place.

einsteen, your input would be appreciated and your presence, honestly, is past due here!
OneWhiteEye
 
Posts: 1220
Joined: Sat Jul 05, 2008 9:40 pm

PreviousNext



Return to Other technical issues

Who is online

Users browsing this forum: No registered users and 0 guests