Hi Hans, Nice to have your feedback! My comments are inlined.
2008/11/6 Hans de Goede <[EMAIL PROTECTED]>: > Hi All, > > Erik Andrén wrote: > > <snip> > >>> Here is what I like to see implemented in libv4l: >>> >>> 1. All the various bayer format conversion (starting byte can be blue, >>> green or red) to RGB > > Already done. > >>> 2. YCrCb to RGB and vice-versa format convertion > > Already done. > >>> 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. > libv4l does currently handle cropping of sif resolution to 1/2 vga, 356x288 > -> 320x240 because of one much used app (skype) only accepting 320x240, and > several other apps assume 320x240 and need to be told explicitly if the cam > cannot handle this (atleast spcaview suffers from this). I'm all for it. I've always thought that the device driver should only expose the features that the H/W is capable of and avoid emulating the extra functionality in the kernel. >>> 4. Efficient auto white balacing > > This is being worked on Would you please tell us the algorithm you're using for this? Any references? >>> 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. 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. >>> 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). > What is planned is adding normalization, which will correct small exposure > errors. > >>> 8. Gamma correction > > I fail to see how this differs from whitebalance. These are two different concepts. Gamma correction is meant to correct the sensor/screen gamma bias and it's something that most users usually neglect. Generally speaking, if you're doing your own bayer decode, then you should apply a gamma correction. Some bridges (like the m5603c) can do this in H/W by configuring a gamma ramp. White balancing is about normalizing the whole picture pixels against a reference white point. >>> 9. JPEG decompression > > Already implemented Is it standard? I mean the processing. Maybe we can have some comments from Willem. >>> 10. All this both in two flavors, plain C (for compatibility) and >>> highly optimized platform-dependent, assembler code. > > Currently there have not been any performance problems yet, optimization is > something which one should only spend time on when its needed. And even then > using assembler often is not the answer. I've seen a 300% performance increase for an IDCT written using the MMX instructions. We can gain a lot in terms of performance from the vector instructions. It's not about assembler only, we can use the built-in intrinsics too. >>>>> 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? Regards, Ilyes Gouta. > not need it and on things like tvcards. This takes some thinking and design, > and I've been a little low on time for working on libv4l lately. Your > patches are on my radar, really they are. >>>>>> And... Hans probably isn't proponent for evade bugs of other >>>>>> applications in library. > > Indeed I'm not, it has taken me a few nights sleeping over it before I added > cropping code to make skype work. > > > 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
