Messages in this thread | | | Subject | Re: [patch] autogain support for bayer10 format (was Re: [patch] propagating controls in libv4l2) | From | Ivaylo Dimitrov <> | Date | Thu, 27 Apr 2017 08:52:21 +0300 |
| |
On 27.04.2017 01:51, Pavel Machek wrote: > Hi! > >>>> There are two separate things here: >>>> >>>> 1) Autofoucs for a device that doesn't use subdev API >>>> 2) libv4l2 support for devices that require MC and subdev API >>> >>> Actually there are three: 0) autogain. Unfortunately, I need autogain >>> first before autofocus has a chance... >>> >>> And that means... bayer10 support for autogain. >>> >>> Plus, I changed avg_lum to long long. Quick calculation tells me int >>> could overflow with few megapixel sensor. >>> >>> Oh, btw http://ytse.tricolour.net/docs/LowLightOptimization.html no >>> longer works. >>> >>> Regards, >>> Pavel >>> >>> diff --git a/lib/libv4lconvert/processing/autogain.c b/lib/libv4lconvert/processing/autogain.c >>> index c6866d6..0b52d0f 100644 >>> --- a/lib/libv4lconvert/processing/autogain.c >>> +++ b/lib/libv4lconvert/processing/autogain.c >>> @@ -68,6 +71,41 @@ static void autogain_adjust(struct v4l2_queryctrl *ctrl, int *value, >>> } >>> } >>> >>> +static int get_luminosity_bayer10(uint16_t *buf, const struct v4l2_format *fmt) >>> +{ >>> + long long avg_lum = 0; >>> + int x, y; >>> + >>> + buf += fmt->fmt.pix.height * fmt->fmt.pix.bytesperline / 4 + >>> + fmt->fmt.pix.width / 4; >>> + >>> + for (y = 0; y < fmt->fmt.pix.height / 2; y++) { >>> + for (x = 0; x < fmt->fmt.pix.width / 2; x++) >> >> That would take some time :). AIUI, we have NEON support in ARM kernels >> (CONFIG_KERNEL_MODE_NEON), I wonder if it makes sense (me) to convert the >> above loop to NEON-optimized when it comes to it? Are there any drawbacks in >> using NEON code in kernel? > > Well, thanks for offer. This is actualy libv4l2. >
Oh, somehow I got confused that this is kernel code :)
> But I'd say NEON conversion is not neccessary anytime soon. First, > this is just trying to get average luminosity. We can easily skip > quite a lot of pixels, and still get reasonable answer. > > Second, omap3isp actually has a hardware block computing statistics > for us. We just don't use it for simplicity. >
Right, I forgot about that.
> (But if you want to play with camera, I'll get you patches; there's > ton of work to be done, both kernel and userspace :-).
Well, I saw a low hanging fruit I thought I can convert to NEON in a day or two, while having some rest from the huge "project" I am devoting all my spare time recently (rebasing hildon/maemo 5 on top of devuan Jessie). Still, if there is something relatively small to be done, just email me and I'll have a look.
Regards, Ivo
| |