I've just bought an ASI 294 color camera, and that is real fun! But I get strange colors - a strong blue tint like others here have talked about, and I have a feeling of a weak red channel. Now, I process my images in PixInsight and the strange colors stay with me after calibration and stacking.
So: the rest of you with this camera: which settings do you use for the channels in the Indi manager?
Look at this link
This is a great resource for calibration and specifically mentions issues with the 294. The bit about white balance and settings for WB-B and WB-R are particularly useful. Never use auto white balance as it leads to bad colour cast in calibration especially when using flats. I set both to 50 and offset 8 with gain 120 and use these setting for all my bias, darks and flats as well as lights.
Usually then you can use Dynamic background extractor and background normalisation to remove colour cast.
I have also been using channel extraction to separate the colours, examining in histogram transform and then balancing the channels with linear fit before combining back to RGB. It is a bit laborious but appears able to remove most colour cast.
Oh and ensure that any debayering is set to RGGB
Others may have other methods but these work for me. I will be interested how other users deal with these problems.
Although I don't use PixInsights for calibrations or integration phases.
Instead I use AstropixelProcessor, which I feel gives a great result and handles the "color cast" you see in PixInsight, which I believe is an artificial cast to do with how the data is written perhaps.
Additionally, I also recommend doing Dark Flat instead of Bias frames with this sensor (this topic has been quite hot around this sensor, check the forums. As the sensor does not behave consistently at with sub-second frames)
When opening my source images in PixInsight I can confirm I get the same blue cast you describe, but this does not affect the final integration which AstropixelProcessor seems to handle well.
One question, as I expect PixInsights should integrate the channels separately, can you apply a HistogramTransform afterwards, but without the "Link RGB Channels" icon enabled. This can be found on the ScreenTransferFunction tool.
When I do this with the "Link RGB Channels" disabled, the result is a normal averaged to grey image (it is color, although the color cast has gone!)
So perhaps calibrate & integrate as normal, but apply an unlinked HistogramTransformation
I have questioned this myself in the past and played at setting these values, but found little difference in my resulting integrated images.
Also I suspect the defaults (in indi panel, WB_R: 52, WB_B: 95) have something to do with the Bayer array and sensitivity of sensor to those color relative to Green.
Also of note, if you have not seen already in the referenced article from above:
"If you use an OSC camera of make ZWO, caution is advised when the 'native' camera driver is used: the ZWO SDK enables the user in the acquisition software to control settings that influence the white balance of a displayed color image. This is achieved by two parameters, WB_R and WB_B, data range 1 to 100, the default values are WB_R = 52 and WB_B = 95. The intensities of the red channel will be multiplied by WB_R/50 and the intensities of the blue channel by WB_B/50. Unfortunately the results of this multiplication are also written to disk in the FITS file. So it is important to set the values of both parameters to 50 and subsequently apply 'Save Config'; only in this way, the real raw intensities will be saved to disk in the FITS files, see . Since the data coming from the camera are saved in FITS files which usually have the number format 'unsigned 16-bit integer', otherwise rounding errors and clipping of high values will arise. Such a complication is generally avoided when the ASCOM camera driver is used instead of the native driver."
This explains the issue. So with FITS files you probably wont be "loosing" any data, just making it harder for some processing applications/workflows to deal with it easily.
I tried the dark flats as well but despite what I expected there was no difference in the outcome and I still ended up with a bad colour cast which was so bad I could not remove it. However since changing the white balance settings things have been better.
When I don't use flats at all there does not appear to be a problem so I think that the flats are the issue and the white balance.
I agree with you that users of APP do not complain of these problems
Thanks for you replies. Maria, very informative, I need to dig a little deeper into what you are writing!
Steve, as for the debayer direction - I saw about that in the other thread. But I am not sure I even understand what it means. TO the best of my knowledge, there is no option for direction of the debayer in Ekos and neither in PI. But we force debayer pattern to be RGGB. So: are you suggesting another debayer pattern?
The debayer remains rggb. The top-down refers to where the data origin is located. I believe that most apps store bottom-up (like a conventional xy graph) but ekos uses top-down. This results in pixels being debayered as the wrong colour.
Not an expert, I just found out the hard way. But I would add that I was glad when my PI trial expired!
The PI guide to calibration was indeed very informative and thorough! Clarifying not least some things about dark optimization that I hadn't realized.
Just to show you: here's a single shot, uncalibrated, of M27, the histogram from Histogram Transformation and the STF. This is taken with the default settings (WB_R = 0.52, WB_B = 0.95). The image is stretched with STF, with unchecked "linked channels", and thus shows a fairly well balanced image, I think - though still weak in red... The histogram shows the colors regarless of the screen strech - and there the difference is quite obvious. However, Maria, I am not sure what you mean by unlinking channels in HistogramTransoformation (but that is perhaps a bit off topic for this forum). I use ColorCalibration to adjust the levels of the RGB channels, but maybe there is a better way.
Anyway, that is post acquisition processing. What matters most here is the acquisition. So what I take from this is that 0.5 for both WB_R and WB_B is a good way to go. But, just out of curiousity, why is the default value something else??
It may be that ZWO does nothing to the WB_? values in their firmware and the 52/95 values are the defaults set by the CMOS chip hardware. Perhaps they give a reasonable white balance for terrestrial photos.
And maybe their ASCOM driver sets values of 50/50.
If that's the case then perhaps the Indi driver should default to 50/50 and set this, not read it from the low level driver.
Is there even a need - a use case - for a user to be able to control this? Or many of the other controls that are available?
I'm too new with the ASI294 to really tell, but I think these settings are confusing. At least it would be better for a user like me if Indi defaulted to 0.5. I am using that setting now, and get great results in PixInsigts! No strange colors after calibration, very nice process!
As for a use case where these settings could be useful: I'm not the one to tell, but I'd prefer going for having them available as long as the defaults are good.