I'm back with another beginner's question: why does the Igniter board digitize an NTSC frame in 720h X 484v instead of 640h X 480v? I don't care about the vertical resolution, that's just taking in a few extra scan lines that aren't used in conventional recording, but the horizontal resolution has me in a kerfluffle. The pixels in the 640h X 480v image are square, but the pixels in the 720h X 484v image are not square -- they're taller than square. When displayed on a monitor with square pixels, the image is stretched horizontally.
This is very bad for my work, because we'll be carrying out precise calculations based on the positions of the events on the screen. We could, of course, correct for the distortion in our calculations -- we're already doing a little of that for another phenomenon arising from the intensifier tubes. But I just want to make certain that there isn't something I'm overlooking here. Is the 720h resolution compensated for in standard television screens? Do video professionals adjust their monitor settings to correct for it?
Re: 720h versus 640h by John Pale on Jan 3, 2007 at 7:08:12 pm
This is normal.
All standard def digital video use rectangular pixels. Things looked stretched on a computer monitor, which use square pixels but display correctly on a video monitor. I wont get into the technical reasons for this, but this was the standard the video industry agreed upon years ago, and is something we all have been forced to deal with when integrating graphics.
Most graphics programs, like Photoshop and After Effects now have presets that deal with the conversion to square pixels on a computer display, so that things do not appear stretched and designers can do their work properly.
Re: 720h versus 640h by Leonid Don Quixote on Jan 4, 2007 at 10:03:58 am
I see; that makes perfect sense. Thanks for the explanation. I use Photoshop for some of the first-round analysis but the main analysis is done with a huge and very messy statistical program that analyzes the content pixel by pixel. I calculate the noise level in each pixel and use that noise level to determine the statistical chance that an increase in brightness represents a random fluctuation or an actual signal. Then I examine the nearby pixels looking for more overbright values, compounding the cumulative probability. Then I combine different values from different frames, knowing that the meteors move in a particular direction at a particular angular velocity. In effect, my software is designed to "see" Leonid meteors with extreme sensitivity. Once it has identified any such meteors, it logs the results. We figure that there are at least 25,000 meteors on the most important 20 hours of videotape. That will make one helluva database. When I participated in the mission, I saw more meteors in two hours than I have seen in all the rest of my life -- and I've been watching meteors since 1964!
Anyway, I'll build the correction for the distortion into my math. I'll probably have a few more questions as I study the many possible arrangements. Thanks again, everybody, for all the help! We are on our way!
