2013-12-09

Following the discussion at DRAVG this morning, the exposure time targets are now 1.0 seconds, and the images are written out at 32-bit float values.

2013-12-06

In response to Danny's email on the coverage maps/stack summary images, I've made a set of changes to the ppSkycell code to address these concerns:

  1. Skycell overlaps. The original processing used a naive method that filled pixels such that the last skycell to cover a pixel was the value accepted (unless that value was non-finite). This ignores any definition of the "primary skycell" for a point on the sky, and introduces odd artifacts related to the edges of skycells (such as the ramp up of the variance in these positions due to convolution issues). The new code allows the last skycell that covers a pixel to be the accepted value only if that pixel is closer to the center of the skycell than the previous value was. This removes the bad overlap regions, and produces a more consistent coverage map.
  2. Zeropoints. The original processing used the values from the stack stage products, with no concern for the differences in exposure times for stacks from different skycells. The solution here has been to scale each input image by a factor = (median_exptime / exptime_skycell)**order. This scales each input to match the median exposure time across the entire projection cell. The order is set to zero for EXP, NUM, and MASK products, as it makes no sense to do this scaling for absolute values. The order for the IM is 1, and for the VAR, 2.
  3. Exposure time values. To ensure that these scaled values are useful, the median exptime is now stored in the image header in the EXPTIME keyword, which previously had NAN values.

This set of changes has led me to notice that the binned MASK products appear to be largely useless. In order for a pixel to be flagged with a given pixel value, the following events must occur:

  • For each input into the stack, that bit value must be raised in a majority of the input pixels. This is necessary for a flag value to exist in the unbinned stack masks.
  • For each pixel of the binning region, the mask must also have that bit value raised in a majority of input pixels. Given our binning sizes of 16x16, this requires a rather large defect to make it to the binned value.

Because of this, I do not think that the binned MASK product is actually very useful. Instead, I believe that the EXP and NUM products, which list the binned exposure time on the sky and number of exposures that contribute, contain all the information for which the MASK product may have been used. A spot check shows that most of these products are largely set to zero value, further suggesting that we may be better served to skip producing this product.

For the two test skycells in Danny's email, I've put into the table below the original processing (that which is currently available via the postage stamp server), and a "final" processing with the new ppSkycell code. The IMAGE product jpgs shown below have been scaled to be 75% of the size manually to get them in under the wiki file size limit.

Product projection_cell Original B1 Original B2 Final B1 Final B2
Image 1423
1604
Mask 1423
1604
Number 1423
1604
Variance 1423
1604
Exptime 1423
1604

Attachments