iraf.net

I am using xregister command to register my images.
I created my BPMS for each unregistered image and then when I registered the image, the BPM associated with that image remained the same. here is a generic example: my unregistered image name is image1.fits and the associated BPM is image1.pl. and then after registration, my registered image name is registeredimage1.fits but this new image has the same BPM image1.pl associated with it. so clearly xregister does not shift the BPM along with the image itself. One way out of this I think is to manually shift each .pl file by the same amount as the registered image was shifted, but time consuming...unless a piece of code is written.....
So I am wondering is it perhaps possible to change the order of doing this a little bit?:the order I have been taught to do things is:
1) take BPMS
2) subtract bias
3)flat divide
4)register these images
5)coadd the reduced and registered images.first of all I would like clarity that BPMs must be taken first, because after reduction the saturated pixel value won't show up....if that wasn't the case, I could leave taking the BPMs until after the images have been registered with the new order of doing things being:ORDER A
1) subtract bias
2)flat divide
3)register these images
4)take BPMS of registered images
5)coadd the reduced and registered images.this new order would then solve the problem of unregistered BPMs that I outlined above...but I don't think that this reordering would produce valid BPMs....so my second idea of reordering is to do the registration step first on the raw data:
ORDER B
1) register images
2) take BPMs
3) subtract bias
4)flat divide
5)coadd reduced and registered imagesbut a problem that I think might arise from doing that is that the unreduced images may be less useful in terms of getting xregister to correctly register them...ie. does the way xregister work necessitate that it uses reduced data or it can it handly unreduced data equally well? if I can reorder my steps as outlines in ORDER B, this I think would solve my problem.Any advice on this is greatly appreciated and any other relevant advice is also appreciated.

First of all I need to be sure we are understanding the same thing. By BPM do you mean "bad pixel mask"? It seems fairly obvious that you are talking about this except when you say "take BPMS" as if this was some kind of exposure.It is true that most tasks in IRAF do not modify a bad pixel associated with an image though many produce new masks. Xregister is an older task that does not do anything to the mask. As you say, you can treat the BPM as an image and do exactly the same operation as you do with your pixel image. This is always the ultimate thing to do.However, because this can be a common thing to spatially change an image and not the mask there is a feature in recent IRAF that will, for certain tasks, match a BPM to an image based on coordinate information in the header. This depends on the spatial operation updating the coordinate systems. In order to do this matching (again only for certain tasks) you set an variable. See the help for "pmmatch". One of the tasks that does this matching is IMCOMBINE so this may solve you problem.So read "pmmatch" and either try it or shift/register the mask along with the pixel image.Frank Valdes