[matplotlib-devel] imsave function

nt to have this patch applied without someone else checking it first. It's pretty simple so applying it locally and running the demo file should be a good enough test. thanks, Gary Ruben Index: matplotlib/CHANGELOG === --- matplot

Re: [matplotlib-devel] imsave function

Thanks for the quick test and comments Andrew. I've made your suggested changes and attached a new patch. Gary Andrew Straw wrote: Hi Gary, I have a couple comments: 1) No need for: +ax = fig.add_subplot(111) +ax.set_axis_off() 2) It's probably best to have maximum compatibility wit

Re: [matplotlib-devel] imsave function

Hi Andrew, I don't have commit access. If you would check it in, that would be great. thanks for offering, Gary Andrew Straw wrote: > Gary, this looks fine to me. Do you have commit access? If not, I'll be > happy to check it in for you. > > -Andrew ---

Re: [matplotlib-devel] Cairo Backend and Subpixel Rendering

John Hunter wrote: > The matplotlib.lines.Line2D objects has an antialiased property -- we > could add the same property to matplotlib.text.Text to turn on/off > subpixel rendering (which could also be supported as an rc param) > > JDH What are the supported combinations of subpixel rendering an

Re: [matplotlib-devel] Color map gamma

I think this would be useful. While you're at it, in the attached file I have a function "rescale_cmap" that effectively changes the autoscaling of the colormap to the data by allowing specification of the range limits - I find this useful. You might like to look at this to see if it's worth ge

Re: [matplotlib-devel] matplotlib image tutorial

Very nice addition Michael. I note that the plt.colormap() line must have gotten lost. It's referred to but not there. I'll add some ideas to John's list: * Demonstrate the imsave() command. * Rather than show 50 lines or so of array data, just show a few lines, but demonstrate what img.shape i

Re: [matplotlib-devel] imsave function

mapping to achieve it? Gary Stéfan van der Walt wrote: Hey all, 2009/2/10 Andrew Straw : Gary Ruben wrote: Hi Andrew, I don't have commit access. If you would check it in, that would be great. Committed to the trunk in r6899... Thanks! And, sheesh, SourceForge's SVN server is slooow

Re: [matplotlib-devel] imsave function

;t know if this can be changed easily. Gary Stéfan van der Walt wrote: > Hi Gary > > Sorry, I didn't even read the docstring since I have been using > SciPy's "imsave" so far. > > 2009/11/8 Gary Ruben : >> This may be all you need. My tests (in the

Re: [matplotlib-devel] auto range limits for spines: please kick the tires

This looks nice Andrew, I haven't tried it, but I wonder whether it's possible to add a keyword arg to suppress the 0's at the origin which are cut through by the axes in the zeroed case (and/or possibly shift the 0 on the horizontal axis left). The same thing is happening in the (1,2) case on t

Re: [matplotlib-devel] imsave, image size

Just saw this thread and thought I should explain that this was indeed a hack by me which was aimed to do exactly what Michael said. I never thought there'd be any side effects from doing this - it's interesting that pdfLaTeX balks because it has never done so for me. Anyway, thanks Michael for

Re: [matplotlib-devel] Re: collection initializer color handling vs quiver

Hi Jordan, Thanks for your heads-up. I actually left this and went back to using polygon patches for the arrows, mainly because I thought I'd have more control over the size without having to do any fancy line collection stuff. Re. your change, the call to the LineCollection__init__ function

Re: [matplotlib-devel] new Quiver progress

This is good news Eric and sounds like the desired behaviour. Thanks for letting me know. I was intending to try to work it out this weekend but have spent my time instead learning to build numpy/scipy/matplotlib from source - a worthwhile exercise. I don't think JDH/Charlie should wait for new

Re: [matplotlib-devel] new Quiver progress

Hi Eric, Having entered the build-from-source world with the latest ubuntu, I applied your patch and tried it out with the example code I sent you using a call similar to quiver2(x,y,u,v,units='x',width=0.5,headwidth=3,headlength=3,headaxislength=2) This works very nicely for my purposes - per

Re: [matplotlib-devel] new Quiver progress

Eric Firing wrote: > Gary, > > Thanks for the prompt test and report. > > I agree that the ability to put a dot at locations where arrows are > below a threshold would be good. I will add it. I think it should be > similar to a circle marker that scales with the arrow width, and has a > diam

Re: [matplotlib-devel] Questions about mathtext, unicode conversion etc.

Hi Edin, Edin Salković wrote: > Hi all, > > Also, if anyone has some good online sources about parsing etc. on the > net, I vwould realy appreciate it. Everything that David Mertz wrote about text processing in his excellent "Charming Python" articles:

Re: [matplotlib-devel] bug 1798196: Axes3D bug

If someone decides to poke around in the 3D plotting files in response to Leon's efforts, there's another fix posted a while back which was not applied:

Re: [matplotlib-devel] ghostscript version fix

Yep. Works. C:\WINDOWS>gswin32c --version 8.51 Darren Dale wrote: > gs --version works with AFPL. Could someone please check that this works on > windows: gswin32c --version > > - > This SF.net email is sponsored by: Splu

Re: [matplotlib-devel] future of mpl documentation

My 2 cents: I think it looks better if you reduce the number of histogram bins from 50 down to 15 or 20. Gary R. John Hunter wrote: > I played around with this a bit this morning -- it may be too busy for > your OS X sensibilities, but let me know if you think think this is an > approach wotrh pu

Re: [matplotlib-devel] Misalignment imshow vs. grid lines

I also see this in mpl 1.1.0, python 2.7.2 with the iPython Qt console and also with the WXAgg backend Gary R. On 30 October 2012 03:16, Nicolas Rougier wrote: > > > matplotlib 1.2.x > python 2.7.2 > osx10.7.5 > > > Nicolas > > On Oct 29, 2012, at 16:29 , Benjamin Root wrote: > >> >>

[matplotlib-devel] Bug in imsave

Hi, I haven't looked at this list for a long time, so hi to all the active devs. I just came across a problem in the image.py imsave() function. Problem: At an ipython --pylab prompt, typing a = rand(29,29) imsave('test.png', a) incorrectly generates a 28x28 pixel image. This happens for several

Re: [matplotlib-devel] Bug in imsave

; > > > On Sun, Apr 7, 2013 at 4:39 AM, gary ruben wrote: > >> Hi, I haven't looked at this list for a long time, so hi to all the >> active devs. >> I just came across a problem in the image.py imsave() function. >> >> Problem: >> At an ipython -

Re: [matplotlib-devel] Better defaults all around?

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

Re: [matplotlib-devel] Matplotlib's new default colormap

There was a talk by Kristen Thyng at scipy2014 that might be a good backgrounder for this: http://pyvideo.org/video/2769/perceptions-of-matplotlib-colormaps At the end she references this site http://mycarta.wordpress.com/ of Matteo Niccoli which is full of good content. I wonder if it's worth con

Re: [matplotlib-devel] release strategy and the color revolution

Just wondering whether anyone has suggested checking candidate colormaps against typical printer color gamuts? On 6 Apr 2015 1:11 pm, "Eric Firing" wrote: > On 2015/04/04 10:10 PM, Nathaniel Smith wrote: > >> We'd welcome any feedback from readers with non-simulated color >> deficiency! >> > > I

Re: [matplotlib-devel] release strategy and the color revolution

ble to use that, along with some common icc profiles to automate the checking, or build it into an optimiser as a constraint. On 6 April 2015 at 15:57, Nathaniel Smith wrote: > On Apr 5, 2015 8:29 PM, "gary ruben" wrote: > > > > Just wondering whether anyone has sug

Re: [matplotlib-devel] Moving color overhaul forward

It's good to hear Stefan is working on circular colormaps as the hsv colormap is way too saturated, ignoring any perceptual aspects. For this, it might be possible to provide some sort of saturation parameter in a function along the lines of the parameters in the cubehelix function? Also, sympy/mpm