On Tue, Nov 23, 2004 at 11:44:54AM +0100, Luca Risolia wrote: > For some reasons I thought ovfx2 used the "ovcamchip" module like other > modules in the ov511 package do.
It uses that module, yes. > However facts still remain. I only hope you won't include color > conversions before submitting the driver to the mainline kernel, > be "ovcamchip" used or not as i2c_driver for the OV image sensors. The driver doesn't contain any _color_ conversions at this moment. It contains a geometry conversion from SBGGR8 to BGR24. It doesn't convert into YUV. The fact that the camera contains an OmniVision sensor and the fact that it uses the ovcamchip module don't imply that the camera can do YUV in hardware. > So I repeat: V4L1 does not support Bayer SBGGR8, but does support YUV's. > Since colorspace conversions are not allowed, this means that you will > have to use native YUV as default format sent by the OV sensor. The sensor in this camera doesn't output YUV. It outputs its native SBGGR8 data. > In case the driver supports V4L2 as well, you could add raw-SBGGR8 as > an optional format and let the user applications asking for it and do > the conversions. Yes, it does support V4L2. Yes, I'm planning direct SBBGR8 output. > > > This is not the best approach. Apart from the disadvantages in terms > > > of performance, no applications will be ever patched if colorspace > > > convertions are done in kernel-space. So I suggest that you fix your > > > applications or libraries. > > > > ... and to remove the Bayer decoding and output in BGGR8 only? > > > > Well, the driver won't be able to output in YUV, since that'd require > > a real colorspace conversion. At this time it's giving output in BGR24, > > converted from BGGR8. > > This's actually false. OV sensors support both YUV and raw RGB _natively_. The sensors do. The USB bridge implemented by the Cypress EzUSB FX2 chip necessarily doesn't. It might, though. But it hasn't been done before. Even under Mac/Win it uses the SBGGR8 mode. > > I can't. The camera is sending 640x480 pixels out. If I shifted the > > active area I'd get a non-standard (smaller) image size. I'll see > > whether the image size being sent could be increased or shifted in HW, > > because the sensor size is a little larger, but I seriously doubt it - > > the window registers seem to be ignored in raw mode. > > I was talking about "shifting" (or panning), not "resizing". OV > sensors provide both the features. In YUV mode only. That's what I'm to trying to say. In this camera the chip is working in raw RGB mode (only). > As I said, before flipping the image, to preserve the correct > R,G or B origin, program the preferred active pixel area and > move it within the full array boundary. If I remember well, > OV7620 has one pixel shift register for this purpose. It doesn't seem to work in RGB mode. I may be doing something wrong, though. > An other solution is to obtain the same result through the USB > controller directly, by programming the number of pixel[lines] > clocks to ignore[accept] after each H-Sync[V-Sync] (I think > all the PC Camera controllers can be programmed this way) The FX2 is rather undocumented, so this is not an option. -- 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
