Issues with *register
brentdutra wrote on Oct 27, 2010
I'm working on a small project on HCG objects using data from SDSS. Right now I'm simply looking for tidal distortions based solely on human eye observations, although I will need to do photometry later. Long story short, most of my objects have hundreds of images which I would love to combine into a single low noise image for each individual object. Easy you say, and yes I mostly agree.
As the images already have WCS data embedded I figured I could use sregister or wregister to simply align the images then combine them. My problem comes with the fact that when *register shifts an image it replaces the missing data with a "trail"; the boundary parameter is set to "nearest". Ok, so replace that value with a constant you say; sure but after I change that then use imcombine my image has problems with areas of low image combination counts. This is also plainly obvious you say, and again I agree but I suppose what I'm hoping to find is a way to easily align and combine the images without this problem.
Essentially what I need is: to align the images using the WCS header data but when shifted to replace the values with "null" which as far as I know, the fits standard supports. Then when combining there will be areas of differing s/n but all of roughly the same counts. Is there a quick and easy way to do this? I know that I could also use trim as well, but I'd prefer to keep as much residual data as possible. Now for the photometry later part I know that will ruin things having an image with varying s/n so is it possible to construct a second fits file as a simple matrix showing which pixels have been combined with however many other images?
As a TA for a lower division astronomy course we used two commercial programs (ccdsoft and maximdl) to have students play with very basic and rudimentary image reduction, and what amazes me is the power that one program (maximdl specifically) had; it could align and combine all without WCS data, and must use some internal trim or null additive combine routine. If anyone has experience with that; that's essentially what I'm looking for but using iraf routines.
Cheers
--Brent
As the images already have WCS data embedded I figured I could use sregister or wregister to simply align the images then combine them. My problem comes with the fact that when *register shifts an image it replaces the missing data with a "trail"; the boundary parameter is set to "nearest". Ok, so replace that value with a constant you say; sure but after I change that then use imcombine my image has problems with areas of low image combination counts. This is also plainly obvious you say, and again I agree but I suppose what I'm hoping to find is a way to easily align and combine the images without this problem.
Essentially what I need is: to align the images using the WCS header data but when shifted to replace the values with "null" which as far as I know, the fits standard supports. Then when combining there will be areas of differing s/n but all of roughly the same counts. Is there a quick and easy way to do this? I know that I could also use trim as well, but I'd prefer to keep as much residual data as possible. Now for the photometry later part I know that will ruin things having an image with varying s/n so is it possible to construct a second fits file as a simple matrix showing which pixels have been combined with however many other images?
As a TA for a lower division astronomy course we used two commercial programs (ccdsoft and maximdl) to have students play with very basic and rudimentary image reduction, and what amazes me is the power that one program (maximdl specifically) had; it could align and combine all without WCS data, and must use some internal trim or null additive combine routine. If anyone has experience with that; that's essentially what I'm looking for but using iraf routines.
Cheers
--Brent
jstottsj wrote on Oct 27, 2010
PostPosted: Wed Oct 27, 2010 9:14 pm
My usual solution would be to set the value to a very negative constant (say -999) when registering and then use the clipping flags in imcombine to exclude those pixels (via lthreshold). This will exclude those invalid points gracefully. The noise will be higher where there are fewer images to combine (naturally), but the averages will be correct.
-JS
As the images already have WCS data embedded I figured I could use sregister or wregister to simply align the images then combine them. My problem comes with the fact that when *register shifts an image it replaces the missing data with a "trail"; the boundary parameter is set to "nearest". Ok, so replace that value with a constant you say; sure but after I change that then use imcombine my image has problems with areas of low image combination counts. This is also plainly obvious you say, and again I agree but I suppose what I'm hoping to find is a way to easily align and combine the images without this problem.
My usual solution would be to set the value to a very negative constant (say -999) when registering and then use the clipping flags in imcombine to exclude those pixels (via lthreshold). This will exclude those invalid points gracefully. The noise will be higher where there are fewer images to combine (naturally), but the averages will be correct.
-JS
brentdutra wrote on Oct 27, 2010
That worked out wonderfully, I can't believe I didn't think of it in the first place. I would have replied sooner but my course load over the past few weeks has been ridiculous. Thank you again for the suggestion.
--Brent
--Brent
Last post on Oct 27, 2010