Fixing a problem with lost resolution in imshow

[dbratell]

imshow would assume an image would cover the whole plot which sometimes,
when the intent was to just plot in a small part of the image resulted in
a lot of lost resolution.

This happened because the created mesh grid was stretched to cover the
whole screen, and then only a small part of the mesh was actually used.

The lost resolution was proportional to the amount of space the image
used in the plot, so an image that was set to show in 10% of the width,
only kept 10% of its horizontal resolution.

There are other factors, like regrid_shape, that can also affect the
resolution of the output and a very, very large regrid_shape could
compensate for this problem at the cost of computation time.

Rationale

I was trying to plot lots of very high resolution images on a map where they each covered just a small fraction of the full plot. This turned out to result in 95% of the original pixels getting lost. I think it's better to not lose pixels.

Implications

This should have very little effect when images cover most of the plot, but when they don't, it can either result in higher resolution or the same resolution. If extent is larger than the visible area it will result in a more sparse remesh grid but in those cases the source data did not have enough pixels anyway so I think it will primarily result in fewer duplicate pixels (and maybe higher performance).

There is also the risk that there is a logical bug in what I have done that will result in the earth imploding.

I don't know enough about testing in cartopy, or testing coverage, to make a test for it, but maybe someone can assist me.

[dbratell]

There is a comment in warp_array:

    # XXX Take into account the extents of the original to determine
    # target_extents?
    target_native_x, target_native_y, extent = mesh_projection(
        target_proj, target_res[0], target_res[1],
        x_extents=target_x_extents, y_extents=target_y_extents)

which is also relevant here. warp_array could have created a much tighter mesh to compensate but it would only have made things slower.

[dbratell]

It has broken things. Big surprise. I think stock_img is plotted with a single pixel in the test_stock_img() test which is probably not enough. :)

[dbratell]

Not sure what is wrong. The code fails to convert extent=[-180, 180, -90, 90] to something useful. I suspect it has something to do with the the corner points of that rectangle being on the other side of the planet which makes the projections fail. It returns
target_extent (-0.00040424187786719957, 0.00040424187786719957, -0.00040424187785713834, 0.00040424187785713834) (zero plus/minus eps?) while it used to be (-6378073.21863, 6378073.21863, -6378073.21863, 6378073.21863). Those numbers came from ax.viewLim.get_points() so a completely different way at arriving at them. I don't even know if -180, 180, -90, 90 can be used as an extent in the ortographic projection.

[dbratell]

Yes, I'm in deep water here. The code change seems to work fine for those areas and projections I'm working with, but clearly this does not work for all projections and all extents.

I would like to make target_extent the intersection of the provided extent and the visible area but operations that work fine in some projections, just fail and return zeros in other projections (Orthographic in particular). I also tried roundtripping it through PlateCaree since I know/think it supports all points on the globe, but once I go back to Orthographic, I'm back to zeros.

Maybe I should just report a bug and leave it to people that are better than I am at juggling projections and area operations.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}