* 3A / auto-exposure Region of Interest setting @ 2016-11-28 14:18 Guennadi Liakhovetski 2016-11-29 18:08 ` Laurent Pinchart 0 siblings, 1 reply; 6+ messages in thread From: Guennadi Liakhovetski @ 2016-11-28 14:18 UTC (permalink / raw) To: Linux Media Mailing List 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 3A / auto-exposure Region of Interest setting 2016-11-28 14:18 3A / auto-exposure Region of Interest setting Guennadi Liakhovetski @ 2016-11-29 18:08 ` Laurent Pinchart 2016-12-21 11:05 ` Guennadi Liakhovetski 0 siblings, 1 reply; 6+ messages in thread From: Laurent Pinchart @ 2016-11-29 18:08 UTC (permalink / raw) To: Guennadi Liakhovetski; +Cc: Linux Media Mailing List, Sakari Ailus 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 3A / auto-exposure Region of Interest setting 2016-11-29 18:08 ` Laurent Pinchart @ 2016-12-21 11:05 ` Guennadi Liakhovetski 2016-12-21 13:56 ` Guennadi Liakhovetski 2016-12-21 14:01 ` Hans Verkuil 0 siblings, 2 replies; 6+ messages in thread From: Guennadi Liakhovetski @ 2016-12-21 11:05 UTC (permalink / raw) To: Laurent Pinchart; +Cc: Linux Media Mailing List, Sakari Ailus, Hans Verkuil 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 3A / auto-exposure Region of Interest setting 2016-12-21 11:05 ` Guennadi Liakhovetski @ 2016-12-21 13:56 ` Guennadi Liakhovetski 2016-12-21 14:04 ` Hans Verkuil 2016-12-21 14:01 ` Hans Verkuil 1 sibling, 1 reply; 6+ messages in thread From: Guennadi Liakhovetski @ 2016-12-21 13:56 UTC (permalink / raw) To: Laurent Pinchart; +Cc: Linux Media Mailing List, Sakari Ailus, Hans Verkuil ...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 > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 3A / auto-exposure Region of Interest setting 2016-12-21 13:56 ` Guennadi Liakhovetski @ 2016-12-21 14:04 ` Hans Verkuil 0 siblings, 0 replies; 6+ messages in thread From: Hans Verkuil @ 2016-12-21 14:04 UTC (permalink / raw) To: Guennadi Liakhovetski, Laurent Pinchart Cc: Linux Media Mailing List, Sakari Ailus 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 >>> >> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 3A / auto-exposure Region of Interest setting 2016-12-21 11:05 ` Guennadi Liakhovetski 2016-12-21 13:56 ` Guennadi Liakhovetski @ 2016-12-21 14:01 ` Hans Verkuil 1 sibling, 0 replies; 6+ messages in thread From: Hans Verkuil @ 2016-12-21 14:01 UTC (permalink / raw) To: Guennadi Liakhovetski, Laurent Pinchart Cc: Linux Media Mailing List, Sakari Ailus 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 >> ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-12-21 14:04 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-11-28 14:18 3A / auto-exposure Region of Interest setting Guennadi Liakhovetski 2016-11-29 18:08 ` Laurent Pinchart 2016-12-21 11:05 ` Guennadi Liakhovetski 2016-12-21 13:56 ` Guennadi Liakhovetski 2016-12-21 14:04 ` Hans Verkuil 2016-12-21 14:01 ` Hans Verkuil
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).