You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
1
(13) |
2
(16) |
3
(5) |
4
(6) |
5
(4) |
6
|
7
(8) |
8
(4) |
9
(8) |
10
(14) |
11
(20) |
12
(3) |
13
(7) |
14
(1) |
15
(1) |
16
(5) |
17
(9) |
18
(5) |
19
|
20
|
21
(5) |
22
(7) |
23
(4) |
24
|
25
|
26
|
27
(3) |
28
(2) |
29
(8) |
30
(6) |
|
|
|
The present behavior of set_xlim and set_ylim can be surprising because making the values stick for subsequent plotting in the same axes requires manually calling set_autoscalex_on(False) etc. It would seem more logical if set_xlim itself included the call to turn autoscalex off--isn't that what a user would almost always want and expect? Rectifying this would constitute a significant change affecting some existing user code. What are people's thoughts on this? Should the change made? If so, do it abruptly, right now, as part of version 1.0? Or phase it in with a temporary kwarg and/or rcparam? It would be nice to avoid all that complexity, but may be we can't, except by leaving everything as it is now. Eric
On 06/26/2010 04:13 PM, Jae-Joon Lee wrote: > In r8472, I tried to modify the image slicing so that it works even if > images are rotated and skewed. And the "noslice" option is now gon. > Let me know if it causes any problem. Thanks very much, JJ, that's great! Eric > > Regards, > > -JJ
In r8472, I tried to modify the image slicing so that it works even if images are rotated and skewed. And the "noslice" option is now gon. Let me know if it causes any problem. Regards, -JJ On Tue, Jun 22, 2010 at 11:05 PM, Jae-Joon Lee <lee...@gm...> wrote: > Eric, > > I should have left more comments about my change. > The issue is that the current slicing algorithm sometimes fails with > "_draw_unsampled_image" which support arbitrary affine transformation > of the image. The slicing gets wrong when the image is significantly > skewed or rotated. So, as a temporary measure, I simply wanted to > disable the slicing until we have a correct algorithm in place. > > I guess a quick (still temporary) fix is to check if affine transform > is needed, and do the slicing if not. > Something like below. The condition is not exactly correct, but I > think it would work in most of cases. > I actually didn't test the patch. I'll be out of town until the end of > this week. > > On a second thought, I think it should not be difficult to workaround > the slicing thing for arbitrary affine transform. I'll think about the > whole issue again when I get back. If you have a better idea, please > go ahead and implement. > > Regards, > > -JJ > > diff --git a/lib/matplotlib/image.py b/lib/matplotlib/image.py > index 7c1128f..b65f446 100644 > --- a/lib/matplotlib/image.py > +++ b/lib/matplotlib/image.py > @@ -248,9 +248,14 @@ class _AxesImageBase(martist.Artist, cm.ScalarMappable): > """ > > > + if self._image_skew_coordinate: > + no_slice = True > + else: > + no_slice = False > + > im, xmin, ymin, dxintv, dyintv, sx, sy = \ > self._get_unsampled_image(self._A, self.get_extent(), > - self.axes.viewLim, noslice=True) > + self.axes.viewLim, noslice=no_slice) > > if im is None: return # I'm not if this check is required. -JJL > > > > On Tue, Jun 22, 2010 at 8:45 PM, Eric Firing <ef...@ha...> wrote: >> JJ, >> >> In AxesImageBase._draw_unsampled_image, there is a call to >> _get_unsampled_image(...noslice=True). When using imshow(Z, >> interpolation='nearest'), this defeats the slicing that makes such a >> difference when zooming and panning a small chunk of a large image. Changing >> it to False makes imshow work better; I don't understand why one would ever >> want noslice=True. Am I missing something? Can we just change it to False? >> Or remove the noslice option and kwarg entirely? >> >> Eric >> >