Interlacing issues.

[maclellan]

Thanks James,

Yes you are correct and in fact almost every surveillance within budget is the interline type. Now from what I've read in ccd sensor datasheets there are tpyically 582 X 512 rows and columns of CCD cells - enough to completely contain all the data in each line as it is read. The rate in which all transfers are completed is known as the shutter speed. It can vary from 1/100000 second to 20 ms or a field in NTSC/PAL.

This means that even though the other cells may change in other rows the image technically is not an exact snapshot in time. However if all rows can be read in 1/100000 second then it is quite close, but additional memory id required to contain digitized pixels. (I have some DSP CCD cameras that I'm testing currently that would almost certainly require this extra storage.)

The controller will read alternating rows to derive the interlaced sequence and process the single field. How this occurs varies with the camera manufacturer. For example a controller could digitize the entire sensor and store the data in memory. Or if it had no additional memory then the shutter would work only for a field.

The issue I am trying to determine is whether or not we are seeing the 'blurring' that occurs since it take time to read all rows - ODDS first then EVENS where it takes some time. Or what we have is an interlace error where the time increases to the point where any moving object shows these lines.

I would think that the CDD camera manufacturer would attempt to keep this number down otherwise the camera would be look more like a CMOS camera. So if the camera has a shutter speed of 1/100000 second but only for a single field then any moving ojbect would blur and it would appear to not work very well.

-Scott

[lazyleopard]

I would think that the CDD camera manufacturer would attempt to keep this number down otherwise the camera would be look more like a CMOS camera. So if the camera has a shutter speed of 1/100000 second but only for a single field then any moving ojbect would blur and it would appear to not work very well.

When you're viewing a moving image on a TV screen you're seeing the individual half-frames in sequence. Faster shutter speeds just make the motion more fluttery, since we're used to seein motion as blur, but with the fast shutter speeds we see crisp images. The interlacing only becomes an issue when you freeze the frame.

I've had a closer look at some of my interlace-mismatch images from cameras that get closer views of people. Lets assume a person is stolling along at one mile per hour, nice and slow. That's 1760x3x12=63360 inches per hour, 1056 inches per minute, 17.6 inches per second. If the interlace error we see is only down to the motion between two half-frames then we'd expect to see 0.352 inches of mis-match for PAL at 50fps, or 0.293 inches of mis-match for NTSC at 60fps.

People usually walk faster than 1 mile an hour, and the accepted speed for a brisk walk is about 4 miles per hour, so that could produce an interlace error of a bit over an inch between half-frames. Now, walking motion isn't smooth, so sometimes we'd expect to see interlace mismatchs a bit more than this.

I've looked at frames of people walking up to my door to press the door-bell. They walk past a camera that is a few feet from them and looking slightly down. I typically see mismatces between a quarter of an inch and a couple of inches at their ears. This seems to fit with my suspicion that I'm seeing interlace mismatches caused by the motion that happens between the half-frames.

[maclellan]

Yes lazy,

That all makes sense. The calculations also make sense. I would like to know exactly how my security camera captures the frame - unfortunately it doesnt come with too much detail in the manual.

Lets assume what you said is occuring and the camera captures the odd field within the shutter time. Say the camera's shutter speed is 1/10000 sec then it would have to process a single field in 10 microseconds or so. This implies that the digitized pixel data has to be queued in memory regardless to allow generation of the ntsc signal over the 16 mSec period. The camera waits for the even field and 16 mSec later it processes the data in another 10 uSec. Fast moving objects should show up as a blur in a surveillance monitor. I would expect to get the results in ZM as you illustrated and I see.

Now lets say camera manufacturer just immediately processes and stores both fields queued in double the memory. This would take 20 uSec and all the pixel data for a frame would just sit in memory until it gets sent out in the NTSC frame or 32 mSec max. The result would be very little or no interlace displacements and a very sharp picture. But for fast moving objects there would be a jerkiness at it moves.

When I conducted the tests with a TV and my good camera I saw what appeared to the the latter. That is I just couldnt see any blurring at all but a jerky motion barely noticeable. In ZM I see very pronounced errors especially when I move the object slowly and vertically. Although the errors are moatly noticable on vertcal edges a closer look shows that sometimes the lines pass right through the object.

A good frame mode camera would be a definitive test as it has a similar goal that is to minimize the differences between fields. I'm trying to find one. If you have any ideas who offer this I would be interested in knowing.

Thanks,

Scott

[lazyleopard]

If the camera takes one frame and then uses it to transmit both odd and even half frames before going on to capture the next full frame then we shouldn't see any interlace errors. The kinds of cameras I'm using appear to capture a new frame between each half-frame, though.

Good hunting.