Newbie Star Alignment Failure

A

Allenbt

New member
I've followed the example in the Light Vortex tutorial on stacking using a few shots I took of M42 (https://www.dropbox.com/sh/7f2fdvgjdlluc42/AACEGgSLpoLRmkOJ24w0GZZ5a?dl=0) after imaging Mars. Relevant parameters are OSC, EFL ~4700mm, 0.2 arcsec/pixel, 0.2 e-/ADU, 8-bit (I know - not ideal). Everything appeared to work fine until I tried Star Alignment. I usually get no matching stars; if I do, it is hundreds - clearly all noise pixels. Since I have a lot of periodic error (the reason the exposures are so short) using noise is the equivalent of stacking with no alignment. I've tried adjusting the detection scales, noise scales, noise reduction, distortion, etc. to no avail. I have enough stars that are not saturated and are above the noise I should hope I could get a solve - see attached, which is a screenshot (to make it small enough to upload here) of one of the original files. So my questions:

1) Is there a way to immediately see what Star Alignment is picking out on the reference frame so I have some feedback as to how the settings are affecting the selection
2) Lacking that - is there a way to manually select the stars I want to use for alignment? Even if I have to do this on dozens of images that would still be less time than I have spent trying to find the right combination of settings
3) There is mild coma. I know the real answer is to correct the optical configuration, but is there a way to reduce this in software? I have other images that I cannot redo. Convolution is the closest I see, but that can't be applied across the entire image.
 

Attachments

  • pM42_22h24m58s616_ISO1600_+37c_Tv6_2020-11-08.jpg
    1,018.9 KB · Views: 55
Obviously neither ImageCalibration nor CosmeticCorrection was applied successfully. There are strong horizontal bands and many hot pixels in your images. This is the reason that StarAlignment fails. If you upload the corresponding light frames and the MasterDark, I will take a look.

Bernd
 
The StarAlignment process in the upcoming 1.8.8-7 version of PixInsight has a new 'minStructureSize' parameter that will help in these marginal cases. I have just tried and these images can be registered in 1.8.8-7 by just increasing this parameter to 16 pixels and RANSAC tolerance to 6 pixels.

This new parameter forces SA to ignore all detected structures with sizes below a specified area in square pixels. This helps registering images with defocused stars, bad tracking, bad calibration, large optical aberrations, extremely low SNR, etc.
 
Thanks for uploading the data. Your light frames (and presumably the calibration frames as well) are JPGs captured with a Canon EOS T3i (= Canon EOS 600D). This might be OK for imaging of planets (I have no experience with it), but it is a bad idea for deep sky astrophotography. When you capture JPGs, a correct image calibration is not feasible. For deep sky astrophotography you should set the camera to use raw (CR2) format, for light frames and all calibration frames. In raw format, the frames of the T3i are recorded as 14 bit Color Filter Array (CFA) data. In PixInsight set the RAW Format Preferences to 'Pure Raw'. The image calibration shall be performed on the CFA data. Only after image calibration (and optionally cosmetic correction) the CFA data shall be debayered. In the case of the T3i, the Bayer pattern is GBRG.

Please see my guide for a more detailed explanation of image calibration: https://pixinsight.com/forum/index.php?threads/for-beginners-guide-to-pis-imagecalibration.11547/ .

Bernd
 
I think, we have no final solution for this issue.
I have a ASI ZWO 2600, which has RGGB pattern, and everything is fine, in the former BPPP as well as now in WBPP.
And I have a ToupTec DSP2600, which has a GBRG Bayer pattern, and says in the FITS files: some programs should use RGGB, i.e. PixInsight.
But unfortunately they have taken away the flexibility to choose a specific pattern as in good old BPP times.
So, and here comes the issue: because PixInsight reads 'GBRG' from the FITS header, it uses GBRG... but it shouldn't, because that leads to wrong debayerred results.

So, what can I do?? Is there eventually a hidden location, where I can choose the preferred Bayer pattern, but cannot find it?

I found 2 solutions, both not desireable:
1st: rollback to BPP
2nd: using BatchEditFITSSingleKeyword to alter GBRG into RGGB in each and every light, dark, bias and flat :-(

Please, help....

Roland
 
I guess there there is a better solution. Please upload a light frame (in FITS format) of your ToupTec DSP2600.

Bernd

P.S.:
Btw, your issue does not seam to be related to the topic of this thread.
 
Last edited:
Unfortunately the forum tells me that the zip file is too large.
I'll prepare a bin4 lightframe
 
What I need is a light frame, not a dark frame, and the binning has to be 1x1.

Please upload to a file hoster and post the link here.

Bernd
 
RolWinde said:
And I have a ToupTec DSP2600, which has a GBRG Bayer pattern, and says in the FITS files: some programs should use RGGB, i.e. PixInsight.
Click to expand...
In order to explain what happens with the frames of your ToupTec camera, I have to go back.

Bayer patterns are altered when
- the image is vertically mirrored and height is even or
- the image is horizontally mirrored and width is even or
- the image is cropped by an odd number of pixels:

Code: 
original    vert. mirr.        hor. mirr.        crop 1 left        crop 1 top
(RGGB)         (GBRG)             (GRBG)             (GRBG)             (GBRG)
R G R G        G B G B            G R G R            G R G .            G B G B
G B G B        R G R G            B G B G            B G B .            R G R G
R G R G        G B G B            G R G R            G R G .            G B G B
G B G B        R G R G            B G B G            B G B .            . . . .

Thus it is crucial to define offsets and orientation unequivocally, otherwise the Bayer pattern might be misinterpreted.

Diffraction Limited created the "Extension keywords" BAYERPAT, XBAYROFF and YBAYROFF that were used by their acquisition and processing software MaxIm-DL https://cdn.diffractionlimited.com/help/maximdl/MaxIm-DL.htm (-> The Basics/FITS File Header Definitions) in order to distinguish different Bayer patterns of OSC cameras. These keywords are nonstandard, but became accepted and are now supported by most processing software that is suitable for astrophotography.

Similarly the programmers of Siril proposed a nonstandard FITS keyword ROWORDER for the vertical orientation of FITS images https://free-astro.org/index.php?title=Siril:FITS_orientation .

PixInsight evaluates all of these 4 nonstandard FITS keywords: BAYERPAT, XBAYROFF, YBAYROFF since v1.8.6.1473 and ROWORDER since v1.8.8-6 in order to find out the CFA pattern of OSC cameras.

Your frame was generated by Sharpcap v3.2.6480.0, 64 bit. This software uses BAYERPAT. It does not use ROWORDER, and it does not comply with the widely accepted keyword names for offsets, but invents its own: it writes BAYOFFX instead of XBAYROFF and BAYOFFY instead of YBAYROFF. This is the reason that the offsets are not taken into account by PixInsight. Please note that this incompatybility is caused by Sharpcap, and not by PixInsight. I suggest you to report this to the creator of Sharpcap. Or use a suitable acquisition software.

RolWinde said:
But unfortunately they have taken away the flexibility to choose a specific pattern as in good old BPP times.
So, and here comes the issue: because PixInsight reads 'GBRG' from the FITS header, it uses GBRG... but it shouldn't, because that leads to wrong debayerred results.
Click to expand...
As to the WBPP settings, no they haven't taken the flexibility: in the Control panel select the light frames (they will be highlighted by an orange background) and change from 'Auto' to 'RGGB' in the section 'CFA Settings'. I hope this helps.

Bernd
 
Last edited:
  • Like
Reactions: dld
Good Grief, I was looking in the lights register all the time, not the Control Panel....
Thank you Bernd
PS: the thread I wanted reply to was Wrong Debayer Pattern Detected
 
bulrichl said:
Your frame was generated by Sharpcap v3.2.6480.0, 64 bit. This software uses BAYERPAT. It does not use ROWORDER, and it does not comply with the widely accepted keyword names for offsets, but invents its own: it writes BAYOFFX instead of XBAYROFF and BAYOFFY instead of YBAYROFF. This is the reason that the offsets are not taken into account by PixInsight.
Click to expand...
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 this compatibility issue should occur no longer. I did not check this though.

Bernd
 
You must log in or register to reply here.
Back
Top