matplotlib-users Mailing List for matplotlib

From: Yi Shang [mailto:mir...@gm...] 
Sent: Friday, August 27, 2010 15:34

from numpy import *
from matplotlib import pyplot as plt
import pylab
params = {'font.size' : 16,
          'axes.labelsize' : 16,
          'font.style' : 'normal',
          'font.family' : 'sans-serif',
        'font.sans-serif' : 'Arial'
}
pylab.rcParams.update(params)

By the way, the update() method above bypasses the validation [1] provided by
the RcParams class. Thus you must take care to give a list of font names for
font.sans-serif and other font families. If you use

for (k, v) in {'font.sans-serif': 'Arial'}.items():
    plt.rcParams[k] = v

or

plt.rc('font', **{'sans-serif': 'Arial'})

then your parameters will be validated, a process that automatically encloses
into a list font names given for families.

[1]
http://matplotlib.sourceforge.net/users/customizing.html#dynamic-rc-settings

On Thu, Sep 2, 2010 at 9:23 AM, Benjamin Root <ben...@ou...> wrote:
> This also raises another pet peeve of mine.  The Agg backend seems to use
> linear blending for alpha.  This is inconsistent with how the world works.
> It is more realistic for logarithmic blending, or at least, a piece-wise
> linear blending.
>
> Imagine I have two overlapping objects with alpha set to .5 (a_1 and a_2).
> What is rendered in matplotlib is completely opaque.  A more realistic
> result would have a final alpha setting of .75 (i.e. - the first item takes
> away half the transparency, then the second item takes away half of the
> remaining transparency.
>
> I am not nearly familiar enough with the Agg backend to know how to
> implement this.  Is this at all feasible?

I'm not sure this is what's going on. Right now, though, I'm seeing
some weird draw artifacts that I don't have time to run down. What I
will say is that while some other blending functions may be
interesting, I don't think it's widely supported. OpenGL just treats
the alpha as a weight for the colors. You can tweak it, but it's
inherently linear unless you write a pixel shader.

Also, I don't think the blending produces an opaque result. I'm pretty
sure you can blend 3 colors together, each with an alpha > 0.5.  The
color will be pretty saturated, but opaque would mean the bottom color
doesn't show through. (I'll hack on an example later). Remember,
though, that your monitor doesn't display an "alpha" color. Any
translucency from a net blending of colors just means that you're
blending in a background color (alpha=1.0) somewhere.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Thu, Sep 2, 2010 at 9:11 AM, Ryan May <rm...@gm...> wrote:

> On Thu, Sep 2, 2010 at 2:15 AM, Mitesh Patel <qe...@gm...> wrote:
> > Hello,
> >
> > Is it possible to specify both an alpha level and a background color so
> > that an entire saved image has a uniform transparency and color?  For
> > example, with matplotlib 1.0.0, this script yields the attached image:
> >
> > from matplotlib.pyplot import figure, savefig, show
> >
> > fig = figure()
> > ax = fig.add_subplot(111)
> > ax.plot([1,2,3])
> >
> > fig.patch.set_alpha(0.5)
> > for ax in fig.axes:
> >    ax.patch.set_alpha(0.5)
> >
> > fig.patch.set_facecolor('red')
> > for ax in fig.axes:
> >    ax.patch.set_facecolor('red')
> >
> > savefig('test.png', facecolor='red')
> >
> >
> > In particular, the areas inside and outside the axes have different
> > transparency level and color.  Perhaps I'm over/mis/ab-using the options
> > here?
>
> It's not that they're not uniform--you're seeing alpha blending
> between the figure patch and the axes patch. Within the axes, both are
> being rendered and blended together. This is more readily apparent if
> you use blue for the axes patch, as I did for the attached image. When
> the red and blue are blended together, you end up with purple. If you
> want it all uniform, you'd be better off setting the axes patch to an
> alpha of 0.0.
>
> Ryan
>
>
This also raises another pet peeve of mine.  The Agg backend seems to use
linear blending for alpha.  This is inconsistent with how the world works.
It is more realistic for logarithmic blending, or at least, a piece-wise
linear blending.

Imagine I have two overlapping objects with alpha set to .5 (a_1 and a_2).
What is rendered in matplotlib is completely opaque.  A more realistic
result would have a final alpha setting of .75 (i.e. - the first item takes
away half the transparency, then the second item takes away half of the
remaining transparency.

I am not nearly familiar enough with the Agg backend to know how to
implement this.  Is this at all feasible?

Ben Root

On Thu, Sep 2, 2010 at 2:15 AM, Mitesh Patel <qe...@gm...> wrote:

> Hello,
>
> Is it possible to specify both an alpha level and a background color so
> that an entire saved image has a uniform transparency and color?  For
> example, with matplotlib 1.0.0, this script yields the attached image:
>
> from matplotlib.pyplot import figure, savefig, show
>
> fig = figure()
> ax = fig.add_subplot(111)
> ax.plot([1,2,3])
>
> fig.patch.set_alpha(0.5)
> for ax in fig.axes:
>    ax.patch.set_alpha(0.5)
>
> fig.patch.set_facecolor('red')
> for ax in fig.axes:
>    ax.patch.set_facecolor('red')
>
> savefig('test.png', facecolor='red')
>
>
> In particular, the areas inside and outside the axes have different
> transparency level and color.  Perhaps I'm over/mis/ab-using the options
> here?
>
> Thanks for your great software and any help you can provide!
>
> Sincerely,
> Mitesh Patel
>
>
>
Mitesh,

That is an interesting idea.  Theoretically, it might be possible to
implement such a feature.  The key design idea of Matplotlib is to have
Artist objects that own other Artist objects.  So, a Figure owns several
axes, and those axes own various plotting elements, which are all subclasses
of Artists.  So, I could imagine that an rgba value could get "inherited" by
a child artist from its parent (unless the user specifies differently).

Would we want to automatically make text inherit the rgba setting?  Also,
currently there are a lot of places in code where one directly specifies
color, or color is automatically chosen (from a colormap or a rotating set
of colors).  I wonder what should be the proper behavior in those cases
(ignore parent setting? if so, then do the setting still get passed on to
child artists? should the automatically chosen settings get passed on?).

What do others think?

Ben Root

On Thu, Sep 2, 2010 at 2:15 AM, Mitesh Patel <qe...@gm...> wrote:
> Hello,
>
> Is it possible to specify both an alpha level and a background color so
> that an entire saved image has a uniform transparency and color?  For
> example, with matplotlib 1.0.0, this script yields the attached image:
>
> from matplotlib.pyplot import figure, savefig, show
>
> fig = figure()
> ax = fig.add_subplot(111)
> ax.plot([1,2,3])
>
> fig.patch.set_alpha(0.5)
> for ax in fig.axes:
>    ax.patch.set_alpha(0.5)
>
> fig.patch.set_facecolor('red')
> for ax in fig.axes:
>    ax.patch.set_facecolor('red')
>
> savefig('test.png', facecolor='red')
>
>
> In particular, the areas inside and outside the axes have different
> transparency level and color.  Perhaps I'm over/mis/ab-using the options
> here?

It's not that they're not uniform--you're seeing alpha blending
between the figure patch and the axes patch. Within the axes, both are
being rendered and blended together. This is more readily apparent if
you use blue for the axes patch, as I did for the attached image. When
the red and blue are blended together, you end up with purple. If you
want it all uniform, you'd be better off setting the axes patch to an
alpha of 0.0.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi, I was struggling with the same problem since 2 days. But today I found
the solution here:

http://efreedom.com/Question/1-2195983/Matplotlib-Formatting-Dates-Axis-3D-Bar-Graph

#When you use the method 

ax.set_xtics

#it doesn't put ticks to your 3d plot, instead puts ticst to 2D canvas. 
#When you use Axes3D, I understand that you should use:

ax.w_xaxis
ax.w_yaxis
ax.w_zaxis 

#to set axis properties. However if you try:

ax.w_xaxis.set_ticks(arrayOfTicks)

#screws up the plot. Instead you can use this, which worked perfect with
matplotlib 1.0 for me.

import matplotlib.ticker as ticker
ax.w_xaxic.set_major_locator(ticker.FixedLocator(arrayOfTicks))

Cheers
Cenk



Mark B. wrote:
> 
> Hello list, I am trying to set ticks on an Axes3D plot.
> What I really want is, actually, not to have any ticks.
> For a 2D plot I set the ticks to an empty list.
> But in a 3D plot, I cannot set any ticks whatsover.
> At least not with a sequence.
> Any thoughts?
> 
> from mpl_toolkits.mplot3d import Axes3D
> 
> fig = figure()
> 
> ax = Axes3D(fig)
> 
> ax.plot([0,1],[0,1],[0,1])
> 
> # Now I want to set ticks:
> 
> ax.set_xticks([])
> 
> # ax.set_xticks([.2,.3,.4]) # changes the scale of the figure, but not the
> ticks
> 
> show()
> 
> And the plot has ticks at .2 .4 .6 .8 on the x-axis.
> 
> Thanks for any help,
> 
> Mark
> 
> 

-- 
View this message in context: http://old.nabble.com/setting-ticks-on-Axes3D-tp27012587p29601789.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Benjamin Root <ben.root@...> writes:

> 
> Jens,Which version of matplotlib are you using?  I wonder if this is the 
> path.simplify bug that was fixed for 1.0.Essentially, there was a bug in some 
> code that caused some points to be skipped in the process of displaying images 
> that had datapoints that were closer together than could be resolved.  I 
> suspect this is what is happening here, because everything looks fine on my 
> latest build.

> Ben Root

Hello Ben,

I have the same problem here (mpl on windows, with the tk-agg backend). After
reading your comment above, I upgraded to 1.0.0, which improved the situation:
In Jens' example code, the old version (I think it was 0.99.1?) had problems
with both the high and the low peak (which could be seen when horizontally
resizing the window); in version 1.0 the high peak is shown correctly (y=0.86),
while the low peak shows "random" values instead of the real minimum (y=-0.63).

In my environment, path.simplify is True. When I set it to False, the problem
disappears, however plotting gets (too) slow for my large data sets. And it
should work correctly with path.simplify, right?

Thanks in advance for your assistance,

Hans

Mike,

Using svn trunk, I see exactly the problem Jens is talking about.  Maybe 
there is still a bug in the path simplification?  If I try to plot after 
turning simplification off, I don't get any image at all, so I can't 
immediately say whether the problem is in the simplification.

To reproduce the bug, run the example Jens supplied, and try changing 
the window width a few times.

Eric



On 08/31/2010 01:08 AM, Jens Nie wrote:
> Hi everyone.
> I face a problem here, which I can’t seem to handle by myself, so any
> help is really appreciated.
> I would like to do a simple line plot of a huge dataset as an overview
> to quickly compare success of different measurement scenarios, and it
> seems that not every datapoint is displayed. I played a little with the
> lod parameter, both for the creation of the axis and the plot command.
> However timing the plot command and the display itself do not show
> differences. Here are a few lines of code that help to reproduce the
> problem.
> import time
> import matplotlib
> matplotlib.use("Qt4Agg")
> import matplotlib.pyplot as plt
> import numpy as np
> xData=np.linspace(0, 10.0, 1e6)
> yData=np.zeros(xData.shape)
> xDataDetail=np.linspace(0.0, 2*np.pi, 1000)
> yDataDetail=np.exp(-xDataDetail)*np.sin(10.0*xDataDetail)
> yData[100000:100000+len(yDataDetail)]=yDataDetail
> fig=plt.figure()
> axes=fig.add_subplot(111)
> tic=time.time()
> axes.plot(xData, yData, "b-")
> toc=time.time()
> axes.grid(True)
> print "Plotting took %g s." % (toc-tic)
> plt.show()
> The code shows how I usually use the matplotlib environment and creates
> a simple dataset of 1 million zeros with a short non trivial peak
> within, that is to be plotted as a blue solid line.
> You can see what happens, when you vary the width of the displaying
> window. On my system usually the minimum amplitude varies when resizing
> the window.
> Is there any way to enforce plotting each and every point?
> I use matplotlib version 1.0.0 on a 32 Bit windows XP system installed
> via the windows installer from sf.
> A quick check on a opensuse 11.3 linux box showed the same issue. Using
> the “standard” TK backend instead of Qt4Agg behaves just the same.
> Jens
>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi.

I tested the svn snapshot from yesterday to see if the problem is there for me in the most recent version. I had to do the check on a linux box, as that one is the only one I am able to compile on. The svn version states itself as 1.0.0 also in matplotlib.__version__ which I hope is ok. The "strange" behavior is still there.

Besides: Where would the correct place be to switch the level of detail parameter. Once for the axes in add_subplot or for every plot command, or both?

Jens


From: Jens Nie [mailto:JN...@Ro...]
Sent: Wednesday, September 01, 2010 10:03 AM
To: mat...@li...
Subject: Re: [Matplotlib-users] How to get all data points plotted/displayed in a line plot

Hi Ben.

It is the version 1.0.0 that i am using, both on Linux and windows. Is there any newer (development) version that I should try?

Jens


[...]

Is there any way to enforce plotting each and every point?

I use matplotlib version 1.0.0 on a 32 Bit windows XP system installed via the windows installer from sf.
A quick check on a opensuse 11.3 linux box showed the same issue. Using the "standard" TK backend instead of Qt4Agg behaves just the same.

Jens


Jens,

Which version of matplotlib are you using?  I wonder if this is the path.simplify bug that was fixed for 1.0.

Essentially, there was a bug in some code that caused some points to be skipped in the process of displaying images that had datapoints that were closer together than could be resolved.  I suspect this is what is happening here, because everything looks fine on my latest build.

Ben Root

Hello,

Is it possible to specify both an alpha level and a background color so
that an entire saved image has a uniform transparency and color?  For
example, with matplotlib 1.0.0, this script yields the attached image:

from matplotlib.pyplot import figure, savefig, show

fig = figure()
ax = fig.add_subplot(111)
ax.plot([1,2,3])

fig.patch.set_alpha(0.5)
for ax in fig.axes:
    ax.patch.set_alpha(0.5)

fig.patch.set_facecolor('red')
for ax in fig.axes:
    ax.patch.set_facecolor('red')

savefig('test.png', facecolor='red')


In particular, the areas inside and outside the axes have different
transparency level and color.  Perhaps I'm over/mis/ab-using the options
here?

Thanks for your great software and any help you can provide!

Sincerely,
Mitesh Patel