APP stacking process slowing down with 157 Lights

Activity Forums Astrosoftware Astro Pixel Processor APP stacking process slowing down with 157 Lights

Tagged: 

Viewing 8 posts - 16 through 23 (of 23 total)
  • Author
    Posts
  • #13781
    Haverkamp
    Participant

    Kees, I see your data in our dropbox, I you upload a  couple of lights and a couple of flats, I’ll check what happens in calibration and if APP applies the masterbias frames to the light and flat frames.

    #13793
    KeesScherer
    Participant

    This new stack (same L,B&F) started at 12:05. It is now 15:38 and at “Light stack” 18% running at 12 % per hour pace. Total estimated time is between 9 and 10 hrs….

    #13799
    KeesScherer
    Participant

    Good news, the stack finished in 7 hrs. I am uploading to our Dropbox.

    #13803
    Haverkamp
    Participant

    Okay, so regular sigma rejection with 1 iteration LNC is faster than no LNC with Linear Fit rejection.

    From the statistics of the stack I see a large boost in noise reduction compared to the previous stack ?

    HDU1 – NOISE-1 = ‘ 3.27E-04’          / noise level of channel 1
    HDU1 – NOISE-2 = ‘ 2.75E-04’          / noise level of channel 2
    HDU1 – NOISE-3 = ‘ 4.09E-04’          / noise level of channel 3
    HDU1 – SNR-1   = ‘ 1.28E+01’          / Signal to Noise Ratio of channel 1
    HDU1 – SNR-2   = ‘ 1.44E+01’          / Signal to Noise Ratio of channel 2
    HDU1 – SNR-3   = ‘ 1.45E+01’          / Signal to Noise Ratio of channel 3
    HDU1 – medNR-1 = ‘ 8.42E+00’          / median noise reduction, channel 1
    HDU1 – medNR-2 = ‘ 8.62E+00’          / median noise reduction, channel 2
    HDU1 – medNR-3 = ‘ 8.79E+00’          / median noise reduction, channel 3
    HDU1 – medENR-1= ‘ 1.60E+00’          / effective median noise reduction, channel 1
    HDU1 – medENR-2= ‘ 1.92E+00’          / effective median noise reduction, channel 2
    HDU1 – medENR-3= ‘ 2.86E+00’          / effective median noise reduction, channel 3
    HDU1 – refNR-1 = ‘ 8.62E+00’          / reference noise reduction, channel 1
    HDU1 – refNR-2 = ‘ 8.77E+00’          / reference noise reduction, channel 2
    HDU1 – refNR-3 = ‘ 8.80E+00’          / reference noise reduction, channel 3
    HDU1 – refENR-1= ‘ 1.68E+00’          / effective reference noise reduction, channel 1
    HDU1 – refENR-2= ‘ 2.04E+00’          / effective reference noise reduction, channel 2
    HDU1 – refENR-3= ‘ 2.99E+00’          / effective reference noise reduction, channel 3
    HDU1 – LNC-DEG = ‘1st degree LNC’     / Local Normalization Correction degree
    HDU1 – LNCRMS-1= ‘ 1.07E-04’          / Local Normalization Correction RMS of channel 1
    HDU1 – LNCRMS-2= ‘ 7.28E-05’          / Local Normalization Correction RMS of channel 2
    HDU1 – LNCRMS-3= ‘ 8.70E-05’          / Local Normalization Correction RMS of channel 3
    HDU1 – LNC-ITER=                    1 / Local Normalization Correction iterations

    noise reduction has improved from 6,?? to almost 9. So that is a huge improvement, have you noticed this when you compare this stack to the previous stack?

    Assuming the old noise reducation was 6,5 and the new one is taken conservatively at 8,5, we have a 8,5/6,5 = 1.3 noise reduction between the stacks. So this stack is 30% less noisy ;-) that’s huge.

    The LNC RMS are well below the noise values as well. That is a good sign.

    #13807
    Haverkamp
    Participant

    Even snel de stack verwerkt met APP, niet helemaal tevreden over de kleurbalans, maar is wel heel gaaf deze.

    #13809
    KeesScherer
    Participant

    Yes i can see a visual improvement in noise level between stack 2 (left) and stack 3 (right). I will post-process stack 3 this morning in PI and upload the result to our Dropbox.

    #13817
    Haverkamp
    Participant

    Nice @keesscherer ?

    I notice there are some hot pixels still showing, these could easily be removed (and most efficiently) with an adequate Bad Pixel Map.

    The Bad Pixel Map will never degrade image quality (can’t inject noise) and will remove the non-linear pixels from your light frames.

    Unlike outlier rejection filters, it can’t hurt your SNR ? so it’s a much better solution to get rid of those hot pixels.

    Outlier rejection should always be considered a last resort to remove artefacts in your data ?

    Some more good news, I have been profiling APP on my MacBook and after having made 2 big stacks in a row the application became really slow, like you describe.. so I am now looking in detail for possible memory leaks and inefficient programming. I think I have already found a couple of problems which I’ll try to fix.

    #13820
    Haverkamp
    Participant

    Even een versie met APP post-processing met wat andere kleuren, ik upload het naar je dropbox @keesscherer ?

Viewing 8 posts - 16 through 23 (of 23 total)
  • You must be logged in to reply to this topic.
Scroll to Top