[lkml]   [2001]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [V4L] Re: [RFC] alternative kernel multimedia API
Mark McClelland writes:
> wrote:
>> On Mon, 29 Oct 2001, Gerd Knorr wrote:

>>> You can't. But I don't see why this is a issue: The only thing a
>>> application can handle easily are controls like contrast/hue where the
>>> only thing a application needs to do is to map it to a GUI and let the
>>> user understand and adjust stuff. The other stuff has way to much
>>> non-trivial dependences, I doubt a application can blindly use new
>>> driver features.
>> Have you ever thought that the reason we only use these controls is
>> because they are the only ones easy to implement now ?
> What I don't understand is how will your driver implement these controls
> in a generic V4L3 GUI control app automatically? No matter how powerful
> the semantic information you give to the app is, it can still only build
> interfaces from standard GUI components that it already knows about. The
> app cannot build a gamma curve control on its own. If it could, we
> wouldn't need programmers anymore :)

The driver provides this: /proc/v4l3/vid0/


The very idea of a gamma table is featuritis. Just a single number
will do for most anyone. You get from 0.01 to 2.55 and "off" with
just 8 bits.

If you want to get fancy, I guess you need:

1 gamma value per primary
3 tri-stimulus values for each primary ("What color is red?")
3 tri-stimulus values for the whitepoint (maybe)
1 black level for each primary

That is 18 values at most.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:12    [W:0.845 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site