Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Imshow keyword arg 'origin' issue #359

Closed
DPeterK opened this issue Oct 10, 2013 · 5 comments
Closed

Imshow keyword arg 'origin' issue #359

DPeterK opened this issue Oct 10, 2013 · 5 comments
Assignees

Comments

@DPeterK
Copy link
Member

DPeterK commented Oct 10, 2013

When plotting an image on a set of Cartopy geoaxes with a native projection not equal to the image's projection, an issue with the origin keyword argument becomes apparent. This kwarg has two options; 'upper' and 'lower', where 'upper' should be appropriate for images (such as jpegs or geotiffs) that define an origin in the upper-left corner of the image.

It can be shown that this kwarg is not being interpreted correctly by using an example from the Cartopy docs: http://scitools.org.uk/cartopy/docs/latest/matplotlib/advanced_plotting.html#images with the following minor changes:

import os
import matplotlib.pyplot as plt

from cartopy import config
import cartopy.crs as ccrs

img_proj = ccrs.Miller()
plot_proj = ccrs.PlateCarree()

fig = plt.figure(figsize=(8, 12))

# get the path of the file. It can be found in the repo data directory.
fname = os.path.join(config["repo_data_dir"],
                     'raster', 'sample', 'Miriam.A2012270.2050.2km.jpg'
                     )
img_extent = (-120.67660000000001, -106.32104523100001,
              13.2301484511245, 30.766899999999502)
img = plt.imread(fname)[::-1, ...]

ax = plt.axes(projection=plot_proj)
ax.set_global()
plt.title('Hurricane Miriam from the Aqua/MODIS satellite\n'
          '2012 09/26/2012 20:50 UTC')

# set a margin around the data
ax.set_xmargin(0.05)
ax.set_ymargin(0.10)

# add the image. Because this image was a tif, the "origin" of the image is
# in the upper left corner.
ax.imshow(img, origin='lower', transform=img_proj, extent=img_extent)
ax.coastlines(resolution='50m', color='black', linewidth=1)

plt.show()

The changes made here are altering the axes projection to Miller and setting the axes extent to global, the combination of which makes the issue evident.

To demonstrate the issue, removing the array manipulation when img is made and changing the origin kwarg's value to upper moves the position of the image from the correct location (generated by the code above), to a location of appropriate longitude but incorrect latitude. This may be seen much more clearly by comparing the two images found below, where origin='upper' is set in the top image, but origin='lower' (with appropriate array manipulation) is set in the lower.

imshow_origin_bug_upper
imshow_origin_bug_lower

@ajdawson
Copy link
Member

This must be related to #358, if not the same bug. It sure looks similar.

@ajdawson
Copy link
Member

ajdawson commented Dec 7, 2013

OK I've nailed down the weird origin behaviour. When the image is interpolated so that it can be displayed on the new projection there is an implicit assumption that the image array is structured from lower left to upper right, meaning that the regridded image is wrong if it is in fact upper left to lower right. Adding this after L744 in geoaxes.py gives the expected behaviour:

if kwargs['origin'] == 'upper':
    # we implicitly assume the orientation is lower when we regrid
    img = img[::-1]
    kwargs['origin'] = 'lower'

However, this does not solve the artefacts outside of the expected domain... I shall see if I can locate that problem before making a PR as they may well be related issues.

@ajdawson
Copy link
Member

ajdawson commented Dec 7, 2013

OK I think I have this one sorted, the artefacts at the edges of the plot are due to the nearest neighbour interpolation routine not masking off points outside the original image. I'll try and put a PR together soon and update here.

@DPeterK
Copy link
Member Author

DPeterK commented Dec 9, 2013

Nice one 👍

@ajdawson
Copy link
Member

ajdawson commented Dec 9, 2013

Thanks for the comprehensive bug report @dkillick.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants