Re: White balance

And if we go down that path, someone can easily write some JS that takes tint / temperature as input and sets the white point. 

On Jan 4, 2013, at 10:23 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

> Seems to me that white point & black point are well defined terms that we can hope to have some consistency on interpretation / implementation without trying to become photo experts.
> 
> Would it make sense to offer an API to set white & black point color values, and leave "tint/temperature" until a later version, when these would hopefully be referenced in someone else's specification?
> 
> On 01/03/2013 02:32 AM, Cullen Jennings (fluffy) wrote:
>> As I'm sure you know, white balance is incredibly important particularly on things like telepresence where we want people skin color to look right (side note:  "Skin" by Lee Varis is a great book on this). Light color caries smoothly across a wide range - so for example, fluorescent lights long ago mostly had a fairly similar emission spectrum. Today that is much different - for example, the florescent lights in my office right now are KinoFlo KF55 which are going to be very different than most. It's spectrum at http://www.kinoflo.com/Image%20Gif/True%20Match%20lamps/Spectral-Charts-123.gif which you can compare that to a halophosphate light which looks like http://upload.wikimedia.org/wikipedia/en/thumb/7/74/Spectrum_of_halophosphate_type_fluorescent_bulb_%28f30t12_ww_rs%29.png/800px-Spectrum_of_halophosphate_type_fluorescent_bulb_%28f30t12_ww_rs%29.png). The net effect of this is that it is very hard to pick a finite set of values to represent what is going on. To get skin color right, you need to be able to smoothly vary the setting for the color of the light.
>> 
>> The color of the light if effectively a two dimensional space. One way of dealt this this is a floating point setting for "color temperature" and a separate one that is somewhat what orthogonal in the a perceptual color space to the temperature axis. There is many ways to do this, but nothing particularly well defined, and each camera manufacture does it differently. This makes it really hard to write programs to use an API like this and get insistence results across cameras. So lets look at what is really going on in the camera and use that to get a better API.
>> 
>> The typical camera is getting light values from a b/w sensor covered by bayer pattern filter that makes the color pixels. The filter has it's own properties so the camera needs to correct for that and the current color setting. In the end, the vector for the sensor color under the bayer pattern is going to get multiplied by a color matrix to get a value that then gets some non linear gamma transform and becomes the color of the pixel produced by the camera. Pretty much all camera do this and the trick is how to set this matrix given whatever camera settings that  have been provided to the camera. An extremely easy way to set up the color transform matrix that is to provide a "white point" IE the raw color that should come out as "white" and a "black point". You will see lots of profession stuff does this because it is well defined what the transform needs to be - if you set the white point on a photo in aperture, you will get the same results as if you did the same thing in photoshop. It's well defined what the algorithm for this is. Color temperature is not so simple - it's not as well defined what happens in a camera for a temperature of "5600" and in particular to the 2nd orthogonal component to the temperature. Of course setting a single setting is easier on the UI of a camera than setting a whitepoint so your typical camera has balances like "cloudy" but that is not what we want here. It does not express the smooth variation of lighting we need to express, it is not implementable in a  consistent way on cameras, and it does not match up well with the capabilities of the cameras we are going to be dealing with.
>> 
>> So I see a few paths forward for us
>> 
>> a) specify an API to set color temp and "tint" as floating point numbers and also define a well defined specification of what the settings mean such that camera can implement consistent results of these setting  (this second part is probably hard)
>> 
>> b) provide an API to set black and white point
>> 
>> c) provide API to set color transform matrix
>> 
>> I prefer b) and think don't like a) because it would be very hard to get right.
>> 
>> 
>> PS - one one side note on SettingsAPI_proposal_v6, the proposal has that "cool" is 4000 to 5000 K and that "warm" is 5000 to 6000 but this is, uh, confused. The high values are "cool" and low values are "warm". Often the term "warn /cool" will be used to mean that over 5000 K is cool, under 3000 is warm, and  3000 to 5000 is neutral.
>> 
>> 
>> 
>> On Dec 24, 2012, at 4:04 PM, "Mandyam, Giridhar" <mandyam@quicinc.com> wrote:
>> 
>>> Don't think Travis is to blame for that one - I proposed it in Camera Settings, see http://gmandyam.github.com/media-capture/#whitebalancemodeenum.  This is consistent with what our drivers currently support in our chipset,
>> Which chipset is that - I'll take a look at it
>> 
>>> and with native API's such as Android (see http://developer.android.com/reference/android/hardware/Camera.Parameters.html).  But is your concern more about SW implementations of such features when they aren't available natively?
>> 
> 
>

Received on Friday, 4 January 2013 20:42:03 UTC