Welcome to iraf.net Friday, March 29 2024 @ 12:25 PM GMT


 Forum Index > Help Desk > Applications New Topic Post Reply
 IMCOMBINE wcs offsets: errors larger than 1 pixel
   
keflavich
 03/02/2009 08:53PM (Read 12411 times)  
++---
Junior

Status: offline


Registered: 03/30/2006
Posts: 30
I'm using imcombine to stack a number of frames with Galactic WCS coordinates specified. The individual frames align perfectly (using DS9 to check on alignment) but when combined there is a large offset in the Y direction. There is a <1 pixel offset in the X direction, as expected, but the Y offset is 5 pixels, which means that it's more than shifting by integer pixels only (which I believe is the cause of the <1 pixel errors) should allow.I used imcopy to crop the files before combining them, but the headers seemed to transform correctly during the cropping, and the crop was only in the X direction.Any idea what could be going wrong? Thanks,
Adam

 
Profile Email Website
 Quote
valdes
 03/02/2009 08:53PM  
+++++
Active Member

Status: offline


Registered: 11/11/2005
Posts: 728
Hi,There is not enough information to give a useful reply. Please include the parameter listing for imcombine. It would be best if I could have an example case. We could try with header listings but some real data with real sources to be able to see how things align would be best. Since this may be private data you could put them in ftp://iraf.noao.edu/pub or, if you can make a few small subsections to demonstrate the problem they could be included as an email attachment.Yours,
Frank Valdes
valdes@noao.edu

 
Profile Email
 Quote
keflavich
 03/02/2009 08:53PM  
++---
Junior

Status: offline


Registered: 03/30/2006
Posts: 30
Thanks for the reply Frank. I had hoped it was a known / easy to answer problem.I used the default parameters except for combine and offset, i.e.:
--> unlearn imcombine
--> imcombine @deconvmaplist MOSAIC_deconv.fits combine=average offset=wcsMar 3 15:41: IMCOMBINE
combine = average, scale = none, zero = none, weight = none
blank = 0.
Images Offsets
v0.7_l006_13pca_deconv_map50_crop.fits 38500 505
v0.7_l009_13pca_deconv_map50_crop.fits 36998 532
v0.7_l012_13pca_deconv_map50_crop.fits 35496 529
v0.7_l018_13pca_deconv_map50_crop.fits 31510 32
v0.7_l024_13pca_deconv_map50_crop.fits 28520 531
v0.7_l029_13pca_deconv_map50_crop.fits 27555 527
v0.7_l030_13pca_deconv_map50_crop.fits 26999 35
v0.7_l032_13pca_deconv_map50_crop.fits 25533 38
v0.7_l035_13pca_deconv_map50_crop.fits 23568 509
v0.7_l040_13pca_deconv_map50_crop.fits 21000 525
v0.7_l045_13pca_deconv_map50_crop.fits 18489 534
v0.7_l050_13pca_deconv_map50_crop.fits 16013 537
v0.7_l055_13pca_deconv_map50_crop.fits 12992 524
v0.7_l065_13pca_deconv_map50_crop.fits 7538 523
v0.7_l072_13pca_deconv_map50_crop.fits 4506 522
v0.7_l077_13pca_deconv_map50_crop.fits 2985 44
v0.7_l082_13pca_deconv_map50_crop.fits 0 0
v0.7_l351_13pca_deconv_map50_crop.fits 46002 527
v0.7_l354_13pca_deconv_map50_crop.fits 44495 517
v0.7_l357_13pca_deconv_map50_crop.fits 43018 530
v0.7_super_gc_13pca_deconv_map50_crop.fits 39971 30 Output image = MOSAIC_deconv.fits, ncombine = 21I'm mosaicing 21 images in Galactic coordinates over the range l=-10 to l=85. All images at l<=29 line up correctly, and all images l>=30 are shifted by about 5 pixels.However, if I just combine l029 and l030, there is no offset - they line up fine.The data is in the public ftp directory.Adam

 
Profile Email Website
 Quote
keflavich
 03/02/2009 08:53PM  
++---
Junior

Status: offline


Registered: 03/30/2006
Posts: 30
I found a workaround; if I mosaic the region that's not shifted and the region that's shifted separately and then combine them, it works fine. Could you remove my data from the pub/ directory when you get a chance?Thanks,
Adam

 
Profile Email Website
 Quote
valdes
 03/02/2009 08:53PM  
+++++
Active Member

Status: offline


Registered: 11/11/2005
Posts: 728
Hi Adam,I glad you found a workaround. I just found time to look at this. I did not see anything in the ftp pub directory that seems to be from you so I can't remove it or take a look. So we'll take this as resolved.Yours,
Frank Valdes

 
Profile Email
 Quote
Mike Potter
 03/02/2009 08:53PM  
++---
Junior

Status: offline


Registered: 04/23/2006
Posts: 15
Maybe obvious - and perhaps insignificant? The celestial equator intersects the galactic equator near l=30 - at about 32-33 degrees in J2000.0 coordinates. Mike

 
Profile Email Website
 Quote
keflavich
 03/02/2009 08:53PM  
++---
Junior

Status: offline


Registered: 03/30/2006
Posts: 30
Mike - good point. Does imcombine convert to RA/Dec coordinates internally when computing WCS offsets?Frank - unfortunately, this issue has become something of a sticking point again on a subset of the data I was using previously. I'm encountering errors near l=80, b=0, and I don't think there are any poles near there in any commonly coordinate systems.The WCS header keywords are below. Let me know if you want me to send you data again; this time the data size might actually be manageable.CTYPE1 = 'GLON-CAR' / Coordinate Type
CTYPE2 = 'GLAT-CAR' / Coordinate Type
EQUINOX = 2000.00 / Equinox of Ref. Coord.
CD1_1 = -0.00199999986216 / Degrees / Pixel
CD2_1 = 0.00000000000 / Degrees / Pixel
CD1_2 = -0.00000000000 / Degrees / Pixel
CD2_2 = 0.00199999986216 / Degrees / Pixel
CRPIX1 = 1492.57 / Reference Pixel in X
CRPIX2 = 1382.02 / Reference Pixel in Y
CRVAL1 = 83.6636091137 / Galactic longitude of reference pixel
CRVAL2 = 1.13116961227 / Galactic latitude of reference pixel
PV2_1 = 0.00000000000 /Projection parameter 1
LONPOLE2= 180.00000 /lonpole
LATPOLE2= 0.0000000 /latpole

 
Profile Email Website
 Quote
valdes
 03/02/2009 08:53PM  
+++++
Active Member

Status: offline


Registered: 11/11/2005
Posts: 728
Hi,Yes I think some data will be necessary for me to demonstrate and understand the problem. Let me know directly when you make some data available.Yours,
Frank
valdes@noao.edu

 
Profile Email
 Quote
keflavich
 03/02/2009 08:53PM  
++---
Junior

Status: offline


Registered: 03/30/2006
Posts: 30
I'm currently uploading the files. I combined these 4 files:
v1.0.2_l077_13pca_map50_crop.fits
v1.0.2_l079_13pca_map50_crop.fits
v1.0.2_l082_13pca_map50_crop.fits
v1.0.2_l086_13pca_map50_crop.fitswithimcombine @cygxmaplist CygX.fits combine=average offset=wcswhere cygxmaplist is the list of those 4 files.Thanks,
Adam

 
Profile Email Website
 Quote
valdes
 03/02/2009 08:53PM  
+++++
Active Member

Status: offline


Registered: 11/11/2005
Posts: 728
Hi Adam,One of the files was truncated (v1.0.2_l072_13pca_map50.fits) but the test you indicated was just with four of the crop files. I ran the test:[code:1:a411f0aca4]
ecl> unlearn imcombine
ecl> imcombine @cygxmaplist CygX.fits combine=average offset=wcsApr 7 9:49: IMCOMBINE
combine = average, scale = none, zero = none, weight = none
blank = 0.
Images Offsets
v1.0.2_l077_13pca_map50_crop.fits 5078 493
v1.0.2_l079_13pca_map50_crop.fits 3560 7
v1.0.2_l082_13pca_map50_crop.fits 1567 489
v1.0.2_l086_13pca_map50_crop.fits 0 0 Output image = CygX.fits, ncombine = 4
ecl> imhead CygX.fits l-
CygX.fits[6112,2637][real]:
[/code:1:a411f0aca4]I can display it and it looks reasonable. Can you tell me where to look to see the ~5 pixel error you mention?Frank

 
Profile Email
 Quote
keflavich
 03/02/2009 08:53PM  
++---
Junior

Status: offline


Registered: 03/30/2006
Posts: 30
Compare the l082 map to the combined map; that's where I see the greatest shift. In particular, look at these sources:

           
          Profile Email Website
           Quote
          valdes
           03/02/2009 08:53PM  
          +++++
          Active Member

          Status: offline


          Registered: 11/11/2005
          Posts: 728
          I think we may be talking about an error in the WCS as opposed to a problem with stacking. I don't see any "blurring", which in its most extreme form would be multiple images. What I do see is different coordinate values for the same source in the stack and an individual image.This ties into how you use the display tools and WCS readback. I use ximtool and the feature that lets me tie too frames together with an offset. Then if I blink and move around the image sources all remain overlapping. So I don't believe we are talking about misregistration of pixels during combining. Do you disagree?A simple test is to change the order of the images in the cygxmaplist to[code:1:384a77d047]
          ecl> e imcom
          imcombine @cygxmaplist1 CygX1.fits combine=average offset=wcsApr 7 11:03: IMCOMBINE
          combine = average, scale = none, zero = none, weight = none
          blank = 0.
          Images Offsets
          v1.0.2_l086_13pca_map50_crop.fits 0 0
          v1.0.2_l077_13pca_map50_crop.fits 5078 490
          v1.0.2_l079_13pca_map50_crop.fits 3560 5
          v1.0.2_l082_13pca_map50_crop.fits 1568 493 Output image = CygX1.fits, ncombine = 4
          [/code:1:384a77d047]where the order in the imcombine output is the order in the xygxmaplist1 file. Note I choose the one that puts the (0,0) offset first. The combined image looks the same but now I get the same (l,b) for a source in the stack as with l082. I use ximtool for the WCS readback.So do you think we are talking about the WCS in the header of the CygX version or do you really think pixels are misregistered when the average is being done.Frank

           
          Profile Email
           Quote
          keflavich
           03/02/2009 08:53PM  
          ++---
          Junior

          Status: offline


          Registered: 03/30/2006
          Posts: 30
          I think it is a WCS error, but I don't think it's an error in the header - I think the WCS offsets applied to each image before combining them are somehow incorrect. The WCS in the combined file is consistent with one of the originals, but not all.Adam

           
          Profile Email Website
           Quote
          keflavich
           03/02/2009 08:53PM  
          ++---
          Junior

          Status: offline


          Registered: 03/30/2006
          Posts: 30
          Also, look at the y offsets: they're different depending on the order. That seems to be the source of the problem; why does order matter?Adam

           
          Profile Email Website
           Quote
          valdes
           03/02/2009 08:53PM  
          +++++
          Active Member

          Status: offline


          Registered: 11/11/2005
          Posts: 728
          The WCS in the output image starts with the WCS of the first image (as do a lot of the other keywords) and then a correction is made to the WCS to account for the assumed integer pixel shift in x and y.I will continue to look at this further.Frank

           
          Profile Email
           Quote
          valdes
           03/02/2009 08:53PM  
          +++++
          Active Member

          Status: offline


          Registered: 11/11/2005
          Posts: 728
          This is a somewhat complex issue, as are most things involving WCS.At its most basic, imcombine with the WCS offset option (intended to allow you not to need a common pixel raster with lots of zeros everywhere outside the image data) is designed around the assumption that the data have been sampled to a common WCS grid. This means the WCS should be the same apart from the pixel coordinate of the reference pixel. Therefore, the CRVAL values should be the same and the differences in the images be incorporated in shifts in the CRPIX values. However, it actually works by finding the pixel coordinate in each image that corresponds to the CRVAL of the first image. Some WCS have the property that this works well, particularly when the scale is small enough that spherical effects are minimal.In your case, the cartesian projection and the largish offsets (of the order of degrees) does not work so well. You would need to work through the math to fully understand and get it right. I'm not sure how you arrived at the sampling and WCS in your data. Maybe you should think mostly in pixel space, that is how the images are related as offsets in x and y pixels, and then at the end add an appropriate WCS to the final composite image.I hope this make some sense.Yours,
          Frank

           
          Profile Email
           Quote
          keflavich
           03/02/2009 08:53PM  
          ++---
          Junior

          Status: offline


          Registered: 03/30/2006
          Posts: 30
          Yes, I see what you're getting at. Do you think it would work if I adjusted the CRVALs in all images to be the same and modified the CRPIXes appropriately? How does imcombine choose the image to give zero offset? Is it the image furthest south and east?We're using the Galactic Cartesian projection because, along the galactic plane, there should be very small deviations from a linear projection. None of our data (yet) is more than 1.5 degrees from the midplane. The WCS computations have been done with IDL astrolib routines and they check out very well on a field-by-field basis.Thanks again,
          Adam

           
          Profile Email Website
           Quote
          valdes
           03/02/2009 08:53PM  
          +++++
          Active Member

          Status: offline


          Registered: 11/11/2005
          Posts: 728
          By understanding what you and imcombine are doing you can make it work.1. The CRVAL from the 1st image in the list acts as the reference position from which offsets are determined.
          2. The reference position uses the WCS in each image to invert to pixel coordinates for the reference coordinate in that particular image.
          3. The difference between the pixel coordinates of the 1st image and the nth image is the relative offset for that image.
          4. Once all the offsets are determined the offsets are shifted so the smallest offset is zero. This means that the image order does not matter as far as the offset values you see in the imcombine output log.This is the main part of the process. The other part is to then take the offset computed for the 1st image (which may not be 0 because of step 4 above) which provides the WCS values and adjust the WCS by modifying the CRPIX values.It looks like the offset computation is working fine for your data but the step of computing the WCS for the final combined image depends on which image is the reference. I'm not sure what we are misunderstanding in this last process but it does seem to mean that comparing coordinates between the stack and an image which was not the first don't completely agree. I would have to think about this more careful to figure out what is going on and I don't have the time to go further into this. I was only guessing that something about CAR projections and that the reference points in each image are different is involved. If you figure out you could post the explanation.Frank

           
          Profile Email
           Quote
          keflavich
           03/02/2009 08:53PM  
          ++---
          Junior

          Status: offline


          Registered: 03/30/2006
          Posts: 30
          Thanks Frank. I think that's exactly what I need in order to find a useful workaround; hopefully in the process I'll be better able to answer the questions we raised here.Adam

           
          Profile Email Website
           Quote
             
          Content generated in: 0.42 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