streaks after meridian flip

I hope this is a fair question for this forum;

Firstly - I am getting a bunch of diagonal streaks in a patch at the top center of my images that only appears immediately after a meridian flip. They appear to be associated mainly, but not entirely with a bright star in the area. Any ideas on what might be happening and how to chase the problem down would be appreciated

Secondly - I recall watching a Fundamentals video that used the GAME script to weed out dust donuts in some sub-frames. I think that may be helpful in processing these images while I try to correct the root cause of the problem. Would that be a decent approach here as I'm reluctant to junk the otherwise good frames?

Comments

  • Scattered light... yeah. It depends on how many subframes it occurs in.
    If a small number- then straight up rejection. (Selective Rejection)
    Selective Rejection:

    Pixel Substitution:



    -the Blockhead


  • I just jumped to the Pixel substitution link and the thumbnail looks exactly like what my Pelican Nebula frame looks like after a meridian flip. At least I know what I'm dealing with now and will watch and absorb the lesson.

    What a brilliant resource you are providing - it really does accelerate the learning curve.

    Many thanks -  Paul

  • Please let other people know... thanks
    -the Blockhead
  • Hi Adam,

    Absolutely - more than happy to spread the word.

    I'm working on calibrating and  integrating the troublesome dataset now (smarter people than me pointed out that the light is coming from Deneb, not very far away from the scattered light on the Pelican Nebula image).

    I am following the selective rejection approach with over half of my frames affected. I'm taking the view that it is better to have more data with the likely outcome being a small area of the image with slightly worse SNR - but the other way of looking at it is that most of the image will have better SNR than if I junked the problem frames.

    Having followed your SR video, I can see how to implement the technique using the standalone image integration tool, but I don't think I can do it using the integration options in WBPP. I'm fine with that, but can you confirm that is the case, or am I missing something that would allow me to do it all in WBPP?

    Thanks again - Paul
  • Yeah, you would need to do it in two steps... you couldn't use WBPP from the beginning in one go. My suggestion is to do everything in WBPP except ImageIntegration. This is the part you will need to do your selective rejection on the images... and then do Image Integration "manually". If you choose to do Local Normalization... it *can* work (you would load these files)... but... no guarantees. You might just want to use Image INtegration with the global normalization method. 

    -the Blockhead
  • Hmm - I've tried this and must be doing something wrong, but can't see what;

    I have low range rejection selected and low range set to zero. However, the integration isn't rejecting the zero value pixels inside the GAME ellipse. When I look at the pixel rejection map, I see a speckled 'noise' pattern everywhere except inside the ellipse - where instead of seeing a grey oval at around 50% (half the frames), I see complete black - all zeros. So even the low range pixels in the good images are not being rejected.

    I've tried with no normalization and no drizzle and pretty much followed the integration setup in the video, but I can't see what I'm doing wrong. Any ideas on what I'm missing?
  • Are you using Winsorized Sigma Clipping?
    GESD is harder to get to work... 
    -the Blockhead
  • No, I used used GESD following the tutorial, I’ll try winsorized sigma clipping and report back.

    Still - why aren’t the zero value pixels being rejected? Shouldn’t the rejection be independent (additional to) whatever rejection algorithm is in play? And even more strangely, why are *no* pixels being rejected within the Game ellipse, unlike other areas in the image? It is almost as if the logic of the rejection is inverted (ie; zero value pixels are not rejected?)

  • The thought has occurred that I may be seeing this because I have a high percentage of bad frames, probably a little over 50%. So that will really mess up any statistical algorithm that relies on a somewhat normal distribution. My median value will be zero, for example. I have a couple of ideas to check this and work around it if so.
  • edited August 2023
    GESD is a bit special. He has a different metric for accounting for values greater than or less than the median. 
    And yes, the number of frames you are selectively rejecting need to be significantly less than the good ones. Otherwise, you should use the pixel substitution method.

    -the Blockhead
  • edited August 2023
    In case this helps someone, I was able to solve this by using a  Frankenstein mash up of the rejection and substitution techniques. The GAME rejection method didn't work on my data because I had too many bad frames (they occurred after a meridian flip - so more than half). The substitution method didn't work on my data because all the RGBL frames had artifacts (R wasn't bad, but that left me with only one layer) so I couldn't match the colours in the repair patch. So I performed bad pixel rejection as follows;

    1) Integrate the complete stack, including bad frames (full_master)
    2) Integrate the "clean" sub-set of good frames (clean_master)
    3) Linear fit clean_master to full_master
    4) Using a blurred GAME mask and iif(inrect(x,y,a,b),clean_master,full_master) substitute the good (if slightly noisier) pixels into the full stack.

    The net effect of this, I think, is essentially the same as the pixel rejection method but should work with any ratio of bad to good frames and will work with any set of integration parameters (so I was able to local normalization and drizzle for example). It also nicely feathers the noisier image into the cleaner one with a very good color balance. I really couldn't discern the repair.
Sign In or Register to comment.