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 [email protected] http://lists.saillard.org/mailman/listinfo/pwc
