Re: 3A / auto-exposure Region of Interest setting

2016-12-21 Thread Hans Verkuil

On 21/12/16 14:56, Guennadi Liakhovetski wrote:

...one more issue to clarify - how to report compound controls with
control events, which also until now only support 32- and 64-bit integers.


For compound controls you can only get an event, not what the new values
are. So you would have to call VIDIOC_G_EXT_CTRLS to obtain the new value.

Regards,

Hans



Thanks
Guennadi

On Wed, 21 Dec 2016, Guennadi Liakhovetski wrote:


Hi Laurent,

On Tue, 29 Nov 2016, Laurent Pinchart wrote:


Hi Guennadi,

(CC'ing Sakari)

On Monday 28 Nov 2016 15:18:03 Guennadi Liakhovetski wrote:

Hi,

Has anyone already considered supporting 3A (e.g. auto-exposure) Region of
Interest selection? In UVC this is the "Digital Region of Interest (ROI)
Control." Android defines ANDROID_CONTROL_AE_REGIONS,
ANDROID_CONTROL_AWB_REGIONS, ANDROID_CONTROL_AF_REGIONS. The UVC control
defines just a single rectangle for all (supported) 3A functions. That
could be implemented, defining a new selection target. However, Android
allows arbitrary numbers of ROI rectangles with associated weights. Any
ideas?


Selections could be used, possibly with an update to the API to allow indexing
selections for a given target. We'd be missing weights though. Another option
would be to use compound controls.


I talked to Hans online and he is in favour of a compound control for ROI
as well, which is also fine with me. Working on an implementation I
realised, that struct v4l2_query_ext_ctrl has min, max, step and default
values as 64-bit fields, which isn't enough for ROI. Shall they all be
replaced with unions of original values and pointers? As long as pointers
don't exceed 64 bits, we'll stay binary compatible. Or do we use those
fields similar to the STRING type to specify min, max, default number of
ROIs and a size of one ROI in step? I guess we should go with the latter.

Thanks
Guennadi


--
Regards,

Laurent Pinchart





--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 3A / auto-exposure Region of Interest setting

2016-12-21 Thread Hans Verkuil

On 21/12/16 12:05, Guennadi Liakhovetski wrote:

Hi Laurent,

On Tue, 29 Nov 2016, Laurent Pinchart wrote:


Hi Guennadi,

(CC'ing Sakari)

On Monday 28 Nov 2016 15:18:03 Guennadi Liakhovetski wrote:

Hi,

Has anyone already considered supporting 3A (e.g. auto-exposure) Region of
Interest selection? In UVC this is the "Digital Region of Interest (ROI)
Control." Android defines ANDROID_CONTROL_AE_REGIONS,
ANDROID_CONTROL_AWB_REGIONS, ANDROID_CONTROL_AF_REGIONS. The UVC control
defines just a single rectangle for all (supported) 3A functions. That
could be implemented, defining a new selection target. However, Android
allows arbitrary numbers of ROI rectangles with associated weights. Any
ideas?


Selections could be used, possibly with an update to the API to allow indexing
selections for a given target. We'd be missing weights though. Another option
would be to use compound controls.


I talked to Hans online and he is in favour of a compound control for ROI
as well, which is also fine with me. Working on an implementation I
realised, that struct v4l2_query_ext_ctrl has min, max, step and default
values as 64-bit fields, which isn't enough for ROI. Shall they all be
replaced with unions of original values and pointers? As long as pointers
don't exceed 64 bits, we'll stay binary compatible. Or do we use those
fields similar to the STRING type to specify min, max, default number of
ROIs and a size of one ROI in step? I guess we should go with the latter.


For compound controls it is currently possible to get the default value
(see the VIDIOC_G_EXT_CTRLS, the documentation for the 'which' field).

This can be extended to MIN/MAX/STEP if needed.

Regards,

Hans



Thanks
Guennadi


--
Regards,

Laurent Pinchart



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 3A / auto-exposure Region of Interest setting

2016-12-21 Thread Guennadi Liakhovetski
...one more issue to clarify - how to report compound controls with 
control events, which also until now only support 32- and 64-bit integers.

Thanks
Guennadi

On Wed, 21 Dec 2016, Guennadi Liakhovetski wrote:

> Hi Laurent,
> 
> On Tue, 29 Nov 2016, Laurent Pinchart wrote:
> 
> > Hi Guennadi,
> > 
> > (CC'ing Sakari)
> > 
> > On Monday 28 Nov 2016 15:18:03 Guennadi Liakhovetski wrote:
> > > Hi,
> > > 
> > > Has anyone already considered supporting 3A (e.g. auto-exposure) Region of
> > > Interest selection? In UVC this is the "Digital Region of Interest (ROI)
> > > Control." Android defines ANDROID_CONTROL_AE_REGIONS,
> > > ANDROID_CONTROL_AWB_REGIONS, ANDROID_CONTROL_AF_REGIONS. The UVC control
> > > defines just a single rectangle for all (supported) 3A functions. That
> > > could be implemented, defining a new selection target. However, Android
> > > allows arbitrary numbers of ROI rectangles with associated weights. Any
> > > ideas?
> > 
> > Selections could be used, possibly with an update to the API to allow 
> > indexing 
> > selections for a given target. We'd be missing weights though. Another 
> > option 
> > would be to use compound controls.
> 
> I talked to Hans online and he is in favour of a compound control for ROI 
> as well, which is also fine with me. Working on an implementation I 
> realised, that struct v4l2_query_ext_ctrl has min, max, step and default 
> values as 64-bit fields, which isn't enough for ROI. Shall they all be 
> replaced with unions of original values and pointers? As long as pointers 
> don't exceed 64 bits, we'll stay binary compatible. Or do we use those 
> fields similar to the STRING type to specify min, max, default number of 
> ROIs and a size of one ROI in step? I guess we should go with the latter.
> 
> Thanks
> Guennadi
> 
> > -- 
> > Regards,
> > 
> > Laurent Pinchart
> > 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 3A / auto-exposure Region of Interest setting

2016-12-21 Thread Guennadi Liakhovetski
Hi Laurent,

On Tue, 29 Nov 2016, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> (CC'ing Sakari)
> 
> On Monday 28 Nov 2016 15:18:03 Guennadi Liakhovetski wrote:
> > Hi,
> > 
> > Has anyone already considered supporting 3A (e.g. auto-exposure) Region of
> > Interest selection? In UVC this is the "Digital Region of Interest (ROI)
> > Control." Android defines ANDROID_CONTROL_AE_REGIONS,
> > ANDROID_CONTROL_AWB_REGIONS, ANDROID_CONTROL_AF_REGIONS. The UVC control
> > defines just a single rectangle for all (supported) 3A functions. That
> > could be implemented, defining a new selection target. However, Android
> > allows arbitrary numbers of ROI rectangles with associated weights. Any
> > ideas?
> 
> Selections could be used, possibly with an update to the API to allow 
> indexing 
> selections for a given target. We'd be missing weights though. Another option 
> would be to use compound controls.

I talked to Hans online and he is in favour of a compound control for ROI 
as well, which is also fine with me. Working on an implementation I 
realised, that struct v4l2_query_ext_ctrl has min, max, step and default 
values as 64-bit fields, which isn't enough for ROI. Shall they all be 
replaced with unions of original values and pointers? As long as pointers 
don't exceed 64 bits, we'll stay binary compatible. Or do we use those 
fields similar to the STRING type to specify min, max, default number of 
ROIs and a size of one ROI in step? I guess we should go with the latter.

Thanks
Guennadi

> -- 
> Regards,
> 
> Laurent Pinchart
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 3A / auto-exposure Region of Interest setting

2016-11-29 Thread Laurent Pinchart
Hi Guennadi,

(CC'ing Sakari)

On Monday 28 Nov 2016 15:18:03 Guennadi Liakhovetski wrote:
> Hi,
> 
> Has anyone already considered supporting 3A (e.g. auto-exposure) Region of
> Interest selection? In UVC this is the "Digital Region of Interest (ROI)
> Control." Android defines ANDROID_CONTROL_AE_REGIONS,
> ANDROID_CONTROL_AWB_REGIONS, ANDROID_CONTROL_AF_REGIONS. The UVC control
> defines just a single rectangle for all (supported) 3A functions. That
> could be implemented, defining a new selection target. However, Android
> allows arbitrary numbers of ROI rectangles with associated weights. Any
> ideas?

Selections could be used, possibly with an update to the API to allow indexing 
selections for a given target. We'd be missing weights though. Another option 
would be to use compound controls.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


3A / auto-exposure Region of Interest setting

2016-11-28 Thread Guennadi Liakhovetski
Hi,

Has anyone already considered supporting 3A (e.g. auto-exposure) Region of 
Interest selection? In UVC this is the "Digital Region of Interest (ROI) 
Control." Android defines ANDROID_CONTROL_AE_REGIONS, 
ANDROID_CONTROL_AWB_REGIONS, ANDROID_CONTROL_AF_REGIONS. The UVC control 
defines just a single rectangle for all (supported) 3A functions. That 
could be implemented, defining a new selection target. However, Android 
allows arbitrary numbers of ROI rectangles with associated weights. Any 
ideas?

Thanks
Guennadi
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html