On Friday 02 February 2007 02:15, Tim wrote: > On Thu, 2007-02-01 at 14:08 +0000, Anne Wilson wrote: > > Axel, what's your feelings about the fact that the sliders for hue and > > colour don't work? Brightness and contrast work well. Do you think it's > > an upstream driver bug, or something else? > > If the person writing the software thinks in the normal way, hue should > really only have an effect when you're messing with a video input source > that encodes hue in a shiftable way (e.g. NTSC). Hue or tint errors are > an NTSC video error (carrier rotated out of phase). Other non-NTSC > systems, such as raw data from an image sensor don't work in that way. > > Likewise, being able to turn colour saturation up and down should only > work if you had a video-signal as source, one that uses an encoded > colour scheme. If you had the raw red, green & blue, colour data from > an image sensor, you'd have to go out of your way to make it possible to > turn the colour saturation up and down. > > Colour balance (whether a picture is tinted by lighting conditions), is > another situation yet again. That involves adjusting the level or red > and or blue signal from the camera, compensating against the amounts of > red and blue in the local light source, so pictures aren't tinted > artificially. I'm not disputing anything of what you've said, Tim, but there must also be something relevant in the way that an application handles the data. My webcam can produce quite acceptable colours in ekiga, but in amsn everything has a blue/purple tint. Since the only thing that is not common to the two situations is the application, it has to be there that there is a problem. That's why I wanted to find some way of changing the balance. Anne
Attachment:
pgp2bScgcExS1.pgp
Description: PGP signature
