On Tue, Nov 23, 2004 at 08:52:22AM +0100, Vojtech Pavlik wrote: > On Tue, Nov 23, 2004 at 01:09:15AM +0100, Luca RIsolia wrote: > > > > > 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 ;) > > > > At the moment, V4L1 does not support the Bayer format. I think the > > "ovcamchip" module still needs to output in YUV format by default, while > > providing the Bayer format as an option, otherwise V4L1 drivers depending > > on ovcamchip will stop working. > > Ok, so you're suggesting both to keep the Bayer decoding and output in > YUV ...
For some reasons I thought ovfx2 used the "ovcamchip" module like other
modules in the ov511 package do.
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.
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. 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.
> > > (I'll have to do this, since the robot needs every CPU cycle it can get,
> > > and cannot waste them on video frame copying.)
> >
> > We all want every CPU cycle we can get, so we should really avoid
> > convertions in kernel space :)
> >
> > > 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.
> >
> > 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_.
> I want BGR24 as an option in addition to the default raw BGGR8.
>
> > > Interesting. For my robotics project I simply flipped the camera and
> > > removed the software flip implementation altogether.
> >
> > To preserve the R,G or B origin in the output from the image sensor,
> > you should shift the active pixel area (w=2a,h=2b) one pixel in the
> > appropriate direction.
>
> 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.
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.
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)
Regards,
Luca Risolia
pgpoeRfwM1P5q.pgp
Description: PGP signature
