matplotlib-users Mailing List for matplotlib

Pythonified wrote:
> 
> I have been trying to assign different colors for each line I plot, where
> the colors are incrementally darkened (or lightened), or selected from a
> colorbar (e.g. rainbow).
> 
> Any ideas?
> 

I have found a simple and better way. One can chose from colors from a color
map:

>>import pylab as pl
>>import matplotlib.cm as cm
>>xval = pl.arange(0, 20, 0.2)
>>for i in range(256):
     ...  pl.plot(xval, pl.sin(xval)+i, c=cm.hot(i), lw=5)

This one if, for instance, picking from a color map called "hot". If one
wants to the colors to fade away, or darken, the "alpha" option can be
utilized or another color map in which colors darken or fade into another
color.

There is no need for a long sophisticated script.

Enjoy,
Pythonified

-- 
View this message in context: http://old.nabble.com/incremental-colors-for-lines-tp31546719p31581404.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Thu, Sep 30, 2010 at 7:55 AM, Jae-Joon Lee <lee...@gm...> wrote:
> On Thu, Sep 23, 2010 at 10:31 AM, C M <cmp...@gm...> wrote:
>> Until a more permanent solution is figured out, can anyone recommend
>> any workarounds, even if they are a little clunky?  I'm embedding mpl
>> plots in wxPython and am also finding this issue suboptimal.
>>
>> Che
>>
>
> A (partial) workaround is possible using the axes_grid1 toolkit (i.e.,
> you need matplotlib 1.0).
> Attached is a module I just cooked up (based on my previous attempt @
> http://www.mail-archive.com/mat...@li.../msg18129.html),
> and it seems to work quite well.
> The usage is simple.
>
>
>        ax = plt.axes([0,0,1,1])
>
>        ax.set_yticks([0.5])
>        ax.set_yticklabels(["very long label"])
>
>        make_axes_area_auto_adjustable(ax) # This is where axes_grid1 comes in
>
> Then, the axes area(including ticklabels and axis label) will be
> automatically adjusted to fit in the given extent ([0, 0, 1, 1] in the
> above case).
>
> While this is mainly for a single axes plot, you may use it with
> multi-axes plot (but somewhat trickier to use). A few examples are
> included in the module.
>

Although this has been a big improvement, there is a lingering issue
that I want to get around to cleaning up now.

When I use this workaround that Jae Joon provided, it works just fine
except that if I call canvas.draw() (because I am adding a star to a
particular marker when point picking), it causes the whole canvas to
"jump" a little bit.

What happens is that on the first call to .draw() the plot area
increases vertically a tiny amount and the title moves up slightly.
On subsequent calls, the plot surface doesn't increase vertically but
the title text moves slightly up and then down quickly.  This happens
each time I point pick for the first 5 or so times, and then it stops
doing it.  I don't even have to add any new points to the plot, just
call canvas.draw() and it will do this.

It is visually distracting and a look and feel demerit for the app for sure.

I've tried to make a sample that is not embedded in wxPython but so
far I can't reproduce the problem.

Jae Joon or anyone, any ideas about why this is occurring and how to
prevent it?  If need be I will try to work up a sample that
demonstrates it, but so far I've failed in that.

Thanks,
Che

Hello Eric,

Thanks to you, the problem is resolved! 

> No, I don't think this is a bug in matplotlib; there are many mpl users, 
> and at least to some extent some devs, who use Macs, so if this were a 
> general bug in 1.0.1 it would have turned up long ago.  
Since you were convinced that mpl is not buggy, I decided to look at EPD. However, before that, and for the record, yes, I did try running your commands by saving them to a file and by invoking 
$Python foo.py 
in my bash shell (where Python was the 64-bit python or path to the 32-bit python). This still caused the crashes, and may not have helped in locating the actual snag.

> Similarly, I  doubt it is the case that EPD is simply broken.  I would be surprised if 
> Enthought did not test EPD versions prior to release! 
There is a very recent thread in epd-users that is similar in flavor to my problem https://mail.enthought.com/pipermail/epd-users/2011-May/000379.html. As in that thread, I too had my DYLD_LIBRARY_PATH set to something in .profile, in my case simply /usr/local/lib. I do not know whether I set it (possibly for CVXOPT to work) or whether an earlier version of EPD installer or some other installer added it. In any case, not having it defined solved my problem (at least this one; don't know if it would break something else though!).

By the way, I know that this particular environment variable has been around in my .profile for quite some time now, so I suspect that something changed in EPD 7.0-2 that causes the trouble (does not appear evident from their change log though). Again, for the record, less than three weeks ago, on EPD 7.0-1, everything was working smoothly. Also, I shall bring this discussion to the attention of those in the epd-users' thread. 

Thanks again! 

-Kaushik

On 05/08/2011 11:42 AM, Kaushik Kalyanaraman wrote:
> Hello Eric,
>
> Thanks for your reply and suggestions!
>
>> Do you see the problem with any plot at all? E.g.,
> <snip>
>> Can you eliminate all traces of EPD, and then just cleanly install one version, and see if the problem still appears?
>
> I cleanly installed EPD. Now, with only a single version (EPD 7.0-2, Python 2.7.1), I find that, interestingly,
>
> a) In the 32-bit version (both when independent of and concurrent with 64-bit EPD), simply calling plot() crashes Python, both in bash and IPython shells.
> b) In the 64-bit version, plot() goes through and creates the correct plot window but savefig() causes a crash when attempting to save in any format (pdf, ps, svg, png).
>
> As in my original mail the error messages echoed to terminal are "Abort trap" and "Bus error" for 64-bit and 32-bit versions, respectively.
>
> Thus, I wish to believe that there is some bug in matplotlib which is possibly not local to savefig() alone (at least for the 32-bit version). In this regard, I wish to request you as well as list members to advise me as to whether I should use version 1.0.0 ? If so, should I build from source or can I simply use the disk image file (and have it easy!) if I wish to replace the EPD bundled matplotlib ?
>

No, I don't think this is a bug in matplotlib; there are many mpl users, 
and at least to some extent some devs, who use Macs, so if this were a 
general bug in 1.0.1 it would have turned up long ago.  Similarly, I 
doubt it is the case that EPD is simply broken.  I would be surprised if 
Enthought did not test EPD versions prior to release! Most likely there 
is something out of the ordinary about your particular system that is 
causing the problem; there is still a version conflict or corrupted file 
somewhere.

Did you try saving the code snippet in my last message to a file, and 
running it?  The point of it was to eliminate the use of an interactive 
backend.

I don't have any more ideas; maybe someone else can suggest the next 
troubleshooting steps.

Eric

> Thanks and Regards,
> Kaushik
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users