On Mon, Nov 22, 2004 at 09:20:40AM -0800, Mark McClelland wrote: > (still catching up on my email, sorry about that...)
I have approximately 800 unanswered e-mails in my inbox, so I can understand that pretty well. ;) > >The attached patch: > > > > * Replaces the BGBR decoding with Bayer decoding, which is > > correct for this type of camera. It uses a mix of bilinear > > and nearest-neighbor approaches, which is fast and simple. > > This seems like the best overall approach. I tried a full-quality Bayer > decoder before, but it was noticeably slower. > > Since format conversion is generally not allowed in the kernel anymore, > I'll probably have to remove it eventually. No great loss though; the > code should work just as well from userspace ;) In my opinion the URB transfer buffers should be mmap()able to userspace to avoid all the extra copying, which eats quite a lot of CPU time (namely at 60 Hz). This should be possible, because the V4L2 interface has a V4L2_PIX_FMT_SBGGR8 format, which the camera is if I recall correctly able to generate directly. (I'll have to do this, since the robot needs every CPU cycle it can get, and cannot waste them on video frame copying.) However, I believe a simple Bayer decoding implementation (like mine) should be included in the kernel driver, since only GnomeMeeting so far supports Bayer decoding in userspace. > > * Uses the QVGA60 bit to turn the interlaced mode into a > > progressive mode with half the data (the correct amount - > > 640x480 bytes, which is the number of pixels the camera has), > > and twice the framerate. > > Nice job. To be honest, I never realized that this could work at > 640x480. I tried this in ov511 once but the camera froze up completely, > which I assumed to mean that QVGA60 only supports QVGA resolution. It > was more likely due to timing or memory limitations of the OV511. It supports the full VGA resolution in raw mode only. What the bit does is that it only disables the "+1 scanline offset" effect in the odd fields. > > * Suggests using "clockdiv=0" to achieve 60 Hz framerate. > > I agree that the default should be 30 Hz for now. Some hosts might not > be able to handle more data than that reliably (the camera has no frame > buffer, so frames get corrupted if the host can't keep up). I encourage > people to test 60 Hz though. 30 Hz (or 25 in Europe) is a good compromise between bandwidth and video smoothness. But 50/60 Hz looks real cool, and is very useful for robotics for example. > > * Disables all kinds of image enhancement options which are > > OK for YUV mode, but disturb raw RGB mode. > > These look correct, though I'll have to take a closer look at some of > them. The Windows driver uses the default values for digital and analog > sharpness, for example (that's not to say that it's correct). Please do check them. I'm most unsure about the white balance and auto brightness settings, the picture looks quite dim to me with my patch. Also, do you have some (at least sketchy) information about the FX2's registers? It seems to me that the set register command simply overwrites the variables of the program running in the FX2. One thing that confuses me is that the FX2 seems to work with the default setting in all different modes I programed the OV chip into, and another is that some of the registers seem to be called "contrast" and "brightness", while those probably can't do anyhthing, since the FX2 doesn't touch the data, it's using its high-performance FIFO/DMA engine for that. > > * Enables RGB matrix reweighing, since the colors "seep" into > > each other and this undoes that effect. > > You're right, that should have been enabled. AFAICT it should only be > disabled for monochrome sensors. I'm still not completely sure about this, since the matrix should be applied after the Bayer decoding in theory. But it seems to work well this way, too. > > * Removes the hardware image flip, since I was too lazy to > > recompute all the Bayer decoding for a mirrored image. > > I read somewhere that there's an undocumented vertical flip bit. It > probably doesn't correct the Bayer order though. I'll have to > investigate further. Interesting. For my robotics project I simply flipped the camera and removed the software flip implementation altogether. > >All in all, it gives you a very nice smooth image with a very good > >(30 Hz or 60 Hz) framerate. > > > >Please test it, and if you're inclined to, merge into your ov511 > >driver suite. > > > >By the way, I'd like to see the ovfx2 merged into the 2.6 kernel, do you > >think it's a good idea now that it works rather well? > > Yes, it's looking almost good enough to merge. I have some cleanups to > do first, but I'll try to get a patch out within a few weeks. I'll be looking forward to that. I've done some further changes in the direction of including it in the 2.6 kernel, I can send you a bigger patch that contains those changes (mostly killing #ifdef KERNEL_VERSION and making it compile within the kernel.), if you're interested. > Thanks again for your help!! Well, it's scratching _my_ itch. ;) -- Vojtech Pavlik SuSE Labs, SuSE CR ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
