Hi Martin,
any colour balance controls you see in the right hand panel in SharpCap come from the camera SDK - SharpCap doesn't implement its own colour balance for camera images, but does have colour balance adjustments for stacked images (deep sky and solar system stacking).
As I understand it, there are two different possible types of colour balance implemented by the SDKs
1) different analog gains being applied to the different colour channels at the sensor level - this sesms to be rare, but some CMOS cameras from QHY appear to have this ability.
2) Multiplicative adjustments being applied to the digital pixel values post readout (by far the most common)
My personal belief is that colour balance adjustments that operate on the digital pixel values as per option 2 above should not be used, since they inevitably throw away some of the detail in the data due to rounding back to integer values after multiplication or due to clipping at the white point. It always seems to me that it is better to preserve the true raw data coming from the sensor and then to deal with this sort of colour balance problem in post-processing, since there you can always try again based on the original raw data if it doesn't quite work out. Additionally, multiplicative adjustment is not sufficient to properly colour balance deep sky astro images if there is a colour tint to any background light pollution...
The first sort of colour balance can have uses - you could perhaps set a higher gain (and hence lower read noise) for the blue channel to help counteract the lower light levels in the blue.
Anyway, having said all of that, if you want to add SDK support for colour balance, then the usual approach is
* A function to set the colour balance values for the three channels
* A function to retrieve the current balance values
* A function that will perform a one-off auto white balance based on the current image (or the next received) - after using this, the retrieve function should be usable to retrieve the values that were calculated by the auto white balance
* You might want to add a master on-off switch in the SDK for white balance processing
I would suggest picking a unit for the adjustment like 1/10th or 1/100th dB, so that zero is a natural neutral value, although a percentage option where 100% is neutral would be fine too. There are some brands where the 'neutral' white balance values vary from model to model, and that is a pain for users (and software developers). Also, once you have a definition for your white balance values, stick to it - another brand tried to change definition recently and it caused a certain amount of chaos as saved settings suddenly gave different results
Hope this helps, do ask if you have any more questions,
cheers,
Robin