On Fri, Jan 27, 2006 at 10:58:16PM +0100, matthieu castet wrote:
> Hi Luc,
>
> > I don't like the output of the image and plan to add
> > better algorithm (but use more cpu times,memory) before releasing this
> > version.
> I don't know if you know the algorithm used in qastrocam [1].
No but i look at it tomorrow.
> Unfortunaly it doesn't seem to works on my computer (I got a B&W
> picture), that's why I ask if Bayer mode was supported in pwc-current
> (10.0.11).
The bayer mode is returned in the same compressed format as the YUV420
format. So if you don't have the decompressor in the kernel, you can't use
*directly* this format. But the raw stream exported by the kernel
V4L2_PIX_FMT_PWC2 contains enough information to uncompressed this image from
the userland. This why I've add the bayer mode in libpwc and not in the
driver (and don't plan to add it).
When I talk about the current driver, I talk about the lastest snapshot (not
the last release). Snapshots of the driver is available on the website.
Release is just a snapshot after some months, or to keep in sync with the
lastest kernel.
I prefer to made the decompressor in userland for this reason:
- It's easier to debug the library, modify the code, optimize without
worrying to reboot between each load/unload of the module. Think about
sometimes i didn't write into the image but near ... Oops, panic and BSOD
- For the RealTime kernel, the decompressor takes too much times because,
you lock the cpu. So lantecy, preemption is good unless one driver don't
play fair.
- I can write mmx, sse, ... operations of the decompressor (can't do in the
kernel). For the moment, i don't see how i can speedup the process
(perhaps the clamp function).
- If you want to uncompress only a small part of the image, it's possible,
think about low cpu in a robot, that track only B&W picture, and do not
want to takes times to decode the two other channel.
- You save some space in kernel memory (table, and dynamic array, code
~200kbytes).
Cons:
- Each applications need to known the format. This can be resolv using the
*ONE* v4l library like alsa do for sound project. In Linux video project,
no one have negin to write a library, because every applications have
already the support for most major devices.
- When some driver changes, perhaps the library need to be updated/keep in
sync with applications. Alsa API nightmare (..., 0.5, 0.9, 1.0)
The format of the raw PWC2 stream:
At the beginning of the raw stream, they are a small header (8bytes)
describes in pwc-ioctl.h; this format is valid for the newer pwc (type>680).
As i never finished to write a decoder for the first one ..., the PWC1 is not
used for the moment, and perhaps the stream is different. libpwc read this
header and convert in one function call to a image in YUV420P or RGB24 pixel
format.
> > Note the driver will never export V4L2_PIX_FMT_SBGGR8 because you
> > need to have the decompressor to produce a image at this format.
> So you'll need to add another private format for pwc bayer one ?
I think this format will not be returned by the kernel driver without
declaring a new format. Even if the v4l2 define a new bayer format, i need to
have this decompressor in the kernel.
The bayer format used by the webcam is SRGGB8. The problem is: if you add a
new standard format, you need to provide a method for application to use
this data. The libpwc can do the conversion, you give the buffer returned by
the kernel, the image format wanted (YUV4v20P or RGB24),
At this moment, only the old libpwc is on my site. I need to choose a licence
for the library to be used by any projects. I'll try to release it under a
dual licence BSD and LGPL.
As I have a newer webcam (logitech fusion), i've made my own [m]jpeg
decompressor and perhaps i'll put it in the libpwc too. Perhaps this the
first step for the ONE v4l library. Library have their own problems (API,
ABI, speed, bugs reports, ...)
Luc
_______________________________________________
pwc mailing list
http://lists.saillard.org/mailman/listinfo/pwc
|