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.
Cheers,
Nate
>
> Laurent, I see that uvc supports it: does the uvc standard mention anything
> with regards to presets?
>
> 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
