This is all VERY new to me but some limited testing I did comparing flats taken with no filter, a mounted 31mm L-3 UV-IR Block filter and a 1.25" L-eXtreme does tend to suggest to me that there is some sort of non-linear colour response in my ASI294MC Pro sensor and the L-eXtreme when the RGB channels are scaled that I don't see in the other two cases and that this could be causing the problem. It mainly affects the red channel as others have noted. I understand that while this issue is common with the ASI294MC Pro, it's not limited to this camera or this specific sensor. The tests were done using a suprisingly well colour balanced led tracing panel, acrylic diffuser and 2 sec exposures with brightness of the light adjusted to get the targeted ADU count. Note, I had the same patterning problem with sky flats earlier.
Using bulrichl's flat's stretching and colour channel comparison approach from the PI forum, I compared low ADU flats for each case against relatively high ADU flats at levels similar to that suggested by the ASIAir's Auto Flats function for each. Roughly, that was about 12,000ADU vs 32,000ADU and noted in the screenshot using (L)ow and (A)uto prefixes in the various images.
https://pixinsight.com/forum/index.php?threads/flats-dont-look-correct.18417/post-112145The images in the screenshot are layed out with the no filter case on the LHS and the L-eXtreme case on the RHS. I've left out the L-3 case here due to space but the results were very similar to the no filter case.
The 1st column for each case has images of the debayered and streched flats, the 2nd column the 'standardised' RGB flats produced using bulrichl's short PixelMath equation. The 1st row is the L ADU case; 2nd row A ADU case; 3rd row A - L; 4th A / L; and the bottom row, seperate RBG components of the 'standardised' A / L image.
As I understand it, if the sensor - filter combination was behaving normally, there should be no colour shift between flats targeting different ADU levels (within the sensors linear range, something like ?2,000 - 50,000 ADU at a guess but I haven't looked that up). That's what we see here in the debayered and stretched flats for all cases, including the L-eXtreme where no scaling of the RGB channels has happened (4th row, columns 1 and 3). I would think that if there was a fixed colour pattern across the linear range that it should be able to be taken care of by current processing techniques.
A problem could be emerging due to this ?non-linearity when the single channel flat is split and seperate scaling factors applied to the RGB channels as part of the image calibrate and registration process such as PixInsight's Weighted Batch Preprocessing script (WBPP) when "Separate CFA scaling factors" is enabled for Flats processing.
As we can see in the image (4th across, 4 down) showing the ratio of the 'standardised' L-eXtreme at high and low ADU's there is a significant colour shift between the low ADU flat and the high. If we look at the seperate RGB channel data for it in the row below, we can clearly see the anomaly in the red channel that many others have noted. The green and blue channels seem to be unaffected by this ?etalon effect in the sensor but interestingly in my case the corners are overcorrecting in both the low and high ADU cases. These effects could well be occuring in broadband imaging too but is likely to swamped by the much wider (and stronger in aggregate) response outside of the narrow wavelengths targets by the (multi-)narrowband filters.
If this is right, it suggests to me that it's very difficult to remove these effects using the current norm of processes such as WBPP using "Separate CFA scaling factors". Ideally there would be another approach, something better than splitting out all the flats and lights (?others) into their own RGB channels before calibrating and registering to treat as their own narrowband datasets, if even that works. @
falke2000's earlier post where he highlights much better results from independent processing of the narrowband channels does suggest it could.
I have had improvements by using lower than suggested ADU levels for my filters with the ASI294MC Pro, dark flats, following the PI recommended WBPP process and using DynamicBackgroundExtraction as suggested by Shawn from VisibleDark in his YouTube video linked below.
https://www.youtube.com/watch?v=eB0J4-O5WUQ I have read that others have had some success using alternative processing approaches e.g. calibration in Siril but I haven't tested that myself yet.
But with my new Apo telescope and using the exact same procedure for taking flats (exp. time ~0.25s) I don't have any problems with flats. So I thinks it's something about the specific scope+filter combination, as my current method for taking flats worked for literally any other setup I own. I just don't have any clue why this problem occurs. This year I haven't tried using the L-Enhance with my Newt yet, but because of the disappointing results from last year I'm not willing to sacrifice any more time with an consistently not working equipment combination.
