How would everyone feel about the following change? It will show the z value of a scalar image in the cursor if available (similar to what Matlab does). If there is no image or the image is RGB, it will revert to the previous behaviour.
Yeah, it is a lot more complicated than that. I made an exa!mole demoing it
in my upcoming book, but it is incomplete in that it only recognizes the
last image added (doesn't take into account the zsort order).
On Jan 8, 2015 9:36 PM, "Thomas A Caswell" notifications@github.com wrote:
You need to also take the extent of the image into account.
—
Reply to this email directly or view it on GitHub #3984 (comment)
.
I should note that my example was partly based off of the functionality
provided by the mpldatacursor package.
On Jan 8, 2015 9:41 PM, "Benjamin Root" ben.root@ou.edu wrote:
Yeah, it is a lot more complicated than that. I made an exa!mole demoing
it in my upcoming book, but it is incomplete in that it only recognizes the
last image added (doesn't take into account the zsort order).
On Jan 8, 2015 9:36 PM, "Thomas A Caswell" notifications@github.com
wrote:
You need to also take the extent of the image into account.
—
Reply to this email directly or view it on GitHub #3984 (comment)
.
--- a/lib/matplotlib/axes/_base.py+++ b/lib/matplotlib/axes/_base.py@@ -438,6 +438,7 @@ class _AxesBase(martist.Artist):
# funcs used to format x and y - fall back on major formatters
self.fmt_xdata = None
self.fmt_ydata = None
+ self.fmt_zdata = None
self.set_cursor_props((1, 'k')) # set the cursor properties for axes
@@ -2961,6 +2962,16 @@ class _AxesBase(martist.Artist):
val = func(y)
return val
+ def _get_z_coord(self, im, x, y):+ xmin, xmax, ymin, ymax = im.get_extent()+ if im.origin == 'upper':+ ymin, ymax = ymax, ymin+ data_extent = mtransforms.Bbox([[ymin, xmin], [ymax, xmax]])+ array_extent = mtransforms.Bbox([[0, 0], im.get_array().shape[:2]])+ trans = mtransforms.BboxTransformFrom(data_extent) +\+ mtransforms.BboxTransformTo(array_extent)+ return trans.transform_point([y,x]).astype(int)+
def format_coord(self, x, y):
"""Return a format string formatting the *x*, *y* coord"""
if x is None:
@@ -2971,7 +2982,15 @@ class _AxesBase(martist.Artist):
ys = '???'
else:
ys = self.format_ydata(y)
- return 'x=%s y=%s' % (xs, ys)+ try:+ im = self.images[np.argmax([im.zorder for im in self.images])]+ i, j = self._get_z_coord(im, x, y)+ z = im.get_array()[i, j]+ formatter = self.fmt_zdata or self.format_xdata+ zs = formatter(z)+ return 'x=%s y=%s z=%s' % (xs, ys, zs)+ except:+ return 'x=%s y=%s' % (xs, ys)
def minorticks_on(self):
'Add autoscaling minor ticks to the axes.'
This is some-what related to the discussion in #2986 in that we were talking about (iirc with out re-reading it in detail) a way to stack the message strings from multiple axes, not just the 'top' one of a twin{x,y} pair.
Yeah, it should probably figure out which of the artists it is over and then only ask the top artist to add an entry to the message. This will also help arbitrate when we have multiple crossing lines or lines on top of images, etc.
Activity
blink1073 commented on Jan 9, 2015
We could also add a fmt_zdata which falls back on format_xdata if None, so the user can directly change the z axis format:
tacaswell commented on Jan 9, 2015
You need to also take the extent of the image into account.
WeatherGod commented on Jan 9, 2015
Yeah, it is a lot more complicated than that. I made an exa!mole demoing it
in my upcoming book, but it is incomplete in that it only recognizes the
last image added (doesn't take into account the zsort order).
On Jan 8, 2015 9:36 PM, "Thomas A Caswell" notifications@github.com wrote:
WeatherGod commented on Jan 9, 2015
I should note that my example was partly based off of the functionality
provided by the mpldatacursor package.
On Jan 8, 2015 9:41 PM, "Benjamin Root" ben.root@ou.edu wrote:
blink1073 commented on Jan 9, 2015
I hear this complaint from everyone I introduce to Python, so I'd really like to nail this down.
blink1073 commented on Jan 9, 2015
Hack so far based on mpldatacursor:
blink1073 commented on Jan 9, 2015
With zorder handling:
tacaswell commented on Jan 9, 2015
All artists have picker logic, you could probably hi-jack that to sort out which, if any of the you are in and then take the top one of that sub-set.
This may be why no one has done this yet (obnoxious demanding devs) ;)
blink1073 commented on Jan 9, 2015
So basically all of mpldatacursor then...
blink1073 commented on Jan 9, 2015
The problem I see is that we don't have an event, which is needed by the picking logic and is used extensively by mpldatacursor.
tacaswell commented on Jan 9, 2015
We should have a mouse motion event (as that is what is updating the
formatter).
On Thu Jan 08 2015 at 10:14:31 PM Steven Silvester notifications@github.com
wrote:
blink1073 commented on Jan 9, 2015
So we'd need to plug in here:
./backend_bases.py:2790: s = event.inaxes.format_coord(event.xdata, event.ydata)
blink1073 commented on Jan 9, 2015
Get the s message there and then get an optional add-on message based on the artist...
blink1073 commented on Jan 9, 2015
Shucks, there is no artist assigned to a motion_notify_event.
tacaswell commented on Jan 9, 2015
This is some-what related to the discussion in #2986 in that we were talking about (iirc with out re-reading it in detail) a way to stack the message strings from multiple axes, not just the 'top' one of a twin{x,y} pair.
This should also be linked to #3146
7 remaining items
blink1073 commented on Jan 9, 2015
I sense a PR coming...
blink1073 commented on Jan 9, 2015
What if there are multiple images though? Don't we still need a zorder arbiter?
tacaswell commented on Jan 9, 2015
Yeah, it should probably figure out which of the artists it is over and then only ask the top artist to add an entry to the message. This will also help arbitrate when we have multiple crossing lines or lines on top of images, etc.
blink1073 commented on Jan 9, 2015
I think we should still check for contains, then check zorder, then ask that artist for its additional message, no?
blink1073 commented on Jan 9, 2015
Ah, I see that is what you already said...