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) |
|
|
|
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.
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® 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 >>>>> >>> >>> > >
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® 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 >>>> >> >>
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
(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 >
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...
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® 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 >>> > >
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® 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 >>> > >
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® 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 >>
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® 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 >>
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
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
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® 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 >
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
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
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
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