Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
wrong flux-scaling of output weight files?
09-17-2014, 22:31
Post: #1
wrong flux-scaling of output weight files?
Dear all,

I'm struggling to come to terms with the way output weight maps are scaled when I'm using flux-scaling as well. As a concrete example, I'm using the following workflow - for reference, all raw input data are multi-extension FITS files with one extension per CCD in a multi-CCD wide-field imager:

1) run swarp on a single frame with multiple CCDs to combine all CCDs into a large frame covering the entire focalplane.

2) Run swarp on the output of step1, again only using a single frame, but activating background subtraction. I found that splitting the focal-plane merging and background subtraction into two steps, rather than applying the background during step 1, solved the problem of background mismatch between detectors in the case of extended sources larger or comparable to the size of a single CCDs.

3) Perform the actual stacking of all frames generated by step 2.

My problem now starts when I apply flux-scaling to step 1. The flux-scaling values are specified via the command-line (-FSCALE_DEFAULT ...). I also use input weight maps (WEIGHT_TYPE MAP_WEIGHT), set to the exposure time of each frame to avoid different scaling of the individual detectors due to some variation in noise characteristics that is introduced otherwise. When I set FSCALE_DEFAULT to 1.0 and also set RESCALE_WEIGHTS to No, I get what I expect, i.e. the output weight map is a nicely merged version of the input weight maps.

Now I set FSCALE_DEFAULT to any other value (say, 0.001, to match the photometric zeropoints of all exposures in my set), my output weight map that used to be X now is suddenly X/(0.001^2), and not X/0.001 as I would have expected.
Dividing by the scaling factor ONCE makes sense, e.g. to weight each exposure with the exposure time after normalizing all exposures to 1s, but diving by the square of the scaling factor seems wrong - is this a bug or am I just missing something here? The same also happens without feeding swarp an input weight map, i.e. the output weight maps with FSCALE_DEFAULT X and FSCALE_DEFAULT set to X differ by X^2.

Ultimately my goal would be to have as weight map output some measure of the exposure time that went into each pixel, but with the current version that does not seem to work - at least not without opening & modifying the weight maps after each step.

Any help, either in solving the problem with swarp or with my mis-understanding on what's going on behind the scenes will be greatly appreciated.

Thanks

Ralf
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)