Stephen Crampton wrote: >Mark, > >A few additional questions: > > > >>The Windows driver supports compression, which allows for a much higher >>frame rate. The Linux driver does too, but you'll need to get the latest >>stable version (1.62) from http://alpha.dyndns.org/ov511/ . After >>compiling the driver, you need to: >> >>insmod ov511.o compress=1 >>insmod ov511_decomp.o >> >>Then check dmesg. If the driver reports that your camera has an OV7620 >>sensor, you should be able to get 30 FPS at up to 352x288, and 10-15 FPS >>at 640x480. If it says you have something else, the frame rate may be lower. >> >> > >FYI, dmesg reports a USB OV511+ video device found, "Sensor is an OV7620." > >When I use the compression as you suggest, there are faint, but noticeable >squares throughout the image. They look like artifacts of the compression >scheme. >
Correct. The quantization that's done during compression causes those artifacts. The blocks are 8x8 for the Y channel and 16x16 for the U/V channels. > Are there options that affect how the compression is done? I >would be willing to trade frame rate for image quality. > There are some options in registers 0x70 - 0x77, but I'm not quite sure what they do, if anything. Your best option is probably to upload a different quantization table. This is defined in ov511.h. It's also defined in the DeZigZag section of ov511_decomp.c, as crude bit-shifts. In fact, rewriting the dequantization code as a loop that multiplies image elements by their corresponding quantization table elements would probably improve the image quality a bit, at the expense of decompression speed. Decreasing the quantization values will result in less image information being lost. >If I could >achieve a consistent 15 fps with decent image quality, I would be >satisfied. Currently, I'm getting a highly variable frame rate that jumps >between about 20 to 37 fps (the rate is measured each frame so it reflects >the time between the current and previous frames). > > Unfortunately, I don't think there's any way around that, other than by dropping frames (either in the camera or in your app). Since the data are compressed with a fixed quantization table, the compressor can't auto-adjust the compression level to maintain a constant frame rate. Even cameras that can do that don't do it all that well, since it takes at least one frame for the change to take effect. >>The newer drivers (2.01+) and the driver in the 2.5 kernel don't support >>RGB/BGR any more. You might want to capture VIDEO_PALETTE_YUV420P images >>instead, and use the conversion code that's in the 1.62 driver >>(yuv420p_to_rgb()) to do the conversion in user-space. That will work >>with the 1.xx drivers too. >> >> > >Do you mean to say that the RGB format is supplied by the driver? > In 1.62, yes. In 2.xx, no. That functionality was intentionally removed. >I thought that was the native mode of the hardware. > The OV7620 can output the image data as GBR 4:2:0, but that's a pretty awkward format to support. Neither V4L nor V4L2 (nor any existing app / file format) supports it, so I use YUV 4:2:0 instead. Converting YUV to RGB isn't difficult at all, especially in user-space, so this doesn't cause much of a problem. > Also, I thought I heard >somewhere that there were video cameras that perform compression on the >CCD chip itself, in parallel, much more efficiently than in software. > > I haven't heard of that. Not sure of how it would work, but sounds interesting. >I'm doing research in computer vision, and I would prefer that technical >issues, such as acquisition of images, take as few resources as possible. > >What I'm getting at is, What's the most efficient way of doing things that >would be forward compatible? Is YUV420P the native mode of the >chip? Given my requirements, would that be your recommendation? > > YUV420P is the most forward-compatible, since it's the only non-greyscale format that the driver in the 2.5 supports now. It's also more convenient since your algorithm could drop the U/V data if it noticed high system load or that it was getting too lagged. >Also, the image freezes briefly every so often. Do you have >recommendations for how to keep the frame rate more or less constant? I >have implemented the double-buffering you suggested. I tried implementing >a frame queue, but I think it adds a lot of overhead as well as a time >lag. Since I'm interesting in using video input to control the computer, >I would prefer to minimize the time lag. > > I suspect the lag is caused by some process taking more than its fair share of CPU time. The preemptive and low-latency kernel patches may help, as well as increasing your process's priority. >One other point regarding compression and image quality. From my >standpoint, the important issue is consistency from frame to frame, so I >can, e.g., track objects. I use brightness (e.g., grayscale images) for >most of my routines, but sometimes I am interested in color (e.g., skin >color). If I could get much better performance, I might opt for grayscale >images from the camera. (This would be pointless, however, if the camera >always sends color and the driver merely converts the images to >grayscale.) > > If your app selects VIDEO_PALETTE_GREY, the camera will be programmed to send greyscale data only. This results in a noticable frame rate improvment. Unfortunately that feature wasn't working with the OV7620 last time I checked, but I can try to fix it if you need it. >Like I said previously, I don't need 30fps, but 4 fps is a bit low. >Somewhere in the middle would be ideal. > > I hate to say it, but for this type of application, a USB camera is never going to work all that well. USB 1.1 simply doesn't have very much bandwidth, nor do most CMOS-based USB cameras have very good image quality. Your best bet might be to get a cheap PCI Bt8xx frame grabber card and a decent CCD camera. That said, I'm willing to help you get your current setup working as best I can. Let me know if you have any further questions. -- Mark McClelland [EMAIL PROTECTED] _______________________________________________ Video4linux-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/video4linux-list
