Thank you for all this extra information! What bizarre behaviour! How curious that MJD-OBS should interfere with the plotting of images in DS9...? I do not understand why this should be the case.

Firstly, I followed your suggestion and upgraded my version of DS9. I am now running DS9 version 7.5. This did make a difference (bringing the before and after images into closer agreement), but did not completely fix the issue.

On your suggestion, I upgraded my WCSLIB to version 5.15. I have recompiled GNU Astro and I can now confirm that the CDELTn header keywords print all significant figures and does also print MJD-OBS into the header.

As an aside, task #14315 may help with issues such as this in the future, by propagating all FITS header keywords into any resultant output files.

I attempted to blink between the images and, once more, found a small offset. The offset now is exceptionally small (single-pixel level), and I would not have noticed it had we not started this bug hunt with a much larger offset.

I took a close look at the header to see if anything else was going on. I found a few things:

• MJD-OBS is missing 1 significant figure when compared with the input file
• the header keyword RADECSYS has been changed to RADESYS (missing the C)
• A LATPOLE/LONPOLE have been assumed (rightly so?)

However, on a whim, I tried one more thing... I used DS9 to blink between exactly the same input image! Lo and behold, I found an offset! The same single-pixel level offset I mentioned above. So, I can conclude that the initial bug has now been fixed by upgrading to the latest version of WCSLIB and DS9, and this continuing mis-match must be a DS9 issue.

Thank you for your help with this bug, much appreciated.

Best,
Lee Kelvin

Sorry, I just remembered you had uploaded your version of `input_rotated.fits'. So I downloaded it and tried it out. Indeed the `WCSLIB' keyword wasn't present. But more importantly/strangely after "blink"ing (sorry, in the previous comment, I mistakenly said "flip"!) I also noticed a shift!

So after renaming your output to `input_rotated_lee.fits', I exported both headers to text files to see the difference:

$ astheader input_rotated.fits > mohammad.txt
[mohammad@akhlaghi desktop]$ astheader input_rotated_lee.fits > lee.txt
[mohammad@akhlaghi desktop]$ diff mohammad.txt lee.txt
15,17c15,17
< PC1_1   =             -1.0E+00 / Coordinate transformation matrix element
< CDELT1  =   9.416666295793E-05 / [deg] Coordinate increment at reference point
< CDELT2  =   9.416666295793E-05 / [deg] Coordinate increment at reference point
---
> PC1_1   =                 -1.0 / Coordinate transformation matrix element
> CDELT1  =    9.41666629579E-05 / [deg] Coordinate increment at reference point
> CDELT2  =    9.41666629579E-05 / [deg] Coordinate increment at reference point
28,29d27
< MJD-OBS =        55238.2821457 / [d] MJD of observation
<
44,46c42,43
< DATE    = '2017-01-20T16:37:28' / file creation date (YYYY-MM-DDThh:mm:ss UT)
< CFITSIO = '3.41    '           / CFITSIO version.
< WCSLIB  = '5.15    '           / WCSLIB version.
---
> DATE    = '2017-01-20T14:42:33' / file creation date (YYYY-MM-DDThh:mm:ss UT)
> CFITSIO = '3.37    '           / CFITSIO version.

Besides the missing `3' digit in the `CDELT' keywords, your header file doesn't have `MJD-OBS' while `input.fits' does have it. This must be another feature that has been added to WCSLIB since version 2.24.

Hello, and thank you for quickly addressing this issue. I can confirm that using the latest build of GNUAstro largely fixes this issue.

However, I still find that there remains a small offset still when matching the input file with an output file by WCS in a FITS viewer such as DS9. I once more make use of the file 'input.fits' attached to the original post. I also once more use the command:

$ astimgwarp --rotate=360 input.fits

Following recent naming convention changes in GNUAstro, this now produces an output file named 'input_rotated.fits', attached to this post.

The input file has a pixel scale of 9.416666295793E-05 degrees per pixel, as encoded by the CD1_1 header keyword.

The output file has a pixel scale of 9.41666629579E-05 degrees per pixel, as encoded by the CDELT1 header keyword. (Note that the WCS encoding has been converted from the CD to the PC/CDELT formalism when running ImageWarp as discussed in support thread #109223.)

You will notice that one significant figure (3) is missing from the output pixel scale. All other WCS header keywords appear identical.

When I match the input and output files in DS9 and blink between them there exists an offset of ~0.1 pixels, mostly shifting on the x-axis. I'm unsure if the loss of this significant figure in the pixel scale is the cause for this discrepancy.

Correspondence with Mohammad Akhlaghi has shown that this issue is not reproducible on his system. I therefore copy below the version numbers for the mandatory dependencies currently installed on my machine, for your reference.

Regards,
Lee Kelvin

OS: Ubuntu 15.04 vivid
GNU Astro: 0.2.61-ad122
libgsl0: 1.16+dfsg-2build1
libcfitsio3: 3.340-3
libwcs4: 4.24-1


(file #39518)

This item has been reassigned from the project GNU Astronomy Utilities support tracker to your tracker.

The original report is still available at support #109222

Following are the information included in the original report:

[field #0]                  Item ID: 109222
[field #1]                 Group ID: 11425
[field #2]              Open/Closed: Open
[field #3]                 Severity: 3 - Normal
[field #4]                  Privacy: Public
[field #8]                         : Unknown support Field Display Type
[field #9]                 Category: ImageWarp
[field #10]             Submitted by: leeskelvin
[field #11]              Assigned to: None
[field #12]             Submitted on: Wed 18 Jan 2017 01:36:19 AM JST
[field #13]                  Summary: ImageWarp 'rotate' does not correctly propagate WCS pixel scale information into header
[field #14]      Original Submission: On applying an image rotation using ImageWarp, the World Coordinate System (WCS) pixel scale information is only partially transferred to the output image.

The attached image 'input.fits' is a 3x3 pixel image with WCS information in the header defined using the  CDi_j FITS standard formalism. The pixel scale for this image is 0.339 arcsec/pixel, i.e., 9.4166667e-5 degrees/pixel.

A 360-degree image rotation is performed on this image using the command:

astimgwarp --rotate=360 input.fits

This produces the output image 'image_warped.fits', attached to this report. The pixel flux values have been correctly preserved, and the output image is aligned precisely with the input image, as expected for a 360-degree rotation.

WCS information in the rotated image header has been translated from the CDi_j formalism to the PCi_j formalism. This requires not only PC1_1 and PC2_2 in the header, but also CDELT1 and CDELT2 values. CDELTn values describe the "physical increment at the reference pixel", giving the pixel scale in degrees per pixel.

Whilst the pixel scale is correctly preserved in the output PCi_j header values, both CDELTn values are equal to 1, incorrectly implying that each pixel is 1 degree in size. This creates problems in, e.g., DS9 when viewing the two files attached to this report side by side and matching by WCS. I would expect the pixel scale to be correctly propagated through to the output header CDELTn parameters.

Regards,
Lee Kelvin

[field #16]               Item Group: Output not reasonable
[field #17]                   Status: None
[field #18]        Component Version: None
[field #19]         Operating System: GNU/Linux
[field #20]          Reproducibility: None
[field #21]               Size (loc): None
[field #22]            Fixed Release: None
[field #23]          Planned Release: None
[field #24]                   Effort: 0.00
[field #28]                 Priority: 5 - Normal
[field #31]         Percent Complete: 0%
[field #33]                  Release: None
[field #58]     Custom Select Box #1: None
[field #59]     Custom Select Box #2: None
[field #60]     Custom Select Box #3: None
[field #61]     Custom Select Box #4: None
[field #62]     Custom Select Box #5: None
[field #63]     Custom Select Box #6: None
[field #64]     Custom Select Box #7: None
[field #65]     Custom Select Box #8: None
[field #66]     Custom Select Box #9: None
[field #67]    Custom Select Box #10: None