Hi,

I just started playing with my new ASI294MC and saw the following strange behaviour: In bias frames (gain 0, offset 14) I can clearly see the CFA (Bayer) pattern. See this image, which is a screenshot of PixInsight, the bias frame heavily stretched and zoomed in:



Since there is no light involved, this cannot be true, there must be an error somewhere. I would expect a noisy background, maybe some column structures, but no Bayer checkerboard. Has anybody else such a behaviour with bias frames of the ASI294MC in KStars/Ekos? I run Astroberry on a Raspi 4B. In dark frames (exposure 300 s, gain 0, offset 14) I see the checkerboard, too, and I wouldn't expect it there, either.

Regards,
Bernd

Found the reason for the implausible bias frame.

The ZWO CCD driver (indi_asi_ccd) has control settings WB_R = 52 and WB_B = 95. Those white balancing factors have a range from 0...100 and are neutral at 50. These factors are multiplied by the red and blue pixels, respectively, leading to a boost in blue intensity of almost a factor of 2 (95/50 = 1.9). Therefore, the blue pixels clearly stand out of the noise floor of the bias frame, and that is what can be seen on the frame shown above.

I now set the values of WB_R = 50 and WB_B = 50 and saved it as default. Now my bias frames look as they should:



So for a proper post processing and image calibration it is important to set any white balance factors in the camera driver to unity (in this case 50).

Regards,
Bernd

One further remark: There are people in other forums (PixInsight for instance) who say that applying white balance factors to the image and saving the so changed image to FITS then doesn‘t return pure „raw“ data... Any thoughts here?

CS
Bernd

What I just noticed is that all my bias frames taken after approximately November last year are all empty - no signal.
October 5, 2019 and before was fine. November 24, 2019 - January 22, 2020 -- bad! I do install nightly updates regularly.
All bias images were taken with 3.2E-05 exposure.
Looks like a bug.
Maybe this "WB_R = 52 and WB_B = 95" was introduced back in November maybe something else changed...
This maybe important...

An all empty bias frame most probably is due to an offset which is too small. Offset cannot be set directly within the Ekos Capture Module (only gain possible there), but you can set it in the ASI Indi driver window ("controls"). For ASI294MC, the offset value translates to a mean pixel value in the bias frame of (approximately) <offset> x 64. You can examine the histogram or the statistics in the FITS preview to see the average pixel intensity, depending on the offset used. I use offset=14 with gain=0, and it leads to a mean bias intensity of 896 = 14x64. For higher gains it may be different. I try to have an average bias intensity between 500 and 1000 ADU on a 16bit scale.

And, in the control tab of the ASI driver I also set WB_R = 50 and WB_B = 50 (NOT 52 and 95 which seems to be the current default) to get a unity white balance in my raw images (be it bias, darks or lights).

I've been using same settings for ASI294MC since I bought it back in February last year.
Don't remember exactly but I think I use the offset of 40 (gain 200).

You can see your effective offset value in the ASI driver page "control". 40 seems high (enough), but maybe in combination with a gain of 200 still too low? You can try increasing the offset and see the histogram or statistics of your bias frame. The pixel average should be well above 500 to be on the safe side (but not higher than 1000 which is unnecessary and reduces usable dynamic range).

Bear in mind that every time the properties that change the data the camera delivers are altered you will need new sets of calibration data - bias and dark frames at least - collected with the same conditions. This will apply to gain, offset and this WB_? property. There could be more.

Yes you‘re right.

But better to create a new calibration library than using zero-clipped bias frames.

Hi,

just wanted to revive this older thread. Any thoughts why KStars/Ekos is using the WB_R and WB_B values in the FITS image? Those white balancing parameters are post processing and should not affect the raw FITS image. Workaround is to set WB_R and WB_B to 50, respectively, resulting in equal gain in R, G, G, B. Only then you get correct bias and dark frames without visible CFA pattern. I'm talking about the ASI294MC Pro, don't know it this behaviour can be found with other cams as well.

CS, Bernd

How is Ekos using WB_R and WB_B exactly? There are not used any where that I know of.

Hi,

to demonstrate I took 4 bias frames with different WB_R and WB_B settings:

1. WB_R = 50, WB_B = 50 (neutral)
2. WB_R = 95, WB_B = 50 (red pixels high)
3. WB_R = 50, WB_B = 95 (blue pixels high)
4. WB_R = 10, WB_B = 10 (red and blue low = green pixels high)

Here is the result, showing the problem. The images are zoomed to the upper left corner so that the first RGGB quadruplet can be seen. The first image (50/50) shows noisy pixels as expected. The second image (95/50) shows amplified red pixels, the third image (50/95) shows amplified blue pixels and the last image (10/10) shows dark red and blue pixels.

This proves that the WB_R and WB_B parameters affect the FITS data which should not be the case. Might be a driver problem? Maybe the driver sends non-raw data?

I can send the original FITS images as well, but they are 22 MB each...

CS, Bernd