| 5 | | I reproduced Peter's analysis for that particular stack, and obtained largely identical results and numbers as he presented. Histograms of the object SKY values have a positive bias in the warps, whereas histograms of the SKY values from the stack do not have the same bias. |
| | 5 | From the DRAVG page, Peter reports that his manual psphot SKY distribution is centered around 1 count, while the SAS static sky distribution is centered around ~0.3. I cannot reproduce the SAS distribution either. The current trunk, the current PV3 processing tag (ipp-pv3-20140717), the ipp-pv3-cr-20140614 processing tag that was used for the SAS processing, and that same tag reverted back to r36878 to match the log file entry for the original static sky run all agree with Peter's distribution: |
| | 6 | |
| | 7 | [[Image(staticsky_comp-3365975.png)]] |
| | 8 | |
| | 9 | I don't know what went wrong with the SAS reduction, as I can not reproduce the values previously published. I believe the ~1 count offset from zero in the stack is consistent with the remaining small background bias that leaves a small amount of background on the input warps. This test also confirms that with a fixed seed value, psphot and psphotStack produce identical background models. This is expected, as they both make an identical call to the psImageBackground function. |
| | 10 | |
| | 11 | Moving on to Peter's analysis of warp/stack SKY levels, I first confirmed that the ppStack code does not subtract any values from the input warps. The images are scaled by a multiplicative factor, individual pixels are rejected, and the remainder are summed. Because of this, the pixel distributions of the stack and the input warps must agree to within a scaling factor. Looking at histograms of all warps and the stack (which I constructed from the warps listed on Peter's analysis, and adopting the factor of 14 between an individual warp and the stack listed there): |
| | 12 | |
| | 13 | [[Image(warp_stack-comparison.png)]] |
| | 14 | |
| | 15 | Fitting Gaussians to the populated bins from that histogram yield "true" mean and sigma values, with warp "4" being the outlier Peter identified. |
| | 16 | |
| | 17 | || Image || Mean || Sigma || |
| | 18 | || 0 || -0.0720957 || 25.3298 || |
| | 19 | || 1 || -0.0575938 || 24.49 || |
| | 20 | || 2 || -0.0890201 || 18.8579 || |
| | 21 | || 3 || -0.0399057 || 25.6635 || |
| | 22 | || 4 || -0.633794 || 64.1527 || |
| | 23 | || 5 || -0.0685074 || 34.0803 || |
| | 24 | || 6 || 0.112552 || 31.1058 || |
| | 25 | || 7 || 0.0159295 || 47.0761 || |
| | 26 | || 8 || 0.104313 || 30.5573 || |
| | 27 | || 9 || 0.119509 || 32.5571 || |
| | 28 | || stack || -0.0428245 || 228.501 || |
| | 29 | |
| | 30 | These values can be used to check that the psphot claimed background level is a function of the sky sigma, as the bias report below discusses. Plotted are three realizations of each warp: from my ppStack process (1), from Peter's ppStack process (3), and I thought that was another psphot run, but it's Peter doing what I claimed I just did but getting a different answer (2). Biased because I clipped at +/- 100? I'll need to fix this bit. |
| | 31 | |
| | 32 | [[Image(sigma_bias.png,200px)]] |
| | 33 | |
| | 34 | Looking at the difference between psphot and the full image fits (to confirm that the outlier does have the same bias as the other images): |
| | 35 | |
| | 36 | [[Image(sigma_bias_cor.png,200px)]] |
| | 37 | |
| | 38 | [[Image(multiple_stack_runs.png)]] |
| | 39 | |
| | 40 | [[Image(warp_stack_pixel_comp.png)]] |
| | 41 | |
