Strange issue with axis ticks & labels appearing/disappearing

[tomr-stargazer]

Hi all, I really like this WCSAxes package and am excited to see the new version release!

Here's a bug that I've been having (both before & after the 0.2 came out) that I thought I'd raise, since I can't make much sense of it.

I often create WCSAxes instances of an all-Galaxy datacube which spans 0 to 360 degrees in longitude (see https://github.com/astrofrog/wcsaxes/issues/39 for a previous issue I raised). Sometimes when I plot such a cube using WCSAxes, the x-axis' labels display properly, but the y-axis labels and ticks only display when I "pan" the image right by a pixel or so, and disappears again if I pan the image back to the left.

When I make the plot:

When I pan to the right:

Here's a video of me reproducing the bug: https://dl.dropboxusercontent.com/u/3294908/wcsaxes_glitch_screengrab.mov using the following script: https://github.com/tomr-stargazer/astrodendro_analysis/blob/master/reproduce_the_wcsaxes_glitch.py

Here is the data in this cube slice: (dumped from numpy.savetxt) https://dl.dropboxusercontent.com/u/3294908/gal_slice.txt and here is the FITS header with WCS parameters: https://dl.dropboxusercontent.com/u/3294908/wcsaxes_glitch_wcs.fits

I wouldn't be surprised if the issue is, again, with the WCS header I'm using rather than a bug in the wcsaxes code, but this time (versus in #39) I have taken care to adjust the WCS settings to match my data, and I even turned the bounds_check off. Any insight is much appreciated!

[astrofrog]

@tomr-stargazer - do you see the same behavior if you zoom in to a small section of the map and pan left/right?

[tomr-stargazer]

Yes, if the "zoomed" section straddles the left edge of the data.

[tomr-stargazer]

Relevant: I realized that matplotlib.pyplot.imshow by default shifts both x-axis and y-axis by -0.5 pixels, setting the lower xlim to -0.5, which seems invalid under this transformation.

In [35]: arraything = arange(9).reshape(3,3)
In [36]: imshow(arraything, interpolation='nearest')
# produces:

This seemed odd to me, though, since I called datacube_dt_wcs.wcs.bounds_check(pix2world=False) before passing the wcs to WCSaxes, and indeed the pixel value -0.5 gives back a real number when I call wcs.all_pix2world directly:

In [33]: datacube_dt_wcs.all_pix2world(-0.5, 0, 0, 0)
Out[33]: [array(180.0625), array(-30.0), array(-35.1)]

I don't know how WCSAxes comes up with the pixel-to-coordinate transformation, though.

[astrofrog]

@tomr-stargazer - this may be a round-off issue, i.e. maybe the lower axes are at -0.5000000000001 or something similar. I will check to see if this is the case, and if there is anything we can do about it.

[tomr-stargazer]

I don't think a round-off issue would be at play. I turned off the bounds_check and so all_pix2world takes any pixel argument:

In [44]: datacube_dt_wcs.all_pix2world(-0.500000001, 0, 0, 0)
Out[44]: [array(180.062500000125), array(-30.0), array(-35.1)]

In [45]: datacube_dt_wcs.all_pix2world(-0.6, 0, 0, 0)
Out[45]: [array(180.075), array(-30.0), array(-35.1)]

In [46]: datacube_dt_wcs.all_pix2world(-100, 0, 0, 0)
Out[46]: [array(192.5), array(-30.0), array(-35.1)]

In [47]: datacube_dt_wcs.all_pix2world(-10000, 0, 0, 0)
Out[47]: [array(1070.0), array(-30.0), array(-35.1)]

I tried setting wcs.bounds_check(world2pix=False) also, but that didn't change anything.

When panning the above image slice, I often get this error (although it didn't appear during the video above) :

Aug 13 10:29:16 tsricemaclt.local python[61528] : Error: this application, or a library it uses, has passed an invalid numeric value (NaN, or not-a-number) to CoreGraphics API. This is a serious error and contributes to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update.

[astrofrog]

I still need to look into it, but WCSAxes requires that coordinates round-trip pixel -> world -> pixel, and that may be what is failing here.

[astrofrog]

Regarding the warning, I wonder whether that's a matplotlib bug? Certainly it should not be passing NaN to CoreGraphics, even if I plot some NaN values.

[astrofrog]

@tomr-stargazer - I just fixed an intricate bug that caused tick labels to disappear (#110) and I'm wondering whether it is what was causing your issue. Could you double check with the latest master to see if you are still having problems?

[tomr-stargazer]

Hi Tom,

sorry for the multi-week delay -- but I have checked out the latest wcsaxes master and it has not seemed to fix this problem. It seems to be maybe related to bounds-checking in the wcs object used to generate the tick labels - I wonder if tracking down all of the wcs objects in the code and forcing them to do this: wcs.bounds_check(world2pix=False, pix2world=False) would go some way towards solving the issue?

[astrofrog]

@tomr-stargazer I started to try and reproduce this issue, but can you make the COGAL_local_mom.fits file available to me? (you can send me the link privately if you don't want to share publicly). It'll be easier than trying to reconstruct it from the ASCII output :)

[tomr-stargazer]

Try this! http://www.cfa.harvard.edu/rtdc/CO/download/COGAL_local_mom.fits.gz On Oct 8, 2014 3:08 AM, "Thomas Robitaille" notifications@github.com wrote:

@tomr-stargazer https://github.com/tomr-stargazer I started to try and reproduce this issue, but can you make the COGAL_local_mom.fits file available to me? (you can send me the link privately if you don't want to share publicly). It'll be easier than trying to reconstruct it from the ASCII output :)

— Reply to this email directly or view it on GitHub https://github.com/astrofrog/wcsaxes/issues/104#issuecomment-58318729.

[astrofrog]

@tomr-stargazer - thanks, and just to make sure I can reproduce the issue you are seeing, can you provide a minimal script that shows the issue? (otherwise I need to try and reproduce the same setup, with the demo modules, etc. and it didn't seem to be working right).

[tomr-stargazer]

I've re-tooled this script https://github.com/tomr-stargazer/astrodendro_analysis/blob/master/reproduce_the_wcsaxes_glitch.py

to work stand-alone, as long as you edit the data_path variable to point to the right place.

Tom

On Wed, Oct 8, 2014 at 9:31 AM, Thomas Robitaille notifications@github.com wrote:

@tomr-stargazer https://github.com/tomr-stargazer - thanks, and just to make sure I can reproduce the issue you are seeing, can you provide a minimal script that shows the issue? (otherwise I need to try and reproduce the same setup, with the demo modules, etc. and it didn't seem to be working right).

— Reply to this email directly or view it on GitHub https://github.com/astrofrog/wcsaxes/issues/104#issuecomment-58357276.

[Cadair]

@astrofrog this looks like it is the same issue I was having with those solar reprojection plots?

[marcopigg]

Hi, I am getting a similar behaviour when trying to plot SDSS images. An example here (sorry for bash, but it's so I can download/unzip more easily). In this particular example, if I try to pan around the image, the labels move in a way which is unrelated to the image or the tick marks. On other SDSS images (I guess it depends on coordinates) no labels are shown and I get the same behaviour described in the first post.

(I am using the latest stable version of all packages numpy, mpl, wcsaxes, astropy etc., and py3.4.3)

[cescstl]

I have the same issue when trying to plot Fermi data.

If I set: ax.set_xlim(0, data.shape[1]) ax.set_ylim(0, data.shape[0])

after ax.imshow, then the labels show up correctly (I guess I chopped one image pixel off, though).