Stack Rejection; Stack Discussions

August 30, 2012

In an attempt to identify which component of ppStack is interfering with the "correct" pixel rejection, I reran skycell.1315.083 from the SAS with both the default and the unconvolved ppStack recipe. The results are shown below for the same five burntool streaks as in the 2012-08-29 discussion. All frames have the default (convolution using in stacking. Image shown is the output unconvolved stack) image on the left, and the unconvolved stack on the right. It's clear from these images that the convolution code does not appear to be the culprit, as the image that used the convolution has fewer and smaller burntool features printing through.

August 29, 2012

Nigel pointed me to a number of remaining linear structures in the SAS data, and I scanned through a number of them. These seem to be almost entirely features due to burntool issues, as shown in the images below. For all images, the first 19 panels show input warps (of 20 total inputs. One was removed for space issues), with the final (bottom right) panel showing the unconvolved SAS8 stack for the same position. The green region markers are linear features that have a detection along them, as supplied by Nigel.

This set shows that the faint linear feature with a detection is caused by a single burntool trail from input 19. Other burntool trails (from inputs 7, 9, 10, and 17) visibly print through onto the final stack as well.

A pair of parallel features are visible in the stack, the result of a burntool trail that has had the core subtracted well, but the edges still remain.

Two inputs create the burntool trail. Note that only the fainter end of the trail is printing through into the stack

Two inputs cause the burntool trail. Note the absence of the bright BT trail from inputs 7 and 9.

Two inputs again.

Given that all of these structures are caused by burntool, there are two obvious strategies to remove them:

1. Improve burntool fitting. The structures that print through are close (within tens of pixels) from the edge of the cell. Burntool has known problems detecting and correcting stars near the cell edges, so it is likely that this is the reason that they aren't subtracted better. The split trail (image two) shows that the brightest burns are not being fit with the correct width, another issue that can hopefully be resolved by burntool. The downside of any such change is that it would require new burntool processing for all exposures, which could slow down reprocessing. The development time for burntool fixes is also not likely to be fast.

2. Improve stack pixel rejection. The fact that the brightest portions of these trails are removed suggests that the current stack rejection is correctly identifying these outliers and rejecting them. However, as the trails become faint (and therefore more consistent with the sky level), they are less likely to be removed from the pixel array. The large variance values clearly let larger outliers remain that is desirable, but without further algorithm tests, it's unclear how to fix this.

August 29, 2012: Example pixel

Here is the input pixel data for the region marker in set #3 above:

exp_name Input pixel Input Mask Input Variance sqrt(V + (0.1 * D)2) sqrt(V + sKMM2) D - median(D) D - KMMmean(D) Z_KMM Z_sys
o5745g0469 -23.9121 128 100.885 10.3249 10.802 -26.5705 -25.0804 -2.42912 -2.45978
o5746g0483 -11.189 8192 56.7516 7.61601 8.51761 -13.8474 -12.3573 -1.62254 -1.62574
o5748g0414 -5.42352 0 70.1953 8.3958 9.27326 -8.08191 -6.59186 -0.785138 -0.871528
o5746g0462 -3.30118 0 50.6332 7.12335 8.15054 -5.95957 -4.46952 -0.627446 -0.731187
o5745g0471 -1.07381 0 60.485 7.77795 8.73402 -3.7322 -2.24215 -0.28827 -0.427318
o5746g0474 1.12729 8192 73.2749 8.56082 9.43785 -1.5311 -0.04105 -0.0047951 -0.16223
o5746g0472 2.15857 0 65.3082 8.08423 9.0059 -0.49982 0.99023 0.122489 -0.0554992
o5745g0461 2.65839 0 66.9029 8.18374 9.09401 0 1.49005 0.182074 0
o5745g0479 3.1499 128 136.597 11.6917 12.3448 0.49151 1.98156 0.169484 0.0398151
o5745g0481 5.66383 0 66.293 8.16173 9.06041 3.00544 4.49549 0.550801 0.331711
o5745g0449 7.05781 0 67.3096 8.23454 9.11634 4.39942 5.88947 0.715215 0.482586
o5748g0394 40.3914 128 71.9988 9.39752 9.37 37.733 39.2231 4.17377 4.027
o5748g0405 56.0568 128 110.147 11.8983 11.2225 53.3984 54.8885 4.61314 4.75816

The first column contains the input exposure name, followed by the image/mask/variance values for that pixel. Next we have two calculations of the value of sigma for that input. The first adds a "systematic error" component equal to 0.1 * image value. The second uses the KMM mixture model calculation to determine the scatter of the main component, and uses this as the systematic component. The next two columns have the deviation from some "mean" values. The first is the default method, which simply calculates the median value (2.65839) and subtracts this off the image data. The second again uses the KMM calculation, and removes the mean value of the main component (1.16834). Finally, I've made two versions of Z = (D - m)/s, using the systematic/median form and the KMM calculated forms.

Based on the rejection threshold of 3.5 (from the config file), both of the burn inputs should have been rejected from the final stack. I do not understand why this hasn't happened, and suggests that ppStack has some issue that is incorrectly doing the rejection.

This example pixel also shows that excluding all pixels with an input value of 128 (SUSPECT) is not necessarily a bad thing. Only one non-extreme input has this bit set.

July 31, 2012

Nigel sent around a jpeg of a mean stacked image (, ignoring masking and ignoring variances. This is easy enough to reconstruct, and I did so for this example skycell (skycell.1406.045, stack_id 1033436). In addition, he overlaid the warp detections ( with psfQf cuts and stack detections ( on this image. I've copied these images to this wiki to keep everything together (I've had to increase the JPEG compression to fit under the wiki filesize limit).

Comparison of mean stack to ppStack stack

This image shows a mosaic of 20/22 inputs around the region of the reflection ghost visible in the mean image. Only two of these inputs contain this feature, so although it is obvious in the mean stack, it is largely removed in the ppStack result. We also have masks on this object, which helps rejection on most pixels, as shown by this image which is a mean combined, rejecting all input pixels that have any mask bit set. This is somewhat more conservative than ppStack, which allows "suspect" pixels to be considered for inclusion if they are consistent with the values from other inputs.

Comparing the unconvolved ppStack output (left) to the mean stacked image (right), it is clear that the majority of the non-astronomical sources are eliminated by ppStack. This includes most of the reflection ghosts, the bright amplifier, the ragged detector edge, and the bad edge cells.

Single frame detections

The psfQf cut shows that the bulk of the "linear" features are removed when psfQf > 0.85. These linear features seem to largely be detections at the edge of the cell, as can be seen by comparing the pattern in the meandetections.jpg image to the edge pattern visible in the warp mosaic.

Stack detections

The detections from the meanstackdetections.jpg do seem to more consistently ignore the features visible on the mean image. I've highlighted two examples where this is not the case:

ppStack largely rejects the pixels that make up the bright reflection ghost, but a small region shows this printing through somewhat (at the ~few sigma level it seems). Comparing the shape of this region with the stack detections in this region shows that this bright feature is causing some false detections, but at a substantially reduced rate compared to the warp detections.

Although this bad edge chip has a mask, some pixels are masked with the "SUSPECT" bit, allowing ppStack to consider them for the stack. Clearly, it's not being quite strict enough in rejecting these pixels, as some of the bright values pop through (corresponding to a pixel that had only the SUSPECT bit set). Comparing this to the stack detections shows that these bright pixels do create detections (the pixels are >5 sigma deviations from their neighbors, so this is understandable). Note however, that these objects should have moment values that are clearly wrong. A grouping of a few pixels is substantially smaller than a PSF.


ppStack's outputs are superior to a simple mean, and reject the majority of deviant input pixels. This process is not perfect, and there are probably improvements that could be applied to the algorithm. The detections from ppStack seem to be largely reliable from a quick scan of the meanstackdetections plot and the ppStack output. Individual frame detections are improved greatly by the psfQf cut, but some non-astrophysical sources can still sneak through, such as the clumps around the end of the bright reflection ghost (the model for this does not fully model the "bloom").