Skewed Alignment

Farzad_k

Well-known member
Hello.

I am noticing that occasionally one of the registered subs appears to be strangely skewed. I don't know what is causing this. The image I am presenting here has been calibrated, debayered and registered.

Thanks for any input.

Farzad
 

Attachments

  • 2020-07-10_16-16-42.jpg
    2020-07-10_16-16-42.jpg
    245.4 KB · Views: 55
Hi Farzad,

I have never seen anything like this, and nothing like this has ever been reported AFAIK. Can you please upload a set of images where this can be reproduced? I need the calibrated/debayered images that you are using as input for the StarAlignment process.
 
I have seen this, I believe only once and a number of years back.
With a bit of effort I resolved it, but do not recall exactly how.
Try "Blinking" your individual subs and see if one (or more) are problematic.
Good luck.
Mark
 
Hi Juan,

I sent you an example and made the images available to you. The way that I resolved this was to use the ImageSolver and then the AlignbyCoordinates script using Undistort as the method. Afterwards, the images registered fine with StarAlignment.

The email was sent on May 29th. The data is from the 1m telescope in Chile.

-adam
 
Hi Farzad,

I have never seen anything like this, and nothing like this has ever been reported AFAIK. Can you please upload a set of images where this can be reproduced? I need the calibrated/debayered images that you are using as input for the StarAlignment process.
Hi Juan.

I am currently uploading the entire session onto Google Drive and it is taking some time to upload. The link to the shared folder is embedded >here<. Files should be available in one hour.

Please note these files were part of an acquisition exercise and don't have the right temperatures which I am sure has nothing to do with the behavior during registration.


Thanks for looking into this and please let me know if you need any more information.

Farzad
 
Hi Adam,

I am sorry but for some reason I didn't receive the files you sent to me. Either I overlooked them (not too surprising given my workload) or they got lost in our network. Can you please send them again?
 
Problem found. One of the frames, namely "M13_Light_120sec_frame1_2020-07-08_c_d.xisf", is wrongly tracked and has a huge amount of hot pixels represented as groups of several contiguous pixels (forming cross or square artifacts) after demosaicing interpolation. Bad tracking has generated multiple star images. So the problem is:

- The star detection algorithm cannot find reliable stars for alignment, since basically all stars are represented as elongated and defocused artifacts.

- Hot pixel artifacts are too large to be removed by the hot pixel removal routine, so all of them are detected as 'excellent' alignment references.

- Since the amount of false alignment references is so large (about 40,000 detected), the probability of finding a false but mathematically valid registration transformation is very high.

So this is not at all a bug in StarAlignment, which is actually finding a registration transformation very efficiently. This problem is the result of bad data. Remove the above referred frame from the data set and there will be no alignment problems. Also try to calibrate the data correctly, so hot pixels are removed before demosaicing.
 
Hi Juan,

I am going to send you a private message on this forum with the details.
In my case, the problem isn't hot pixels. I would not able to figure it out.
-adam
 
Problem found. One of the frames, namely "M13_Light_120sec_frame1_2020-07-08_c_d.xisf", is wrongly tracked and has a huge amount of hot pixels represented as groups of several contiguous pixels (forming cross or square artifacts) after demosaicing interpolation. Bad tracking has generated multiple star images. So the problem is:

- The star detection algorithm cannot find reliable stars for alignment, since basically all stars are represented as elongated and defocused artifacts.

- Hot pixel artifacts are too large to be removed by the hot pixel removal routine, so all of them are detected as 'excellent' alignment references.

- Since the amount of false alignment references is so large (about 40,000 detected), the probability of finding a false but mathematically valid registration transformation is very high.

So this is not at all a bug in StarAlignment, which is actually finding a registration transformation very efficiently. This problem is the result of bad data. Remove the above referred frame from the data set and there will be no alignment problems. Also try to calibrate the data correctly, so hot pixels are removed before demosaicing.

Thanks a lot for looking into this.

So, I need to be more careful with calibration. I do see the hot pixels in the debayered images. I don't see the bad tracking on frame 1 though. All stars seem to be round or near round to me. I will work on this though.

Farzad
 
Hi Farzad. See attached screenshot of your "M13_Light_120sec_frame1_2020_07_08_c_d" image, where bad tracking is clearly shown:

Desktop_Preview01.jpg
 
Hi Farzad. See attached screenshot of your "M13_Light_120sec_frame1_2020_07_08_c_d" image, where bad tracking is clearly shown:

View attachment 8723

Thanks Juan, I see the problem now.

In terms of the bad pixels and better calibration of the light frames, I wonder why dithering wasn't enough to deal with bad pixels. Perhaps the dither was too small? For bad pixels, I am experimenting with various pixel rejection settings to find the right parameters for isolating them out during integration. Practicing with a few subs, it doesn't look like I am able to put a dent into it by varying pixel rejection values or by Cosmetic Correction. You have any recommendations?

Thanks

Farzad
 
I've had a lot of these distorted frames from StarAlign recently (example attached) :
View attachment M15_f20_sa_s.jpg
The problem images seem to have a few things in common:
  • relatively poor seeing (so large, fuzzy stars)
  • high background brightness, so many smaller stars not detectable
  • fields (such as globular clusters) with a large number of stars, many with overlapping images.
This obviously makes it difficult to correctly identify star pairs for alignment. I have noted that the same images are often unsolvable with ImageSolver (so I can't even abandon StarAlign and use ImageSolver followed by the slow but very effective AlignByCoordiates utility). For me, these images are an unavoidable consequence of urban backyard imaging on summer nights with no real darkness.
It is rather frustrating that StarAlign proposes highly distorted solutions like this (which may be reasonable in complex wide field mosaic situations), when the input is a stack of narrow field images with a few pixels of dithering. It would be nice (for the user, and perhaps for the algorithm) if the user could hint at this "expected solution" type. It might also help if the search for alignment stars could be limited by a mask (e.g. to exclude the core of a cluster). (I have read the note on using previews to constrain star searching, but importing views and creating previews would be hard work for a stack of 30 images).
 
so large, fuzzy stars

This is never a reason for problems like the one we are discussing here. Hot pixel artifacts is a common reason. Can you please upload a reduced data set where we can verify this issue with your data?
 
Fred,

Yes to the hot pixel reason. Usually this is the problem Fred. Did you employ cosmetic correction?

Did you watch my video above?

It is literally a matching example of your screen shot.
-adam
 
Last edited:
Adam, I have watched it and am ready to apply CC. It is my understanding it gets applied post calibration and not after debayering, is that correct?

Also, why is it that the dark master is not getting the bad pixels out at integration phase? The documentation says: "...and also in instrumental defects such as hot or cold pixels and bad pixel rows and columns (with the necessary help of some dithering between subexposures!).". I checked and even though I had dithered my data they all line up pretty well before registration, meaning that dither either did not actually happen, although I was watching SGP saying it is happening, or dither may have been too small.

Farzad
 
Back
Top