SourceForge logo
SourceForge logo
Menu

matplotlib-users — Discussion related to using matplotlib

You can subscribe to this list here.

2003 Jan
Feb
Mar
Apr
May
(3)
Jun
Jul
Aug
(12)
Sep
(12)
Oct
(56)
Nov
(65)
Dec
(37)
2004 Jan
(59)
Feb
(78)
Mar
(153)
Apr
(205)
May
(184)
Jun
(123)
Jul
(171)
Aug
(156)
Sep
(190)
Oct
(120)
Nov
(154)
Dec
(223)
2005 Jan
(184)
Feb
(267)
Mar
(214)
Apr
(286)
May
(320)
Jun
(299)
Jul
(348)
Aug
(283)
Sep
(355)
Oct
(293)
Nov
(232)
Dec
(203)
2006 Jan
(352)
Feb
(358)
Mar
(403)
Apr
(313)
May
(165)
Jun
(281)
Jul
(316)
Aug
(228)
Sep
(279)
Oct
(243)
Nov
(315)
Dec
(345)
2007 Jan
(260)
Feb
(323)
Mar
(340)
Apr
(319)
May
(290)
Jun
(296)
Jul
(221)
Aug
(292)
Sep
(242)
Oct
(248)
Nov
(242)
Dec
(332)
2008 Jan
(312)
Feb
(359)
Mar
(454)
Apr
(287)
May
(340)
Jun
(450)
Jul
(403)
Aug
(324)
Sep
(349)
Oct
(385)
Nov
(363)
Dec
(437)
2009 Jan
(500)
Feb
(301)
Mar
(409)
Apr
(486)
May
(545)
Jun
(391)
Jul
(518)
Aug
(497)
Sep
(492)
Oct
(429)
Nov
(357)
Dec
(310)
2010 Jan
(371)
Feb
(657)
Mar
(519)
Apr
(432)
May
(312)
Jun
(416)
Jul
(477)
Aug
(386)
Sep
(419)
Oct
(435)
Nov
(320)
Dec
(202)
2011 Jan
(321)
Feb
(413)
Mar
(299)
Apr
(215)
May
(284)
Jun
(203)
Jul
(207)
Aug
(314)
Sep
(321)
Oct
(259)
Nov
(347)
Dec
(209)
2012 Jan
(322)
Feb
(414)
Mar
(377)
Apr
(179)
May
(173)
Jun
(234)
Jul
(295)
Aug
(239)
Sep
(276)
Oct
(355)
Nov
(144)
Dec
(108)
2013 Jan
(170)
Feb
(89)
Mar
(204)
Apr
(133)
May
(142)
Jun
(89)
Jul
(160)
Aug
(180)
Sep
(69)
Oct
(136)
Nov
(83)
Dec
(32)
2014 Jan
(71)
Feb
(90)
Mar
(161)
Apr
(117)
May
(78)
Jun
(94)
Jul
(60)
Aug
(83)
Sep
(102)
Oct
(132)
Nov
(154)
Dec
(96)
2015 Jan
(45)
Feb
(138)
Mar
(176)
Apr
(132)
May
(119)
Jun
(124)
Jul
(77)
Aug
(31)
Sep
(34)
Oct
(22)
Nov
(23)
Dec
(9)
2016 Jan
(26)
Feb
(17)
Mar
(10)
Apr
(8)
May
(4)
Jun
(8)
Jul
(6)
Aug
(5)
Sep
(9)
Oct
(4)
Nov
Dec
2017 Jan
(5)
Feb
(7)
Mar
(1)
Apr
(5)
May
Jun
(3)
Jul
(6)
Aug
(1)
Sep
Oct
(2)
Nov
(1)
Dec
2018 Jan
Feb
Mar
Apr
(1)
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
2020 Jan
Feb
Mar
Apr
May
(1)
Jun
Jul
Aug
Sep
Oct
Nov
Dec
2025 Jan
(1)
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
S M T W T F S

1
(16)
2
(22)
3
(28)
4
(17)
5
(17)
6
(7)
7
8
(15)
9
(28)
10
(26)
11
(28)
12
(19)
13
(5)
14
(3)
15
(21)
16
(28)
17
(11)
18
(18)
19
(6)
20
(5)
21
(18)
22
(11)
23
(22)
24
(28)
25
(17)
26
(17)
27
(7)
28
(16)
29
(24)
30
(25)
31
(14)



Showing 17 results of 17

From: David A. <dwa...@su...> - 2010年03月05日 22:29:56
All,
In one post from John Hunter, I heard the word "traits", which I assume is from the enthought distribution.
Is there a move in matplotlib toward the "trait" technology taking place? How about for Python in general?
Thanks.
David.
From: Jae-Joon L. <lee...@gm...> - 2010年03月05日 21:40:11
divider.get_horizontal() returns a list of size objects
(http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/api/axes_size_api.html#module-mpl_toolkits.axes_grid.axes_size)
that are currently used.
For example,
 cax = divider.new_horizontal(size="5%", pad=0.05)
 horiz_list = divider.get_horizontal()
horiz_list[0] is x-size of ax, horiz_list[1] is pad size, and
horiz_list[2] is x-size of cax. You can modify those size objects (but
usually they don't provide public interfaces). Or you can substitute
any of them with a valid size object.
 horiz_list[1]._fixed_size = 0. # makes pad 0 inches
 horiz_list[2]._fraction = 0.1 # width of cax becomes 10% of the width of ax
Or
 from mpl_toolkits.axes_grid.axes_size import Fixed, Fraction
 horiz_list[1] = Fixed(0.)
 horiz_list[2] = Fraction(0.1, horiz_list[0])
There are not much of documentation available, but this may be helpful.
 http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/axes_divider.html
Regards,
-JJ
On Fri, Mar 5, 2010 at 3:38 PM, Thomas Robitaille
<tho...@gm...> wrote:
> Hi Jae-Joon,
>
> Thanks for your help! One last question - if I create a colorbar axes with
>
> cax = divider.new_horizontal(size="5%", pad=0.05)
>
> Is it possible to then modify the size and pad parameters, or do I need to delete the axes and start again?
>
> Cheers,
>
> Tom
>
> On Mar 5, 2010, at 12:20 PM, Jae-Joon Lee wrote:
>
>> Unfortunately, axes_grid toolkit (in most cases) creates an axes using
>> its own Axes class by default. Here is some more details.
>>
>> http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#axisline
>>
>> To use mpl's original Axes class, append axes_class parameter.
>>
>> import matplotlib.axes as maxes
>> cax = divider.new_horizontal(size="5%", pad=0.05, axes_class=maxes.Axes)
>>
>> Then your code should work.
>>
>> Just in case, with the axes_grid's own Axes class, instead of looping
>> over major_ticks, you do
>>
>> cax.axis["left"].toggle(all=False)
>> cax.axis["right"].toggle(all=True)
>>
>> Regards,
>>
>> -JJ
>>
>>
>> On Fri, Mar 5, 2010 at 9:38 AM, Thomas Robitaille
>> <tho...@gm...> wrote:
>>> Hi Jae-Joon,
>>>
>>> I am encountering another issue, when using the method you suggest in combination with the parasite_axes from the matplotlib toolkit:
>>>
>>> ---
>>>
>>> import matplotlib.pyplot as mpl
>>> import numpy as np
>>> from mpl_toolkits.axes_grid import make_axes_locatable
>>> import mpl_toolkits.axes_grid.parasite_axes as mpltk
>>>
>>> fig = mpl.figure()
>>>
>>> ax = mpltk.SubplotHost(fig, 1, 1, 1)
>>> fig.add_axes(ax)
>>>
>>> divider = make_axes_locatable(ax)
>>>
>>> cax = divider.new_horizontal(size="5%", pad=0.05)
>>> fig.add_axes(cax)
>>>
>>> image = ax.imshow(np.random.random((100,100)))
>>>
>>> cb = fig.colorbar(image, cax=cax)
>>>
>>> ---
>>>
>>> In the above case, the labels end up on the wrong side of the plot, and the usual method for changing the label position, e.g.:
>>>
>>> for tick in cax.xaxis.get_major_ticks():
>>> tick.tick1On = True
>>> tick.tick2On = True
>>> tick.label1On = False
>>> tick.label2On = True
>>>
>>> does not work. Do you have any idea why this might be?
>>>
>>> Thanks for any help,
>>>
>>> Thomas
>>>
>>>
>>>
>>> On Mar 4, 2010, at 10:28 PM, Jae-Joon Lee wrote:
>>>
>>>> see
>>>>
>>>> http://www.mail-archive.com/mat...@li.../msg15919.html
>>>>
>>>> axes_grid toolkit provides some helper function that utilizes
>>>> axes_locator (take a look at demo_locatable_axes_easy function in the
>>>> example below)
>>>>
>>>> http://matplotlib.sourceforge.net/examples/axes_grid/demo_axes_divider.html
>>>>
>>>> -JJ
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Mar 4, 2010 at 9:05 PM, Thomas Robitaille
>>>> <tho...@gm...> wrote:
>>>>> Hi,
>>>>>
>>>>> I am trying to set up a colorbar that automatically resizes if I zoom in to an image (which changes the aspect ratio of the axes, so I want the colorbar to get resized too). Let's say I have two Axes instances, say ax (for the main image) and cax (for the colorbar). I can set up a callback if the view limits in one axes change, for example
>>>>>
>>>>> ax.callbacks.connect('xlim_changed', update_colorbar)
>>>>> ax.callbacks.connect('ylim_changed', update_colorbar)
>>>>>
>>>>> Now I can store a reference to cax inside ax:
>>>>>
>>>>> ax._cax = cax
>>>>>
>>>>> And I can now define update_colorbar so that it basically changes the position of cax:
>>>>>
>>>>> def update_colorbar(ax):
>>>>>
>>>>>  # Get current position
>>>>>  xmin = ax..get_position().xmin
>>>>>  ...
>>>>>
>>>>>  # Compute new colorbar position
>>>>>  ...
>>>>>
>>>>>  # Set new position
>>>>>  ax._cax.set_position(...)
>>>>>
>>>>>  # Return axes instance
>>>>>  return ax
>>>>>
>>>>> Now the issue is that if I select a region of the image to zoom into, then as soon as I've selected the region, update_colorbar gets called, but by then, the aspect ratio of ax hasn't changed, and so the position I find when I do xmin = ax..get_position().xmin in update_colorbar is the *old* position of ax, not the new one. So the colorbar position is always one step behind compared to the main image axes.
>>>>>
>>>>> Can anyone think of any way that would avoid this issue, and to be able to use the *new* position of ax inside update_colorbar?
>>>>>
>>>>> Thanks in advance for any help,
>>>>>
>>>>> Thomas
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel&#174; Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>
>>>
>>>
>
>
From: Thomas R. <tho...@gm...> - 2010年03月05日 20:38:23
Hi Jae-Joon,
Thanks for your help! One last question - if I create a colorbar axes with
cax = divider.new_horizontal(size="5%", pad=0.05)
Is it possible to then modify the size and pad parameters, or do I need to delete the axes and start again?
Cheers,
Tom
On Mar 5, 2010, at 12:20 PM, Jae-Joon Lee wrote:
> Unfortunately, axes_grid toolkit (in most cases) creates an axes using
> its own Axes class by default. Here is some more details.
> 
> http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#axisline
> 
> To use mpl's original Axes class, append axes_class parameter.
> 
> import matplotlib.axes as maxes
> cax = divider.new_horizontal(size="5%", pad=0.05, axes_class=maxes.Axes)
> 
> Then your code should work.
> 
> Just in case, with the axes_grid's own Axes class, instead of looping
> over major_ticks, you do
> 
> cax.axis["left"].toggle(all=False)
> cax.axis["right"].toggle(all=True)
> 
> Regards,
> 
> -JJ
> 
> 
> On Fri, Mar 5, 2010 at 9:38 AM, Thomas Robitaille
> <tho...@gm...> wrote:
>> Hi Jae-Joon,
>> 
>> I am encountering another issue, when using the method you suggest in combination with the parasite_axes from the matplotlib toolkit:
>> 
>> ---
>> 
>> import matplotlib.pyplot as mpl
>> import numpy as np
>> from mpl_toolkits.axes_grid import make_axes_locatable
>> import mpl_toolkits.axes_grid.parasite_axes as mpltk
>> 
>> fig = mpl.figure()
>> 
>> ax = mpltk.SubplotHost(fig, 1, 1, 1)
>> fig.add_axes(ax)
>> 
>> divider = make_axes_locatable(ax)
>> 
>> cax = divider.new_horizontal(size="5%", pad=0.05)
>> fig.add_axes(cax)
>> 
>> image = ax.imshow(np.random.random((100,100)))
>> 
>> cb = fig.colorbar(image, cax=cax)
>> 
>> ---
>> 
>> In the above case, the labels end up on the wrong side of the plot, and the usual method for changing the label position, e.g.:
>> 
>> for tick in cax.xaxis.get_major_ticks():
>> tick.tick1On = True
>> tick.tick2On = True
>> tick.label1On = False
>> tick.label2On = True
>> 
>> does not work. Do you have any idea why this might be?
>> 
>> Thanks for any help,
>> 
>> Thomas
>> 
>> 
>> 
>> On Mar 4, 2010, at 10:28 PM, Jae-Joon Lee wrote:
>> 
>>> see
>>> 
>>> http://www.mail-archive.com/mat...@li.../msg15919.html
>>> 
>>> axes_grid toolkit provides some helper function that utilizes
>>> axes_locator (take a look at demo_locatable_axes_easy function in the
>>> example below)
>>> 
>>> http://matplotlib.sourceforge.net/examples/axes_grid/demo_axes_divider.html
>>> 
>>> -JJ
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Mar 4, 2010 at 9:05 PM, Thomas Robitaille
>>> <tho...@gm...> wrote:
>>>> Hi,
>>>> 
>>>> I am trying to set up a colorbar that automatically resizes if I zoom in to an image (which changes the aspect ratio of the axes, so I want the colorbar to get resized too). Let's say I have two Axes instances, say ax (for the main image) and cax (for the colorbar). I can set up a callback if the view limits in one axes change, for example
>>>> 
>>>> ax.callbacks.connect('xlim_changed', update_colorbar)
>>>> ax.callbacks.connect('ylim_changed', update_colorbar)
>>>> 
>>>> Now I can store a reference to cax inside ax:
>>>> 
>>>> ax._cax = cax
>>>> 
>>>> And I can now define update_colorbar so that it basically changes the position of cax:
>>>> 
>>>> def update_colorbar(ax):
>>>> 
>>>> # Get current position
>>>> xmin = ax..get_position().xmin
>>>> ...
>>>> 
>>>> # Compute new colorbar position
>>>> ...
>>>> 
>>>> # Set new position
>>>> ax._cax.set_position(...)
>>>> 
>>>> # Return axes instance
>>>> return ax
>>>> 
>>>> Now the issue is that if I select a region of the image to zoom into, then as soon as I've selected the region, update_colorbar gets called, but by then, the aspect ratio of ax hasn't changed, and so the position I find when I do xmin = ax..get_position().xmin in update_colorbar is the *old* position of ax, not the new one. So the colorbar position is always one step behind compared to the main image axes.
>>>> 
>>>> Can anyone think of any way that would avoid this issue, and to be able to use the *new* position of ax inside update_colorbar?
>>>> 
>>>> Thanks in advance for any help,
>>>> 
>>>> Thomas
>>>> ------------------------------------------------------------------------------
>>>> Download Intel&#174; Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>> 
>> 
>> 
From: Friedrich R. <fri...@gm...> - 2010年03月05日 20:36:59
2010年3月5日 David Goldsmith <d_l...@ya...>:
> I think it's a bug in numpy.ma._extrema_operations.reduce (at least Pierre GM couldn't explain it away and instructed me to file a bug ticket on it over there, which I did; w/ your permission, I'll add your code to that ticket?) - at the very least, it should be able to handle zero-size arrays more robustly (i.e., w/out raising an exception) IMO. Of course, that doesn't mean that once it's been fixed, imshow (or cm, which is apparently what's really calling it) won't encounter some other problem on account of the fix, but I guess we'll have to cross that bridge when we come to it?
Hmm, IMO it's correct to raise because the minimum of nothing isn't
defined? Matplotlib tries to find a minimum. Anyway, you cannot draw
ndarrays arr with 0 in arr.shape. So I think matplotlib should maybe
silently skip attempting to draw it?
Friedrich
From: David G. <d_l...@ya...> - 2010年03月05日 20:03:43
(Pierre GM: are you subscribed to this list? If so, sorry for cc-ing you.)
--- On Fri, 3/5/10, Friedrich Romstedt <fri...@gm...> wrote:
> From: Friedrich Romstedt <fri...@gm...>
> Subject: Re: [Matplotlib-users] Mysterious "ValueError: zero-size array..."
> To: "David Goldsmith" <d_l...@ya...>
> Date: Friday, March 5, 2010, 10:46 AM
> I can reproduce the error with:
> 
> >>> argW = numpy.asarray([[0, 1, 2], [3, 4, 5],
> [6, 7, 8], [9, 10, 11]])
> >>> argW
> array([[ 0, 1, 2],
>    [ 3, 4, 5],
>    [ 6, 7, 8],
>    [ 9, 10, 11]])
> >>> argW[0:1, 0:0]
> array([], shape=(1, 0), dtype=int32)
> >>> d1.axes.imshow(argW[0:1, 0:0])
> Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>  File
> "D:\Programme\Programmierung\python-2.4.1\lib\site-packages\matplotlib\axes.py",
> line 5471, in imshow
>   im.autoscale_None()
>  File
> "D:\Programme\Programmierung\python-2.4.1\lib\site-packages\matplotlib\cm.py",
> line 148, in autoscale_None
>   self.norm.autoscale_None(self._A)
>  File
> "D:\Programme\Programmierung\python-2.4.1\lib\site-packages\matplotlib\colors.py",
> line 682, in autoscale_None
>   if self.vmin is None: self.vmin =
> ma.minimum(A)
>  File
> "D:\Programme\Programmierung\python-2.4.1\lib\site-packages\numpy\ma\core.py",
> line 3042, in __call__
>   return self.reduce(a)
>  File
> "D:\Programme\Programmierung\python-2.4.1\lib\site-packages\numpy\ma\core.py",
> line 3057, in reduce
>   t = self.ufunc.reduce(target, **kargs)
> ValueError: zero-size array to ufunc.reduce without
> identity
> 
> So it seems to me that you pass in an array with shape <
> 4 in at least
> one of the dimensions?
Thanks for your reply, Friedrich, and for creating the reproducing example! 
I think it's a bug in numpy.ma._extrema_operations.reduce (at least Pierre GM couldn't explain it away and instructed me to file a bug ticket on it over there, which I did; w/ your permission, I'll add your code to that ticket?) - at the very least, it should be able to handle zero-size arrays more robustly (i.e., w/out raising an exception) IMO. Of course, that doesn't mean that once it's been fixed, imshow (or cm, which is apparently what's really calling it) won't encounter some other problem on account of the fix, but I guess we'll have to cross that bridge when we come to it?
> NB: You lose at most 3 pixels at the border of your image
> when drawing
> it the method you proposed, because the int floor'ing will
> cause that.
I was afraid of that (fancy index math has never been one of my strong suits) but ultimately I'm making ~5e3 x ~5e3 images (which is why I'm having to create the images that way in the first place - I was getting a memory error trying to imshow the whole full-resolution image w/ one call), so that loss is negligible (but if you can show me how to avoid it, I'd be much appreciative).
> NB II: Something happened, you sent the last message four
> times?
Yeah, my apologies, I'm not sure why that happened; maybe was having connectivity issues and wasn't sure if I'd sent it successfully? Anyway, sorry 'bout that. :-(
Thanks again!
DG
> 
> Friedrich
> 
 
From: Bruce F. <br...@cl...> - 2010年03月05日 18:11:38
Has anyone had any success in making land or sea locations transparent
in a resulting .png? There are instances when I would like an image
to be overlayed on a map and let the underlying terrain map show
through. Using an image as a ground overlay in Google Earth would be
an example of such a usage.
Also, I've noticed that figurePatch.set_alpha(0.0) does not apply
transparency within the bounding box. I'm still ending up with white
areas within the bounding box. Can transparency be set within the
basemap box?
Thanks so much!
Bruce
---------------------------------------
Bruce W. Ford
Clear Science, Inc.
br...@cl...
http://www.ClearScienceInc.com
Phone/Fax: 904-379-9704
8241 Parkridge Circle N.
Jacksonville, FL 32211
Skype: bruce.w.ford
Google Talk: fo...@gm...
From: Jae-Joon L. <lee...@gm...> - 2010年03月05日 17:20:46
Unfortunately, axes_grid toolkit (in most cases) creates an axes using
its own Axes class by default. Here is some more details.
http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#axisline
To use mpl's original Axes class, append axes_class parameter.
import matplotlib.axes as maxes
cax = divider.new_horizontal(size="5%", pad=0.05, axes_class=maxes.Axes)
Then your code should work.
Just in case, with the axes_grid's own Axes class, instead of looping
over major_ticks, you do
cax.axis["left"].toggle(all=False)
cax.axis["right"].toggle(all=True)
Regards,
-JJ
On Fri, Mar 5, 2010 at 9:38 AM, Thomas Robitaille
<tho...@gm...> wrote:
> Hi Jae-Joon,
>
> I am encountering another issue, when using the method you suggest in combination with the parasite_axes from the matplotlib toolkit:
>
> ---
>
> import matplotlib.pyplot as mpl
> import numpy as np
> from mpl_toolkits.axes_grid import make_axes_locatable
> import mpl_toolkits.axes_grid.parasite_axes as mpltk
>
> fig = mpl.figure()
>
> ax = mpltk.SubplotHost(fig, 1, 1, 1)
> fig.add_axes(ax)
>
> divider = make_axes_locatable(ax)
>
> cax = divider.new_horizontal(size="5%", pad=0.05)
> fig.add_axes(cax)
>
> image = ax.imshow(np.random.random((100,100)))
>
> cb = fig.colorbar(image, cax=cax)
>
> ---
>
> In the above case, the labels end up on the wrong side of the plot, and the usual method for changing the label position, e.g.:
>
> for tick in cax.xaxis.get_major_ticks():
> tick.tick1On = True
> tick.tick2On = True
> tick.label1On = False
> tick.label2On = True
>
> does not work. Do you have any idea why this might be?
>
> Thanks for any help,
>
> Thomas
>
>
>
> On Mar 4, 2010, at 10:28 PM, Jae-Joon Lee wrote:
>
>> see
>>
>> http://www.mail-archive.com/mat...@li.../msg15919.html
>>
>> axes_grid toolkit provides some helper function that utilizes
>> axes_locator (take a look at demo_locatable_axes_easy function in the
>> example below)
>>
>> http://matplotlib.sourceforge.net/examples/axes_grid/demo_axes_divider.html
>>
>> -JJ
>>
>>
>>
>>
>> On Thu, Mar 4, 2010 at 9:05 PM, Thomas Robitaille
>> <tho...@gm...> wrote:
>>> Hi,
>>>
>>> I am trying to set up a colorbar that automatically resizes if I zoom in to an image (which changes the aspect ratio of the axes, so I want the colorbar to get resized too). Let's say I have two Axes instances, say ax (for the main image) and cax (for the colorbar). I can set up a callback if the view limits in one axes change, for example
>>>
>>> ax.callbacks.connect('xlim_changed', update_colorbar)
>>> ax.callbacks.connect('ylim_changed', update_colorbar)
>>>
>>> Now I can store a reference to cax inside ax:
>>>
>>> ax._cax = cax
>>>
>>> And I can now define update_colorbar so that it basically changes the position of cax:
>>>
>>> def update_colorbar(ax):
>>>
>>>  # Get current position
>>>  xmin = ax..get_position().xmin
>>>  ...
>>>
>>>  # Compute new colorbar position
>>>  ...
>>>
>>>  # Set new position
>>>  ax._cax.set_position(...)
>>>
>>>  # Return axes instance
>>>  return ax
>>>
>>> Now the issue is that if I select a region of the image to zoom into, then as soon as I've selected the region, update_colorbar gets called, but by then, the aspect ratio of ax hasn't changed, and so the position I find when I do xmin = ax..get_position().xmin in update_colorbar is the *old* position of ax, not the new one. So the colorbar position is always one step behind compared to the main image axes.
>>>
>>> Can anyone think of any way that would avoid this issue, and to be able to use the *new* position of ax inside update_colorbar?
>>>
>>> Thanks in advance for any help,
>>>
>>> Thomas
>>> ------------------------------------------------------------------------------
>>> Download Intel&#174; Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>
>
From: Jae-Joon L. <lee...@gm...> - 2010年03月05日 16:59:03
Hi,
It turns out to be a bug (new_vertical works, but new_horizontal does not).
To work around this
right after
cax = divider.new_horizontal(size="5%", pad=0.05, pack_start=True)
add these lines
locator = divider.new_locator(nx=0, ny=0)
cax.set_axes_locator(locator)
These two lines only need to be executed when "new_horizontal" is
called with pack_start=True.
The code below does some monkey patching to fix this bug. Use this if
it fits your need.
Regards,
-JJ
# work around new_horizontal bug
from mpl_toolkits.axes_grid.axes_divider import AxesDivider
if not hasattr(AxesDivider, "_new_horizontal_bug_fixed"):
 new_horizontal_orig = AxesDivider.new_horizontal
 def new_horizontal(self, size, pad=None, pack_start=False, **kwargs):
 ax = new_horizontal_orig(self, size, pad=pad,
 pack_start=pack_start, **kwargs)
 if pack_start:
 locator = self.new_locator(nx=0, ny=0)
 ax.set_axes_locator(locator)
 return ax
 AxesDivider.new_horizontal = new_horizontal
 AxesDivider._new_horizontal_bug_fixed = True
On Fri, Mar 5, 2010 at 9:05 AM, Thomas Robitaille
<tho...@gm...> wrote:
> Hi Jae-Joon,
>
> Thanks! This is exactly what I needed. Putting the colorbar on the right or bottom works great - however, I am running into issues with trying to put the colorbar on the left or bottom (which, from my understanding, is controlled by using pack_start=True?). Should the following code work?
>
> import matplotlib.pyplot as mpl
> import numpy as np
> from mpl_toolkits.axes_grid import make_axes_locatable
>
> fig = mpl.figure()
> ax = fig.add_subplot(1,1,1)
> divider = make_axes_locatable(ax)
> cax = divider.new_horizontal(size="5%", pad=0.05, pack_start=True)
> fig.add_axes(cax)
> image = ax.imshow(np.random.random((100,100)))
> cb = fig.colorbar(image, cax=cax)
>
> Cheers,
>
> Thomas
>
> On Mar 4, 2010, at 10:28 PM, Jae-Joon Lee wrote:
>
>> see
>>
>> http://www.mail-archive.com/mat...@li.../msg15919.html
>>
>> axes_grid toolkit provides some helper function that utilizes
>> axes_locator (take a look at demo_locatable_axes_easy function in the
>> example below)
>>
>> http://matplotlib.sourceforge.net/examples/axes_grid/demo_axes_divider.html
>>
>> -JJ
>>
>>
>>
>>
>> On Thu, Mar 4, 2010 at 9:05 PM, Thomas Robitaille
>> <tho...@gm...> wrote:
>>> Hi,
>>>
>>> I am trying to set up a colorbar that automatically resizes if I zoom in to an image (which changes the aspect ratio of the axes, so I want the colorbar to get resized too). Let's say I have two Axes instances, say ax (for the main image) and cax (for the colorbar). I can set up a callback if the view limits in one axes change, for example
>>>
>>> ax.callbacks.connect('xlim_changed', update_colorbar)
>>> ax.callbacks.connect('ylim_changed', update_colorbar)
>>>
>>> Now I can store a reference to cax inside ax:
>>>
>>> ax._cax = cax
>>>
>>> And I can now define update_colorbar so that it basically changes the position of cax:
>>>
>>> def update_colorbar(ax):
>>>
>>>  # Get current position
>>>  xmin = ax..get_position().xmin
>>>  ...
>>>
>>>  # Compute new colorbar position
>>>  ...
>>>
>>>  # Set new position
>>>  ax._cax.set_position(...)
>>>
>>>  # Return axes instance
>>>  return ax
>>>
>>> Now the issue is that if I select a region of the image to zoom into, then as soon as I've selected the region, update_colorbar gets called, but by then, the aspect ratio of ax hasn't changed, and so the position I find when I do xmin = ax..get_position().xmin in update_colorbar is the *old* position of ax, not the new one. So the colorbar position is always one step behind compared to the main image axes.
>>>
>>> Can anyone think of any way that would avoid this issue, and to be able to use the *new* position of ax inside update_colorbar?
>>>
>>> Thanks in advance for any help,
>>>
>>> Thomas
>>> ------------------------------------------------------------------------------
>>> Download Intel&#174; Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>
>
From: Thomas R. <tho...@gm...> - 2010年03月05日 14:38:17
Hi Jae-Joon,
I am encountering another issue, when using the method you suggest in combination with the parasite_axes from the matplotlib toolkit:
---
import matplotlib.pyplot as mpl
import numpy as np
from mpl_toolkits.axes_grid import make_axes_locatable
import mpl_toolkits.axes_grid.parasite_axes as mpltk
 
fig = mpl.figure()
ax = mpltk.SubplotHost(fig, 1, 1, 1)
fig.add_axes(ax)
divider = make_axes_locatable(ax)
cax = divider.new_horizontal(size="5%", pad=0.05)
fig.add_axes(cax)
image = ax.imshow(np.random.random((100,100))) 
cb = fig.colorbar(image, cax=cax) 
---
In the above case, the labels end up on the wrong side of the plot, and the usual method for changing the label position, e.g.:
for tick in cax.xaxis.get_major_ticks():
 tick.tick1On = True
 tick.tick2On = True
 tick.label1On = False
 tick.label2On = True
does not work. Do you have any idea why this might be?
Thanks for any help,
Thomas
On Mar 4, 2010, at 10:28 PM, Jae-Joon Lee wrote:
> see
> 
> http://www.mail-archive.com/mat...@li.../msg15919.html
> 
> axes_grid toolkit provides some helper function that utilizes
> axes_locator (take a look at demo_locatable_axes_easy function in the
> example below)
> 
> http://matplotlib.sourceforge.net/examples/axes_grid/demo_axes_divider.html
> 
> -JJ
> 
> 
> 
> 
> On Thu, Mar 4, 2010 at 9:05 PM, Thomas Robitaille
> <tho...@gm...> wrote:
>> Hi,
>> 
>> I am trying to set up a colorbar that automatically resizes if I zoom in to an image (which changes the aspect ratio of the axes, so I want the colorbar to get resized too). Let's say I have two Axes instances, say ax (for the main image) and cax (for the colorbar). I can set up a callback if the view limits in one axes change, for example
>> 
>> ax.callbacks.connect('xlim_changed', update_colorbar)
>> ax.callbacks.connect('ylim_changed', update_colorbar)
>> 
>> Now I can store a reference to cax inside ax:
>> 
>> ax._cax = cax
>> 
>> And I can now define update_colorbar so that it basically changes the position of cax:
>> 
>> def update_colorbar(ax):
>> 
>> # Get current position
>> xmin = ax..get_position().xmin
>> ...
>> 
>> # Compute new colorbar position
>> ...
>> 
>> # Set new position
>> ax._cax.set_position(...)
>> 
>> # Return axes instance
>> return ax
>> 
>> Now the issue is that if I select a region of the image to zoom into, then as soon as I've selected the region, update_colorbar gets called, but by then, the aspect ratio of ax hasn't changed, and so the position I find when I do xmin = ax..get_position().xmin in update_colorbar is the *old* position of ax, not the new one. So the colorbar position is always one step behind compared to the main image axes.
>> 
>> Can anyone think of any way that would avoid this issue, and to be able to use the *new* position of ax inside update_colorbar?
>> 
>> Thanks in advance for any help,
>> 
>> Thomas
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> 
From: Thomas R. <tho...@gm...> - 2010年03月05日 14:05:43
Hi Jae-Joon,
Thanks! This is exactly what I needed. Putting the colorbar on the right or bottom works great - however, I am running into issues with trying to put the colorbar on the left or bottom (which, from my understanding, is controlled by using pack_start=True?). Should the following code work?
import matplotlib.pyplot as mpl
import numpy as np
from mpl_toolkits.axes_grid import make_axes_locatable
fig = mpl.figure()
ax = fig.add_subplot(1,1,1)
divider = make_axes_locatable(ax)
cax = divider.new_horizontal(size="5%", pad=0.05, pack_start=True)
fig.add_axes(cax)
image = ax.imshow(np.random.random((100,100))) 
cb = fig.colorbar(image, cax=cax) 
Cheers,
Thomas
On Mar 4, 2010, at 10:28 PM, Jae-Joon Lee wrote:
> see
> 
> http://www.mail-archive.com/mat...@li.../msg15919.html
> 
> axes_grid toolkit provides some helper function that utilizes
> axes_locator (take a look at demo_locatable_axes_easy function in the
> example below)
> 
> http://matplotlib.sourceforge.net/examples/axes_grid/demo_axes_divider.html
> 
> -JJ
> 
> 
> 
> 
> On Thu, Mar 4, 2010 at 9:05 PM, Thomas Robitaille
> <tho...@gm...> wrote:
>> Hi,
>> 
>> I am trying to set up a colorbar that automatically resizes if I zoom in to an image (which changes the aspect ratio of the axes, so I want the colorbar to get resized too). Let's say I have two Axes instances, say ax (for the main image) and cax (for the colorbar). I can set up a callback if the view limits in one axes change, for example
>> 
>> ax.callbacks.connect('xlim_changed', update_colorbar)
>> ax.callbacks.connect('ylim_changed', update_colorbar)
>> 
>> Now I can store a reference to cax inside ax:
>> 
>> ax._cax = cax
>> 
>> And I can now define update_colorbar so that it basically changes the position of cax:
>> 
>> def update_colorbar(ax):
>> 
>> # Get current position
>> xmin = ax..get_position().xmin
>> ...
>> 
>> # Compute new colorbar position
>> ...
>> 
>> # Set new position
>> ax._cax.set_position(...)
>> 
>> # Return axes instance
>> return ax
>> 
>> Now the issue is that if I select a region of the image to zoom into, then as soon as I've selected the region, update_colorbar gets called, but by then, the aspect ratio of ax hasn't changed, and so the position I find when I do xmin = ax..get_position().xmin in update_colorbar is the *old* position of ax, not the new one. So the colorbar position is always one step behind compared to the main image axes.
>> 
>> Can anyone think of any way that would avoid this issue, and to be able to use the *new* position of ax inside update_colorbar?
>> 
>> Thanks in advance for any help,
>> 
>> Thomas
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> 
From: David G. <d_l...@ya...> - 2010年03月05日 04:14:21
Hi, folks! Let's see, first the tech stuff: Python version - 2.5.4; matplotlib version - 0.99.0; numpy version - 1.4.0; Platform: 32 bit Windows Vista Home Premium SP2. 
OK, now for the problem: imshow is (indirectly) raising "ValueError: zero-size array to ufunc.reduce without identity." Here's the traceback:
Traceback (most recent call last):
 File "<mycode>", line 108, in <module>
ax.imshow(part2plot, cmap_name, extent = extent)
 File "C:\Python254\lib\site-packages\matplotlib\axes.py", line 6261, in imshow
im.autoscale_None()
 File "C:\Python254\lib\site-packages\matplotlib\cm.py", line 236, in autoscale_None
self.norm.autoscale_None(self._A)
 File "C:\Python254\lib\site-packages\matplotlib\colors.py", line 792, in autoscale_None
if self.vmin is None: self.vmin = ma.minimum(A)
 File "C:\Python254\Lib\site-packages\numpy\ma\core.py", line 5555, in __call__
return self.reduce(a)
 File "C:\Python254\Lib\site-packages\numpy\ma\core.py", line 5570, in reduce
t = self.ufunc.reduce(target, **kargs)
ValueError: zero-size array to ufunc.reduce without identity
Script terminated.
And here's the "local" code (it may be difficult to generate a self-contained reproducer of the problem, so I'm postponing that 'til it appears absolutely necessary):
 ax.hold(True)
 for i in range(4):
 for j in range(4):
 part2plot = argW[j*ny/4:(j+1)*ny/4, i*nx/4:(i+1)*nx/4]
 if N.any(N.logical_not(N.isfinite(part2plot))):
 print i, j,
 print N.argwhere(N.logical_not(N.isfinite(part2plot)))
 extent = (i*nx/4, (i+1)*nx/4, (j+1)*ny/4, j*ny/4)
 ax.imshow(part2plot, cmap_name, extent = extent)
I added the print statements because Googling the error, I found an indication that if my image array contained any NaN's, that might be the cause; sure enough, I did have some, but I eliminated them, and now nothing gets printed before the exception is raised, so, unless I'm missing something obvious (wouldn't be the first time ;-)) something else is the problem. 
Any ideas? Thanks!
DG
 
From: David G. <d_l...@ya...> - 2010年03月05日 03:47:28
Hi, folks! Let's see, first the tech stuff: Python version - 2.5.4; matplotlib version - 0.99.0; numpy version - 1.4.0; Platform: 32 bit Windows Vista Home Premium SP2. 
OK, now for the problem: imshow is (indirectly) raising "ValueError: zero-size array to ufunc.reduce without identity." Here's the traceback:
Traceback (most recent call last):
 File "<mycode>", line 108, in <module>
ax.imshow(part2plot, cmap_name, extent = extent)
 File "C:\Python254\lib\site-packages\matplotlib\axes.py", line 6261, in imshow
im.autoscale_None()
 File "C:\Python254\lib\site-packages\matplotlib\cm.py", line 236, in autoscale_None
self.norm.autoscale_None(self._A)
 File "C:\Python254\lib\site-packages\matplotlib\colors.py", line 792, in autoscale_None
if self.vmin is None: self.vmin = ma.minimum(A)
 File "C:\Python254\Lib\site-packages\numpy\ma\core.py", line 5555, in __call__
return self.reduce(a)
 File "C:\Python254\Lib\site-packages\numpy\ma\core.py", line 5570, in reduce
t = self.ufunc.reduce(target, **kargs)
ValueError: zero-size array to ufunc.reduce without identity
Script terminated.
And here's the "local" code (it may be difficult to generate a self-contained reproducer of the problem, so I'm postponing that 'til it appears absolutely necessary):
 ax.hold(True)
 for i in range(4):
 for j in range(4):
 part2plot = argW[j*ny/4:(j+1)*ny/4, i*nx/4:(i+1)*nx/4]
 if N.any(N.logical_not(N.isfinite(part2plot))):
 print i, j,
 print N.argwhere(N.logical_not(N.isfinite(part2plot)))
 extent = (i*nx/4, (i+1)*nx/4, (j+1)*ny/4, j*ny/4)
 ax.imshow(part2plot, cmap_name, extent = extent)
I added the print statements because Googling the error, I found an indication that if my image array contained any NaN's, that might be the cause; sure enough, I did have some, but I eliminated them, and now nothing gets printed before the exception is raised, so, unless I'm missing something obvious (wouldn't be the first time ;-)) something else is the problem. 
Any ideas? Thanks!
DG
 
From: Jae-Joon L. <lee...@gm...> - 2010年03月05日 03:28:43
see
http://www.mail-archive.com/mat...@li.../msg15919.html
axes_grid toolkit provides some helper function that utilizes
axes_locator (take a look at demo_locatable_axes_easy function in the
example below)
http://matplotlib.sourceforge.net/examples/axes_grid/demo_axes_divider.html
-JJ
On Thu, Mar 4, 2010 at 9:05 PM, Thomas Robitaille
<tho...@gm...> wrote:
> Hi,
>
> I am trying to set up a colorbar that automatically resizes if I zoom in to an image (which changes the aspect ratio of the axes, so I want the colorbar to get resized too). Let's say I have two Axes instances, say ax (for the main image) and cax (for the colorbar). I can set up a callback if the view limits in one axes change, for example
>
> ax.callbacks.connect('xlim_changed', update_colorbar)
> ax.callbacks.connect('ylim_changed', update_colorbar)
>
> Now I can store a reference to cax inside ax:
>
> ax._cax = cax
>
> And I can now define update_colorbar so that it basically changes the position of cax:
>
> def update_colorbar(ax):
>
>  # Get current position
>  xmin = ax..get_position().xmin
>  ...
>
>  # Compute new colorbar position
>  ...
>
>  # Set new position
>  ax._cax.set_position(...)
>
>  # Return axes instance
>  return ax
>
> Now the issue is that if I select a region of the image to zoom into, then as soon as I've selected the region, update_colorbar gets called, but by then, the aspect ratio of ax hasn't changed, and so the position I find when I do xmin = ax..get_position().xmin in update_colorbar is the *old* position of ax, not the new one. So the colorbar position is always one step behind compared to the main image axes.
>
> Can anyone think of any way that would avoid this issue, and to be able to use the *new* position of ax inside update_colorbar?
>
> Thanks in advance for any help,
>
> Thomas
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
From: David G. <d_l...@ya...> - 2010年03月05日 02:54:11
Hi, folks! Let's see, first the tech stuff: Python version - 2.5.4; matplotlib version - 0.99.0; numpy version - 1.4.0; Platform: 32 bit Windows Vista Home Premium SP2. 
OK, now for the problem: imshow is (indirectly) raising "ValueError: zero-size array to ufunc.reduce without identity." Here's the traceback:
Traceback (most recent call last):
 File "<mycode>", line 108, in <module>
ax.imshow(part2plot, cmap_name, extent = extent)
 File "C:\Python254\lib\site-packages\matplotlib\axes.py", line 6261, in imshow
im.autoscale_None()
 File "C:\Python254\lib\site-packages\matplotlib\cm.py", line 236, in autoscale_None
self.norm.autoscale_None(self._A)
 File "C:\Python254\lib\site-packages\matplotlib\colors.py", line 792, in autoscale_None
if self.vmin is None: self.vmin = ma.minimum(A)
 File "C:\Python254\Lib\site-packages\numpy\ma\core.py", line 5555, in __call__
return self.reduce(a)
 File "C:\Python254\Lib\site-packages\numpy\ma\core.py", line 5570, in reduce
t = self.ufunc.reduce(target, **kargs)
ValueError: zero-size array to ufunc.reduce without identity
Script terminated.
And here's the "local" code (it may be difficult to generate a self-contained reproducer of the problem, so I'm postponing that 'til it appears absolutely necessary):
 ax.hold(True)
 for i in range(4):
 for j in range(4):
 part2plot = argW[j*ny/4:(j+1)*ny/4, i*nx/4:(i+1)*nx/4]
 if N.any(N.logical_not(N.isfinite(part2plot))):
 print i, j,
 print N.argwhere(N.logical_not(N.isfinite(part2plot)))
 extent = (i*nx/4, (i+1)*nx/4, (j+1)*ny/4, j*ny/4)
 ax.imshow(part2plot, cmap_name, extent = extent)
I added the print statements because Googling the error, I found an indication that if my image array contained any NaN's, that might be the cause; sure enough, I did have some, but I eliminated them, and now nothing gets printed before the exception is raised, so, unless I'm missing something obvious (wouldn't be the first time ;-)) something else is the problem. 
Any ideas? Thanks!
DG
 
From: David G. <d_l...@ya...> - 2010年03月05日 02:18:41
Hi, folks! Let's see, first the tech stuff: Python version - 2.5.4; matplotlib version - 0.99.0; numpy version - 1.4.0; Platform: 32 bit Windows Vista Home Premium SP2. 
OK, now for the problem: imshow is (indirectly) raising "ValueError: zero-size array to ufunc.reduce without identity." Here's the traceback:
Traceback (most recent call last):
 File "<mycode>", line 108, in <module>
ax.imshow(part2plot, cmap_name, extent = extent)
 File "C:\Python254\lib\site-packages\matplotlib\axes.py", line 6261, in imshow
im.autoscale_None()
 File "C:\Python254\lib\site-packages\matplotlib\cm.py", line 236, in autoscale_None
self.norm.autoscale_None(self._A)
 File "C:\Python254\lib\site-packages\matplotlib\colors.py", line 792, in autoscale_None
if self.vmin is None: self.vmin = ma.minimum(A)
 File "C:\Python254\Lib\site-packages\numpy\ma\core.py", line 5555, in __call__
return self.reduce(a)
 File "C:\Python254\Lib\site-packages\numpy\ma\core.py", line 5570, in reduce
t = self.ufunc.reduce(target, **kargs)
ValueError: zero-size array to ufunc.reduce without identity
Script terminated.
And here's the "local" code (it may be difficult to generate a self-contained reproducer of the problem, so I'm postponing that 'til it appears absolutely necessary):
 ax.hold(True)
 for i in range(4):
 for j in range(4):
 part2plot = argW[j*ny/4:(j+1)*ny/4, i*nx/4:(i+1)*nx/4]
 if N.any(N.logical_not(N.isfinite(part2plot))):
 print i, j,
 print N.argwhere(N.logical_not(N.isfinite(part2plot)))
 extent = (i*nx/4, (i+1)*nx/4, (j+1)*ny/4, j*ny/4)
 ax.imshow(part2plot, cmap_name, extent = extent)
I added the print statements because Googling the error, I found an indication that if my image array contained any NaN's, that might be the cause; sure enough, I did have some, but I eliminated them, and now nothing gets printed before the exception is raised, so, unless I'm missing something obvious (wouldn't be the first time ;-)) something else is the problem. 
Any ideas? Thanks!
DG
 
From: Thomas R. <tho...@gm...> - 2010年03月05日 02:06:03
Hi,
I am trying to set up a colorbar that automatically resizes if I zoom in to an image (which changes the aspect ratio of the axes, so I want the colorbar to get resized too). Let's say I have two Axes instances, say ax (for the main image) and cax (for the colorbar). I can set up a callback if the view limits in one axes change, for example
ax.callbacks.connect('xlim_changed', update_colorbar)
ax.callbacks.connect('ylim_changed', update_colorbar)
Now I can store a reference to cax inside ax:
ax._cax = cax
And I can now define update_colorbar so that it basically changes the position of cax:
def update_colorbar(ax):
 # Get current position
 xmin = ax..get_position().xmin
 ...
 # Compute new colorbar position
 ...
 # Set new position
 ax._cax.set_position(...)
 # Return axes instance
 return ax
Now the issue is that if I select a region of the image to zoom into, then as soon as I've selected the region, update_colorbar gets called, but by then, the aspect ratio of ax hasn't changed, and so the position I find when I do xmin = ax..get_position().xmin in update_colorbar is the *old* position of ax, not the new one. So the colorbar position is always one step behind compared to the main image axes.
Can anyone think of any way that would avoid this issue, and to be able to use the *new* position of ax inside update_colorbar?
Thanks in advance for any help,
Thomas
From: Thomas R. <tho...@gm...> - 2010年03月05日 01:55:10
Hi,
I would like to change the orientation of a colorbar once it has already been drawn. So for example if I create the colorbar with:
cb = fig.colorbar(mappable=image, cax=cax, orientation='vertical')
I would like to be able to do
cb.set_orientation('horizontal')
Is there a way to do this, since set_orientation does not exist?
Thanks for any help,
Thomas

Showing 17 results of 17

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /