0.00
#... |
|---|
|
Hi guys, Hopefully someone can shed some light on a problem I am having when loading my subs to Deep Sky stacker. So some contextual; background, I am using a ZWO ASI178MC-Cool for imaging. I use ASICAP for acquisition for its simplicity, I have tried APT but it just adds a whole new level of complexity. Long story short, I'm keeping my capture methods simple so I can focus on getting a feel for the settings and obtaining as much data as possible I use the 16-Raw setting which requires me to check the "Monochrome 16 bit FITS Files..." in DSS. My camera has a bayer matrix of RGGB, and for the last 6 months I have kept that box checked and received no problems. However, recently I noticed that my subs are coming out the wrong color, I am having to change the pattern setting in DSS to BGGR. The strange thing is that one set of subs will be in the original RGGB then anther in BGGR. I cant find what it is that is causing the change as the captured images will flip in between sub sets on the same night. I always thought the matrix was static inside the camera, is this incorrect? Hopefully you guys can help, I can work around it but it is kind of a pain., Thanks and much love, John Michael Bellisario |
3.21
#... |
|---|
|
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 |
|
0.00
#... |
|---|
|
Hi Michael, Thanks for your input, it reinforced my initial thoughts. I picked up a new laptop just for aquisition, so I'm guessing it was either that or one of the many updates I've done. So I'm struggled to diagnose the source of the bayer matrix swap because I haven't found any pattern withing the error. FOR EXAMPLE, last night framed up M57 and imaged 20 subs, I then slewed to m20 and finished out the remainder or the night imaging the Trifid. All the setting were the same, the only changes I made between sets was the destination folder. This morning when I loaded them into DSS M57 was color Correct with the RGGB matric selected but M20 was inverted and I had to switched the setting to BGGR. This seems to be the case with all of my subs lately, some are one and some are the other. I Thought maybe it was meridian flips but that doesn't make much sense because DSS is not coordinate bias, or is it? |
|
3.21
#... |
|---|
| 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?) |
|
0.00
#... |
|---|
| Ya I can when I get home from work |
0.00
#... |
|---|
|
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 ? |
3.35
#... |
|---|
| I think it also depends on the debayer method being used (eg. VNG). Also, I believe some apps read raw file bottom-up by default (eg. PixInsight), whereas other default to top-down ... not sure if that might have an effect to. When getting a new OSC camera, I like to take an image of something white (eg. couple of sheets of white paper over the OTA), then check the colour balance of the resulting image. Helps to confirm the best pattern/method for the software (eg. RGGB using VNG), and for tuning debayer matrix weighting, if that option exists in the software. Good luck! |
18.84
#... |
|---|
|
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 |
|
3.21
#... |
|---|
Hello,I'm obviously facing the same problem with my ToupTek ATR3CMOS-Camera (similar to the ZWO ASI 1600 MC and others) It is simply the way the software reads the fits-file. If you have (phisically) this pattern on your chip: BG GR If you read the file top-left to bottom-right you get: BGGR. If you read the file bottom-right to top-left you get: GRBG. That happened :-) |
|
0.00
#... |
|---|
|
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 |
|
3.21
#... |
|---|
| Hi Alfred, this is indeed odd. Never heard of this behaviour before, hope you can solve it. CS Michael |
0.00
#... |
|---|
|
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/ |
0.00
#... |
|---|
| I gave up on DSS about a year ago. Between your bayer problem and the only one frame to stack messages I went to Astro Pixel Processor. I am a happy man now. The learning curve took less time and trouble than debugging DSS. |
|
0.00
#... |
|---|
| 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 |
|
0.00
#... |
|---|
| Did you update your camera with the 12/31/2020 firmware?https://astronomy-imaging-camera.com/software-drivers |
|
0.00
#... |
|---|
|
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.! |
|
0.00
#... |
|---|
|
I faced absolute the same problem as described. I reported about in this Thread already. It occurs at my ToupTek ATR3CMOS 16000KPA. I also found a workaround with Maxim DL. In the Meantime the problem was solved. Wether DSS nor APT were the reason why. In my Case it was definitely the firmware ! I had the newest firmware installed, but there was the bug ! After installing a precessing Version it worked ! In the Meanwhile they released new versions. I now had the current Version installed and it works properly as well. |
|
0.00
#... |
|---|
|
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. |
2.86
#... |
|---|
|
Hi John, hi Colm, i issued a similar topic back in the days when i had a QHY10. This camera had a dark overscan area, which changed the original order of Bayer pattern when applied. Depending on the driver i used, the image was additionally flipped into vertical direction. Which again changed the order. Did you compare the pixel sizes of the RGGB and BGGR versions? Do these match? Apart from that, i would think of a driver issue. What @Ruediger wrote also sounds plausible. Ersma, Horst |
|
0.00
#... |
|---|
|
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 |
1.20
#... |
|---|
|
Did you crop the image in the software? Did you catch a “window” - sub frame ? The crop may not be aligned on the Bayer matrix. Same may happen with the driver crop (if driver has an issue) to remove overscan. Try capturing full sub with overscan to see if the problem persists. |
|
0.00
#... |
|---|
|
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.  |
|
0.00
#... |
|---|
| I forgot to add, ignore the white line across the top and the black line down the left side. They are screen grab edges and not part of the master dark. The band is just under the white line in the top. |
