matplotlib-users Mailing List for matplotlib

There is one issue I spotted in this code. Although hard to notice from the
produced plot, only the latest grid is updated when set_ydata is called. So
a slight modification makes this code running correctly as originally
intended.

L1list = []
L2list = []
for i in range(nums): for j in range(xx*16, xx*16+16): if i == 0:
L1list.append(grid[j%16].plot(dd1, conc1[j], color='r', lw=1.5)[0])
L2list.append(grid[j%16].plot(dd2, conc2[j], color='b', lw=1.5)[0]) grid[j%
16].set_xscale('log') grid[j%16].set_xticks([10, 100, 1000]) grid[j%16].
set_yticks([-25, 0, 25]) grid[j%16].yaxis.set_minor_locator(ticker.
MultipleLocator(5)) grid[j%16].set_xlim(1,2000, auto=False) grid[j%16].
set_ylim(-50,50, auto=False) else: L1list(j%16).set_ydata(conc1[j])
L2list(j%16).set_ydata(conc2[j])

On Thu, Jul 5, 2012 at 11:15 AM, Fabrice Silva <si...@lm...>wrote:

>
>
> > At end of the outer loop, instead of closing the figure, you should
> > call "remove()" for each plot element you made.  Essentially, as you
> > loop over the inner loop, save the output of the plot() call to a
> > list, and then when done with those plots, pop each element of that
> > list and call "remove()" to take it out of the subplot.  This will let
> > the subplot axes retain the properties you set earlier.
>
> Instead of remove()'ing the graphical elements, you can also reuse them
> if the kind of plots you intend to do is the same along the figure
> for simple plots. See : http://paste.debian.net/177857/
>
> --
> Fabrice Silva
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>



-- 
Gökhan

On Tue, Jul 17, 2012 at 3:01 PM, Jonathan Slavin <js...@cf...>wrote:

> Francesco,
>
> While I like your solution, there is an alternative that is simpler and
> works for me.  That is 1) save matplotlib plot as a png, 2) convert to
> eps using either ImageMagick or GraphicsMagick.  You do end up with
> relatively large files, but they look identical to the original plots.
>
> Regards,
> Jon
>

No, it is not the same thing.  Text in a vector-based format such as eps is
scalable.  ImageMagick and GraphicsMagick are inherently raster-based, and
before that, PNGs are raster-based.  Therefore, the text is not scaled and
anti-aliased according to the display size.

I will be looking over the proposed solution this evening.

Cheers!
Ben Root

Francesco,

While I like your solution, there is an alternative that is simpler and
works for me.  That is 1) save matplotlib plot as a png, 2) convert to
eps using either ImageMagick or GraphicsMagick.  You do end up with
relatively large files, but they look identical to the original plots.

Regards,
Jon

>         Dear matplotlibers,
>         
>         after spending some more time about my problem on how to
>         emulate
>         transparency to create nice eps figures with shaded areas,
>         I found this web page:
>         http://stackoverflow.com/questions/2049230/convert-rgba-color-to-rgb?rq=1
>         
>         So I decided to implement the algorithm and it seems that the
>         approach
>         works (see attached pdf).
>         Of course if there are many layers of transparent colors, it
>         would be
>         very hard to get the exact colors, but so far it's the best
>         approach
>         that I've found.
>         
>         The code can be downloaded from here:
>         https://github.com/montefra/mimic_alpha/downloads
>         
>         Cheers,
>         Francesco
-- 
______________________________________________________________
Jonathan D. Slavin              Harvard-Smithsonian CfA
js...@cf...         60 Garden Street, MS 83
phone: (617) 496-7981           Cambridge, MA 02138-1516
 cell: (781) 363-0035           USA
______________________________________________________________

On 2012/07/09 7:33 AM, Brendan Barnwell wrote:
> On 2012-07-09 06:13, Benjamin Root wrote:
>> On Sun, Jul 8, 2012 at 9:04 PM, Brendan Barnwell<bre...@br...>wrote:
>>>   cs = pyplot.contourf(x,y,z,levels=np.arange(50, 220, 20),
>>>   cmap=pyplot.cm.jet, extend='both')
>>>   cs.cmap.set_under('k')
>>>   cs.set_clim(50, 210)
>>>   cb = pyplot.colorbar(cs)
>>>
>>>           But why do I have to do this?  The whole reason I passed in my
>>>   specified levels was because I wanted THOSE to be the data limits.
>>>   Why is matplotlib expanding the data limits, and thus preventing me
>>>   from specifying the "out of range" color using the normal set_under
>>>   and set_over methods?
>>>
>>>
>> You are right, that behavior is very inconsistent with the documentation.
>> Looking over the QuadContourSet._process_levels() method, I doubt the
>> problem lies there.  While testing, I noticed that whatever color I set for
>> set_under() was always being ignored in the colorbar.  I suspect the
>> problem lies there.
>
> 	You mean in the colorbar and/or set_under?  I don't think so, because
> the problem occurs whether or not you use a colorbar, and, at least
> for me, set_under works as long as the data limits are set correctly.
>    If in my code above, I change set_under("k") to set_under("yellow")
> or whatever else I like, that color is correctly used both in the
> contourf plot and on the colorbar (on the lower arrow).  The code that
> I pointed to in _process_levels is setting vmin and vmax.  It's
> possible this isn't the root of the problem, but the code certainly
> looks strange and unmotivated, and it is what's causing incorrect clim
> to be set.
>

Please check out https://github.com/matplotlib/matplotlib/pull/1022.

Eric

On 07/17/2012 03:32 PM, Benjamin Root wrote:
>     Short question: is there any (simple) way to generate "spectral" images
>     such as the ones in http://astro.u-strasbg.fr/~koppen/discharge/
>     <http://astro.u-strasbg.fr/%7Ekoppen/discharge/> ?

I have a 1st version of what I had in mind:

https://gist.github.com/3131381

Any comments on how to do it the proper way (e.g. good use of normalize 
and colormaps) is welcome!

Cheers,

I think it is me who put that code there. But I cannot recall why I did it.
I may have copied that behavior from other code, but cannot find which.

Yes, I agree that the current behavior is not very desirable.
So, anyone who have an idea how this should behave, please go ahead
and fix this.

Regards,

-JJ


On Sun, Jul 15, 2012 at 1:54 AM, John Hunter <jd...@gm...> wrote:
>
>
> On Sat, Jul 14, 2012 at 11:48 AM, John Hunter <jd...@gm...> wrote:
>>
>> I do not understand why in the following example, if I set
>> patch_alpha=1.0, I do not see the shadow effect.  I would expect to see it
>> for the the rightmost four bars, where the original bars do not entirely
>> occlude the shadow, so even if alpha is 1.0, there are parts of the shadow
>> that are not behind the original bars and should still be visible.
>>
>>
>
>
> I now see that this line explains the behavior
>
> https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/patheffects.py#L183
>
>  gc0.set_alpha(1.-self._patch_alpha)
>
> so maybe I should amend my question: is this desirable that the shadow alpha
> is 1-patch_alpha, since an alpha of 1 on the patch does not imply that there
> is no visible shadow?
>
>

Dear matplotlibers,

after spending some more time about my problem on how to emulate
transparency to create nice eps figures with shaded areas,
I found this web page:
http://stackoverflow.com/questions/2049230/convert-rgba-color-to-rgb?rq=1

So I decided to implement the algorithm and it seems that the approach
works (see attached pdf).
Of course if there are many layers of transparent colors, it would be
very hard to get the exact colors, but so far it's the best approach
that I've found.

The code can be downloaded from here:
https://github.com/montefra/mimic_alpha/downloads

Cheers,
Francesco

On Tue, Jul 17, 2012 at 08:21:50AM -0500, Benjamin Root wrote:
> On Tue, Jul 17, 2012 at 6:25 AM, todd rme <tod...@gm...> wrote:
> 
> > On Wed, Jul 11, 2012 at 5:23 PM, John Hunter <jd...@gm...> wrote:
> > >
> > >
> > > On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall
> > > <dam...@gm...> wrote:
> > >>
> > >> Well, as Ben said, that error fill plot is neato! It doesn't look too
> > >> complicated, either. I'd be more than happy to port it over later today
> > >> when I get bored of typing up my thesis. It'll probably only take me
> > >> about 30 minutes.
> > >>
> > >> If nobody is opposed to this idea, I'll go ahead and submit a PR this
> > >> evening (British Summer (hah!) Time).
> > >
> > >
> > >
> > > While it is a nice graph, I am not sure that the use case is common
> > enough
> > > to justify a new plotting method.  One can get the same result with:
> > >
> > >
> > >   In [68]: x = np.linspace(0, 2 * np.pi)
> > >
> > >   In [69]: y_sin = np.sin(x)
> > >
> > >   In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
> > >
> > >   In [71]: plot(x, y_sin)
> > >   Out[71]: [<matplotlib.lines.Line2D object at 0x96959ec>]
> > >
> > >   In [72]: fill_between(np.concatenate([x, x[::-1]]), err,
> > facecolor='red',
> > > alpha=0.5)
> > >   Out[72]: <matplotlib.collections.PolyCollection object at 0x962758c>
> > >
> > > Admittedly the [::-1] thing is a bit counter-intuitive, but rather than
> > > adding a new plotting method, perhaps we would be better off with a
> > helper
> > > method to create the xs and ys for fill_between
> > >
> > >   xs, ys = mlab.pad_line(x, y, 0.2)
> > >   fill_between(xs, ys)
> > >
> > > JDH
> >
> > What about adding a property to the existing errorbar to let someone
> > change it to the filled version?  This could also, potentially, be
> > extended with other types of error bars if the need arises.
> >
> > -Todd
> >
> 
> Intriguing idea.  I am actually quite comfortable with that.
> 

I like this idea, too.

> Ben Root

-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Tue, Jul 17, 2012 at 8:12 AM, Yannick Copin <yan...@la...>wrote:

> Hi List,
>
> Short question: is there any (simple) way to generate "spectral" images
> such as the ones in http://astro.u-strasbg.fr/~koppen/discharge/ ?
>
> Long version: say I have 1D-array l, which I would like to visualize as
> the L component of an HSL image, where the HS component would e.g. come
> from the standard "spectral" cmap (that's what I think I understood of
> the problem, but maybe what I said is just nonsense...). How should I
> proceed?
>
> Cheers,
>

I would utilize the ColorbarBase object.  It has a method "add_lines()"
where you could add black lines at the locations you want.

Cheers!
Ben Root

On Tue, Jul 17, 2012 at 6:25 AM, todd rme <tod...@gm...> wrote:

> On Wed, Jul 11, 2012 at 5:23 PM, John Hunter <jd...@gm...> wrote:
> >
> >
> > On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall
> > <dam...@gm...> wrote:
> >>
> >> Well, as Ben said, that error fill plot is neato! It doesn't look too
> >> complicated, either. I'd be more than happy to port it over later today
> >> when I get bored of typing up my thesis. It'll probably only take me
> >> about 30 minutes.
> >>
> >> If nobody is opposed to this idea, I'll go ahead and submit a PR this
> >> evening (British Summer (hah!) Time).
> >
> >
> >
> > While it is a nice graph, I am not sure that the use case is common
> enough
> > to justify a new plotting method.  One can get the same result with:
> >
> >
> >   In [68]: x = np.linspace(0, 2 * np.pi)
> >
> >   In [69]: y_sin = np.sin(x)
> >
> >   In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
> >
> >   In [71]: plot(x, y_sin)
> >   Out[71]: [<matplotlib.lines.Line2D object at 0x96959ec>]
> >
> >   In [72]: fill_between(np.concatenate([x, x[::-1]]), err,
> facecolor='red',
> > alpha=0.5)
> >   Out[72]: <matplotlib.collections.PolyCollection object at 0x962758c>
> >
> > Admittedly the [::-1] thing is a bit counter-intuitive, but rather than
> > adding a new plotting method, perhaps we would be better off with a
> helper
> > method to create the xs and ys for fill_between
> >
> >   xs, ys = mlab.pad_line(x, y, 0.2)
> >   fill_between(xs, ys)
> >
> > JDH
>
> What about adding a property to the existing errorbar to let someone
> change it to the filled version?  This could also, potentially, be
> extended with other types of error bars if the need arises.
>
> -Todd
>

Intriguing idea.  I am actually quite comfortable with that.

Ben Root

On Wed, Jul 11, 2012 at 5:23 PM, John Hunter <jd...@gm...> wrote:
>
>
> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall
> <dam...@gm...> wrote:
>>
>> Well, as Ben said, that error fill plot is neato! It doesn't look too
>> complicated, either. I'd be more than happy to port it over later today
>> when I get bored of typing up my thesis. It'll probably only take me
>> about 30 minutes.
>>
>> If nobody is opposed to this idea, I'll go ahead and submit a PR this
>> evening (British Summer (hah!) Time).
>
>
>
> While it is a nice graph, I am not sure that the use case is common enough
> to justify a new plotting method.  One can get the same result with:
>
>
>   In [68]: x = np.linspace(0, 2 * np.pi)
>
>   In [69]: y_sin = np.sin(x)
>
>   In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
>
>   In [71]: plot(x, y_sin)
>   Out[71]: [<matplotlib.lines.Line2D object at 0x96959ec>]
>
>   In [72]: fill_between(np.concatenate([x, x[::-1]]), err, facecolor='red',
> alpha=0.5)
>   Out[72]: <matplotlib.collections.PolyCollection object at 0x962758c>
>
> Admittedly the [::-1] thing is a bit counter-intuitive, but rather than
> adding a new plotting method, perhaps we would be better off with a helper
> method to create the xs and ys for fill_between
>
>   xs, ys = mlab.pad_line(x, y, 0.2)
>   fill_between(xs, ys)
>
> JDH

What about adding a property to the existing errorbar to let someone
change it to the filled version?  This could also, potentially, be
extended with other types of error bars if the need arises.

-Todd