| | 1 | == 2014-05-21 == |
| | 2 | |
| | 3 | The background issue should now be solved for good. There were two issues the contributed to this problem. The first one was the value being written to disk was being trucated via an effective int() call, which isn't appropriate around zero. To make this fully consistent, psLib now takes the floor() of the value. The second issue related to the fuzz value, and I was confused about the math in the 2014-05-16 plot that implied that a fuzz value of 1.0 was needed. Gene pointed out on Monday that the floor function effectively removes a random value between 0 and 1 for all numbers fed into it. To correct for this, the fuzz value needs to add back this random value, corresponding to a fuzz value of zero. Due to the int vs floor vs ceil, this is mathematically equivalent to what I was finding (int for negative numbers is ceil, floor and ceil are offset by 1 unit). |
| | 4 | |
| | 5 | I launched a small (27 exposure) set from the SAS to directly compare with the previously processed SAS, and ran the same test as on 2014-05-16 to check that the residual background on the stacks created from these newly processed does not increase with number of inputs: |
| | 6 | |
| | 7 | [[Image(comparison.png)]] |
| | 8 | |
| | 9 | This plot shows the background level is flat for all input numbers, fixing the issue. |
| | 10 | |
| | 11 | For dealing with older data, the background offset can be determined by checking the BSCALE value on the image. The background is offset by +0.5 * BSCALE, due to this 1/2 bin issue with the fuzz value. |
| | 12 | |
