Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

PI Stacking Oddity

Astrophotography Imaging Software
  • Please log in to reply
32 replies to this topic

#26 N1ghtSc0p3

N1ghtSc0p3

    Viking 1

  • *****
  • Posts: 514
  • Joined: 19 Feb 2011
  • Loc: Texas

Posted 04 May 2021 - 07:53 PM

Thanks for sharing the single sub. I did two different debayer steps, one with RGGB (typical) and one with GBRG (suggested in a previous post). The only other processing I did was applying ABE to each, and then transferring the auto-stretch (from STF) to the HistogramTransformation to go non-linear so I could save them in .jpg format. There was no color calibration done to either of the single subs. Here are the two frames.

 

RGGB:

 

RGGB_VNG_ABE.jpg

 

and GBRG:

 

GBRG_VNG_ABE.jpg

 

IMO, the GBRG is the correct demosaicing pattern to use for the 533MC as it looks more natural.

 

Cheers!


Edited by N1ghtSc0p3, 04 May 2021 - 07:57 PM.


#27 Yooper_

Yooper_

    Explorer 1

  • -----
  • topic starter
  • Posts: 64
  • Joined: 22 May 2020
  • Loc: Upper Peninsula of Michigan

Posted 04 May 2021 - 08:08 PM

Yooper_,

 

   OK, I have initial results of my testing of the calibration frames.

 

   In answer to your question about finding the average ADU of an image, you only have to open up the Statistics Process in PixInsight (Process | Image | Statistics).

 

   I was worried about using the ASCOM driver generated Dark Frame you took. This is not usually recommended. Any time you calibrate Light Frames, you must exactly match Exposure, Gain, Offset, Temperature, Device Driver, and Capture software for all frames. Any mismatch can and often does cause problems. That is the case here. The ASCOM driver Dark frame, while looking to have about the right median ADU, did not work well at all. It led to massive clipping during calibration.

 

   To get around the bad Dark Frame issue without the use of the ASCOM Dark Frame, I cheated. I took the Bias Frame and simply added 4 ADU to it to simulate a Dark frame. When the Light Frame was calibrated with the Bias_Plus_4 frame and also calibrated with a Master Flat made from subtracting the Bias from the Flat, the result looked pretty good but still suffered from clipping where too many pixels were turned to pure black (0 ADU). This was then fixed by doing the calibration again but adding a 900 ADU output Pedestal to the calibrated result. At this point, the Light was well calibrated and only had 2 pixels remaining that were clipped to black. (I strongly feel these would have been cured by using Cosmetic Correction which I did not run.)

 

   After doing the manual calibration, the weak blue channel showed up again. I traced this back to the Flat Frame. A portion of the weak blue channel seen before may be coming from the color balance settings in the driver but another portion seems to be coming from the light source being slightly deficient in blue light. At least there was not the massive clipping in the blue channel seen before.

 

   With more playing, I think I could come up with a manual process for you to follow to recover the data you have but it would not help you with your learning of PixInsight. The main thing to do is to try to find out what happened to your first set of Dark frames and then secondarily investigate the relative color balance of your Flat light source. (You can do that by taking flats with various light sources, deBayering them and examining the RGB Flat to see how the three color channels relate to one another. You want each to be roughly centered in the histogram although they do not need to be perfectly aligned. Just ensure that no color channel is too close to the left or right edge of the histogram and that the "free space" on the left and right is about equal. (In other words, get the average ADU into the 30,000 to 34,000 ADU range.)

 

 

John

This is amazing information, thanks folks!

 

The M101 stack I was working with was a short night to work the bugs out. The bugs ended up being much more interesting than I expected, so this has been a great learning opportunity. I'm using a tracing pad for my flats so I wouldn't doubt it is deficient in one color type.

 

I've got plenty of poor weather for the next week to re-shoot all of my calibration frames.

 

Am I better off to stick with the ASCOM Driver, or does it not matter as long as I use the same driver across all frame types?



#28 jdupton

jdupton

    Gemini

  • *****
  • Posts: 3,369
  • Joined: 21 Nov 2010
  • Loc: Central Texas, USA

Posted 04 May 2021 - 08:15 PM

Yooper_,

 

   It does not really matter which driver type you use. Just always shoot all frame types (Light, Dark, Bias, Flat, FlatDark, etc) for a session using the same driver.

 

   One nice thing about the ASCOM driver is that it bypasses the native driver color balance settings and always uses 50/50 whether you have saved that value or not.

 

 

John



#29 Yooper_

Yooper_

    Explorer 1

  • -----
  • topic starter
  • Posts: 64
  • Joined: 22 May 2020
  • Loc: Upper Peninsula of Michigan

Posted 04 May 2021 - 08:18 PM

Yooper_,

 

   It does not really matter which driver type you use. Just always shoot all frame types (Light, Dark, Bias, Flat, FlatDark, etc) for a session using the same driver.

 

   One nice thing about the ASCOM driver is that it bypasses the native driver color balance settings and always uses 50/50 whether you have saved that value or not.

 

 

John

Great, thanks John! 



#30 KTAZ

KTAZ

    Surveyor 1

  • *****
  • Posts: 1,812
  • Joined: 09 Apr 2020
  • Loc: Scottsdale, AZ

Posted 04 May 2021 - 08:22 PM

Very strange that ZWO clearly states the CFA as RGGB in their specification.

 

Has anybody contacted ZWO customer service to ask this question? They are quite responsive and usually get back in a few days.

 

OP should do a clean stack with each debayer setting, then do a proper DBE and Color Calibration before making a choice. And I highly recommend you contact ZWO.


  • elmiko likes this

#31 elmiko

elmiko

    Fly Me to the Moon

  • *****
  • Posts: 5,921
  • Joined: 27 Jul 2009
  • Loc: Arizona

Posted 04 May 2021 - 09:43 PM

I use RGGB debayer with the same camera, working fine. Very odd indeed.



#32 bulrichl

bulrichl

    Ranger 4

  • *****
  • Posts: 360
  • Joined: 27 May 2018
  • Loc: La Palma (Canary Islands)

Posted 05 May 2021 - 06:20 AM

IMO, the GBRG is the correct demosaicing pattern to use for the 533MC as it looks more natural.

There is much confusion about the correct Bayer/mosaic pattern of the ZWO ASI533MC Pro in this thread.

 

The single light frame L_2021-04-30_23-26-41_Bin1x1_90s__-10C_2021-04-30_G100.fit (post #16) was captured with APT, and this is its FITS header:

 

FITS_header_APT.JPG

APT-FITS header: BAYERPAT=RGGB, no x and y offsets for the bayer matrix

---


Let's take a look at the histograms of the debayered single light frame:

 

1. Using RGGB:

Histogram_RGGB.JPG

The red and blue channels are different, this is to be expected.

 

2. Using GBRG:

Histogram_GBRG.JPG

The red and blue channels are almost identical, this is impossible. (Using GRBG, the histogram would look similar, because only the red and the blue channels are exchanged.)

 

Assuming that no offsets for the bayer pattern are applied and the origin is 'Upper left corner (top-down)', the above findings prove that the correct Bayer/mosaic pattern is of type XGGY, and not GXYG. And when you try RGGB and BGGR, you will find that only RGGB leads to correct star colors.

 

---

 

The thread from the Sharpcap forum that you cited in post #8 is misleading. This is a FITS header of a different light frame captured with Sharpcap and a ZWO ASI533MC Pro:

 

FITS_header_Sharpcap.JPG

 

Sharpcap-FITS header: BAYERPAT=GBRG, BAYOFFX=0, BAYOFFY=1

 

Sharpcap uses x and y offsets for the bayer matrix. Unfortunately, it uses unusual keywords (presumably own creations) instead of the widely accepted nonstandard FITS keywords XBAYROFF and YBAYROFF (created by SBIG, now Diffraction Limited, see https://cdn.diffract...Definitions.htm ) that PixInsight evaluates as well. This is the reason that the weird comment has been added by Sharpcap "NOTE: Use RGGB on some software (eg PixInsight)". I wrote a personal message to the creator of Sharpcap hoping that this incompatibility will be fixed soon.

 

Bernd

 

P.S.:
In the Sharpcap forum, section Help and Support/Bug Reports, I just found a thread of April 18, 2021 "Issue with FITS files of OSC camera generated by Sharpcap" in which it was requested to include the FITS keywords XBAYROFF and YBAYROFF. Dr. Robin Glover, the creator of Sharpcap replied that in version 4.0 of his software, these keywords will be written to the FITS header additionally.


Edited by bulrichl, 05 May 2021 - 11:17 AM.

  • jdupton, limeyx and jonnybravo0311 like this

#33 bulrichl

bulrichl

    Ranger 4

  • *****
  • Posts: 360
  • Joined: 27 May 2018
  • Loc: La Palma (Canary Islands)

Posted 15 May 2021 - 03:41 AM

According to the SharpCap 4.0 Beta website, beta versions >= 4.0.7703.0 (April 21, 2021) seem to write the additional FITS keywords XBAYROFF and YBAYROFF to the FITS header, so the above mentioned compatibility issue (wrong Debayer/mosaic pattern applied in PixInsight) should occur no longer. I did not check this though.

 

Bernd




CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics





Also tagged with one or more of these keywords: Astrophotography, Imaging, Software



Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics