matplotlib-devel Mailing List for matplotlib

On Thu, Nov 27, 2014 at 9:54 AM, Todd <tod...@gm...> wrote:
>
> On Nov 26, 2014 10:04 PM, "Nathaniel Smith" <nj...@po...> wrote:
>>
>> The main differences in requirements are:
>> - for the color cycle, you want isoluminant colors, to avoid the issue
>> where one line is glaring bright red and one is barely-visible-grey.
>> For general-purpose 2d colormaps, though, you almost always want the
>> luminance to vary to help distinguish colors from each other.
>
> If you used isoluminance colors for the lines, wouldn't that mean a plot
> printed in grayscale would have all lines be the same shade of gray?
Yes. But IME it's very difficult to use greyscale alone to distinguish
between multiple plot lines no matter what: you can't go much beyond 2
lines before you either end up with hard-to-see lines (b/c they don't
have enough contrast with the white background) or the lines become
nigh-indistinguishable ("which one is the slightly-darker grey?"). And
if you have substantial luminance variation to make the greyscale
work, then the color images end up looking really weird (the scarlet
versus faint-yellow problem, where you end up emphasizing one set of
data over another -- emphasis should be done on purpose! in
matplotlib's current color cycle the yellow and cyan tend to
disappear).
If you're worried about greyscale then IMHO you should use different
line styles (solid/dashed/dotted/...) and/or use solid black for
everything and label the lines directly.
Which isn't to say that there's never any value in picking line colors
from a colormap, it's just more complicated than it seems :-).
-n
-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

For reference, the IPython script is in tools/update_whatsnew.py
On Thu Nov 27 2014 at 11:58:40 AM Ian Thomas <ian...@gm...> wrote:
> On 27 November 2014 at 16:16, Thomas Caswell <tca...@gm...> wrote:
>
>> There should be an automatic process, but no one has written it yet. I
>> think IPython has code we can adapt in their doc build process. I had
>> planned to deal with this when we cut the next minor/major release.
>>
>> Tom
>>
>
> Thanks for letting me know Tom.
>
> Ian
>

On 27 November 2014 at 16:16, Thomas Caswell <tca...@gm...> wrote:
> There should be an automatic process, but no one has written it yet. I
> think IPython has code we can adapt in their doc build process. I had
> planned to deal with this when we cut the next minor/major release.
>
> Tom
>
Thanks for letting me know Tom.
Ian

There should be an automatic process, but no one has written it yet. I
think IPython has code we can adapt in their doc build process. I had
planned to deal with this when we cut the next minor/major release.
Tom
On Thu, Nov 27, 2014, 04:18 Ian Thomas <ian...@gm...> wrote:
> Fellow developers,
>
> I know we are now encouraged when writing a PR not to alter
> doc/users/whats_new.rst and doc/api/api_changes.rst directly, but rather to
> create files in the doc/users/whats_new and doc/api/api_changes directories
> instead. When building the master branch docs I was expecting the contents
> of these new files to be automagically incorporated in the appropriate doc
> sections, but this does not happen on my development system (ubuntu 14.04,
> python 2.7, sphinx 1.2.2).
>
> I figure either I am doing something wrong, or this is a bug, or there is
> manual process at release time to cut and paste the new files into the
> parent files. Which is it?
>
> Ian
> ------------------------------------------------------------
> ------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&
> iu=/4140/ostg.clktrk_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Nov 26, 2014 10:04 PM, "Nathaniel Smith" <nj...@po...> wrote:
>
> On Wed, Nov 26, 2014 at 9:30 AM, Todd <tod...@gm...> wrote:
> > On Sat, Nov 22, 2014 at 12:22 AM, Nathaniel Smith <nj...@po...> wrote:
> >>
> >> - Default line colors: The rgbcmyk color cycle for line plots doesn't
> >> appear to be based on any real theory about visualization -- it's just
> >> the corners of the RGB color cube, which is a highly perceptually
> >> non-uniform space. The resulting lines aren't terribly high contrast
> >> against the default white background, and the different colors have
> >> varying luminance that makes some lines "pop out" more than others.
> >>
> >> Seaborn's default is to use a nice isoluminant variant on matplotlib's
> >> default:
> >>
> >>
http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
> >> ggplot2 uses isoluminant colors with maximally-separated hues, which
> >> also works well. E.g.:
> >>
> >>
http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
> >
> > About this, I am not expert so forgive me if this is nonsensical.
However,
> > it would seem to me that these requirements are basically the same as
the
> > requirements for the new default colormap that prompted this whole
> > discussion. So, rather than create two inconsistent set of colors that
> > accomplish similar goals, might it be better to instead use the default
> > colormap for the line colors? You could pick "N" equally-spaced colors
from
> > the colormap and use those as the line colors.
>
> The main differences in requirements are:
> - for the color cycle, you want isoluminant colors, to avoid the issue
> where one line is glaring bright red and one is barely-visible-grey.
> For general-purpose 2d colormaps, though, you almost always want the
> luminance to vary to help distinguish colors from each other.
If you used isoluminance colors for the lines, wouldn't that mean a plot
printed in grayscale would have all lines be the same shade of gray?

Fellow developers,
I know we are now encouraged when writing a PR not to alter
doc/users/whats_new.rst and doc/api/api_changes.rst directly, but rather to
create files in the doc/users/whats_new and doc/api/api_changes directories
instead. When building the master branch docs I was expecting the contents
of these new files to be automagically incorporated in the appropriate doc
sections, but this does not happen on my development system (ubuntu 14.04,
python 2.7, sphinx 1.2.2).
I figure either I am doing something wrong, or this is a bug, or there is
manual process at release time to cut and paste the new files into the
parent files. Which is it?
Ian

On Wed, Nov 26, 2014 at 9:30 AM, Todd <tod...@gm...> wrote:
> On Sat, Nov 22, 2014 at 12:22 AM, Nathaniel Smith <nj...@po...> wrote:
>>
>> - Default line colors: The rgbcmyk color cycle for line plots doesn't
>> appear to be based on any real theory about visualization -- it's just
>> the corners of the RGB color cube, which is a highly perceptually
>> non-uniform space. The resulting lines aren't terribly high contrast
>> against the default white background, and the different colors have
>> varying luminance that makes some lines "pop out" more than others.
>>
>> Seaborn's default is to use a nice isoluminant variant on matplotlib's
>> default:
>>
>> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
>> ggplot2 uses isoluminant colors with maximally-separated hues, which
>> also works well. E.g.:
>>
>> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
>
> About this, I am not expert so forgive me if this is nonsensical. However,
> it would seem to me that these requirements are basically the same as the
> requirements for the new default colormap that prompted this whole
> discussion. So, rather than create two inconsistent set of colors that
> accomplish similar goals, might it be better to instead use the default
> colormap for the line colors? You could pick "N" equally-spaced colors from
> the colormap and use those as the line colors.
The main differences in requirements are:
- for the color cycle, you want isoluminant colors, to avoid the issue
where one line is glaring bright red and one is barely-visible-grey.
For general-purpose 2d colormaps, though, you almost always want the
luminance to vary to help distinguish colors from each other.
- for the color cycle, there's no problem with using widely separated
hues -- in fact it's usually better b/c it increases contrast between
the different items, and there's no need to communicate an ordering
between them. But if you try to use the whole hue space in a colormap
then you end up with the much-loathed jet.
-n
-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

On 26 Nov 2014, at 07:53 pm, Chris Barker <Chr...@no...> wrote:
> On Wed, Nov 26, 2014 at 1:30 AM, Todd <tod...@gm...> wrote:
>> About this, I am not expert so forgive me if this is nonsensical. However, it would seem to me that these requirements are basically the same as the requirements for the new default colormap that prompted this whole discussion. So, rather than create two inconsistent set of colors that accomplish similar goals, might it be better to instead use the default colormap for the line colors? You could pick "N" equally-spaced colors from the colormap and use those as the line colors.
>> 
> I'm no expert either, but while similar principles about colorblind compatibility, etc apply, you want to sue a different scheme to represent a continuous range of colors and a set of distinct colors that aren't intended to be ranked.
> 
I’ve also become throughly annoyed with the default colour cycle, especially with its
glaring cyan-magenta contrast, and found it desirable to have an easier way to
customise this either explicitly or by changing color_cycle.
As there are already a couple of sequences existing in the available colourmaps that
could be useful for different purposes or tastes, what’s lacking in particular in my view
is an easier-to-use interface to draw colours from those maps; I think that’s along the
lines of what Todd also has suggested further down in his mail.
I’ve written a little utility I’m simply appending because it’s so short, which returns an
array of colours of specified length that could be passed to axes.color_cycle or just
explicitly used as crange[i]. Also useful to colour scatter plot markers according to a
certain quantity (pass this quantity as "values" to crange).
Regarding to the above, I think sometimes the line colour requirements are similar to
those for a general colourmap, e.g. I often want to plot a series of lines like different
spectra, which are easily enough distinguishable, but should IMO reflect a certain
continuous trend like different temperatures - are ranked, IOW - and thus would be well
represented by a sequence of values from "heat" or "coolwarm". However there are still
some additional requirements, as you’d generally want every colour to have enough
contrast on a white or bright background canvas. In the example below I’ve added a
"max_lum" keyword to darken whitish or yellow colours appropriately.
This is probably not extremely sophisticated in terms of colour physiology, but if you
have a suggestion if and where it could be added to matplotlib, I could go ahead and
make a pull request (and try to find the time to add some tests and examples).
Cheers,
						Derek
def crange(cmap, values, max_lum=1, start=0, stop=255, vmin=None, vmax=None):
 """
 Returns RGBA colour array of length values from colormap cmap
 cmap: valid matplotlib.cm colormap name or instance
 values: either int - number of colour values to return or
 array of values to be mapped on colormap range
 max_lum: restrict colours to maximum brightness (1=white)
 start,stop: range of colormap to use (full range 0-255)
 vmin,vmax: input values mapped to start/stop (default actual data limits)
 """
 try:
 if np.isscalar(values):
 vrange = np.linspace(start,stop,np.int(values))
 else:
 v = np.array(values).astype(np.float)
 vmin = vmin or v.min()
 vmax = vmax or v.max()
 vrange = start+(v-vmin)*(stop-start)/(vmax-vmin)
 except (ValueError, TypeError) as err:
 print("invalid input values: must be no. of colours or array: %s" %
 err)
 return None
 vrange = np.uint8(np.round(vrange))
 cmap = matplotlib.cm.get_cmap(cmap)
 lcor = (1.0-max_lum) / 9
 crange = cmap(vrange)
 crange[:,:3] *= (1-crange[:,:3].sum(axis=1)**2*lcor).reshape(-1,1)
 return crange

On Wed, Nov 26, 2014 at 1:30 AM, Todd <tod...@gm...> wrote:
> About this, I am not expert so forgive me if this is nonsensical.
> However, it would seem to me that these requirements are basically the same
> as the requirements for the new default colormap that prompted this whole
> discussion. So, rather than create two inconsistent set of colors that
> accomplish similar goals, might it be better to instead use the default
> colormap for the line colors? You could pick "N" equally-spaced colors
> from the colormap and use those as the line colors.
>
I'm no expert either, but while similar principles about colorblind
compatibility, etc apply, you want to sue a different scheme to represent a
continuous range of colors and a set of distinct colors that aren't
intended to be ranked.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hi Phil,
I am in London but busy with other stuff on Saturday. I might be able to
join in on Sunday.
best
Jens
On Wed, Nov 26, 2014 at 11:04 AM, Phil Elson <pel...@gm...> wrote:
> There will be an open source Python sprint, hosted by Bloomberg, this
> weekend in London. The event will be attended by core developers of many of
> the major scientific Python packages (IPython, numpy, scipy, pandas,
> scikit-learn) who will act as mentors to those who would like to get
> involved in the development of these important scientific tools.
>
> I will be attending as a mentor for matplotlib (if there are any other
> core developers who may be able to attend, the more the merrier!) and am
> hoping there will be many attendees who want to get a helping hand getting
> started with matplotlib development. We've got lots of room for
> improvement, from the obvious documentation enhancements right through to
> the nitty-gritty of improving backends such as nbagg.
>
> If you want to come along to the event, please sign-up at
>
> http://go.bloomberg.com/promo/invite/bloomberg-open-source-day-scientific-python/
> .
>
> Hope you see some of you there,
>
> Phil
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

There will be an open source Python sprint, hosted by Bloomberg, this
weekend in London. The event will be attended by core developers of many of
the major scientific Python packages (IPython, numpy, scipy, pandas,
scikit-learn) who will act as mentors to those who would like to get
involved in the development of these important scientific tools.
I will be attending as a mentor for matplotlib (if there are any other core
developers who may be able to attend, the more the merrier!) and am hoping
there will be many attendees who want to get a helping hand getting started
with matplotlib development. We've got lots of room for improvement, from
the obvious documentation enhancements right through to the nitty-gritty of
improving backends such as nbagg.
If you want to come along to the event, please sign-up at
http://go.bloomberg.com/promo/invite/bloomberg-open-source-day-scientific-python/
.
Hope you see some of you there,
Phil

On Sat, Nov 22, 2014 at 12:22 AM, Nathaniel Smith <nj...@po...> wrote:
> - Default line colors: The rgbcmyk color cycle for line plots doesn't
> appear to be based on any real theory about visualization -- it's just
> the corners of the RGB color cube, which is a highly perceptually
> non-uniform space. The resulting lines aren't terribly high contrast
> against the default white background, and the different colors have
> varying luminance that makes some lines "pop out" more than others.
>
> Seaborn's default is to use a nice isoluminant variant on matplotlib's
> default:
>
> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
> ggplot2 uses isoluminant colors with maximally-separated hues, which
> also works well. E.g.:
>
> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
>
>
About this, I am not expert so forgive me if this is nonsensical. However,
it would seem to me that these requirements are basically the same as the
requirements for the new default colormap that prompted this whole
discussion. So, rather than create two inconsistent set of colors that
accomplish similar goals, might it be better to instead use the default
colormap for the line colors? You could pick "N" equally-spaced colors
from the colormap and use those as the line colors.
You could even take this a step further, and instead of hard-coding the
line colors, you could make it possible to assign a named colormap to the
line colors parameter. Then there could be a second integer parameter that
determines how many colors to pick from that colormap (it would only do
anything if the line colors are a colormap, otherwise it would be
ignored).

On 22 Nov 2014 02:22, "Benjamin Root" <ben...@ou...> wrote:
>
> Some of your wishes are in progress already:
https://github.com/matplotlib/matplotlib/pull/3818
> There is also an issue open about scaling the dashes with the line width,
and you are right, the spacing for the dashes are terrible.
Nice!
> I can definitely see the argument to making a bunch of these visual
changes together. Preferably, I would like to do these changes via style
sheets so that we can provide a "classic" stylesheet for backwards
compatibility.
Yeah, I didn't want to get into the details of mechanism here because
that's a comparatively simple technical question, compared to the questions
about whether we should make changes and which changes we should make. But
I'm definitely assuming we'll provide a simple supported/documented way to
request the old defaults, and I agree that the obvious way is by swapping
out stylesheets. This might require adding a few more parameters to
rcParam, but I'm guessing that won't be a big deal.
> I do actually like the autoscaling system as it exists now. The problem
is that the data margins feature is applied haphazardly. The power spectra
example is a good example of where we could "smarten" the system.
Can you elaborate on what you like about it? Like I said, when I first
heard about it sounded like a neat idea. But in practice, over my years of
using matplotlib... sometimes it's been fine, and sometimes it's made me
roll my eyes/swear, but I don't think there's been a single instance where
I looked at a graph and thought "oo, nice one matplotlib - your insistence
on shrinking my data to use fewer pixels in order to get a major tick lined
up exactly with the spines has really improved this graph. Neat tick/spine
alignment really is the highest priority in data visualization".
Even in the rare cases where my measurement scale actually does have a neat
0-1 or 0-100 range, I usually find that matplotlib has chosen something
like 0-90, or, if we fix the issue with cramming data right up into the
axes, then I guess I'll end up with -10 - 110. Which looks worse than
something like -4 - 104, because with -4 - 104, my outermost axis labels
are 0 and 100. With -10 - 110, the outermost labels are -10 and 110, and
it's weird and confusing to have axis labels naming impossible values.
So can you share your examples of where this behavior has given you
substantively better results?
> As for the ticks... I think that is a very obscure edge-case. I
personally prefer inward.
Yeah, that one is a pet peeve - I was gratified to see that the seaborn
folks also took the trouble to fix it (I'm not alone!). To be fair, though,
the reason I noticed isn't that I care a lot about ticks per se, it's
because the default was screwing up my figures so I had to go track it down
:-/. Here's another example -- the final versions of the autocorrelation
graphs I mentioned above.
[image: Inline image 1]
In both of these graphs, having the ticks to point inwards created weird
confusing intersections with the lines, so I had to flip them to point
outwards. It's just an objective thing, if you use the same pixels for data
and metadata then that creates room for ugly stuff to happen. And when it
comes to defaults, if you have two choices that are basically equivalent,
except that one is always fine and one is usually fine but sometimes screws
things up, then the former seems like the obvious choice...
-n

On 24 Nov 2014 12:42, "Benjamin Root" <ben...@ou...> wrote:
>
> It is odd you mentioned the extra refreshes. I have to double-check my
book examples, but I think I found that I needed to add some extra
draw_idle() calls when using native wx widgets.
>
> This does raise another point. As a development policy, how should we
treat the backends? Should we be free to change it up so long as it works
well with Matplotlib, or should we be cautious and recognize that there are
users who go down beyond the canvas layer?
>
Because the backends are pretty close I would like to think we can modify
them, but by my own experience this is not the case. Whenever you want to
do something more (but not too much) you as user just tweak the backend.
That is one of the reasons behind MEP22. To offer a "clean" way to modify
the backend without actually modifying it.
@tacaswell was working on a PR along the lines of making the backend
components reusable (not just the canvas)
> Ben Root
>
> On Mon, Nov 24, 2014 at 12:28 PM, Chris Barker <chr...@no...>
wrote:
>>
>> On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing <ef...@ha...> wrote:
>>>
>>> On 2014年11月23日, 12:18 PM, Benjamin Root wrote:
>>> > Reading through the backend_wx.py code, I noticed a small deviation
from
>>> > the other interactive backends. All other
>>> > new_figure_manager_given_figure() separately creates a canvas and
>>> > manager object (which, in turn, creates the window object) and hooks
>>> > them all up. The manager would handle all window responsibilities such
>>> > as creation/destruction and sizing. However, for the WX backend, this
>>> > function just creates a FigureFrameWx object, which is the window
>>> > widget. This object also becomes responsible for creating the canvas
and
>>> > the manager.
>>> >
>>> > This setup seems a bit backwards to me, but I am not entirely sure. It
>>> > is definitely different. Does anybody know if it is merely a remnant
of
>>> > older designs (I think WX was the first backend)? What are the
>>> > limitations of this approach, if any? Is there any interest in
>>> > normalizing this backend design with the others (or vice versa)?
>>>
>>> In general, making the backends as similar as possible (and factoring
>>> out as much as possible) is good; but actually messing around with these
>>> things can be time consuming, painful, and hazardous. It's hard to test
>>> with all the different platforms and versions.
>>
>>
>> Last I looked, and I doubt much has changed, the wx back-end required a
fair bit of love -- there was a lot of extra refresh() calls being made in
various places, most of which were unnecessary most of the time -- i.e. a
bunch of extra refreshes. I've been hoping for literally years to find the
time to go in an clean that up, but not yet....
>>
>> So -- if someone can dedicate some time to clean up the wx back-end,
then it wold make sense to look into normalizing this, too. But I agree
with Eric, this is likely to be a significant job -- wouldn't tough unless
your'e ready to commit to some real work.
>>
>> If it ain't broke.....
>>
>> -Chris
>>
>> --
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R (206) 526-6959 voice
>> 7600 Sand Point Way NE (206) 526-6329 fax
>> Seattle, WA 98115 (206) 526-6317 main reception
>>
>> Chr...@no...
>>
>>
------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Mon, Nov 24, 2014 at 9:41 AM, Benjamin Root <ben...@ou...> wrote:
> It is odd you mentioned the extra refreshes. I have to double-check my
> book examples, but I think I found that I needed to add some extra
> draw_idle() calls when using native wx widgets.
>
I haven't messed with widgets within MPL at all -- so I'm no help there.
> This does raise another point. As a development policy, how should we
> treat the backends? Should we be free to change it up so long as it works
> well with Matplotlib, or should we be cautious and recognize that there are
> users who go down beyond the canvas layer?
>
I've toyed with using the guts of MPL as a generic
for-something-other-than-plotting AGG renderer. But I think it's fair to
not support that kind of use-case with guarantees of backwards
compatibility.
I do think a just-agg-drawing lib would be a nice think to have. So some
day, it may make sense to spilt it our out of MPL, and then we'd need to
worry about preserving the API, but while it's built into MPL, I wouldn't
worry about it.
-CHB
>
> Ben Root
>
> On Mon, Nov 24, 2014 at 12:28 PM, Chris Barker <chr...@no...>
> wrote:
>
>> On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing <ef...@ha...> wrote:
>>
>>> On 2014年11月23日, 12:18 PM, Benjamin Root wrote:
>>> > Reading through the backend_wx.py code, I noticed a small deviation
>>> from
>>> > the other interactive backends. All other
>>> > new_figure_manager_given_figure() separately creates a canvas and
>>> > manager object (which, in turn, creates the window object) and hooks
>>> > them all up. The manager would handle all window responsibilities such
>>> > as creation/destruction and sizing. However, for the WX backend, this
>>> > function just creates a FigureFrameWx object, which is the window
>>> > widget. This object also becomes responsible for creating the canvas
>>> and
>>> > the manager.
>>> >
>>> > This setup seems a bit backwards to me, but I am not entirely sure. It
>>> > is definitely different. Does anybody know if it is merely a remnant of
>>> > older designs (I think WX was the first backend)? What are the
>>> > limitations of this approach, if any? Is there any interest in
>>> > normalizing this backend design with the others (or vice versa)?
>>>
>>> In general, making the backends as similar as possible (and factoring
>>> out as much as possible) is good; but actually messing around with these
>>> things can be time consuming, painful, and hazardous. It's hard to test
>>> with all the different platforms and versions.
>>>
>>
>> Last I looked, and I doubt much has changed, the wx back-end required a
>> fair bit of love -- there was a lot of extra refresh() calls being made in
>> various places, most of which were unnecessary most of the time -- i.e. a
>> bunch of extra refreshes. I've been hoping for literally years to find the
>> time to go in an clean that up, but not yet....
>>
>> So -- if someone can dedicate some time to clean up the wx back-end, then
>> it wold make sense to look into normalizing this, too. But I agree with
>> Eric, this is likely to be a significant job -- wouldn't tough unless
>> your'e ready to commit to some real work.
>>
>> If it ain't broke.....
>>
>> -Chris
>>
>> --
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R (206) 526-6959 voice
>> 7600 Sand Point Way NE (206) 526-6329 fax
>> Seattle, WA 98115 (206) 526-6317 main reception
>>
>> Chr...@no...
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

It is odd you mentioned the extra refreshes. I have to double-check my book
examples, but I think I found that I needed to add some extra draw_idle()
calls when using native wx widgets.
This does raise another point. As a development policy, how should we treat
the backends? Should we be free to change it up so long as it works well
with Matplotlib, or should we be cautious and recognize that there are
users who go down beyond the canvas layer?
Ben Root
On Mon, Nov 24, 2014 at 12:28 PM, Chris Barker <chr...@no...>
wrote:
> On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing <ef...@ha...> wrote:
>
>> On 2014年11月23日, 12:18 PM, Benjamin Root wrote:
>> > Reading through the backend_wx.py code, I noticed a small deviation from
>> > the other interactive backends. All other
>> > new_figure_manager_given_figure() separately creates a canvas and
>> > manager object (which, in turn, creates the window object) and hooks
>> > them all up. The manager would handle all window responsibilities such
>> > as creation/destruction and sizing. However, for the WX backend, this
>> > function just creates a FigureFrameWx object, which is the window
>> > widget. This object also becomes responsible for creating the canvas and
>> > the manager.
>> >
>> > This setup seems a bit backwards to me, but I am not entirely sure. It
>> > is definitely different. Does anybody know if it is merely a remnant of
>> > older designs (I think WX was the first backend)? What are the
>> > limitations of this approach, if any? Is there any interest in
>> > normalizing this backend design with the others (or vice versa)?
>>
>> In general, making the backends as similar as possible (and factoring
>> out as much as possible) is good; but actually messing around with these
>> things can be time consuming, painful, and hazardous. It's hard to test
>> with all the different platforms and versions.
>>
>
> Last I looked, and I doubt much has changed, the wx back-end required a
> fair bit of love -- there was a lot of extra refresh() calls being made in
> various places, most of which were unnecessary most of the time -- i.e. a
> bunch of extra refreshes. I've been hoping for literally years to find the
> time to go in an clean that up, but not yet....
>
> So -- if someone can dedicate some time to clean up the wx back-end, then
> it wold make sense to look into normalizing this, too. But I agree with
> Eric, this is likely to be a significant job -- wouldn't tough unless
> your'e ready to commit to some real work.
>
> If it ain't broke.....
>
> -Chris
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chr...@no...
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing <ef...@ha...> wrote:
> On 2014年11月23日, 12:18 PM, Benjamin Root wrote:
> > Reading through the backend_wx.py code, I noticed a small deviation from
> > the other interactive backends. All other
> > new_figure_manager_given_figure() separately creates a canvas and
> > manager object (which, in turn, creates the window object) and hooks
> > them all up. The manager would handle all window responsibilities such
> > as creation/destruction and sizing. However, for the WX backend, this
> > function just creates a FigureFrameWx object, which is the window
> > widget. This object also becomes responsible for creating the canvas and
> > the manager.
> >
> > This setup seems a bit backwards to me, but I am not entirely sure. It
> > is definitely different. Does anybody know if it is merely a remnant of
> > older designs (I think WX was the first backend)? What are the
> > limitations of this approach, if any? Is there any interest in
> > normalizing this backend design with the others (or vice versa)?
>
> In general, making the backends as similar as possible (and factoring
> out as much as possible) is good; but actually messing around with these
> things can be time consuming, painful, and hazardous. It's hard to test
> with all the different platforms and versions.
>
Last I looked, and I doubt much has changed, the wx back-end required a
fair bit of love -- there was a lot of extra refresh() calls being made in
various places, most of which were unnecessary most of the time -- i.e. a
bunch of extra refreshes. I've been hoping for literally years to find the
time to go in an clean that up, but not yet....
So -- if someone can dedicate some time to clean up the wx back-end, then
it wold make sense to look into normalizing this, too. But I agree with
Eric, this is likely to be a significant job -- wouldn't tough unless
your'e ready to commit to some real work.
If it ain't broke.....
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

That is super cool. I was thinking about doing something similar, glad it
has already been so well done.
The example figures at the bottom bring up another point, we should have a
canonical set of test figures, both for the color map and the defaults in
general, I think that will really help with this discussion.
That example could also be reused as a standard show-case for style-files.
Tom
On Mon Nov 24 2014 at 11:32:41 AM Michael Droettboom <md...@st...>
wrote:
> I, for one, would love to see a pull request for this if you're game.
>
> Mike
>
>
> On 11/24/2014 04:27 AM, Lion Krischer wrote:
>
> Hi all,
>
> I was made aware of this thread and thought I’d share a notebook I
> recently made for a similar purpose:
>
> http://nbviewer.ipython.org/gist/krischer/d35096a9d3b6da5846a5 (takes a
> while to load...)
>
> It attempts to "optimize" colormaps by defining optimality as having a
> linear lightness across the colormap in LAB color space. It is very simple
> and not a proper optimization procedure. It just goes to LAB space, sets
> the lightness to the target lightness, and goes back to sRGB space. This
> does not always work as the LAB color space is much bigger than the RGB one
> but in many cases it produces fairly good results.
>
> The nice thing about this is that the lightness range can be chosen so it
> is does not always have to be stark white or black at the ends and some hue
> can be preserved.
>
> I am not sure if some similar functionality is useful to include into
> matplotlib (I don’t really think so) but if yes, let me know and I’ll give
> it a try. I guess it could also be extended to optimize towards monotonic
> changes in hue.
>
> Cheers and all the best!
>
> Lion
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREEhttp://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Matplotlib-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> --
> Michael Droettboom
> Science Software Branch
> Space Telescope Science Institute
> http://www.droettboom.com
>
> ------------------------------------------------------------
> ------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/
> 4140/ostg.clktrk_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I, for one, would love to see a pull request for this if you're game.
Mike
On 11/24/2014 04:27 AM, Lion Krischer wrote:
> Hi all,
>
> I was made aware of this thread and thought I’d share a notebook I 
> recently made for a similar purpose:
>
> http://nbviewer.ipython.org/gist/krischer/d35096a9d3b6da5846a5 (takes 
> a while to load...)
>
> It attempts to "optimize" colormaps by defining optimality as having a 
> linear lightness across the colormap in LAB color space. It is very 
> simple and not a proper optimization procedure. It just goes to LAB 
> space, sets the lightness to the target lightness, and goes back to 
> sRGB space. This does not always work as the LAB color space is much 
> bigger than the RGB one but in many cases it produces fairly good results.
>
> The nice thing about this is that the lightness range can be chosen so 
> it is does not always have to be stark white or black at the ends and 
> some hue can be preserved.
>
> I am not sure if some similar functionality is useful to include into 
> matplotlib (I don’t really think so) but if yes, let me know and I’ll 
> give it a try. I guess it could also be extended to optimize towards 
> monotonic changes in hue.
>
> Cheers and all the best!
>
> Lion
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
http://www.droettboom.com

Hi all,
I was made aware of this thread and thought I’d share a notebook I recently made for a similar purpose:
http://nbviewer.ipython.org/gist/krischer/d35096a9d3b6da5846a5 <http://nbviewer.ipython.org/gist/krischer/d35096a9d3b6da5846a5> (takes a while to load...)
It attempts to "optimize" colormaps by defining optimality as having a linear lightness across the colormap in LAB color space. It is very simple and not a proper optimization procedure. It just goes to LAB space, sets the lightness to the target lightness, and goes back to sRGB space. This does not always work as the LAB color space is much bigger than the RGB one but in many cases it produces fairly good results.
The nice thing about this is that the lightness range can be chosen so it is does not always have to be stark white or black at the ends and some hue can be preserved.
I am not sure if some similar functionality is useful to include into matplotlib (I don’t really think so) but if yes, let me know and I’ll give it a try. I guess it could also be extended to optimize towards monotonic changes in hue.
Cheers and all the best!
Lion

I'd like to propose an update to the default boxplot symbology: all black
Q: How much more black could the boxplots be?
A: None. None more black.
(sorry, ben)
On Fri, Nov 21, 2014 at 7:18 PM, Benjamin Root <ben...@ou...> wrote:
> With regards to defaults for 2.0, I am actually all for breaking them for
> the better. What I find important is giving users an easy mechanism to use
> an older style, if it is important to them. The current behavior isn't
> "buggy" (for the most part) and failing to give users a way to get behavior
> that they found desirable would be alienating. I think this is why projects
> like prettyplotlib and seaborn have been so important to matplotlib. It
> enables those who are in the right position to judge styles to explore the
> possibilities easily without commiting matplotlib to any early decision and
> allowing it to have a level of stability that many users find attractive.
>
> At the moment, the plans for the OO interface changes should not result in
> any (major) API breaks, so I am not concerned about that at the moment.
> Let's keep focused on style related issues in this thread.
>
> Tabbed figures? Intriguing... And I really do need to review that MEP of
> yours...
>
> Cheers!
> Ben Root
>
> On Fri, Nov 21, 2014 at 9:36 PM, Federico Ariza <ari...@gm...>
> wrote:
>
>> I like the idea of aligning a set of changes for 2.0 even if still far
>> away.
>>
>> Regarding to backwards compatibility I think that indeed it is important
>> but when changing mayor version (1.x to 2.0) becomes less important and we
>> must take care of prioritizing evolution.
>> Take for example the OO interface (not defined yet) this is very
>> probable to break the current pyplot interface but still this is a change
>> that needs to be done.
>>
>> In terms of defaults. I would like to see the new Navigation as default
>> (if it gets merged) and tabbed figures (to come after navigation), having
>> separate figures feel kind of ..."old"
>> On 21 Nov 2014 21:23, "Benjamin Root" <ben...@ou...> wrote:
>>
>>> Some of your wishes are in progress already:
>>> https://github.com/matplotlib/matplotlib/pull/3818
>>> There is also an issue open about scaling the dashes with the line
>>> width, and you are right, the spacing for the dashes are terrible.
>>>
>>> I can definitely see the argument to making a bunch of these visual
>>> changes together. Preferably, I would like to do these changes via style
>>> sheets so that we can provide a "classic" stylesheet for backwards
>>> compatibility.
>>>
>>> I do actually like the autoscaling system as it exists now. The problem
>>> is that the data margins feature is applied haphazardly. The power spectra
>>> example is a good example of where we could "smarten" the system. As for
>>> the ticks... I think that is a very obscure edge-case. I personally prefer
>>> inward.
>>>
>>> It is good to get these grievances enumerated. I am interested in seeing
>>> where this discussion goes.
>>>
>>> Cheers!
>>> Ben Root
>>>
>>> On Fri, Nov 21, 2014 at 6:22 PM, Nathaniel Smith <nj...@po...> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Since we're considering the possibility of making a matplotlib 2.0
>>>> release with a better default colormap, it occurred to me that it
>>>> might make sense to take this opportunity to improve other visual
>>>> defaults.
>>>>
>>>> Defaults are important. Obviously for publication graphs you'll want
>>>> to end up tweaking every detail, but (a) not everyone does but we
>>>> still have to read their graphs, and (b) probably only 1% of the plots
>>>> I make are for publication; the rest are quick one-offs that I make
>>>> on-the-fly to help me understand my own data. For such plots it's
>>>> usually not worth spending much/any time tweaking layout details, I
>>>> just want something usable, quickly. And I think there's a fair amount
>>>> of low-hanging improvements possible.
>>>>
>>>> Batching multiple visual changes like this together seems much better
>>>> than spreading them out over multiple releases. It keeps the messaging
>>>> super easy to understand: "matplotlib 2.0 is just like 1.x, your code
>>>> will still work, the only difference is that your plots will look
>>>> better by default". And grouping these changes together makes it
>>>> easier to provide for users who need to revert back to the old
>>>> defaults -- it's easy to provide simple binary choice between "before
>>>> 2.0" versus "after 2.0", harder to keep track of a bunch of different
>>>> changes spread over multiple releases.
>>>>
>>>> Some particular annoyances I often run into and that might be
>>>> candidates for changing:
>>>>
>>>> - The default method of choosing axis limits is IME really, really
>>>> annoying, because of the way it tries to find "round number"
>>>> boundaries. It's a clever idea, but in practice I've almost never seen
>>>> this pick axis limits that are particularly meaningful for my data,
>>>> and frequently it picks particularly bad ones. For example, suppose
>>>> you want to plot the spectrum of a signal; because of FFT's preference
>>>> for power-of-two sizes works it's natural to end up with samples
>>>> ranging from 0 to 255. If you plot this, matplotlib will give you an
>>>> xlim of (0, 300), which looks pretty ridiculous. But even worse is the
>>>> way this method of choosing xlims can actually obscure data -- if the
>>>> extreme values in your data set happen to fall exactly on a "round
>>>> number", then this will be used as the axis limits, and you'll end up
>>>> with data plotted directly underneath the axis spine. I frequently
>>>> encounter this when making scatter plots of data in the 0-1 range --
>>>> the points located at exactly 0 and 1 are very important to see, but
>>>> are nearly invisible by default. A similar case I ran into recently
>>>> was when plotting autocorrelation functions for different signals. For
>>>> reference I wanted to include the theoretically ideal ACF for white
>>>> noise, which looks like this:
>>>> plt.plot(np.arange(1000), [1] + [0] * 999)
>>>> Good luck reading that plot!
>>>>
>>>> R's default rule for deciding axis limits is very simple: extend the
>>>> data range by 4% on each side; those are your limits. IME this rule --
>>>> while obviously not perfect -- always produces something readable and
>>>> unobjectionable.
>>>>
>>>> - Axis tickmarks should point outwards rather than inwards: There's
>>>> really no advantage to making them point inwards, and pointing inwards
>>>> means they can obscure data. My favorite example of this is plotting a
>>>> histogram with 100 bins -- that's an obvious thing to do, right? Check
>>>> it out:
>>>> plt.hist(np.random.RandomState(0).uniform(size=100000), bins=100)
>>>> This makes me do a double-take every few months until I remember
>>>> what's going on: "WTF why is the bar on the left showing a *stacked*
>>>> barplot...ohhhhh right those are just the ticks, which happen to be
>>>> exactly the same width as the bar." Very confusing.
>>>>
>>>> Seaborn's built-in themes give you the options of (1) no axis ticks at
>>>> all, just a background grid (by default the white-on-light-grey grid
>>>> as popularized by ggplot2), (2) outwards pointing tickmarks. Either
>>>> option seems like a better default to me!
>>>>
>>>> - Default line colors: The rgbcmyk color cycle for line plots doesn't
>>>> appear to be based on any real theory about visualization -- it's just
>>>> the corners of the RGB color cube, which is a highly perceptually
>>>> non-uniform space. The resulting lines aren't terribly high contrast
>>>> against the default white background, and the different colors have
>>>> varying luminance that makes some lines "pop out" more than others.
>>>>
>>>> Seaborn's default is to use a nice isoluminant variant on matplotlib's
>>>> default:
>>>>
>>>> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
>>>> ggplot2 uses isoluminant colors with maximally-separated hues, which
>>>> also works well. E.g.:
>>>>
>>>> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
>>>>
>>>> - Line thickness: basically every time I make a line plot I wish the
>>>> lines were thicker. This is another thing that seaborn simply changes
>>>> unconditionally.
>>>>
>>>> In general I guess we could do a lot worse than to simply adopt
>>>> seaborn's defaults as the matplotlib defaults :-) Their full list of
>>>> overrides can be seen here:
>>>> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L135
>>>> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L301
>>>>
>>>> - Dash styles: a common recommendation for line plots is to
>>>> simultaneously vary both the color and the dash style of your lines,
>>>> because redundant cues are good and dash styles are more robust than
>>>> color in the face of greyscale printing etc. But every time I try to
>>>> follow this advice I find myself having to define new dashes from
>>>> scratch, because matplotlib's default dash styles ("-", "--", "-.",
>>>> ":") have wildly varying weights; in particular I often find it hard
>>>> to even see the dots in the ":" and "-." styles. Here's someone with a
>>>> similar complaint:
>>>>
>>>> http://philbull.wordpress.com/2012/03/14/custom-dashdot-line-styles-in-matplotlib/
>>>>
>>>> Just as very rough numbers, something along the lines of "--" = [7,
>>>> 4], "-." = [7, 4, 3, 4], ":" = [2, 1.5] looks much better to me.
>>>>
>>>> It might also make sense to consider baking the advice I mentioned
>>>> above into matplotlib directly, and having a non-trivial dash cycle
>>>> enabled by default. (So the first line plotted uses "-", second uses
>>>> "--" or similar, etc.) This would also have the advantage that if we
>>>> make the length of the color cycle and the dash cycle relatively
>>>> prime, then we'll dramatically increase the number of lines that can
>>>> be plotted on the same graph with distinct appearances. (I often run
>>>> into the annoying situation where I throw up a quick-and-dirty plot,
>>>> maybe with something like pandas's dataframe.plot(), and then discover
>>>> that I have multiple indistinguishable lines.)
>>>>
>>>> Obviously one could quibble with my specific proposals here, but does
>>>> in general seem like a useful thing to do?
>>>>
>>>> -n
>>>>
>>>> --
>>>> Nathaniel J. Smith
>>>> Postdoctoral researcher - Informatics - University of Edinburgh
>>>> http://vorpus.org
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>>> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>>> more
>>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

On 2014年11月23日, 12:18 PM, Benjamin Root wrote:
> Reading through the backend_wx.py code, I noticed a small deviation from
> the other interactive backends. All other
> new_figure_manager_given_figure() separately creates a canvas and
> manager object (which, in turn, creates the window object) and hooks
> them all up. The manager would handle all window responsibilities such
> as creation/destruction and sizing. However, for the WX backend, this
> function just creates a FigureFrameWx object, which is the window
> widget. This object also becomes responsible for creating the canvas and
> the manager.
>
> This setup seems a bit backwards to me, but I am not entirely sure. It
> is definitely different. Does anybody know if it is merely a remnant of
> older designs (I think WX was the first backend)? What are the
> limitations of this approach, if any? Is there any interest in
> normalizing this backend design with the others (or vice versa)?
Gtk came before Wx, and the mpl drawing model was influenced by that gtk 
heritage. (And on linux, Wx is a layer on top of Gtk.)
I have no idea what the consequences are of the subtle difference you 
point out, or whether it was a deliberate choice for some compelling 
reason, or whether it followed gtk but then gtk was changed later, or what.
In general, making the backends as similar as possible (and factoring 
out as much as possible) is good; but actually messing around with these 
things can be time consuming, painful, and hazardous. It's hard to test 
with all the different platforms and versions.
Eric
>
> Thanks to everybody for putting up with my questions over the last few
> months. Oftentimes, just writing out the questions have been very useful
> to me, along with your responses. The good news is the book is almost
> done, and I hope that it will be an extremely useful reference.
>
> Cheers!
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Reading through the backend_wx.py code, I noticed a small deviation from
the other interactive backends. All other new_figure_manager_given_figure()
separately creates a canvas and manager object (which, in turn, creates the
window object) and hooks them all up. The manager would handle all window
responsibilities such as creation/destruction and sizing. However, for the
WX backend, this function just creates a FigureFrameWx object, which is the
window widget. This object also becomes responsible for creating the canvas
and the manager.
This setup seems a bit backwards to me, but I am not entirely sure. It is
definitely different. Does anybody know if it is merely a remnant of older
designs (I think WX was the first backend)? What are the limitations of
this approach, if any? Is there any interest in normalizing this backend
design with the others (or vice versa)?
Thanks to everybody for putting up with my questions over the last few
months. Oftentimes, just writing out the questions have been very useful to
me, along with your responses. The good news is the book is almost done,
and I hope that it will be an extremely useful reference.
Cheers!
Ben Root

On 2014年11月22日, 7:43 PM, Benjamin Root wrote:
> I don't have a mac to double-check, but reading through the
> backend_cocoaagg.py, I don't see any creation of a navigation toolbar?
> Is this assumption right?
Probably so:
from matplotlib import cbook
cbook.warn_deprecated(
 '1.3',
 message="The CocoaAgg backend is not a fully-functioning backend. "
 "It may be removed in matplotlib 1.4.")
Looks like it is time to delete it. I don't think this deprecation 
warning brought forth any cries of pain, so my guess is that no one is 
actually using it, or ever has done so routinely.
Eric
>
> Thanks!
> Ben Root

On 2014年11月22日, 9:06 AM, gary ruben wrote:
> A few thoughts to add to the excellent ones to date, to do with colorbar
> behaviour.
> My general comment would be that if the axis tick formatter defaults are
> changed not to forget about the colorbar as I typically find it needs
> more tweaking than the main axes.
> I'll make a couple of suggestions, but these are low on the list
> compared to the suggestions that others have made.
>
> 1. consider rasterizing colorbar contents by default
> 2. make colorbar axis sizing for matshow behave like imshow
>
>
> 1. consider rasterizing colorbar contents by default
> Eric describes this here
> http://matplotlib.1069221.n5.nabble.com/rasterized-colorbar-td39582.html
> and suggests that rasterizing the colorbar may not be desirable,
> although I'm not totally sure why. Perhaps it is because I have noticed
> that mixing rasterized content with vector lines/axes in matplotlib is
> generally imperfect. If saving the figure as a pdf or svg with dpi left
> at default, you can usually see offsets and scaling problems. For
> example after rasterizing a colorbar I usually see white pixels along
> the top and side within the vector colorbar frame. This also shows up
> when using imshow or matshow to show images. I don't know if this is an
> agg limitation, a backend limitation or a bug. If it's a known
> limitation, maybe avoid this suggestion, but if it's a bug, maybe it can
> be fixed and then rasterizing the colorbar might become a better default
> option.
I think the problem is that the outlines are snapped to pixel 
boundaries, but the color blocks are not. Something like that. I think 
a similar problem is manifest in the small offsets often seen between 
colorbar ticks and colorbar boundaries.
>
> For colorbars I usually do lots of tweaking along the lines of:
>
> cb = plt.colorbar(format=ScalarFormatter(useMathText=True))
> cb.formatter.set_useOffset(False)
> cb.formatter.set_scientific(True)
> cb.formatter.set_powerlimits((0,2))
> cb.update_ticks()
> cb.solids.set_rasterized(True)
>
> although I'm not sure about advocating useMathText and set_scientific
> for defaults. I wonder what other think about this?
I don't see why you would want the *default* to be to override the 
rcParams setting for use_mathtext. This just makes it harder to 
document, and harder for people to keep track of what determines what.
To some extent this applies to the rest of your customizations as well. 
 Deviations from the rcParams defaults via special cases, hardwired 
into mpl, should be avoided as much as possible. A richer configuration 
system, building on rcParams or some modification of it, will probably 
be the goal instead. The evolving style module is a step in this direction.
>
> Things like default powerlimits for the colorbar might be rethought. I
> think colorbars typically have too many ticks and associated labels and
> they should perhaps favour integer labels over floating point
> representation if possible.
> In the extreme case, for continuous colormaps, often a tick at just the
> top and bottom of the range would be adequate.
I agree, but the question is how to make it as easy as possible for each 
user to get their desired result. I don't think this is the time to do 
much in the way of tweaking hard-wired defaults.
>
> 2. I'm not sure how much pyplot.matshow is generally used but I still
> use it.
> Could the colorbar height for matshow pick up the axis height of the
> main figure, or maybe imshow could default to interpolation='nearest' so
> I wouldn't be tempted to use matshow any more?
>
> For example,
> plt.matshow(rand(20,20))
> plt.colorbar()
>
> doesn't behave nicely like
>
> plt.imshow(rand(20,20), interpolation='nearest')
> plt.colorbar()
The difference is that matshow is adjusting the figure size based on the 
array dimensions without taking into account the later addition of a 
colorbar. The only way to fix this in our present framework would be to 
use a kwarg to tell matshow to include a colorbar from the start, so it 
would be able to calculate the figure size appropriately.
With imshow plus a colorbar, the "nice" behavior occurs only for a 
particular small range of array dimension ratios, such as the unity 
ratio in your example. For example, try using rand(5, 10).
Eric
>
>
> Gary