Welcome to iraf.net Monday, May 13 2024 @ 05:05 PM GMT


 Forum Index > Help Desk > Applications New Topic Post Reply
 WREGISTER with CD[1-2] keywords??
   
aoxsic
 12/18/2008 02:13PM (Read 2372 times)  
++---
Junior

Status: offline


Registered: 03/13/2007
Posts: 16
Hello,I have 2 images (I have more but this is for illustrating purposes) with the following WCS in the headers.Image 1im1.fits[2048,2048][real]: GOODS-S
ORIGIN = 'NOAO-IRAF FITS Image Kernel July 2003' / FITS file originator
DATE = '2008-12-18T13:44:57' / Date FITS file was generated
IRAF-TLM= '14:44:57 (18/12/2008)' / Time of last modification
TELESCOP= 'ESO-VLT-U4' / ESO Telescope Name
INSTRUME= 'HAWKI ' / Instrument used
RA = ' 03:32:30.780' / 03:32:30.7 RA (J2000) pointing
DEC = '-27:47:03.444' / -27:47:03.4 DEC (J2000) pointing
EQUINOX = 2000. / Standard FK5 (years)
RADECSYS= 'FK5 ' / Coordinate reference frame
CTYPE1 = 'RA---TAN' / Pixel coordinate system
CTYPE2 = 'DEC--TAN' / Pixel coordinate system
CRVAL1 = 53.1282500833324 / Coordinate value of ref. pixel
CRVAL2 = -27.7842890222217 / Coordinate value of ref. pixel
CRPIX1 = 2163. / Ref. pixel in <axis direction>
CRPIX2 = 2164. / Ref. pixel in <axis direction>
CD1_1 = -2.12772320597554E-05 / Translation matrix element.
CD1_2 = 2.05256649614546E-05 / Translation matrix element.
CD2_1 = 2.05256649614546E-05 / Translation matrix element.
CD2_2 = 2.12772320597554E-05 / Translation matrix element.
CHECKSUM= '6gUL7gRL6gRL6gRL' / HDU checksum updated 2008-10-29T08:23:09
DATASUM = '3116835200' / data unit checksum updated 2008-10-29T08:23:09Image 2
im2.fits[2048,2048][real]: GOODS-S
ORIGIN = 'NOAO-IRAF FITS Image Kernel July 2003' / FITS file originator
DATE = '2008-12-18T13:45:05' / Date FITS file was generated
IRAF-TLM= '14:45:04 (18/12/2008)' / Time of last modification
TELESCOP= 'ESO-VLT-U4' / ESO Telescope Name
INSTRUME= 'HAWKI ' / Instrument used
RA = ' 03:32:34.111' / 03:32:34.1 RA (J2000) pointing
DEC = '-27:46:59.808' / -27:46:59.8 DEC (J2000) pointing
EQUINOX = 2000. / Standard FK5 (years)
RADECSYS= 'FK5 ' / Coordinate reference frame
CTYPE1 = 'RA---TAN' / Pixel coordinate system
CTYPE2 = 'DEC--TAN' / Pixel coordinate system
CRVAL1 = 53.1421256958324 / Coordinate value of ref. pixel
CRVAL2 = -27.7832760655551 / Coordinate value of ref. pixel
CRPIX1 = 2163. / Ref. pixel in <axis direction>
CRPIX2 = 2164. / Ref. pixel in <axis direction>
CD1_1 = -2.12772320597554E-05 / Translation matrix element.
CD1_2 = 2.05256649614546E-05 / Translation matrix element.
CD2_1 = 2.05256649614546E-05 / Translation matrix element.
CD2_2 = 2.12772320597554E-05 / Translation matrix element.
CHECKSUM= '3N7fAN6Z5N6fAN6Z' / HDU checksum updated 2008-10-29T08:23:15
DATASUM = '390317682' / data unit checksum updated 2008-10-29T08:23:15
I use wregister with the following parameters:
input = "im2.fits" The input images
reference = "im1.fits" Input reference images
output = "reg__im2.fits" The output registered images
(xmin = INDEF) Minimum logical x reference coordinate value
(xmax = INDEF) Maximum logical x reference coordinate value
(ymin = INDEF) Minimum logical y reference coordinate value
(ymax = INDEF) Maximum logical y reference coordinate value
(nx = 10) Number of grid points in x
(ny = 10) Number of grid points in y
(wcs = "world") The default world coordinate system
(transpose = no) Force a world coordinate tranpose ?
(xformat = "%10.3f") Output logical x coordinate format
(yformat = "%10.3f") Output logical y coordinate format
(wxformat = "") Output world x coordinate format
(wyformat = "") Output world y coordinate format
(fitgeometry = "rotate") Fitting geometry
(function = "polynomial") Type of coordinate surface to be computed
(xxorder = 2) Order of x fit in x
(xyorder = 2) Order of x fit in y
(xxterms = "half") X fit cross terms type
(yxorder = 2) Order of y fit in x
(yyorder = 2) Order of y fit in y
(yxterms = "half") Y fit cross terms type
(reject = INDEF) The rejection limit in units of sigma
(calctype = "real") Transformation computation type
(geometry = "geometric") Transformation geometry
(xsample = 1.0) X coordinate sampling interval
(ysample = 1.0) Y coordinate sampling interval
(interpolant = "poly5") The interpolant type
(boundary = "constant") Boundary extensiontype
(constant = 0.0) Constant for constant boundary extension
(fluxconserve = yes) Preserve image flux ?
(nxblock = 512) X dimension blocking factor
(nyblock = 512) Y dimension blocking factor
(wcsinherit = yes) Inherit wcs of the reference image ?
(verbose = yes) Print messages about progress of task?
(interactive = no) Compute transformation interactively?
(graphics = "stdgraph") The standard graphics device
(gcommands = ) The graphics cursor
(mode = "al") The registered image, reg__im2.fits is supposed to inherit the WCS of the reference:Registered im2:reg__im2.fits[2048,2048][real]: GOODS-S
ORIGIN = 'NOAO-IRAF FITS Image Kernel July 2003' / FITS file originator
DATE = '2008-12-18T13:48:41' / Date FITS file was generated
IRAF-TLM= '14:48:43 (18/12/2008)' / Time of last modification
TELESCOP= 'ESO-VLT-U4' / ESO Telescope Name
INSTRUME= 'HAWKI ' / Instrument used
RA = ' 03:32:34.111' / 03:32:34.1 RA (J2000) pointing
DEC = '-27:46:59.808' / -27:46:59.8 DEC (J2000) pointing
CTYPE1 = 'RA---TAN' / Pixel coordinate system
CTYPE2 = 'DEC--TAN' / Pixel coordinate system
CRVAL1 = 53.1282500833324 / Coordinate value of ref. pixel
CRVAL2 = -27.7842890222217 / Coordinate value of ref. pixel
CRPIX1 = 2163. / Ref. pixel in <axis direction>
CRPIX2 = 2164. / Ref. pixel in <axis direction>
CD1_1 = -2.1277232059755E-5 / Translation matrix element.
CD1_2 = 2.05256649614546E-5 / Translation matrix element.
CD2_1 = 2.05256649614546E-5 / Translation matrix element.
CD2_2 = 2.12772320597554E-5 / Translation matrix element.
CHECKSUM= '3N7fAN6Z5N6fAN6Z' / HDU checksum updated 2008-10-29T08:23:15
DATASUM = '390317682' / data unit checksum updated 2008-10-29T08:23:15
WCSDIM = 2
LTM1_1 = 1.
LTM2_2 = 1.
WAT0_001= 'system=image'
WAT1_001= 'wtype=tan axtype=ra'
WAT2_001= 'wtype=tan axtype=dec'
When I display the images in DS9 the registered image, reg_im2.fits, is indeed shifted but it's not aligned to im1.fits. This is true for all images from this dataset that I try to align with WREGISTER. Is there something wrong with my parameters that you recognize? I used WREGISTER before with headers who had a PC matrix and CDELT keywords and it worked just fine, but I built a CD matrix before registering, so this can't be an issue with there not being any PC matrix. I'm at a loss. What is wrong? Any ideas? HOw can I test what the problem is? All the keywords are there, wregister seems to find the right offsets, so what am I doing wrong??wregister database contains:# Thu 13:59:13 18-Dec-2008
begin im2.fits
xrefmean 1013.5
yrefmean 1013.5
xmean 1288.411
ymean 700.6638
geometry rotate
function polynomial
xshift 274.7966
yshift -312.7218
xmag 1.
ymag 1.
xrotation 0.006470478
yrotation 0.006470478
xrms 3.168809E-4
yrms 3.150256E-4
surface1 11
3. 3.
2. 2.
2. 2.
0. 0.
1. 1.
2026. 2026.
1. 1.
2026. 2026.
274.7966 -312.7218
1. -1.129311E-4
1.129311E-4 1.
surface2 0Thanks for any insight.

 
Profile Email
 Quote
aoxsic
 12/18/2008 02:13PM  
++---
Junior

Status: offline


Registered: 03/13/2007
Posts: 16
I found a workaround: if I flip the sign on the CDi_j matrix in the headers, i.e. I multiply by -1, then WREGISTER aligns properly. The error before was due to the fact that either xshift or yshift had the wrong sign as obtained by wregister (or rather, geomap). Now I can't decide if this is a HAWKI data header inconsistency and this sign flipping information should be in the header but is not, or if this is a WREGISTER problem and WREGISTER should have picked up on this. I don't see how the latter can be the case though, all the usual WCS keywords are accounted for. SOFI data doesn't have this problem, with SOFI data I don't have to play with the headers at all before WREGISTER can align properly. Maybe WREGISTER is not to blame after all. Has anyone experienced anything similar?

 
Profile Email
 Quote
valdes
 12/18/2008 02:13PM  
+++++
Active Member

Status: offline


Registered: 11/11/2005
Posts: 728
Without more urgency I won't look at this any deeper. I just would comment that indeed if the WCS and the data (i.e. the sources) are not in agreement due to an error in the WCS you could experience the problem you report. What I would do is display the images, measure some RA and DEC values as reported by the display tool (e.g. ds9) and see if they agree with some reference material like a DSS image or other information you have about the coordinates of sources. It might not actually require measuring sources but only looking at the direction of the RA and DEC scales in a DSS image as opposed to the direction RA and DEC increase in your image data.I find it interesting that the magnitudes of the CD terms are similar which would mean the image is rotated by something like 45 degrees to celestial axes.Yours,
Frank Valdes

 
Profile Email
 Quote
   
Content generated in: 0.11 seconds
New Topic Post Reply

Normal Topic Normal Topic
Sticky Topic Sticky Topic
Locked Topic Locked Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Anonymous users can post 
Filtered HTML Allowed 
Censored Content 
dog allergies remedies cialis 20 mg chilblain remedies


Privacy Policy
Terms of Use

User Functions

Login