Hi, 2008/11/6 Hans de Goede <[EMAIL PROTECTED]>: > Ilyes Gouta wrote: >> >> Hi Hans, >> >> Nice to have your feedback! My comments are inlined. >> >>>>> 3. Fast image resize using bilinear (to scale-down) and lancoz (to >>>>> scale-up) interpolation >>> >>> Not done and not planned, applications should be able to handle any >>> resolution the cam can give (which will vary by cam), and use Xv to scale >>> it >>> to the display resolution they want to use, no need to waste cpu on this >>> if >>> the gpu can do it for you. >> >> I don't think that all applications would want to go through Xv to get >> H/W assisted scaling. For the common application, Xv is much more >> associated to the YUV overlay video rendering than H/W scaling. So, I >> still think that the fast resize feature is interesting to have. > > Actually Xv is about *stretched* overlay rendering, this could be yuv, but > could be rgb too, Xv is all about hardware assisted stretching.
Yeah, still not every dev. would want Xv, what about frame buffer applications? Let's forget X a bit here. >>>>> 4. Efficient auto white balacing >>> >>> This is being worked on >> >> Would you please tell us the algorithm you're using for this? Any >> references? > > Currently I have some students of mine (I'm a CS teacher) looking into this, > sofar they have only tried the make the whole screen perfect gray on average > approach. OK. >>>>> 5. Picture sharpening >>>>> 6. Noise removal through low-pass filtering >>> >>> This is way higher level then what libv4l strives to be >> >> The ALi driver, for Windows, for my m5603c/mt9v011 based webcam does >> this in software. > > The fact that windows, and esp a windows driver does something is a non > argument. > >> Noise reduction/removal is nice to have since the >> bayer steam reflect often the poor quality of the sensors and/or the >> bad lighting conditions. > > Actually nice to have, iow not essential. I'm all for having a library that > does this *on top of* libv4l. Why another library? It doesn't make sense to have another processing pass/loop when you can easily embed it in original transformation pipeline. We can already have noise reduction if we opt to have the resize feature in libv4l. At the end, resizing involves bilinear/lanczos/whatever interpolations which is a form of low pass filtering and thus noise reduction. >>>>> 7. Exposure correction >>> >>> Doing software autoexposure for cams which have an exposure control, but >>> not >>> autoexposure is planned, but I think you mean correcting the initial >>> exposure setting being off, besides that this is impossible if its off >>> far >>> enough, its also fighting a symptom, we should get the exposure settings >>> of >>> the cam right. >> >> No, I meant autoexposure, we can't just fix everything (initial exposure). >> > > Ok, this is planned. > >>>>> 9. JPEG decompression >>> >>> Already implemented >> >> Is it standard? I mean the processing. Maybe we can have some comments >> from Willem. > > It can handle both standard JPEG's (with and without a quantization table, > if its missing it will use the default one) and special custom JPEG formats > (currently only Pixart JPEG). Very cool. What standard did you base your code upon? Any references? >>>>>>> On Wed, Nov 5, 2008 at 10:40 PM, Lukáš Karas <[EMAIL PROTECTED]> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Ilyes, >>>>>>>> >>>>>>>> maintaining of libv4l is Hans de Goede now. I would like come in to >>>>>>>> develop process >>>>>>>> of this library, but Hans push any patch, that I post him :( >>>>>>>> Yes I know, some my patches wasn't pretty at first... >>>>>>>> >>> Lukáš, sorry about that as I've mailed before and indicated above I'm >>> very >>> much interested in white balance and normalization in software for the >>> cheap >>> cams which do not do this in hardware. But this needs to be done >>> properly, I >>> want things to work out of the box for end users, this means that we need >>> to >>> detect somehow when a cam needs these software auto whitebalance, and >>> then >>> enable it automatically, this also means not enabling it on cams which do >> >> How do intend to do it? By maintaining a list of capabilities for >> every device? How about extending V4L2 do have this information from >> the drivers? > > This is something which has to be decided upon, most likely we will add an > "is webcam" flag to the v4l2 capabilities bitfield, and then if this flag is > set, check for a autowhitebalance v4l2 control, if the cam does not have > that we activate software autowhitebalance (and add a fake autowhitebalance > control to control that, default on). > > For cams which have awb, but where it cannot be turned of, we will still add > an autowhitebalance v4l2 control to the driver to signal this, this control > will then be readonly and always read awb on. > > Atleast that is what was discussed at the Linux Plumbers Conference end > September, and that is the way forward IMHO, feedback on this much > appreciated. I still want to see how libv4l will be embedded properly in the capture flow, i.e between the final application and the kernel and capture device. Using hacks like LD_PRELOAD isn't a long term solution. Alright, good work! Regards, Ilyes Gouta. > Regards, > > Hans > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ M560x-driver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/m560x-driver-devel
