Bayer Pattern Changing???

Hi John,

the bayer matrix IS static in the camera, it is "hardware" like a filter directly in front of your chip. But different softwares read out the bayer pattern in different directions. So a pattern like
RG
GB
can be interpreted as RGGB (top left to bottom right) or BGGR (bottom right to top left) or even GRBG (top right to bottom left) or anything else.
So did you perform an update on any software you used for capturing or processing? That is the only way i can imagine that the pattern changes in the same piece of software.
I hope that my thoughts might help and i also hope that i am correct with what i wrote - these bayer-patterns often confuse me. It took me about a month or so to figure out which software uses which direction when debayering the images from my ASI178MC. I ended up with a more or less complex Excel chart after endless trial-and-error-sessions :-)

CS
Michael

No, the flip makes no sense for your strange problem. Could you give me access to an unprocessed fits file of each M57 and M20 (via DropBox, GoogleDrive or anything else?)

Hello,
I'm obviously facing the same problem with my ToupTek ATR3CMOS-Camera (similar to the ZWO ASI 1600 MC and others)
Did an extensive Testing with 'APT' and 'ToupSky' (comes with the Camera) for capturing the Images. So far, so good - basically satisfied with the results.
BUT:
Surprisingly I found different Bayer Pattern - when I tried to stack it with DSS - even within the same Sequence. Some of them are BGGR others GRBG !
Any idea what happenend here ?

Hi all,
This may be related to the introduction of fits tag "ROWORDER" which was introduced in PI with the latest version and evaluated as per defsult. Also in APT. Probably also in other apps too.
There are a couple of threats in the APT Forum you may check. The best advice is currently not to mix fits from different imaging sessions, or acquisition software versions.
CS
Rüdiger

Thank you for your replies.
Yes, I knew already the Bayer Pattern System. But i expected that all shots of a sequence has the wrong or right Bayer Pattern.

But this is not the case.

When I'm judging a Sequence of 10 shots in DSS (set to BGGR) roughly one half of the Images has a BGGR-Bayer Pattern and is displayed in correct colours, but the others are displayed in wrong colours having a GBRG-Pattern.

So i was forced to introduce an additional preprocessing step. I did a Colour conversion of all Images with MaximDL to a uniform Bayer Pattern (in my case to BGGR).

After this procedure stacking could be done correctly.

However it's not the best solution, but it works.

Alfred

Reviving this as many are reporting it. It's not trivial and affects 50% of all subs. My camera is BGGR and it's alternate pairing is GRBG. It uses the Panasonic mn34230 chip, as toupsky and asi 1600. 
I had a discussion on APP form, here is the link and examples of how to spot this issue in sub exposures. I also need to separate out all subs in two bundles, processes separately and finally integrate the two master lights.
It might be related to the ascom driver vs the software, but it happens with apt, sharpcap and anything else running the cam through ascom.

It makes live stacking impossible however, as the maze like pattern and green background occur in 50% of all captures, which is a real pity when I want to do live stack occasionally.

https://www.astropixelprocessor.com/community/main-forum/alternating-bayer-pattern-within-a-single-imaging-session/

Glad you are sorted. I use app for everything too, although the bayer problem I am reporting remains, and likely does for a lot of people and not related to the stacking software, but the capture stage. There is something off with the fits writing and it is not consistent across softwares. Looks like our problems are slightly different, but the random bayer writing change occurs to exactly 50% of all files in a single session, while running. Anyway, clear skies

No, my camera is not a ZWO one, but it has the same chip as some of them like the 1600 e.g. I have the latest native and ASCOM drivers, but the native driver only works with Explore Capture software and that does not support mount communication to control dithering. All software using ASCOM allow me full control of gain, offset etc., but the fits header writing is always between the two bayer pattern pairings within a session. 
For now, unless I upgrade to 2600MC pro eventually, i have two process two sets of BGGR and GRBG images, and integrate the two masters together and that works fine if a little longer to do. Wish I had the livestack option though, since the mixing of debayering ruins the stack every time, sob sob.!

Thanks @Landy100at

I found you post on another german forum and am trying to use the F4W2HDU to change the fits header. 
Strange, the change works when I look at fits viewer from ASI (my camera is the ES 16 MP, Bresser). So I thought it was working.

But in DSS and APP, the changes make no difference, my images are still either BGGR and GRBG. Except now, I have moved them all to the same folder and have to sort them into two groups again .

I could not access the firmware in your dropbox links, I guess they were old on that forum. I have had this problem even using the driver on the CD from 2019 that came with the camera. 
might you be able to share a link to the old firmware that works for you please?

It would be such a help to get this camera to save fits files correctly for the first time.

In all my images from this camera, I have had to process without any calibration frames since the darks are also affected by this problem, and calibrating flats leads to overcorrection etc. big problem.

Thanks for any help with the firmware.

Hallo Horst,

Pixel sizes are identicaly in both cases, and additionally there is no 90 degree rotation either, which I checked too.

It is only for the similar pairing BGGR and GRBG here.

Modifying the BAYERPAT and COLORTYP fits header keywords does not work, so the issue happens when images are captured and written to the header, but does not happen for images shorter than 5 seconds uniquely.

It is extremely annoying to be honest, especially for extra processing of subs and no ability to do live stacking on short summer nights!

Clear skies

HI Yannis,

No cropping done in the software, and when binned 1x1, this CMOS chip it is always at maximum resolution. 
Overscan removal by the driver could be the problem, good point.

So I tried to find the oldest compatible version of the driver. for the ASCOM one, there is an option from Bresser, Explore Scientific, Orion, Mallincam, TouTek etc. They all released this same camera with the MN34230 Panasonic chip, same as QHY163C and the ASI 1600MC Pro and others.

The touptek driver is the oldest. I tried it ad made a dark library again for one of my most common imaging parameters (offset, gain, time, temp).

first thign I noticed: all frames have the same debayering needs, so that is a good sign. Normally it randomly flip (totalling 50% BGGR and 50% GRBG) using more recent driver (you can see example here: https://www.astropixelprocessor.com/community/main-forum/alternating-bayer-pattern-within-a-single-imaging-session/).

When I integrated a master dark, it turns my older images taken with the newer driver into strange blue or yellow tones. So I will need to capture some subs with this camera and the older touptek driver to see if lights and darks are compatible.

Here is the master dark below. It has one new feature compared to other master darks where I had to integrate the GRBG and BGGR separately and then together. It has a band across the top. Of course, the tone is blueish here, but greenish using the other bayer pattern. I will check with new lights with this driver to see what happens, but still no obvious solution.