Dear Robin,
Moravian Instruments has released new cameras — the C2-46000 and C1+46000.
The SDK DLL has been updated, and SharpCap works correctly with these cameras. No changes are required on your side — it’s sufficient to include the latest DLL in the SharpCap distribution.
https://www.gxccd.com/cat?id=164&lang=405
Best regards,
Martin
Moravian Instruments C2-46000 and C1+ 46000.
-
admin
- Site Admin
- Posts: 17342
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: Moravian Instruments C2-46000 and C1+ 46000.
Hi Martin,
thanks for letting me know - I have updated to the new DLLs, so that the new SDK will be in the next update of SharpCap 4.1.
cheers,
Robin
thanks for letting me know - I have updated to the new DLLs, so that the new SDK will be in the next update of SharpCap 4.1.
cheers,
Robin
Re: Moravian Instruments C2-46000 and C1+ 46000.
Robin,
I now have the color version of the C2-46000 camera, and it does not appear to have any color balance controls, unlike ZWO or QHY cameras. Does that mean this functionality is not handled by SharpCap, but rather needs to be implemented in the camera hardware or driver?
How do you determine whether a camera supports color balance controls?
Which functions or features in the camera API are you looking for?
At the moment, there are no such functions available in the DLL, but we are planning to add them. Please let me know what approach would work best for you.
I now have the color version of the C2-46000 camera, and it does not appear to have any color balance controls, unlike ZWO or QHY cameras. Does that mean this functionality is not handled by SharpCap, but rather needs to be implemented in the camera hardware or driver?
How do you determine whether a camera supports color balance controls?
Which functions or features in the camera API are you looking for?
At the moment, there are no such functions available in the DLL, but we are planning to add them. Please let me know what approach would work best for you.
-
admin
- Site Admin
- Posts: 17342
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: Moravian Instruments C2-46000 and C1+ 46000.
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
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