On 27 September 2016 at 23:09, Tim Jenness <[log in to unmask]> wrote:
> (replying to the normal Starlink user list)
>
> What version of the software did you upgrade from and which version are you
> using now?
>
> Are you sure that the WCS is wrong? Is it possible that you have ended up
> with more padding around the image so that the pixel counts are different
> but the WCS itself is still compatible? If you load the FITS image into GAIA
> and zoom in so that you can see individual pixels, does it report the same
> WCS for the same structure?
>
> For the NDF versions, does ndftrace suggest that the WCS of the pixel
> origins match?
>
> --
> Tim Jenness
>
> On Tue, Sep 27, 2016 at 2:47 PM, Kianoosh Tahani <[log in to unmask]>
> wrote:
>>
>> Dear Starlink team,
>>
>> I am trying to regrid my data onto larger pixel by using the wcsalign
>> command. I am changing the pixel size of Herschel data at
>>
>> lower wavelengths (i.e.
>> 70 (blue), 160(red), 250(psw), 350(pmw)
>> um ($\mu m$) ) to the pixel size of the data at 500(plw) um (11.5'' pixel
>> size). Therefore, I use the 500(plw) um data as the reference:
>>
>>  % wcsalign in=(e.g.)blue out=regridmap lbnd=! ubnd=! ref=plw rebin
>> conserve=f
>>
>> Then I change the regridmap.sdf file to a fits file via ndf2fits command.
>>
>> This procedure used to work fine, however, now (possibly) after updating
>> the software of my computer the NAXIS1 and NAXIS2 of the FITS HEADER of the
>> reference file (plw.fits or 500 um data) no longer matches with the FITS
>> HEADER of the "regridmap.fits" produced. (original (plw) Naxis1=1244 &
>> NAXIS2=944 while the produced file is NAXIS1=1243 & NAXIS2=941).

Since you ran wcsalign with "lbnd=! ubnd=!", the pixel bounds of the
output (regridmap) will be chosen so that the output just encompasses
all the data in the input (blue). So in general the output will have
different pixel bounds to the reference (plw). If you want the output
to have the same pixel bounds as the reference, you need to remove
"lbnd=! ubnd=!" from the command line, and instead accept the
suggested default values when prompted for parameters lbnd and ubnd
(you could instead just append "accept" to the end of the command line
to force the suggested value to be accepted without prompting). For
further help, do:

% kaphelp wcsalign param lbnd

>> This small change in the NAXIS is causing an error on the real position of
>> the objects/clumps I am studying on my data. Your help on solving and
>> tackling the issue is greatly appreciated.

Tim's point is that just because a particular (l,b) position has moved
to a different FITS pixel does not necessarily mean the WCS is wrong.
It may be that emission features have also moved in the same way. You
could check this for instance by finding the (l,b) of the centroid of
a bright feature in both maps and comparing them. The centroid command
in kappa may be of use for this. Or you could do it roughly by eye
using gaia - just point the cursor at the same peak of emission in
both maps and compare the (l,b).

How are the regions you showed in your DS9 plot defined? Are they
defined in pixel coordinates or in (l,b) ?

Without knowing the old and new starlink versions, it's hard to say if
any significant change occurred in the software between your two
versions. Version information is stored in
$STARLINK_DIR/manifests/starlink.version

David

----
Starlink User Support list
For list configuration, including subscribing to and unsubscribing from the list, see
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STARLINK