I want to specify my own color cycle in matplotlibrc. I know I can do in
the actual script:
matplotlib.axes.set_default_color_cycle(['w', 'w', 'w', 'w', 'w', 'w', 'w'])
but it renders my scripts not portable (if somebody does not have black
bg in matplotlibrc as I do then he will not see the plot).
(How) Can I specify my color cycle in matplotlibrc - or another portable
fashion? Or at least disable it so the lines.color is used for all colors?
Dominik
OK I started hacking and added a color_cycle property to matplotlibrc.
Would you be so kind to add this fix to the official version? Thanks!
Dominik
$ diff -w axes.py axes.py.org
135,137c135
< # DSZ take defaultColors from rcParams
< # defaultColors = ['b','g','r','c','m','y','k']
< defaultColors = rcParams['axes.color_cycle']
- ---
defaultColors = ['b','g','r','c','m','y','k']
$ diff -w rcsetup.py rcsetup.py.org
442,443d441
< # DSZ add color_cycle property
< 'axes.color_cycle' : [['b','g','r','c','m','y','k'],
validate_stringlist],
Add to custom matplotlibrc as e.g.:
axes.color_cycle : w, w, w, w, w, w, w
Dominik Szczerba wrote:
I want to specify my own color cycle in matplotlibrc. I know I can do in
the actual script:matplotlib.axes.set_default_color_cycle(['w', 'w', 'w', 'w', 'w', 'w', 'w'])
but it renders my scripts not portable (if somebody does not have black
bg in matplotlibrc as I do then he will not see the plot).(How) Can I specify my color cycle in matplotlibrc - or another portable
fashion? Or at least disable it so the lines.color is used for all colors?Dominik
-
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Hey Dominik,
I’d also like to see the default color_cycle be customizeable. But, if I’m not mistaken, this approach doesn’t quite do what you want (at least it doesn’t on a recent version of mpl). The problem is that the color given by lines.color (rcParam) sort of overrides the first color in the specified color cycle (see _process_plot_var_args._clear_color_cycle in axes.py).
It seems important for lines.color and the first color in the color cycle to match since this matching is also enforced in axes.set_default_color_cycle, except in reverse (the first color in the color cycle overrides line.color). If both lines.color and axes.color_cycle (or maybe lines.color_cycle) are rcParams, there would be issues with how to match the two (e.g. which takes precedence if they differ).
As I said earlier, I’d like to see this change made, but I think it may change the current behavior. Maybe a mpl developer could weigh in?
-Tony
On Dec 24, 2009, at 4:21 AM, Dominik Szczerba wrote:
OK I started hacking and added a color_cycle property to matplotlibrc.
Would you be so kind to add this fix to the official version? Thanks!
Dominik$ diff -w axes.py axes.py.org
135,137c135
< # DSZ take defaultColors from rcParams
< # defaultColors = [‘b’,‘g’,‘r’,‘c’,‘m’,‘y’,‘k’]
< defaultColors = rcParams[‘axes.color_cycle’]
defaultColors = [‘b’,‘g’,‘r’,‘c’,‘m’,‘y’,‘k’]
$ diff -w rcsetup.py rcsetup.py.org
442,443d441
< # DSZ add color_cycle property
< ‘axes.color_cycle’ : [[‘b’,‘g’,‘r’,‘c’,‘m’,‘y’,‘k’],
validate_stringlist],Add to custom matplotlibrc as e.g.:
axes.color_cycle : w, w, w, w, w, w, w
Tony S Yu wrote:
OK I started hacking and added a color_cycle property to matplotlibrc.
Would you be so kind to add this fix to the official version? Thanks!
Dominik$ diff -w axes.py axes.py.org <http://axes.py.org>
135,137c135
< # DSZ take defaultColors from rcParams
< # defaultColors = ['b','g','r','c','m','y','k']
< defaultColors = rcParams['axes.color_cycle']
- ---defaultColors = ['b','g','r','c','m','y','k']
$ diff -w rcsetup.py rcsetup.py.org <http://rcsetup.py.org>
442,443d441
< # DSZ add color_cycle property
< 'axes.color_cycle' : [['b','g','r','c','m','y','k'],
validate_stringlist],Add to custom matplotlibrc as e.g.:
axes.color_cycle : w, w, w, w, w, w, w
Hey Dominik,
I'd also like to see the default color_cycle be customizeable. But, if
I'm not mistaken, this approach doesn't quite do what you want (at least
it doesn't on a recent version of mpl). The problem is that the color
given by lines.color (rcParam) sort of overrides the first color in the
specified color cycle (see
``_process_plot_var_args._clear_color_cycle`` in axes.py).It seems important for lines.color and the first color in the color
cycle to match since this matching is also enforced in
``axes.set_default_color_cycle``, except in reverse (the first color in
the color cycle overrides line.color). If both lines.color and
axes.color_cycle (or maybe lines.color_cycle) are rcParams, there would
be issues with how to match the two (e.g. which takes precedence if they
differ).As I said earlier, I'd like to see this change made, but I think it may
change the current behavior. Maybe a mpl developer could weigh in?-Tony
Hi Tony,
You are correct, line color overrides the first cycle color. That does
not appear a very happy choice to me but this way or another you can
still specify BOTH lines.color and the cycle in the param file to get
whatever you want, no?
Dominik
On Dec 24, 2009, at 4:21 AM, Dominik Szczerba wrote:
Yup, that should do exactly what you want. But, since it's a bit of a hack (you should only need to make 1 change to matplotlibrc), I doubt this patch would be appropriate for the main distribution.
Ideally, we'd need to figure out if the matplotlibrc changes 1) only lines.color and make this the first color in color_cycle, 2) only lines.color_cycle and make the first color override lines.color, or 3) both lines.color and lines.color_cycle (behavior unknown if colors don't match). Unfortunately, I don't see an easy way to tell if rcParams have been changed from their default values.
Actually, the best case IMO, would be if lines.color was deprecated and lines.color_cycle[0] (or maybe lines.colors[0]) was used in its place. However, this change breaks compatibility.
-Tony
On Dec 29, 2009, at 3:35 AM, Dominik Szczerba wrote:
Tony S Yu wrote:
Hey Dominik,
I'd also like to see the default color_cycle be customizeable. But, if
I'm not mistaken, this approach doesn't quite do what you want (at least
it doesn't on a recent version of mpl). The problem is that the color
given by lines.color (rcParam) sort of overrides the first color in the
specified color cycle (see
``_process_plot_var_args._clear_color_cycle`` in axes.py).It seems important for lines.color and the first color in the color
cycle to match since this matching is also enforced in
``axes.set_default_color_cycle``, except in reverse (the first color in
the color cycle overrides line.color). If both lines.color and
axes.color_cycle (or maybe lines.color_cycle) are rcParams, there would
be issues with how to match the two (e.g. which takes precedence if they
differ).As I said earlier, I'd like to see this change made, but I think it may
change the current behavior. Maybe a mpl developer could weigh in?-Tony
Hi Tony,
You are correct, line color overrides the first cycle color. That does
not appear a very happy choice to me but this way or another you can
still specify BOTH lines.color and the cycle in the param file to get
whatever you want, no?Dominik
Tony S Yu wrote:
Tony S Yu wrote:
Hey Dominik,
I'd also like to see the default color_cycle be customizeable. But, if
I'm not mistaken, this approach doesn't quite do what you want (at least
it doesn't on a recent version of mpl). The problem is that the color
given by lines.color (rcParam) sort of overrides the first color in the
specified color cycle (see
``_process_plot_var_args._clear_color_cycle`` in axes.py).It seems important for lines.color and the first color in the color
cycle to match since this matching is also enforced in
``axes.set_default_color_cycle``, except in reverse (the first color in
the color cycle overrides line.color). If both lines.color and
axes.color_cycle (or maybe lines.color_cycle) are rcParams, there would
be issues with how to match the two (e.g. which takes precedence if they
differ).As I said earlier, I'd like to see this change made, but I think it may
change the current behavior. Maybe a mpl developer could weigh in?-Tony
Hi Tony,
You are correct, line color overrides the first cycle color. That does
not appear a very happy choice to me but this way or another you can
still specify BOTH lines.color and the cycle in the param file to get
whatever you want, no?Dominik
Yup, that should do exactly what you want. But, since it's a bit of a hack (you should only need to make 1 change to matplotlibrc), I doubt this patch would be appropriate for the main distribution.
Ideally, we'd need to figure out if the matplotlibrc changes 1) only lines.color and make this the first color in color_cycle, 2) only lines.color_cycle and make the first color override lines.color, or 3) both lines.color and lines.color_cycle (behavior unknown if colors don't match). Unfortunately, I don't see an easy way to tell if rcParams have been changed from their default values.
Hi Tony,
My patches (there were two!) remove the badly hardcoded definition of
defaultColors in axes.py and instead define default axes.color_cycle in
rcsetup.py (defaulting it to the already established color array
['b','g','r','c','m','y','k']). Now, in axes.py, defaultColors are taken
from rcParams, and not a hardcoded array, so unless you modify your own
rc file, you will get the old behavior. It is if and only if you define
your color_cycle in your own rc file that will do anything new. I do not
see how this introduces any incompatibilities.
Dominik
On Dec 29, 2009, at 3:35 AM, Dominik Szczerba wrote:
Actually, the best case IMO, would be if lines.color was deprecated and lines.color_cycle[0] (or maybe lines.colors[0]) was used in its place. However, this change breaks compatibility.
-Tony
Tony S Yu wrote:
Tony S Yu wrote:
Hey Dominik,
I’d also like to see the default color_cycle be customizeable. But, if
I’m not mistaken, this approach doesn’t quite do what you want (at least
it doesn’t on a recent version of mpl). The problem is that the color
given by lines.color (rcParam) sort of overrides the first color in the
specified color cycle (see
_process_plot_var_args._clear_color_cyclein axes.py).It seems important for lines.color and the first color in the color
cycle to match since this matching is also enforced in
axes.set_default_color_cycle, except in reverse (the first color in
the color cycle overrides line.color). If both lines.color and
axes.color_cycle (or maybe lines.color_cycle) are rcParams, there would
be issues with how to match the two (e.g. which takes precedence if they
differ).As I said earlier, I’d like to see this change made, but I think it may
change the current behavior. Maybe a mpl developer could weigh in?-Tony
Hi Tony,
You are correct, line color overrides the first cycle color. That does
not appear a very happy choice to me but this way or another you can
still specify BOTH lines.color and the cycle in the param file to get
whatever you want, no?Dominik
Yup, that should do exactly what you want. But, since it’s a bit of a hack (you should only need to make 1 change to matplotlibrc), I doubt this patch would be appropriate for the main distribution.
Ideally, we’d need to figure out if the matplotlibrc changes 1) only lines.color and make this the first color in color_cycle, 2) only lines.color_cycle and make the first color override lines.color, or 3) both lines.color and lines.color_cycle (behavior unknown if colors don’t match). Unfortunately, I don’t see an easy way to tell if rcParams have been changed from their default values.
Hi Tony,
My patches (there were two!) remove the badly hardcoded definition of
defaultColors in axes.py and instead define default axes.color_cycle in
rcsetup.py (defaulting it to the already established color array
[‘b’,‘g’,‘r’,‘c’,‘m’,‘y’,‘k’]). Now, in axes.py, defaultColors are taken
from rcParams, and not a hardcoded array, so unless you modify your own
rc file, you will get the old behavior. It is if and only if you define
your color_cycle in your own rc file that will do anything new. I do not
see how this introduces any incompatibilities.
Dominik
Sorry for the confusion. I wasn’t saying your patches introduce incompatibilities, but I did say that their behavior is not ideal. For example, your matplotlibrc requires both “lines.color_cycle : w, w, w, w, w, w” (actually I think you only need one “w,”) and “lines.color : w”. Ideally (at least IMO), I should only need to set the color cycle, and it was surprising to me (surprises = bad) that I’d have to also set “lines.color”
The incompatibilities I spoke of would only be true if you went with my suggestion to deprecate “lines.color”.
-T
On Dec 29, 2009, at 3:35 AM, Dominik Szczerba wrote:
Tony S Yu wrote:
Tony S Yu wrote:
Tony S Yu wrote:
Hey Dominik,
I'd also like to see the default color_cycle be customizeable. But, if
I'm not mistaken, this approach doesn't quite do what you want (at
least
it doesn't on a recent version of mpl). The problem is that the color
given by lines.color (rcParam) sort of overrides the first color in the
specified color cycle (see
``_process_plot_var_args._clear_color_cycle`` in axes.py).It seems important for lines.color and the first color in the color
cycle to match since this matching is also enforced in
``axes.set_default_color_cycle``, except in reverse (the first color in
the color cycle overrides line.color). If both lines.color and
axes.color_cycle (or maybe lines.color_cycle) are rcParams, there would
be issues with how to match the two (e.g. which takes precedence if
they
differ).As I said earlier, I'd like to see this change made, but I think it may
change the current behavior. Maybe a mpl developer could weigh in?-Tony
Hi Tony,
You are correct, line color overrides the first cycle color. That does
not appear a very happy choice to me but this way or another you can
still specify BOTH lines.color and the cycle in the param file to get
whatever you want, no?Dominik
Yup, that should do exactly what you want. But, since it's a bit of a
hack (you should only need to make 1 change to matplotlibrc), I doubt
this patch would be appropriate for the main distribution.Ideally, we'd need to figure out if the matplotlibrc changes 1) only
lines.color and make this the first color in color_cycle, 2) only
lines.color_cycle and make the first color override lines.color, or
3) both lines.color and lines.color_cycle (behavior unknown if colors
don't match). Unfortunately, I don't see an easy way to tell if
rcParams have been changed from their default values.Hi Tony,
My patches (there were two!) remove the badly hardcoded definition of
defaultColors in axes.py and instead define default axes.color_cycle in
rcsetup.py (defaulting it to the already established color array
['b','g','r','c','m','y','k']). Now, in axes.py, defaultColors are taken
from rcParams, and not a hardcoded array, so unless you modify your own
rc file, you will get the old behavior. It is if and only if you define
your color_cycle in your own rc file that will do anything new. I do not
see how this introduces any incompatibilities.
DominikSorry for the confusion. I wasn't saying your patches introduce
incompatibilities, but I did say that their behavior is not ideal. For
example, your matplotlibrc requires *both* "lines.color_cycle : w, w, w,
w, w, w" (actually I think you only need one "w,") *and* "lines.color :
w". Ideally (at least IMO), I should only need to set the color cycle,
and it was surprising to me (surprises = bad) that I'd have to also set
"lines.color"
True, in this context my solution is not ideal indeed, but the current
solution is dramatic: it forces one to use black on white color scheme,
else the colors are very poorly visible. Setting them in the user script
ruins the portability.
Most people will probably not care, therefore I believe my solution is
optimal. I have to work with black background, and I am sure those like
me will bother to add two extra lines to the rc file.
Dominik
On Dec 29, 2009, at 3:35 AM, Dominik Szczerba wrote:
The incompatibilities I spoke of would only be true if you went with my
suggestion to deprecate "lines.color".-T
Dominik Szczerba wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1OK I started hacking and added a color_cycle property to matplotlibrc.
Would you be so kind to add this fix to the official version? Thanks!
Dominik
Your basic idea--that the colorcycle should be settable in rcParams--makes good sense, but the implementation needs some changes, maybe including a bit of redesign of the color cycle handling. I will look into it. A little discussion on the devel list may be required. I think we will want to completely decouple lines.color from a new lines.colorcycle, but maybe there is some good reason, other than history, for why they are coupled.
Eric
$ diff -w axes.py axes.py.org
135,137c135
< # DSZ take defaultColors from rcParams
< # defaultColors = ['b','g','r','c','m','y','k']
< defaultColors = rcParams['axes.color_cycle']
- ---defaultColors = ['b','g','r','c','m','y','k']
$ diff -w rcsetup.py rcsetup.py.org
442,443d441
< # DSZ add color_cycle property
< 'axes.color_cycle' : [['b','g','r','c','m','y','k'],
validate_stringlist],Add to custom matplotlibrc as e.g.:
axes.color_cycle : w, w, w, w, w, w, w
Dominik Szczerba wrote:
I want to specify my own color cycle in matplotlibrc. I know I can do in
the actual script:matplotlib.axes.set_default_color_cycle(['w', 'w', 'w', 'w', 'w', 'w', 'w'])
but it renders my scripts not portable (if somebody does not have black
bg in matplotlibrc as I do then he will not see the plot).(How) Can I specify my color cycle in matplotlibrc - or another portable
fashion? Or at least disable it so the lines.color is used for all colors?Dominik
-
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)iEYEARECAAYFAkszMqcACgkQ/EBMh9bUuzJIigCgryC7tOPPkWkjjE/6/OTvLiiH
OUMAoIsGCWSAC6AO3F12Rv5yQN6tMQkL
=Ch5N
-----END PGP SIGNATURE-----------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev _______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
One nice thing about gnuplot is the option its GUI provides to toggle between using coloured lines and using black lines with various dashed patterns. I think it would be nice in matplotlib to also be able to have a default series of dashed patterns that could automatically be cycled through.
Gary R
Eric Firing wrote:
Dominik Szczerba wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1OK I started hacking and added a color_cycle property to matplotlibrc.
Would you be so kind to add this fix to the official version? Thanks!
DominikYour basic idea--that the colorcycle should be settable in rcParams--makes good sense, but the implementation needs some changes, maybe including a bit of redesign of the color cycle handling. I will look into it. A little discussion on the devel list may be required. I think we will want to completely decouple lines.color from a new lines.colorcycle, but maybe there is some good reason, other than history, for why they are coupled.
Eric Firing wrote:
Dominik Szczerba wrote:
OK I started hacking and added a color_cycle property to matplotlibrc.
Would you be so kind to add this fix to the official version? Thanks!
DominikYour basic idea--that the colorcycle should be settable in
rcParams--makes good sense, but the implementation needs some changes,
maybe including a bit of redesign of the color cycle handling. I will
look into it. A little discussion on the devel list may be required. I
think we will want to completely decouple lines.color from a new
lines.colorcycle, but maybe there is some good reason, other than
history, for why they are coupled.
Hi Eric,
That's great. I would be happy if a final conclusion from the devel list
could be forwarded here as well.
Thanks,
Dominik
Eric
$ diff -w axes.py axes.py.org
135,137c135
< # DSZ take defaultColors from rcParams
< # defaultColors = ['b','g','r','c','m','y','k']
< defaultColors = rcParams['axes.color_cycle']
---defaultColors = ['b','g','r','c','m','y','k']
$ diff -w rcsetup.py rcsetup.py.org
442,443d441
< # DSZ add color_cycle property
< 'axes.color_cycle' : [['b','g','r','c','m','y','k'],
validate_stringlist],Add to custom matplotlibrc as e.g.:
axes.color_cycle : w, w, w, w, w, w, w
Dominik Szczerba wrote:
I want to specify my own color cycle in matplotlibrc. I know I can do in
the actual script:matplotlib.axes.set_default_color_cycle(['w', 'w', 'w', 'w', 'w', 'w', 'w'])
but it renders my scripts not portable (if somebody does not have black
bg in matplotlibrc as I do then he will not see the plot).(How) Can I specify my color cycle in matplotlibrc - or another portable
fashion? Or at least disable it so the lines.color is used for all colors?Dominik
-
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Dominik Szczerba wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Eric Firing wrote:
Dominik Szczerba wrote:
OK I started hacking and added a color_cycle property to matplotlibrc.
Would you be so kind to add this fix to the official version? Thanks!
DominikYour basic idea--that the colorcycle should be settable in rcParams--makes good sense, but the implementation needs some changes, maybe including a bit of redesign of the color cycle handling. I will look into it. A little discussion on the devel list may be required. I think we will want to completely decouple lines.color from a new lines.colorcycle, but maybe there is some good reason, other than history, for why they are coupled.
Hi Eric,
That's great. I would be happy if a final conclusion from the devel list
could be forwarded here as well.
Thanks,
Dominik
Dominik,
I added rcParams support for the color cycle to svn, but a line style cycle remains at the level of a suggestion.
Eric
I'm happy for it to remain just a suggestion and not a reality. I mentioned it in case it was easy to implement alongside the color cycle but it seems it is not. Thanks for considering it anyway Eric,
Gary
Eric Firing wrote:
Dominik Szczerba wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Eric Firing wrote:
Dominik Szczerba wrote:
OK I started hacking and added a color_cycle property to matplotlibrc.
Would you be so kind to add this fix to the official version? Thanks!
Dominik