Thank you Hans.
I'll see how to use V4L2_CTRL_FLAG_UPDATE and _INACTIVE.
Cheers,
Nate
On Wed, Apr 15, 2009 at 3:24 PM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote:
> On Wednesday 15 April 2009 08:10:58 Dongsoo, Nathaniel Kim wrote:
>> Hello Hans,
>>
>> On Tue, Apr 14, 2009 at 11:50 PM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote:
>> > On Tuesday 14 April 2009 13:54:02 Mauro Carvalho Chehab wrote:
>> >> On Fri, 10 Apr 2009 06:50:32 +0900
>> >>
>> >> "Dongsoo, Nathaniel Kim" <dongsoo.kim@xxxxxxxxx> wrote:
>> >> > Hello everyone,
>> >> >
>> >> > I'm posting this RFC one more time because it seems to everyone has
>> >> > been forgot this, and I'll be appreciated if any of you who is
>> >> > reading this mailing list give me comment.
>> >> >
>> >> > I'm adding some choices for you to make it easier. (even the option
>> >> > for that this is a pointless discussion)
>> >> >
>> >> >
>> >> >
>> >> > I've got a big question popping up handling white balance with
>> >> > V4L2_CID_WHITE_BALANCE_TEMPERATURE CID.
>> >> >
>> >> > Because in digital camera we generally control over user interface
>> >> > with pre-defined white balance name. I mean, user controls white
>> >> > balance with presets not with kelvin number.
>> >> > I'm very certain that TEMPERATURE CID is needed in many of video
>> >> > capture devices, but also 100% sure that white balance preset
>> >> > control is also necessary for digital cameras.
>> >> > How can we control white balance through preset name with existing
>> >> > V4L2 API?
>> >> >
>> >> > For now, I define preset names in user space with supported color
>> >> > temperature preset in driver like following.
>> >> >
>> >> > #define MANUAL_WB_TUNGSTEN 3000
>> >> > #define MANUAL_WB_FLUORESCENT 4000
>> >> > #define MANUAL_WB_SUNNY 5500
>> >> > #define MANUAL_WB_CLOUDY 6000
>> >> >
>> >> > and make driver to handle those presets like this. (I split in
>> >> > several ranges to make driver pretend to be generic)
>> >> >
>> >> > case V4L2_CID_WHITE_BALANCE_TEMPERATURE:
>> >> > if (vc->value < 3500) {
>> >> > /* tungsten */
>> >> > err = ce131f_cmds(c, ce131f_wb_tungsten);
>> >> > } else if (vc->value < 4100) {
>> >> > /* fluorescent */
>> >> > err = ce131f_cmds(c, ce131f_wb_fluorescent);
>> >> > } else if (vc->value < 6000) {
>> >> > /* sunny */
>> >> > err = ce131f_cmds(c, ce131f_wb_sunny);
>> >> > } else if (vc->value < 6500) {
>> >> > /* cloudy */
>> >> > err = ce131f_cmds(c, ce131f_wb_cloudy);
>> >> > } else {
>> >> > printk(KERN_INFO "%s: unsupported kelvin
>> >> > range\n", __func__);
>> >> > }
>> >> > ......
>> >> >
>> >> > I think this way seems to be ugly. Don't you think that another CID
>> >> > is necessary to handle WB presets?
>> >> > Because most of mobile camera modules can't make various color
>> >> > temperatures in expecting kelvin number with user parameter.
>> >> >
>> >> > So, here you are some options you can chose to give your opinion.(or
>> >> > you can make your own opinion)
>> >> >
>> >> > (A). Make a new CID to handle well known white balance presets
>> >> > Like V4L2_CID_WHITE_BALANCE_PRESET for CID and enum values like
>> >> > following for value
>> >> >
>> >> > enum v4l2_whitebalance_presets {
>> >> > V4L2_WHITEBALANCE_TUNGSTEN = 0,
>> >> > V4L2_WHITEBALANCE_FLUORESCENT,
>> >> > V4L2_WHITEBALANCE_SUNNY,
>> >> > V4L2_WHITEBALANCE_CLOUDY,
>> >> > ....
>> >> >
>> >> > (B). Define well known kelvin number in videodev2.h as preset name
>> >> > and share with user space
>> >> > Like following
>> >> >
>> >> > #define V4L2_WHITEBALANCE_TUNGSTEN 3000
>> >> > #define V4L2_WHITEBALANCE_FLUORESCENT 4000
>> >> > #define V4L2_WHITEBALANCE_SUNNY 5500
>> >> > #define V4L2_WHITEBALANCE_CLOUDY 6000
>> >> >
>> >> > and use those defined values with V4L2_CID_WHITE_BALANCE_TEMPERATURE
>> >> >
>> >> > urgh.....
>> >> >
>> >> > (C). Leave it alone. It's a pointless discussion. we are good with
>> >> > existing WB API.
>> >> > (really?)
>> >> >
>> >> >
>> >> > I'm very surprised about this kind of needs were not issued yet.
>> >>
>> >> I vote for (B). This is better than creating another user control for
>> >> something that were already defined. The drivers that don't support
>> >> specifying the color temperature, in Kelvin should round to the
>> >> closest supported value, and return the proper configured value when
>> >> questioned.
>> >
>> > I'm going with A. My reasoning is that presets 1) differ per device, 2)
>> > will normally be better tested than a random temperature value.
>>
>> I totally agree with you.
>>
>> > Remember that the control API is meant to export the options that the
>> > device supports to the application. So the presets cannot be defined as
>> > macros but must really come from the device driver. An application can
>> > then show the available presets to the user.
>> >
>> > I wonder if these two aren't mutually exclusive: you either can use any
>> > value, or only use presets.
>>
>> Don't worry about that. Generally, it is possible to use both of them
>> if they are supported by device. I mean, if device supports kelvin,
>> you can control WB with kelvin value. And if device is supports
>> presets, you can control WB with them also.
>> Difference between them should be a optimization in quality of WB
>> controlled Image. Because even though kelvin temperature is the key of
>> controlling white balance, there could be another factor to make a
>> batter white balance for some specific circumstances.
>> So, white balance presets are containing a optimized white balance
>> control from sensor manufacturer.
>> One thing should be taken carefully when we are making a new control
>> for white balance preset. Which is like following case:
>>
>> Set sensor white balance to "daylight" preset. + make some change with
>> kelvin temperature with white balance control = Sensor is not exactly
>> in "daylight" white balance preset status.
>>
>> So if device is supporting both of ways to control white balance, we
>> should make driver to care about the relationship and status between
>> both controls.
>
> If you have both, then the preset control must have a 'Manual' preset. And
> setting the preset control to a non-manual preset has the effect of also
> updating the WB kelvin value. That way the application can read back the
> precise kelvin value used. This is even useful when the driver only
> supports presets.
>
> Note that the application can tell relationships like this from the
> V4L2_CTRL_FLAG_UPDATE and _INACTIVE flags. It's used as well in the
> complicated MPEG control handling (see cx2341x.c).
>
> Regards,
>
> Hans
>
> --
> Hans Verkuil - video4linux developer - sponsored by TANDBERG
>
--
========================================================
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media & Communications R&D Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo.kim@xxxxxxxxx
dongsoo45.kim@xxxxxxxxxxx
========================================================
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
