astrofrog / wcsaxes Goto Github PK

For WCS, this can be obtained by setting crval=0,0 and looking for the lon/lat lines to -180 to 180 and -90 to 90.

In rcparams.png, you can see that tick marks in the top-left, bottom-left, and bottom-rigth corners are not being clipped to the axes. Also, like in Matplotlib it would look nicer if tick marks on the edge of the plot were avoided.

Need documentation for https://github.com/astrofrog/wcsaxes/pull/72/files

Demonstrated here:

http://nbviewer.ipython.org/gist/anizami/d02fc3a75e4b78a8d257

Over in astropy/photutils#114 (comment) we noticed that plotting circles using Circle over an image that was plotted with imshow, the circle sometimes appears shifted by ~ 1 pixel.

@astrofrog @anizami Do you have a unit test in wcsaxes already that check this for the default interpolation and for interpolation="nearest"?

cc @bsipocz @larrybradley

Unless I am mistaken SkyCoord reads the whole transform graph to see all the coordinates that are registered to it (both inside astropy and outside?). If you used this functionality it would make it really easy to support SunPy coordinates in WCSAxes.

It would be nice to heave an easy way to set the padding between the axes labels and tick labels and the plot axes.

Normally, wcsaxes axis labels avoid tick marks / tick labels. However, when I manually specify set_axislabel_position('b') on a CooridinateHelper, the label is placed immediately beneath the axis, on top of other ticks/ticklabels

We need to implement the functionality described in the API as:

glon, glat = ax.get_coords_overlay('galactic')

which allows a different coordinate system to be plotted.

There may be places where we can improve the performance of the code by using Cython or C. Of course, we first need to figure out where the bottlenecks are :)

Including:

• instances of Formatter subclasses
• strings with e.g. '%5.4f'
• strings with e.g. '{0:5.3f}'

@anizami - I was thinking about the fact we need test data for the tests and for the docs, and I think the cleanest thing to do would be to create a wcsaxes.datasets sub-module inside which the datasets are downloaded. Of course, we don't want to download it if the user is just importing wcsaxes, and we also don't want the user to download it every time they access wcsaxes.datasets, but Astropy allows caching, so I think you can use cache=True when calling download_file. So I think if you create a datasets.py sub-module and move the downloads to there, you can then try and see if the files are imported the first time wcsaxes.datasets is imported, then you can try and close python and open it up again, import wcsaxes.datasets, and it should then get it from the cache.

Once this works, you can change test_image.py to get the files from wcsaxes.datasets instead and then also use this when writing the docs on slicing.

Does this make sense?

The code introduced in #46 fails for non-square axes. The calculation should take into account the aspect ratio of the axes.

cc @lpsinger

We should generalize https://github.com/astrofrog/wcsaxes/blob/master/wcsaxes/utils.py#L93 otherwise users can't overlay arbitrary coordinate systems if original WCS is not in a known frame. Also, some of this could be moved to astropy core.

When labels along an axis go 13:14:12 13:14:13 etc we can avoid printing out the degree and minutes each time.

@anizami - just opened this as a reminder to ourselves

and combine with _gen_axes_patch. Will work on this at SciPy 2014.

We should be able to use the bounding boxes of labels to detect overlap and avoid showing labels that overlap.

(I will look into this)

... so that if one gives a PV cube with a m/s spectral axis, it can be shown e.g. in km/s

I can do this.

When I run import wcsaxes; wcsaxes.test() in Python on my machine, all the tests pass but after that it gives this infinite loop of messages (which I can only get rid of by closing the terminal). The loop of messages (cropped) is here:
https://gist.github.com/anizami/39bb3b1e55e747185d17
I looked up the issue and it's a problem with the pyreadline package that is for Windows:
pyreadline/pyreadline#18. It's been fixed in the PR pyreadline/pyreadline#24 that hasn't been merged yet. When I cloned a copy of this PR's branch and installed that version of pyreadline, the infinite loop issue went away and all the tests pass. I don't know if this is something we can control for but can we maybe add a warning in the installation.rst docs for Windows with Anaconda users?

The installation docs say one should do

import wcsaxes
wcsaxes.test()

but the top-level namespace doesn't contain test as far as I can see.

Currently it looks like the API docs aren't working for WCSAxesSubplot:

<autosummary>:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
writing additional files... (4 module code pages)None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
 _modules/index
None:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
 genindexNone:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
 py-modindexNone:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'
 searchNone:None: WARNING: toctree contains reference to nonexisting document u'api/wcsaxes.WCSAxesSubplot'

@eteq - do you have any ideas why this might be happening?

Support the rotation of tick marks along the grid lines. This should be trivial.

I've played with wcsaxes a bit and overall it works great!

One thing I found surprising is that ticks disappear when they overlap (see the x axis in cell 2) whereas matplotlib doesn't try to be clever and simply overplot them (see x axis in cell 3):
http://nbviewer.ipython.org/gist/cdeil/b0376df98069bc4f0f0b

Maybe follow the matplotlib behaviour?

see http://bpaste.net/show/193140/

For example, using geospatial data. See for example this projection:

http://nsidc.org/data/polar_stereo/ps_grids.html?file=/data/grids/ps_grid.html

There is lots of polar data available, so it would be cool to demonstrate this.

The following test script produces some unusual results:

#!/usr/bin/env python
from matplotlib import pyplot as plt
from wcsaxes import WCSAxes
import astropy.wcs

wcs = astropy.wcs.WCS()
wcs.wcs.ctype = ['RA---TAN', 'DEC--TAN']
wcs.wcs.crval = [90, 70]
wcs.wcs.cdelt = [16, 16]
wcs.wcs.crpix = [1, 1]
wcs.wcs.radesys = 'ICRS'
wcs.wcs.equinox = 2000.0
fig = plt.figure(figsize=(3, 3), dpi=72)
ax = WCSAxes(fig, [0.1, 0.1, 0.8, 0.8], wcs=wcs)
fig.add_axes(ax)
ax.set_xlim(1, -1)
ax.set_ylim(-1, 1)
ax.grid()
fig.savefig('test.png', dpi=72)

The ticks are pointing in the wrong direction with respect to the axes, and are not being clipped to the axes rect.

see http://bpaste.net/show/193140/

Instead of being negative it's huge!

We should set up some asv benchmark tests to make sure that we don't include any performance regressions: http://spacetelescope.github.io/asv/index.html

Some image tests are not currently marked with the remote_data decorator - @anizami, could you fix this? The tests should run (but skip over these tests) for:

python setup.py test

At the moment, this crashes with an error saying some of the tests tried to access the internet.

Here's an example that doesn't show a thing:

https://gist.github.com/9429231
http://nbviewer.ipython.org/gist/anonymous/9429231

I think there must be an issue with the WCS being created; this may be an upstream bug but it certainly affects WCSAxes as there is no sensible error message printed

Hi,

I found that sometimes, WCSAxes fails to properly wrap around zero. Attached are two examples showing (a) when it works and (b) when it doesn't. The WCS headers and data that are needed to reproduce this are found here:

Failing data: https://dl.dropboxusercontent.com/u/3294908/slice_of_galaxy_image.txt
Failing WCS: https://dl.dropboxusercontent.com/u/3294908/galaxy_2d_header.fits
Passing data: https://dl.dropboxusercontent.com/u/3294908/slice_of_oph_image.txt
Passing WCS: https://dl.dropboxusercontent.com/u/3294908/ophiuchus_2d_header.fits

These cases broadly follow the example from this notebook: http://nbviewer.ipython.org/github/astrofrog/wcsaxes-examples/blob/master/WCSAxes%20Demo.ipynb

Failing case:

galaxy = np.loadtxt('slice_of_galaxy_image.txt')
fig = plt.figure()
In [15]: ax = WCSAxes(fig, [0.1, 0.1, 0.8, 0.8], wcs=WCS('galaxy_2d_header.fits'))
WARNING: FITSFixedWarning: The WCS transformation has more axes (2) than the image it is associated with (0) [astropy.wcs.wcs]

In [16]: fig.add_axes(ax)

In [16]: ax.imshow(galaxy, origin='lower')
Out[16]: <matplotlib.image.AxesImage at 0x4dcb490>

In [17]: fig.canvas.draw()
/home/tom/anaconda/lib/python2.7/site-packages/WCSAxesExperimental-0.0.0-py2.7.egg/wcsaxes/coordinate_range.py:49: RuntimeWarning: invalid value encountered in greater
/home/tom/anaconda/lib/python2.7/site-packages/WCSAxesExperimental-0.0.0-py2.7.egg/wcsaxes/coordinate_range.py:57: RuntimeWarning: invalid value encountered in greater
/home/tom/anaconda/lib/python2.7/site-packages/WCSAxesExperimental-0.0.0-py2.7.egg/wcsaxes/coordinate_range.py:10: RuntimeWarning: invalid value encountered in greater
/home/tom/anaconda/lib/python2.7/site-packages/WCSAxesExperimental-0.0.0-py2.7.egg/wcsaxes/coordinate_helpers.py:345: RuntimeWarning: invalid value encountered in greater
/home/tom/anaconda/lib/python2.7/site-packages/WCSAxesExperimental-0.0.0-py2.7.egg/wcsaxes/coordinate_helpers.py:346: RuntimeWarning: invalid value encountered in greater
/home/tom/anaconda/lib/python2.7/site-packages/WCSAxesExperimental-0.0.0-py2.7.egg/wcsaxes/coordinate_helpers.py:357: RuntimeWarning: invalid value encountered in greater
/home/tom/anaconda/lib/python2.7/site-packages/WCSAxesExperimental-0.0.0-py2.7.egg/wcsaxes/coordinate_helpers.py:358: RuntimeWarning: invalid value encountered in greater
/home/tom/anaconda/lib/python2.7/site-packages/WCSAxesExperimental-0.0.0-py2.7.egg/wcsaxes/coordinate_helpers.py:371: RuntimeWarning: invalid value encountered in less

Passing case:

 # (replace `galaxy` with `ophiuchus` in the above code)

I wanted to try out wcsaxes, so I pasted the examples from the docs into a notebook (located here.
As you can see the axis frame is often shifted from the ticks and image, i.e. it doesn't work for me (wcsaxes version a44c658, matplotlib version 1.3.1).

@astrofrog Do you plan to maintain the WCSAxes Demo notebook?
If yes, could you include a command to download the example FITS files (or include them in the notebook if that is possible) so that one can start playing with wcsaxes?

cc @anizami

I've been using the WCSAxesSubplot with fig.set_tight_layout(True), which resizes axes as needed to fill available space. However, this is currently broken:

from wcsaxes import WCSAxesSubplot
import matplotlib.pyplot as plt
from astropy.io import fits
from astropy.wcs import WCS

data = fits.getdata('w5.fits')
wcs = WCS('w5.fits')


f = plt.figure()
f.set_tight_layout(True)
ax = WCSAxesSubplot(f, 111)
ax.set_xlabel('x')
ax.set_ylabel('y')
f.add_subplot(ax)

ax.imshow(data)
plt.show()

I think that d0e8a3c introduced the problem (hooray, git bisect!). Generally, the issue is probably that get_tightbbox is not properly taking axis labels into account.

wcsaxes currently tries to put axis labels as close as possible to the axis, without overlapping any other text. This means that sometimes the label is inline with the ticklabels, and sometimes it's below:

This is kind of jarring when interactively panning using tight_axes, since snapping between these two layouts causes the image size to change abruptly

I would prefer that the axis labels are always placed below the tick labels, and that they never "jump up"

This one is a little random. I would like to be able to plot a WCSAxes object and then change the WCS object (i.e. replace it with different instance) and have the Axes refresh on a re-draw command.

i.e.

ax = WCSAxes(..., wcs=WCS())
ax.wcs = WCS2()
ax.draw()

The reason for this is animating a series of images, the data is easy to change but the WCS information needs to be updated as well.

I would be happy to work on this as time allows, but some guidance would be nice.