Resolution and image clarity

[lazyleopard]

I've got a camera feeding into zm via a Bt878 card. The card is apparently capable of:

Maximum Width: 924
Maximum Height: 576

However, to get the frame ratio right, 768x576 would appear to be the maximum practical size.
The camera I'm using is a standard PAL camera, so the 768 horizontal is over-optimistic, but
the 576 seems to get two halves of an interlaced frame fairly well. As happens with an interlaced
frame, moving objects often appear doubled. Not so good if you want to identify them....

576x432 would seem to make the most of the available horizontal resolution, but makes a mess
of the vertical resolution. Again, not wonderful if you want to identify moving objects.

The usual recommendation seems to be to use 384x288, which slightly under-uses the camera's
horizontal resolution, but takes a non-interlaced frame, thus avoiding the double-imaging of moving
objects, but at the cost of some loss of resolution.

What image size is most likely to give the best images for identifying a moving object on a set-up like this?

[zoneminder]

Hi Rick,

I think the 384x288 is probably the most optimum setup. If you're getting interlaced images then it's effectively two images stuck together, taking up four times the space for no additional information. I would also think this is is plenty for most identification purposes. Other than that I'm not really an expert in video standards or processing.

Cheers,

Phil,

[lazyleopard]

Yes, I figure that's correct when the target is moving. The interlaced image does double the vertical axis resolution because the lines on even and odd frames are interlaced, but the frames are 1/50th of a second apart, so moving objects get doubled. If the target stays still for long enough to avoid the doubling then the resultant picture will be better, but most times that's not the case. :/

[masatj]

Is there no way to resolve the interlacing issue? I don't remember seeing any interlacing artifacts when using a win32 video security program that came with my 4 input (one chip) card. The highest resolution supported by the win32 software/driver was only 640x480, and it had a peculiar way of switching inputs. Rather than capturing 1 frame per input per cycle, it would capture 2 frames. Could that be one of the ways it avoided interlacing problems? The pause between frames didn't seem much longer than with zoneminder's 1 frame/cycle. Here's the card I purchased (cheapest one I could find here in .cz for $100): http://www.provideo.com.tw/PV140VPRO.htm

[zoneminder]

I can't be sure, but I don't know if there's much you can do in software, other than in the driver perhaps. As I understand it, the interlacing artifacts are because effectively the card _has_ captured two frames, and interlaced them to join them together. The only way I can think of resolving this is either to capture only up to the maximum resolution it can capture in one go, or capture slowly enough that it thinks it has enough time to get the whole lot in one go, though whether that it possible i don't know.

When using your card , do you still get interlacing with only one input used? Switching only occurs if multiple inputs are used so if you see it with one input only then it's not a switching issue. There are all sorts of secondary issues with conversion of 400 odd video lines into computer standard pixel dimensions to consider as well. I will see if I can find out anything further.

Phil,

[masatj]

Not sure when I'll get a to try your suggestion...probably early next week...I'll post the results then.

[masatj]

It didn't help...although I might not have tested it thoroughly enough...I left one camera on Modect and walked in front of it...but zonemidner didn't capture anything...which is a pity because it was doing around 25 fps and I haven't seen anything captured at that speed yet...rather than trying to walk in front of that camera again (yeah I'm lazy) I turned it off and turned on a street camera hoping that a car would pass by soon...funny thing is that the street camera was only able to do around 2.5 fps which is the average if all 4 cameras are on...and on the first capture I saw interlacing artifacts so I proceeded to downgrade the resolution on all the cameras to 384x288 =[

[zoneminder]

Hi Jan,

I have found some reference to de-interlacing algorithms which I am going to try and track down and see how feasible they are to implement on the fly. So that may help the interlacing issue. You other problems about no motion detection are something else, what are the zone settings on the camera you walked in front of?

Phil,

[masatj]

zone settings were default...but I think the problem was that zoneminder wasn't done updating the resolution yet...and zmc wasn't ready to do motion detection/capture yet...I also noticed that a black image was captured on some of the cameras when switching resolutions.

[lazyleopard]

I've a suspiscion that some of the more noticable interlace errors (where stationary objects get cut up) occur when one bt8x8 chip is being switched between two or more channels. Sometimes the image that's grabbed seems to have the interlaced lines swapped. Doesn't seem to happen when the input's only using one channel, and doesn't always happen when there're two or more. I'm experimenting with grabbing and discarding a frame or two before passing one on for analysis. It'll cut the frame rate but if it does reliably improve the clarity of interlaced images then I can live with the reduced rate.

[lazyleopard]

...and a week's worth of images would tend to suggest that interlace errors are greatly reduced by grabbing and discarding a frame or two before passing one on for analysis where one BT8x8 chip is serving more than one monitor.

[zoneminder]

I have been toying with the idea of adding an optional 'de-interlace' monitor setting where each image would be split into two, each made up of alternate lines, doubled in height and then this would be treated as two images. I'm not sure if it has any value though as you could probably just reduce the image size and get double the frame rate, for the same effect, apart from the enhance vertical resolution.

Thoughts?

[lazyleopard]

Not something I think I'd use, as the highest frame-rate I'm asking of any of my monitors at the moment is 4fps, and that's at a non-interlaced resolution anyway.

The interlacing errors I was getting can be seen if you compare these two equivalent bits from images captured by one of my garden cameras:
This is a bad image, while this is a good one.

The errors seem to happen when one BT8x8 is switched between two or more inputs, and persist only for a frame or two. I'm currently running with a patched version of zm_local_camera which discards two frames after a camera switch. Some point I'll try discarding only one to see whether that works as well.

[lazyleopard]

I've put my patch into the user contributions section - it's based on 1.19.1 (not 1.18.x as this thread's location implies).

I also played with small bits of a couple of images where there's a fast-moving target, using a sub-optimal way to extract the half-frames:

interlaced one half-frame the other half-frame

interlaced one half-frame the other half-frame

The 1/50th separation could be interesting - and maybe even useful for spotting relatively fast-moving objects.

[jameswilson]

sorry to resurrect this one, but it is something id like to be able to do. Im assuming that the card is the limitation here and not zm. The interlace problem i have is not due to switching as i currently have only 1 cam. I have read elsewhere about using a camera that outputs a non interlaced signal, i therefore assume this would solve problem and resolution could be taken as high as hard disks and capture cards allow. Im also curious why this doesnt affect our tv, is it because the image is constantly moving, picked up interlaced, recorded interlaced, transmitted interlaced and viewed interlaced. So now im curious as to how my sky+ manages? Also following the previous argument that anything moving faster than 1/50th socond causes it, why doesnt then image bend. ie whole camera moves right the first line is spot on but subsequent lines are slightly out (if that makes sense).

James