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

Fixing a problem with lost resolution in imshow #1645

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

dbratell
Copy link

@dbratell dbratell commented Aug 27, 2020

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.

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 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.
@dbratell
Copy link
Author

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
Copy link
Author

dbratell commented Aug 27, 2020

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
Copy link
Author

dbratell commented Aug 27, 2020

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
Copy link
Author

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
Copy link

CLAassistant commented Apr 8, 2024

CLA assistant check
All committers have signed the CLA.

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

Successfully merging this pull request may close these issues.

2 participants