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 ------------------------------------------------------------------------------ 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
