matplotlib-devel Mailing List for matplotlib (Page 20)

Hi Nathaniel,


> > Basically, it allows you to pick the start/end color of a colormap from
> two
> > cross sections in CIELab space and interpolates those colors linearly
> (see
> > the README file for more details).
>
> There's a downside to this approach for the kinds of colormaps we've
> been talking about in this thread, where we want both a large
> lightness range plus a colorful result. The problem is that the way
> color space is shaped, you can't simultaneously have both high
> saturation (colorfulness) *and* high/low lightness. So if you pick
> your extreme points to be near black and white, then they can only
> have a slight tinting of color, and then if you linearly interpolate
> between these, then you end up with slightly tinted greyscale.
>

You raise an excellent point here. It explains nicely what I have
experienced while playing with my GUI. Indeed, I found that a simple linear
interpolation did not result in totally satisfactory colormaps (see my
previous reply to Federico). I couldn't quite explain why, but your
explanation makes this clear.

One exception I encountered is an interpolation between dark blue and
yellow as in the attached screenshot (which I hope makes it through to the
mailing list) - probably because it mostly avoids the low-saturation
(grey-ish) region of the color space. But I agree with you that using a
curved, rather than linear, interpolation can probably yield better results.

It sounds like you have a good deal of experience with various color spaces
and colormaps. Do you have an idea for a good "recipe" how to pick a curve
in a given colorspace that leads to a satisfactory colormap? My first idea
was to change the interpolating line to a circular arc passing through an
"intermediate" color, but it's not clear to me whether there is any
preferred "direction" for nudging the line into an arc. Also, most other
colormaps, such as the examples "YlGnBu" and "cubehelix" which you
mentioned, use more complicated curves than mere circular arcs (btw, kudos
for your script - it's a great way of visualising these colormaps). I don't
have enough knowledge yet to decide whether either approach is better. I've
started toying with curved interpolations in my code but this is not quite
ready to be pushed to Github yet. Anyway, if you have any suggestions I'd
love to hear them.

I also found a few more blog posts and papers which I hadn't seen before
and which look extremely useful:

(i) "Subtleties of color"

http://earthobservatory.nasa.gov/blogs/elegantfigures/2013/08/05/subtleties-of-color-part-1-of-6/

A series of six blog posts with an excellent introduction to color theory
and the issues around choosing colormaps. Well worth a read! It also
suggests that CIE L*c*h* space (which uses the three variables lightness,
chroma (saturation) and hue), may be a better choice than CIE L*a*b*, which
I have been using so far.


(ii) "How To Avoid Equidistant HSV Colors"
http://vis4.net/blog/posts/avoid-equidistant-hsv-colors/

Blog post with some interactive tools to visualise sections of CIE L*a*b*
space and HCL (Hue-Chroma-Lightness) space.

Here is a nice standalone version of the second tool:
http://tristen.ca/hcl-picker/#/hlc/6/1/1B2531/E5FC74


(iii) "Generating Color Palettes using Intuitive Parameters"
http://magnaview.nl/documents/MagnaView-M_Wijffelaars-Generating_color_palettes_using_intuitive_parameters.pdf

Excellent-looking paper on the subject. I haven't read it in full yet but
it looks like a great resource which might answer some of my questions
above.


At this stage I'm wondering how best to proceed. There seems to be huge
number of resources and information, but we don't really have a clear path
forward. I agree with Phil Elson's assessment when I talked to him at the
Open Source Day: what we need is for someone to make a suggestion for a
colormap and list a number of reasons why this particular one should be
chosen. Then we have a basis for discussion and can argue about it. If
anybody has such a suggestion yet, it would be great to hear about it (even
if it is not perfect). Otherwise I'll try to make one once I have explored
various options a bit more (although it may take a little while as my spare
time is rather limited at the moment).

Best wishes,
Max

Hi Federico,

Thanks for trying it out and for the feedback!

Indeed, I started out writing a simple IPython notebook along the lines you
suggested, with just a couple of sliders and plots, but it quickly became
too slow and unwieldy for quick explorations, hence the slightly more
elaborate GUI.

I agree that the reason for the 3D plot on the right may not be obvious at
the moment. Personally, I find it useful to get a feel for what the
representable colors in CIELab space (and the cross sections for L=const)
look like, but when simply using a linear interpolation between two colors
(as I'm doing at the moment) it may not be needed to visualise it in 3D.

The reason I added it is that while playing around with the GUI I got the
impression that my initial suggestion of using a simple linear
interpolation between two colors may not result in the best-looking
colormaps (this is confirmed by Nathaniel's reply). I'm currently toying
with the option to use curved interpolations, and for thee it would be very
useful IMHO to see what they look like in 3D.

Btw, I have refactored my code a bit and it should be easy to write a
simpler UI (e.g. in an IPython notebook) which doesn't need the other
dependencies (also, I could drop the wxpython dependency because some
conflict with Vispy which I had experienced seems to have disappeared). If
you like, feel free to give it a shot to write a UI the way you imagine it.
It's always good to have more options for exploration. :)

Best wishes,
Max


2015-01-08 17:44 GMT+00:00 Federico Ariza <ari...@gm...>:

> Nice job.
>
> I find your GUI a little bit confusing (new to colormap stuff) but I
> like the idea, basically I find it overkill, I would replace the gui
> by a plot and a couple of slider widgets something simpler to
> integrate without new dependencies.
> Do you really need the third 3d plot on the right?
>
> On Mon, Jan 5, 2015 at 9:37 PM, Maximilian Albert
> <max...@gm...> wrote:
> > Happy new year everyone!
> >
> > Apologies for the long silence. I was snowed in with work before
> Christmas
> > and then mostly cut off from the internet for the past two weeks.
> > Fortunately, I had a chance over the holidays to flesh out the GUI which
> I
> > mentioned in my previous email. You can find it here:
> >
> >    https://github.com/maxalbert/colormap-selector
> >
> > Basically, it allows you to pick the start/end color of a colormap from
> two
> > cross sections in CIELab space and interpolates those colors linearly
> (see
> > the README file for more details). Currently there is one scatterplot to
> > illustrate the resulting colormap but it can be trivially extended to
> show
> > more interesting sample plots. There are still a few things missing that
> I'd
> > like to add but at least it's in a state where it can be used and I'd be
> > grateful for feedback, especially with regard to the colormaps generated
> > with it (I do have some opinions myself but it would be interesting to
> hear
> > others' first).
> >
> > Regarding our ongoing discussion, I had a very useful chat with two
> > colleagues before Christmas which spurred more thoughts. But I guess it's
> > best to discuss them in a separate email when I'm less tired. ;)
> >
> > Best wishes,
> > Max
> >
> >
> ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming! The Go Parallel Website,
> > sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> > hub for all things parallel software development, from weekly thought
> > leadership blogs to news, videos, case studies, tutorials and more. Take
> a
> > look and join the conversation now. http://goparallel.sourceforge.net
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
> --
> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>
> -- Antonio Alducin --
>

Let's say we want a time zone aware date time converter.  The basic goal is to convert some input type (datetime) to the MPL internal type (float days past Jan 0, 0001).  We also need to tell MPL how to format the axis (default formatter, locator, limits, label).



- The convert() method takes the input type (datetime) and the xunits (or yunits) keyword argument and converts it to the MPL type.  The axis input can be used to change the results depending on the plot type (polar plots always require radians for example).  For the TZ converter, would take the input value (datetime), convert it to the time zone requested by the units input, then convert that to a float using dates.date2num().  Note that the input can be a sequence or a single value so the converter has to handle both cases.



- The axisinfo() method is used to provide the default axis locator and formatter objects when the user creates a plot with this type.  The axis input is useful here to handle the result differently for a polar plot.  For the TZ converter, this would be exactly the same as the web docs - return the default locator and formatter for dates.  Most of the time this method can just return standard MPL formatters and locators (for either dates or numbers).



- The default_units() method provides a default value for the xunits or yunits keyword argument if one isn't specified.  The default in this case might be "UTC".



Hope that helps some, if you have more specific questions feel free to send them to me.



Ted



________________________________
From: Thomas Caswell [tca...@gm...]
Sent: Thursday, January 08, 2015 11:14 AM
To: Drain, Theodore R (392P); mat...@li...
Subject: Re: [matplotlib-devel] Date overhaul?

I was hoping for something a bit more extensive of the intenals.  I have tried to understand the units code a couple of times now and always hit a brick wall.

On Thu Jan 08 2015 at 2:07:02 PM Drain, Theodore R (392P) <the...@jp...<mailto:the...@jp...>> wrote:

Google search "matplotlib units" yields: http://matplotlib.org/api/units_api.html



So it sounds like the update is to make MPL's internal date system higher resolution which would be great.   We would just need to update our converters to convert to that format instead of the current floating point format.  Our custom classes are not public (and can't really be made public) but they aren't very complicated so we can certainly talk about the implementation if that helps.



________________________________
From: Thomas Caswell [tca...@gm...<mailto:tca...@gm...>]
Sent: Thursday, January 08, 2015 10:57 AM
To: Drain, Theodore R (392P); mat...@li...<mailto:mat...@li...>

Subject: Re: [matplotlib-devel] Date overhaul?
One of the other driving factors to over-haul the default date handling is that floats do not have enough precision to deal with nano-second resolution data (which is what I think drove pandas to use datetime64).

It sounds like the correct solution

Is the unit framework documented anywhere and are those custom classes public?

Tom

On Thu Jan 08 2015 at 12:59:17 PM Drain, Theodore R (392P) <the...@jp...<mailto:the...@jp...>> wrote:

I agree w/ the original poster that it would help to have a MEP to clearly define what the goals of the overhaul are



Something else to keep in mind: we at least don't normally plot dates in "earth" based time systems.  ~10 years ago we contracted with John Hunter to add the arbitrary unit system to MPL.  This allows users to plot in their own data types and define a converter to handle the conversion to MPL types and labeling.  We have our own "date time" like class which handles relativistic time scales (TDB, TT, TAI, GPS, Mars time, etc) at extremely high precision.  We register a unit converter w/ MPL which allows our users to plot these types natively and use the xunits keyword (or yunits) to control how the plot looks.  So we can do this:



plot( x, y, xunits="GPS", yunits="km/s" )

plot( x, y, xunits="PST", yunits="mph" )



It would also be pretty easy to add a time zone aware unit converter with the existing MPL code which would allow you to do things w/ datetime like this:



plot( x, y, xunits="UTC+8" )

plot( x, y, xunits="EST" )



I guess the point of this is to remind folks that not everyone plots dates in time zone based systems...



Ted



________________________________
From: Chris Barker [chr...@no...<mailto:chr...@no...>]
Sent: Thursday, January 08, 2015 9:00 AM
To: mat...@li...<mailto:mat...@li...>
Subject: Re: [matplotlib-devel] Date overhaul?

On Thu, Jan 8, 2015 at 7:04 AM, Skip Montanaro <sk...@po...<mailto:sk...@po...>> wrote:
I'm real naive about this stuff, but I have always wondered why
matplotlib didn't just use datetime objects, or at least use
timezone-aware datetime objects as an "interchange" format to get the
timezone stuff right.

Time zone handling is a pain in the %}€*

And the definitions keep changing.

So you need a complex DB and library that needs frequent updating.

This is why neither the standard library nor numpy support time zone handling out of the box.

But the datetime object does support a hook to add timezone info.

The numpy datetime64 may implementation   _may_ provide a similar hook in the future.

There is the pytz package, which MPL could choose to depend on.

But even that is a bit ugly--e.g. from the pytz docs:

"""Unfortunately using the tzinfo argument of the standard datetime constructors ‘’does not work’’ with pytz for many timezones."""

So my suggestion is that MPL punts, and stick with leaving time zone handling up to the user, I.e only use datetimes that are timezone "naive". What this means is that MPL would always a assume all datetimes interacting with each other are in the same time zone (including same DST status).

Anyway, I'm being a bit lazy here, so I may be wrong, but I think the issue at hand is that MPL currently uses a float array to store and manipulate datetimes, and the thought is that it may be better to use numpy datetime64 arrays -- that would give us more consistent precision, and less code to convert to/from various datetime formats.

I'm a bit on the fence about whether it's time to do it, as datetime64 does have issues with the locale timezone, but as any implementation would want to work with not-just-the-latest numpy anyway, it may make sense to start now.

-Chris






--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...<mailto:Chr...@no...>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net_______________________________________________
Matplotlib-devel mailing list
Mat...@li...<mailto:Mat...@li...>
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net_______________________________________________
Matplotlib-devel mailing list
Mat...@li...<mailto:Mat...@li...>
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I was hoping for something a bit more extensive of the intenals.  I have
tried to understand the units code a couple of times now and always hit a
brick wall.

On Thu Jan 08 2015 at 2:07:02 PM Drain, Theodore R (392P) <
the...@jp...> wrote:

>  Google search "matplotlib units" yields:
> http://matplotlib.org/api/units_api.html
>
>
>
> So it sounds like the update is to make MPL's internal date system higher
> resolution which would be great.   We would just need to update our
> converters to convert to that format instead of the current floating point
> format.  Our custom classes are not public (and can't really be made
> public) but they aren't very complicated so we can certainly talk about the
> implementation if that helps.
>
>
>  ------------------------------
> *From:* Thomas Caswell [tca...@gm...]
> *Sent:* Thursday, January 08, 2015 10:57 AM
> *To:* Drain, Theodore R (392P); mat...@li...
>
> *Subject:* Re: [matplotlib-devel] Date overhaul?
>  One of the other driving factors to over-haul the default date handling
> is that floats do not have enough precision to deal with nano-second
> resolution data (which is what I think drove pandas to use datetime64).
>
>  It sounds like the correct solution
>
>  Is the unit framework documented anywhere and are those custom classes
> public?
>
>  Tom
>
> On Thu Jan 08 2015 at 12:59:17 PM Drain, Theodore R (392P) <
> the...@jp...> wrote:
>
>>  I agree w/ the original poster that it would help to have a MEP to
>> clearly define what the goals of the overhaul are
>>
>>
>>
>> Something else to keep in mind: we at least don't normally plot dates in
>> "earth" based time systems.  ~10 years ago we contracted with John Hunter
>> to add the arbitrary unit system to MPL.  This allows users to plot in
>> their own data types and define a converter to handle the conversion to MPL
>> types and labeling.  We have our own "date time" like class which handles
>> relativistic time scales (TDB, TT, TAI, GPS, Mars time, etc) at extremely
>> high precision.  We register a unit converter w/ MPL which allows our users
>> to plot these types natively and use the xunits keyword (or yunits) to
>> control how the plot looks.  So we can do this:
>>
>>
>>
>> plot( x, y, xunits="GPS", yunits="km/s" )
>>
>> plot( x, y, xunits="PST", yunits="mph" )
>>
>>
>>
>> It would also be pretty easy to add a time zone aware unit converter with
>> the existing MPL code which would allow you to do things w/ datetime like
>> this:
>>
>>
>>
>> plot( x, y, xunits="UTC+8" )
>>
>> plot( x, y, xunits="EST" )
>>
>>
>>
>> I guess the point of this is to remind folks that not everyone plots
>> dates in time zone based systems...
>>
>>
>>
>> Ted
>>
>>
>>  ------------------------------
>> *From:* Chris Barker [chr...@no...]
>> *Sent:* Thursday, January 08, 2015 9:00 AM
>> *To:* mat...@li...
>> *Subject:* Re: [matplotlib-devel] Date overhaul?
>>
>>       On Thu, Jan 8, 2015 at 7:04 AM, Skip Montanaro <sk...@po...>
>> wrote:
>>
>>> I'm real naive about this stuff, but I have always wondered why
>>> matplotlib didn't just use datetime objects, or at least use
>>> timezone-aware datetime objects as an "interchange" format to get the
>>> timezone stuff right.
>>>
>>
>>  Time zone handling is a pain in the %}€*
>>
>>  And the definitions keep changing.
>>
>>  So you need a complex DB and library that needs frequent updating.
>>
>>  This is why neither the standard library nor numpy support time zone
>> handling out of the box.
>>
>>  But the datetime object does support a hook to add timezone info.
>>
>>  The numpy datetime64 may implementation   _may_ provide a similar hook
>> in the future.
>>
>>  There is the pytz package, which MPL could choose to depend on.
>>
>>  But even that is a bit ugly--e.g. from the pytz docs:
>>
>>  """Unfortunately using the tzinfo argument of the standard datetime
>> constructors ‘’does not work’’ with pytz for many timezones."""
>>
>> So my suggestion is that MPL punts, and stick with leaving time zone
>> handling up to the user, I.e only use datetimes that are timezone "naive".
>> What this means is that MPL would always a assume all datetimes interacting
>> with each other are in the same time zone (including same DST status).
>>
>> Anyway, I'm being a bit lazy here, so I may be wrong, but I think the
>> issue at hand is that MPL currently uses a float array to store and
>> manipulate datetimes, and the thought is that it may be better to use
>> numpy datetime64 arrays -- that would give us more consistent precision,
>> and less code to convert to/from various datetime formats.
>> I'm a bit on the fence about whether it's time to do it, as datetime64
>> does have issues with the locale timezone, but as any implementation would
>> want to work with not-just-the-latest numpy anyway, it may make sense to
>> start now.
>>
>> -Chris
>>
>>
>>
>>
>>
>>
>>  --
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R            (206) 526-6959   voice
>> 7600 Sand Point Way NE   (206) 526-6329   fax
>> Seattle, WA  98115       (206) 526-6317   main reception
>>
>> Chr...@no...
>>    ------------------------------------------------------------
>> ------------------
>> Dive into the World of Parallel Programming! The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>   ------------------------------------------------------------
> ------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Google search "matplotlib units" yields: http://matplotlib.org/api/units_api.html



So it sounds like the update is to make MPL's internal date system higher resolution which would be great.   We would just need to update our converters to convert to that format instead of the current floating point format.  Our custom classes are not public (and can't really be made public) but they aren't very complicated so we can certainly talk about the implementation if that helps.



________________________________
From: Thomas Caswell [tca...@gm...]
Sent: Thursday, January 08, 2015 10:57 AM
To: Drain, Theodore R (392P); mat...@li...
Subject: Re: [matplotlib-devel] Date overhaul?

One of the other driving factors to over-haul the default date handling is that floats do not have enough precision to deal with nano-second resolution data (which is what I think drove pandas to use datetime64).

It sounds like the correct solution

Is the unit framework documented anywhere and are those custom classes public?

Tom

On Thu Jan 08 2015 at 12:59:17 PM Drain, Theodore R (392P) <the...@jp...<mailto:the...@jp...>> wrote:

I agree w/ the original poster that it would help to have a MEP to clearly define what the goals of the overhaul are



Something else to keep in mind: we at least don't normally plot dates in "earth" based time systems.  ~10 years ago we contracted with John Hunter to add the arbitrary unit system to MPL.  This allows users to plot in their own data types and define a converter to handle the conversion to MPL types and labeling.  We have our own "date time" like class which handles relativistic time scales (TDB, TT, TAI, GPS, Mars time, etc) at extremely high precision.  We register a unit converter w/ MPL which allows our users to plot these types natively and use the xunits keyword (or yunits) to control how the plot looks.  So we can do this:



plot( x, y, xunits="GPS", yunits="km/s" )

plot( x, y, xunits="PST", yunits="mph" )



It would also be pretty easy to add a time zone aware unit converter with the existing MPL code which would allow you to do things w/ datetime like this:



plot( x, y, xunits="UTC+8" )

plot( x, y, xunits="EST" )



I guess the point of this is to remind folks that not everyone plots dates in time zone based systems...



Ted



________________________________
From: Chris Barker [chr...@no...<mailto:chr...@no...>]
Sent: Thursday, January 08, 2015 9:00 AM
To: mat...@li...<mailto:mat...@li...>
Subject: Re: [matplotlib-devel] Date overhaul?

On Thu, Jan 8, 2015 at 7:04 AM, Skip Montanaro <sk...@po...<mailto:sk...@po...>> wrote:
I'm real naive about this stuff, but I have always wondered why
matplotlib didn't just use datetime objects, or at least use
timezone-aware datetime objects as an "interchange" format to get the
timezone stuff right.

Time zone handling is a pain in the %}€*

And the definitions keep changing.

So you need a complex DB and library that needs frequent updating.

This is why neither the standard library nor numpy support time zone handling out of the box.

But the datetime object does support a hook to add timezone info.

The numpy datetime64 may implementation   _may_ provide a similar hook in the future.

There is the pytz package, which MPL could choose to depend on.

But even that is a bit ugly--e.g. from the pytz docs:

"""Unfortunately using the tzinfo argument of the standard datetime constructors ‘’does not work’’ with pytz for many timezones."""

So my suggestion is that MPL punts, and stick with leaving time zone handling up to the user, I.e only use datetimes that are timezone "naive". What this means is that MPL would always a assume all datetimes interacting with each other are in the same time zone (including same DST status).

Anyway, I'm being a bit lazy here, so I may be wrong, but I think the issue at hand is that MPL currently uses a float array to store and manipulate datetimes, and the thought is that it may be better to use numpy datetime64 arrays -- that would give us more consistent precision, and less code to convert to/from various datetime formats.

I'm a bit on the fence about whether it's time to do it, as datetime64 does have issues with the locale timezone, but as any implementation would want to work with not-just-the-latest numpy anyway, it may make sense to start now.

-Chris






--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...<mailto:Chr...@no...>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net_______________________________________________
Matplotlib-devel mailing list
Mat...@li...<mailto:Mat...@li...>
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

One of the other driving factors to over-haul the default date handling is
that floats do not have enough precision to deal with nano-second
resolution data (which is what I think drove pandas to use datetime64).

It sounds like the correct solution

Is the unit framework documented anywhere and are those custom classes
public?

Tom

On Thu Jan 08 2015 at 12:59:17 PM Drain, Theodore R (392P) <
the...@jp...> wrote:

>  I agree w/ the original poster that it would help to have a MEP to
> clearly define what the goals of the overhaul are
>
>
>
> Something else to keep in mind: we at least don't normally plot dates in
> "earth" based time systems.  ~10 years ago we contracted with John Hunter
> to add the arbitrary unit system to MPL.  This allows users to plot in
> their own data types and define a converter to handle the conversion to MPL
> types and labeling.  We have our own "date time" like class which handles
> relativistic time scales (TDB, TT, TAI, GPS, Mars time, etc) at extremely
> high precision.  We register a unit converter w/ MPL which allows our users
> to plot these types natively and use the xunits keyword (or yunits) to
> control how the plot looks.  So we can do this:
>
>
>
> plot( x, y, xunits="GPS", yunits="km/s" )
>
> plot( x, y, xunits="PST", yunits="mph" )
>
>
>
> It would also be pretty easy to add a time zone aware unit converter with
> the existing MPL code which would allow you to do things w/ datetime like
> this:
>
>
>
> plot( x, y, xunits="UTC+8" )
>
> plot( x, y, xunits="EST" )
>
>
>
> I guess the point of this is to remind folks that not everyone plots dates
> in time zone based systems...
>
>
>
> Ted
>
>
>  ------------------------------
> *From:* Chris Barker [chr...@no...]
> *Sent:* Thursday, January 08, 2015 9:00 AM
> *To:* mat...@li...
> *Subject:* Re: [matplotlib-devel] Date overhaul?
>
>    On Thu, Jan 8, 2015 at 7:04 AM, Skip Montanaro <sk...@po...> wrote:
>
>> I'm real naive about this stuff, but I have always wondered why
>> matplotlib didn't just use datetime objects, or at least use
>> timezone-aware datetime objects as an "interchange" format to get the
>> timezone stuff right.
>>
>
>  Time zone handling is a pain in the %}€*
>
>  And the definitions keep changing.
>
>  So you need a complex DB and library that needs frequent updating.
>
>  This is why neither the standard library nor numpy support time zone
> handling out of the box.
>
>  But the datetime object does support a hook to add timezone info.
>
>  The numpy datetime64 may implementation   _may_ provide a similar hook
> in the future.
>
>  There is the pytz package, which MPL could choose to depend on.
>
>  But even that is a bit ugly--e.g. from the pytz docs:
>
>  """Unfortunately using the tzinfo argument of the standard datetime
> constructors ‘’does not work’’ with pytz for many timezones."""
>
> So my suggestion is that MPL punts, and stick with leaving time zone
> handling up to the user, I.e only use datetimes that are timezone "naive".
> What this means is that MPL would always a assume all datetimes interacting
> with each other are in the same time zone (including same DST status).
>
> Anyway, I'm being a bit lazy here, so I may be wrong, but I think the
> issue at hand is that MPL currently uses a float array to store and
> manipulate datetimes, and the thought is that it may be better to use
> numpy datetime64 arrays -- that would give us more consistent precision,
> and less code to convert to/from various datetime formats.
> I'm a bit on the fence about whether it's time to do it, as datetime64
> does have issues with the locale timezone, but as any implementation would
> want to work with not-just-the-latest numpy anyway, it may make sense to
> start now.
>
> -Chris
>
>
>
>
>
>
>  --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> Chr...@no...
>   ------------------------------------------------------------
> ------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I agree w/ the original poster that it would help to have a MEP to clearly define what the goals of the overhaul are



Something else to keep in mind: we at least don't normally plot dates in "earth" based time systems.  ~10 years ago we contracted with John Hunter to add the arbitrary unit system to MPL.  This allows users to plot in their own data types and define a converter to handle the conversion to MPL types and labeling.  We have our own "date time" like class which handles relativistic time scales (TDB, TT, TAI, GPS, Mars time, etc) at extremely high precision.  We register a unit converter w/ MPL which allows our users to plot these types natively and use the xunits keyword (or yunits) to control how the plot looks.  So we can do this:



plot( x, y, xunits="GPS", yunits="km/s" )

plot( x, y, xunits="PST", yunits="mph" )



It would also be pretty easy to add a time zone aware unit converter with the existing MPL code which would allow you to do things w/ datetime like this:



plot( x, y, xunits="UTC+8" )

plot( x, y, xunits="EST" )



I guess the point of this is to remind folks that not everyone plots dates in time zone based systems...



Ted



________________________________
From: Chris Barker [chr...@no...]
Sent: Thursday, January 08, 2015 9:00 AM
To: mat...@li...
Subject: Re: [matplotlib-devel] Date overhaul?

On Thu, Jan 8, 2015 at 7:04 AM, Skip Montanaro <sk...@po...<mailto:sk...@po...>> wrote:
I'm real naive about this stuff, but I have always wondered why
matplotlib didn't just use datetime objects, or at least use
timezone-aware datetime objects as an "interchange" format to get the
timezone stuff right.

Time zone handling is a pain in the %}€*

And the definitions keep changing.

So you need a complex DB and library that needs frequent updating.

This is why neither the standard library nor numpy support time zone handling out of the box.

But the datetime object does support a hook to add timezone info.

The numpy datetime64 may implementation   _may_ provide a similar hook in the future.

There is the pytz package, which MPL could choose to depend on.

But even that is a bit ugly--e.g. from the pytz docs:

"""Unfortunately using the tzinfo argument of the standard datetime constructors ‘’does not work’’ with pytz for many timezones."""

So my suggestion is that MPL punts, and stick with leaving time zone handling up to the user, I.e only use datetimes that are timezone "naive". What this means is that MPL would always a assume all datetimes interacting with each other are in the same time zone (including same DST status).

Anyway, I'm being a bit lazy here, so I may be wrong, but I think the issue at hand is that MPL currently uses a float array to store and manipulate datetimes, and the thought is that it may be better to use numpy datetime64 arrays -- that would give us more consistent precision, and less code to convert to/from various datetime formats.

I'm a bit on the fence about whether it's time to do it, as datetime64 does have issues with the locale timezone, but as any implementation would want to work with not-just-the-latest numpy anyway, it may make sense to start now.

-Chris






--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...<mailto:Chr...@no...>

On Tue, Jan 6, 2015 at 2:37 AM, Maximilian Albert
<max...@gm...> wrote:
> Happy new year everyone!
>
> Apologies for the long silence. I was snowed in with work before Christmas
> and then mostly cut off from the internet for the past two weeks.
> Fortunately, I had a chance over the holidays to flesh out the GUI which I
> mentioned in my previous email. You can find it here:
>
>    https://github.com/maxalbert/colormap-selector
>
> Basically, it allows you to pick the start/end color of a colormap from two
> cross sections in CIELab space and interpolates those colors linearly (see
> the README file for more details).

There's a downside to this approach for the kinds of colormaps we've
been talking about in this thread, where we want both a large
lightness range plus a colorful result. The problem is that the way
color space is shaped, you can't simultaneously have both high
saturation (colorfulness) *and* high/low lightness. So if you pick
your extreme points to be near black and white, then they can only
have a slight tinting of color, and then if you linearly interpolate
between these, then you end up with slightly tinted greyscale.

Colormaps like YlGnBu or cubehelix or parula are designed to start out
with low saturation, then as they move into the middle of the
lightness scale they arc outwards, then arc back in again.

This is a lot easier to visualize (e.g. by playing with the script I
posted upthread) than it is to explain in text :-). Like, if you do
viscm(YlGnBu_r) and look at the plot in the lower-right then it's
clear that it's not a simple straight line in (J'/K, a', b') space
(which is a higher-tech analogue to L* a* b* space).

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

Nice job.

I find your GUI a little bit confusing (new to colormap stuff) but I
like the idea, basically I find it overkill, I would replace the gui
by a plot and a couple of slider widgets something simpler to
integrate without new dependencies.
Do you really need the third 3d plot on the right?

On Mon, Jan 5, 2015 at 9:37 PM, Maximilian Albert
<max...@gm...> wrote:
> Happy new year everyone!
>
> Apologies for the long silence. I was snowed in with work before Christmas
> and then mostly cut off from the internet for the past two weeks.
> Fortunately, I had a chance over the holidays to flesh out the GUI which I
> mentioned in my previous email. You can find it here:
>
>    https://github.com/maxalbert/colormap-selector
>
> Basically, it allows you to pick the start/end color of a colormap from two
> cross sections in CIELab space and interpolates those colors linearly (see
> the README file for more details). Currently there is one scatterplot to
> illustrate the resulting colormap but it can be trivially extended to show
> more interesting sample plots. There are still a few things missing that I'd
> like to add but at least it's in a state where it can be used and I'd be
> grateful for feedback, especially with regard to the colormaps generated
> with it (I do have some opinions myself but it would be interesting to hear
> others' first).
>
> Regarding our ongoing discussion, I had a very useful chat with two
> colleagues before Christmas which spurred more thoughts. But I guess it's
> best to discuss them in a separate email when I'm less tired. ;)
>
> Best wishes,
> Max
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

On Thu, Jan 8, 2015 at 7:04 AM, Skip Montanaro <sk...@po...> wrote:

> I'm real naive about this stuff, but I have always wondered why
> matplotlib didn't just use datetime objects, or at least use
> timezone-aware datetime objects as an "interchange" format to get the
> timezone stuff right.
>

Time zone handling is a pain in the %}€*

And the definitions keep changing.

So you need a complex DB and library that needs frequent updating.

This is why neither the standard library nor numpy support time zone
handling out of the box.

But the datetime object does support a hook to add timezone info.

The numpy datetime64 may implementation   _may_ provide a similar hook in
the future.

There is the pytz package, which MPL could choose to depend on.

But even that is a bit ugly--e.g. from the pytz docs:

"""Unfortunately using the tzinfo argument of the standard datetime
constructors ‘’does not work’’ with pytz for many timezones."""

So my suggestion is that MPL punts, and stick with leaving time zone
handling up to the user, I.e only use datetimes that are timezone "naive".
What this means is that MPL would always a assume all datetimes interacting
with each other are in the same time zone (including same DST status).

Anyway, I'm being a bit lazy here, so I may be wrong, but I think the issue
at hand is that MPL currently uses a float array to store and manipulate
datetimes, and the thought is that it may be better to use numpy datetime64
arrays -- that would give us more consistent precision, and less code to
convert to/from various datetime formats.
I'm a bit on the fence about whether it's time to do it, as datetime64 does
have issues with the locale timezone, but as any implementation would want
to work with not-just-the-latest numpy anyway, it may make sense to start
now.

-Chris






-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

I'm real naive about this stuff, but I have always wondered why
matplotlib didn't just use datetime objects, or at least use
timezone-aware datetime objects as an "interchange" format to get the
timezone stuff right.

Skip

On Wed, Jan 7, 2015 at 2:10 PM, Eric Firing <ef...@ha...> wrote:

>   One thing that has held this up is that datetime64
> came into numpy half-baked, and has remained experimental with known
> problems that need to be fixed.  It looks like the core of datetime64,
> ignoring timezone problems, isn't going to change, so it should be
> possible to work with that in matplotlib.
>

you can do some googling, but the issue with timezones in datetime64 is
that is _always_ uses the system timezone to translate when parsing iso
strings (and bare datetime.datetime objects) without a timezone, and I'm
pretty sure does somethign like that when formatting string output, too.

It can be worked around if you are careful to always make it think you are
working in UTC.

This should change in a release or two (and I'm sorry to say that I've held
that up by stalling on getting proposals properly written up), but Eric's
right, the internals should stay close enough that it's worth using.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On 2015/01/07 11:48 AM, Paul Ganssle wrote:

> Recently I took a crack at fixing some of the bugs in dates.py, and it
> seems like there's been some talk of overhauling how dates are handled.
> I don't see an MEP for that, so I'm wondering if anyone can give me some
> more details about what the impetus was for overhauling date handling
> and just in general what needs to be done. I wouldn't mind taking a
> crack at the date handling stuff while it's still fresh in my mind.

Paul,

I think the main thing is supporting, and taking advantage of, the numpy 
datetime64 dtype.  One thing that has held this up is that datetime64 
came into numpy half-baked, and has remained experimental with known 
problems that need to be fixed.  It looks like the core of datetime64, 
ignoring timezone problems, isn't going to change, so it should be 
possible to work with that in matplotlib.

Eric

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Recently I took a crack at fixing some of the bugs in dates.py, and it
seems like there's been some talk of overhauling how dates are handled.
I don't see an MEP for that, so I'm wondering if anyone can give me some
more details about what the impetus was for overhauling date handling
and just in general what needs to be done. I wouldn't mind taking a
crack at the date handling stuff while it's still fresh in my mind.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
 
iQIcBAEBAgAGBQJUramTAAoJEM1U/OPZZL77t4kP/1Gj2roe2ZzGJF3u2L71p+TD
gK63EKcoqLnjCs080nDfsERSSN8tG0OQvCLNcxQBV7p22rd6lMdn5MvHxYKuZVEE
rD2+92f45Ql5gAw+Q8rOJKcIt/fH0MHDO5TPCJl1Mjcp1ZsQk2DO/qdOmPWlgjbg
H++WWW6kXbJpBBWelNzKCR6HIhFfcEtBCNoc0MDclLm7qlxR6vGoFNBWeNptEjQ+
4q6ZASMfIxkRKI1KpiYW+3ezMGCyw9hd/aJvj9iSti5BXL0CZHfUg1Rt7gYpsHU4
I0gSFzSIOTQb8TjKpyeD3yjxmllxgaXxdUm5i3Snp0+Cv7yWYYwAArTm/Aq6h2+z
X4qaXNxys5BKqOa+oCiYLdlE/GHA+REvw4+VFoL/oOp5wVlGjaJY2jwhjhJnjvzT
f4tvampwFfl0KPAm+eoqkMhqt/jjZetKwXXK+DTETO9o80yvTaM28nd1LYLD9ywN
QDfVbCzrg01cQQpWVT5JtzeHoJ/4du8I+cC0VWzMM159X44GfYbtV1QUbRgdiTPh
TUwDJi48Zg3eVI45L95r1eC4Q8VFzkTf59m1wve7xuVkOgNZq15BriQC7TQWWKH6
RXjTYD09PRmTyZg4YeshqLHApyAXzFYtSckHDiEFy6BPTYHsgPQcbX0U1igZUsrA
9rHjCWUZK33cLbla2CpG
=RJbm
-----END PGP SIGNATURE-----

Tony! This is very cool. Bravo.

On Mon, Jan 5, 2015 at 8:42 PM, Tony Yu <ts...@gm...> wrote:

> I've been playing around with learning Javascript lately. As part of the
> process, I created a Flask app to build a gallery for matplotlib style
> sheets:
>
> https://github.com/tonysyu/matplotlib-style-gallery
>
> If you run that locally, you can actually input styles, either with a URL
> to a *.mplstyle file or with matplotlibrc commands. Here's a static version
> without the custom inputs:
>
> http://tonysyu.github.io/raw_content/matplotlib-style-gallery/gallery.html
>
> Ideally, I'd get this into a form that could be submitted as a PR for the
> matplotlib website, but I'll need a bit more spare time to learn some more
> web development (sessions, client storage, etc).
>
> Cheers!
> -Tony
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

I've been playing around with learning Javascript lately. As part of the
process, I created a Flask app to build a gallery for matplotlib style
sheets:

https://github.com/tonysyu/matplotlib-style-gallery

If you run that locally, you can actually input styles, either with a URL
to a *.mplstyle file or with matplotlibrc commands. Here's a static version
without the custom inputs:

http://tonysyu.github.io/raw_content/matplotlib-style-gallery/gallery.html

Ideally, I'd get this into a form that could be submitted as a PR for the
matplotlib website, but I'll need a bit more spare time to learn some more
web development (sessions, client storage, etc).

Cheers!
-Tony

Happy new year everyone!

Apologies for the long silence. I was snowed in with work before Christmas
and then mostly cut off from the internet for the past two weeks.
Fortunately, I had a chance over the holidays to flesh out the GUI which I
mentioned in my previous email. You can find it here:

   https://github.com/maxalbert/colormap-selector

Basically, it allows you to pick the start/end color of a colormap from two
cross sections in CIELab space and interpolates those colors linearly (see
the README file for more details). Currently there is one scatterplot to
illustrate the resulting colormap but it can be trivially extended to show
more interesting sample plots. There are still a few things missing that
I'd like to add but at least it's in a state where it can be used and I'd
be grateful for feedback, especially with regard to the colormaps generated
with it (I do have some opinions myself but it would be interesting to hear
others' first).

Regarding our ongoing discussion, I had a very useful chat with two
colleagues before Christmas which spurred more thoughts. But I guess it's
best to discuss them in a separate email when I'm less tired. ;)

Best wishes,
Max

On Wed, Dec 31, 2014 at 4:53 AM, Benjamin Root <ben...@ou...> wrote:
> There is no better way to do this at the moment. There have been talk of
> integrating the animation interface into Figure objects so that creating an
> animation would be similar to creating any other type of plot, with
> references to the animation object stored in the figure like any other
> Artist.
>
> The basic rule of thumb is, if you are using a constructor, then assign the
> constructed object somewhere!

Thanks a lot Benjamin! Very helpful indeed.


>
> I hope that clears it up!
> Ben Root
>
>
> On Sun, Dec 28, 2014 at 7:25 AM, Amit Saha <ami...@gm...> wrote:
>>
>> Hi all,
>>
>> I realize that once I create a FuncAnimation object, I must assign it
>> to a label to make it persist [1]. Is this going to remain the case in
>> the foreseeable future? Is there a better way of doing this now?
>>
>> Thanks,
>> Amit.
>>
>>
>> [1] https://github.com/matplotlib/matplotlib/issues/1656
>>
>> --
>> http://echorand.me
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming! The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>



-- 
http://echorand.me

Neat stuff! Just a quick note about the 3D plot. By default, the scatter
markers are shaded to give an illusion of depth. This is often what we
want, but I think in this case, it might make sense to not do that. Add
depthshade=False to the scatter call to turn it off. I think that was added
for mpl version 1.3.

Ben Root

On Tue, Dec 23, 2014 at 4:16 AM, Nathaniel Smith <nj...@po...> wrote:

> On Fri, Nov 21, 2014 at 10:53 PM, Eric Firing <ef...@ha...> wrote:
> > On 2014/11/21, 4:42 PM, Nathaniel Smith wrote:
> >> On Fri, Nov 21, 2014 at 5:46 PM, Darren Dale <dsd...@gm...>
> wrote:
> >>> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pel...@gm...>
> wrote:
> >>>>
> >>>> Please use this thread to discuss the best choice for a new default
> >>>> matplotlib colormap.
> >>>>
> >>>> This follows on from a discussion on the matplotlib-devel mailing list
> >>>> entitled "How to move beyond JET as the default matplotlib colormap".
> >>>
> >>>
> >>> I remember reading a (peer-reviewed, I think) article about how "jet"
> was a
> >>> very unfortunate choice of default. I can't find the exact article
> now, but
> >>> I did find some other useful ones:
> >>>
> >>>
> http://cresspahl.blogspot.com/2012/03/expanded-control-of-octaves-colormap.html
> >>> http://www.sandia.gov/~kmorel/documents/ColorMaps/
> >>>
> http://www.sandia.gov/~kmorel/documents/ColorMaps/ColorMapsExpanded.pdf
> >>
> >> Those are good articles. There's a lot of literature on the problems
> >> with "jet", and lots of links in the matplotlib issue [1]. For those
> >> trying to get up to speed quickly, MathWorks recently put together a
> >> nice review of the literature [2]. One particularly striking paper
> >> they cite studied a group of medical students and found that (a) they
> >> were used to/practiced at using jet, (b) when given a choice of
> >> colormaps they said that they preferred jet, (c) they nonetheless made
> >> more *medical diagnostic errors* when using jet than with better
> >> designed colormaps (Borkin et al, 2011).
> >>
> >> I won't suggest a specific colormap, but I do propose that whatever we
> >> chose satisfy the following criteria:
> >>
> >> - it should be a sequential colormap, because diverging colormaps are
> >> really misleading unless you know where the "center" of the data is,
> >> and for a default colormap we generally won't.
> >>
> >> - it should be perceptually uniform, i.e., human subjective judgements
> >> of how far apart nearby colors are should correspond as linearly as
> >> possible to the difference between the numerical values they
> >> represent, at least locally. There's lots of research on how to
> >> measure perceptual distance -- a colleague and I happen to have
> >> recently implemented a state-of-the-art model of this for another
> >> project, in case anyone wants to play with it [3], or just using
> >> good-old-L*a*b* is a reasonable quick-and-dirty approximation.
> >>
> >> - it should have a perceptually uniform luminance ramp, i.e. if you
> >> convert to greyscale it should still be uniform. This is useful both
> >> in practical terms (greyscale printers are still a thing!) and because
> >> luminance is a very strong and natural cue to magnitude.
> >>
> >> - it should also have some kind of variation in hue, because hue
> >> variation is a really helpful additional cue to perception, having two
> >> cues is better than one, and there's no reason not to do it.
> >>
> >> - the hue variation should be chosen to produce reasonable results
> >> even for viewers with the more common types of colorblindness. (Which
> >> rules out things like red-to-green.)
> >>
> >> And, for bonus points, it would be nice to choose a hue ramp that
> >> still works if you throw away the luminance variation, because then we
> >> could use the version with varying luminance for 2d plots, and the
> >> version with just hue variation for 3d plots. (In 3d plots you really
> >> want to reserve the luminance channel for lighting/shading, because
> >> your brain is *really* good at extracting 3d shape from luminance
> >> variation. If the 3d surface itself has massively varying luminance
> >> then this screws up the ability to see shape.)
> >>
> >> Do these seem like good requirements?
> >
> > Goals, yes, though I wouldn't put much weight on the "bonus" criterion.
> >   I would add that it should be aesthetically pleasing, or at least
> > comfortable, to most people.  Perfection might not be attainable, and
> > some tradeoffs may be required. Is anyone set up to produce test images
> > and/or metrics for judging existing colormaps, or newly designed ones,
> > on all of these criteria?
>
> I had some time on a plane today, so I wrote a little script for
> visualizing colormaps (esp. WRT perceptual uniformity and
> colorblindness). To try it:
>
> $ git clone https://github.com/njsmith/pycam02ucs.git
> $ cd pycam02ucs
> $ ipython
> In [1]: %matplotlib
> In [2]: from pycam02ucs.viscm import viscm
> In [3]: viscm("jet")
>
> (Or substitute your favorite built-in colormap, or pass a matplotlib
> colormap object, i.e. a callable that takes an array of values in the
> range [0, 1] and returns an array of RGBA values with shape (n, 4).)
>
> I'm attaching an example, plus an annotated example explaining what
> the different bits show.
>
> It's a bit crude, but has definitely reached the
> fun-to-play-around-with stage :-). If anyone makes improvements send
> me a PR!
>
> Hidden feature: you can pass show_gamut=True to get a crude
> approximation of the space of possible sRGB colors drawn onto the 3d
> plot at the bottom. The idea is if trying to design a better colormap
> it's useful to have a sense of what potential colors are available to
> use. It's pretty crude and somewhat distracting though so I left it
> off by default for now.
>
> -n
>
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> http://vorpus.org
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

There is no better way to do this at the moment. There have been talk of
integrating the animation interface into Figure objects so that creating an
animation would be similar to creating any other type of plot, with
references to the animation object stored in the figure like any other
Artist.

The basic rule of thumb is, if you are using a constructor, then assign the
constructed object somewhere!

I hope that clears it up!
Ben Root


On Sun, Dec 28, 2014 at 7:25 AM, Amit Saha <ami...@gm...> wrote:

> Hi all,
>
> I realize that once I create a FuncAnimation object, I must assign it
> to a label to make it persist [1]. Is this going to remain the case in
> the foreseeable future? Is there a better way of doing this now?
>
> Thanks,
> Amit.
>
>
> [1] https://github.com/matplotlib/matplotlib/issues/1656
>
> --
> http://echorand.me
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi all,

I realize that once I create a FuncAnimation object, I must assign it
to a label to make it persist [1]. Is this going to remain the case in
the foreseeable future? Is there a better way of doing this now?

Thanks,
Amit.


[1] https://github.com/matplotlib/matplotlib/issues/1656

-- 
http://echorand.me

Hi all,

I realize that once I create a FuncAnimation object, I must assign it
to a label to make it persist [1]. Is this going to remain the case in
the foreseeable future? Is there a better way of doing this now?

Thanks,
Amit.


[1] https://github.com/matplotlib/matplotlib/issues/1656
-- 
http://echorand.me

If working on XKCD style plotting for matplotlib taught me anything, it is
that playing with software in a way that it was not originally designed to
do can lead to some excellent discoveries (bugs) and generate new ideas and
generalisations - not to mention it being a lot of fun!

So, in that vein, I wanted to put together a simple Christmas e-card using
matplotlib. My main aim was to re-purpose some of the familiar matplotlib
functionality to generate a simple festive animation.

I decided to go for a snowy scene, with a snow-capped greeting and sprig of
holly. The snow is simply a scatter plot scaled by flake size and animated
to fall in a pleasing way. The text is making use of the path effects
functionality extended in v1.4 to add randomised "snow" around the text
(the same effect employed by XKCD as it happens). And the holly is a nice
demonstration of the power of Paths and vector rendering in matplotlib.

The source can be found at
https://gist.github.com/pelson/ca795a02a420a1b9bfbc, and it requires
matplotlib >= v1.4.

If you're impatient and don't want to run the code (don't do it), the
animation is available on YouTube at
https://www.youtube.com/watch?v=POnAkPpe770.

Finally, to all those taking some time off this festive season, I wish you
a very happy holiday and wish you all the best for the new year.

Phil Elson

On Fri, Nov 21, 2014 at 10:53 PM, Eric Firing <ef...@ha...> wrote:
> On 2014/11/21, 4:42 PM, Nathaniel Smith wrote:
>> On Fri, Nov 21, 2014 at 5:46 PM, Darren Dale <dsd...@gm...> wrote:
>>> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pel...@gm...> wrote:
>>>>
>>>> Please use this thread to discuss the best choice for a new default
>>>> matplotlib colormap.
>>>>
>>>> This follows on from a discussion on the matplotlib-devel mailing list
>>>> entitled "How to move beyond JET as the default matplotlib colormap".
>>>
>>>
>>> I remember reading a (peer-reviewed, I think) article about how "jet" was a
>>> very unfortunate choice of default. I can't find the exact article now, but
>>> I did find some other useful ones:
>>>
>>> http://cresspahl.blogspot.com/2012/03/expanded-control-of-octaves-colormap.html
>>> http://www.sandia.gov/~kmorel/documents/ColorMaps/
>>> http://www.sandia.gov/~kmorel/documents/ColorMaps/ColorMapsExpanded.pdf
>>
>> Those are good articles. There's a lot of literature on the problems
>> with "jet", and lots of links in the matplotlib issue [1]. For those
>> trying to get up to speed quickly, MathWorks recently put together a
>> nice review of the literature [2]. One particularly striking paper
>> they cite studied a group of medical students and found that (a) they
>> were used to/practiced at using jet, (b) when given a choice of
>> colormaps they said that they preferred jet, (c) they nonetheless made
>> more *medical diagnostic errors* when using jet than with better
>> designed colormaps (Borkin et al, 2011).
>>
>> I won't suggest a specific colormap, but I do propose that whatever we
>> chose satisfy the following criteria:
>>
>> - it should be a sequential colormap, because diverging colormaps are
>> really misleading unless you know where the "center" of the data is,
>> and for a default colormap we generally won't.
>>
>> - it should be perceptually uniform, i.e., human subjective judgements
>> of how far apart nearby colors are should correspond as linearly as
>> possible to the difference between the numerical values they
>> represent, at least locally. There's lots of research on how to
>> measure perceptual distance -- a colleague and I happen to have
>> recently implemented a state-of-the-art model of this for another
>> project, in case anyone wants to play with it [3], or just using
>> good-old-L*a*b* is a reasonable quick-and-dirty approximation.
>>
>> - it should have a perceptually uniform luminance ramp, i.e. if you
>> convert to greyscale it should still be uniform. This is useful both
>> in practical terms (greyscale printers are still a thing!) and because
>> luminance is a very strong and natural cue to magnitude.
>>
>> - it should also have some kind of variation in hue, because hue
>> variation is a really helpful additional cue to perception, having two
>> cues is better than one, and there's no reason not to do it.
>>
>> - the hue variation should be chosen to produce reasonable results
>> even for viewers with the more common types of colorblindness. (Which
>> rules out things like red-to-green.)
>>
>> And, for bonus points, it would be nice to choose a hue ramp that
>> still works if you throw away the luminance variation, because then we
>> could use the version with varying luminance for 2d plots, and the
>> version with just hue variation for 3d plots. (In 3d plots you really
>> want to reserve the luminance channel for lighting/shading, because
>> your brain is *really* good at extracting 3d shape from luminance
>> variation. If the 3d surface itself has massively varying luminance
>> then this screws up the ability to see shape.)
>>
>> Do these seem like good requirements?
>
> Goals, yes, though I wouldn't put much weight on the "bonus" criterion.
>   I would add that it should be aesthetically pleasing, or at least
> comfortable, to most people.  Perfection might not be attainable, and
> some tradeoffs may be required. Is anyone set up to produce test images
> and/or metrics for judging existing colormaps, or newly designed ones,
> on all of these criteria?

I had some time on a plane today, so I wrote a little script for
visualizing colormaps (esp. WRT perceptual uniformity and
colorblindness). To try it:

$ git clone https://github.com/njsmith/pycam02ucs.git
$ cd pycam02ucs
$ ipython
In [1]: %matplotlib
In [2]: from pycam02ucs.viscm import viscm
In [3]: viscm("jet")

(Or substitute your favorite built-in colormap, or pass a matplotlib
colormap object, i.e. a callable that takes an array of values in the
range [0, 1] and returns an array of RGBA values with shape (n, 4).)

I'm attaching an example, plus an annotated example explaining what
the different bits show.

It's a bit crude, but has definitely reached the
fun-to-play-around-with stage :-). If anyone makes improvements send
me a PR!

Hidden feature: you can pass show_gamut=True to get a crude
approximation of the space of possible sRGB colors drawn onto the 3d
plot at the bottom. The idea is if trying to design a better colormap
it's useful to have a sense of what potential colors are available to
use. It's pretty crude and somewhat distracting though so I left it
off by default for now.

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

P.S. I just found
http://davidjohnstone.net/pages/lch-lab-colour-gradient-picker

On 22 December 2014 at 11:21, Phil Elson <pel...@gm...> wrote:

> Thanks for all the contributions so far. Looks like matplotlib is blessed
> with people who are far more knowledgeable than I on the subject, and I'd
> say we were pretty much at a consensus on requirements.
>
> Given these requirements, what we need is some proposed colormaps - Max's
> approach of generating an optimal solution in LAB space sounds interesting,
> as do the other approaches of minimising some parameters of existing
> colormaps.
>
> To facilitate this discussion, do we need a repository of proposed
> colormaps so that we can compare like with like? I notice that Mike Bostock
> has an interesting post to show various color spaces in d3.js which may be
> of interest http://bl.ocks.org/mbostock/3014589.
>
>
>
> On 4 December 2014 at 14:38, Maximilian Albert <
> max...@gm...> wrote:
>
>> Hi all,
>>
>> I had a discussion with Phil Elson about this last weekend during the
>> Bloomberg Open Source Day. I don't consider myself an expert on colormaps
>> by any means, but I started digging into them a while ago when I was
>> looking for a way of generating a perceptually linear *cyclic* colormap in
>> order to represent phase angle values. (I've been meaning to discuss this
>> issue on this list for a while but will do so in a different thread once I
>> get around to tidying up my results so far.) Phil encouraged me to reply to
>> this thread because he said that even non-expert views would be very
>> welcome, so here you go.
>>
>> Basically, I agree with most of what Nathaniel Smith suggested in his
>> email from November 21. I'm going to comment on some of his points inline
>> below and will finally suggest a way of designing a new colormap at the end.
>>
>>
>> Nathaniel Smith wrote:
>>
>> > it should be a sequential colormap [...]
>>
>> Agreed.
>>
>> > it should be perceptually uniform
>>
>> Agreed.
>>
>> > There's lots of research on how to measure perceptual distance --
>> > a colleague and I happen to have recently implemented a
>> > state-of-the-art model of this for another project, in case anyone
>> > wants to play with it [3].
>>
>> I haven't had time to check this out in detail yet, but it looks pretty
>> interesting and will certainly be very useful to assess the quality of any
>> suggestions. However, can this help to actually *design* a new colormap?
>> The answer might be hidden in the referenced paper [Luo2006], but I haven't
>> read it yet.
>>
>> > or just using good-old-L*a*b* is a reasonable quick-and-dirty
>> approximation.
>>
>> Can you elaborate how "dirty" you think using L*a*b* would be? (See my
>> suggestion for finding a new colormap below.)
>>
>> >- it should have a perceptually uniform luminance ramp, i.e. if you
>> > convert to greyscale it should still be uniform.
>>
>> Agreed. What's unclear to me is how large this luminance ramp should be.
>> We certainly can't go all the way to full luminance because this won't be
>> visible on a white background. This probably needs experimenting (again see
>> below).
>>
>> > - it should also have some kind of variation in hue, because
>> > hue variation is a really helpful additional cue to perception,
>> > having two cues is better than one, and there's no reason
>> > not to do it.
>>
>> Agreed.
>>
>> > - the hue variation should be chosen to produce reasonable results
>> > even for viewers with the more common types of colorblindness.
>> > (Which rules out things like red-to-green.)
>>
>> Agreed. Are you aware of any simple ways of avoiding the most common
>> issues? Are there any blog posts or papers on designing colormaps that are
>> suitable for colorblind people?
>>
>> > And, for bonus points, it would be nice to choose a hue ramp that
>> > still works if you throw away the luminance variation, because then we
>> > could use the version with varying luminance for 2d plots, and the
>> > version with just hue variation for 3d plots. (In 3d plots you really
>> > want to reserve the luminance channel for lighting/shading, because
>> > your brain is *really* good at extracting 3d shape from luminance
>> > variation. If the 3d surface itself has massively varying luminance
>> > then this screws up the ability to see shape.)
>>
>> Just out of interest, is there currently an easy way in matplotlib of
>> producing a 3d plot where luminance is used for lighting/shading as you
>> suggest?
>>
>>
>> Now the question is: how do we actually *design* a colormap with these
>> requirements? Leon Krischer's notebook [1] looks totally awesome, but if I
>> understand correctly the optimisation he uses "only" takes care of
>> linearising the luminance value, but this does not necessarily guarantee
>> that the hue values are also linear, right? It also feels somewhat clumsy
>> to me to start out with a colormap that's "wrong" (w.r.t. our requirements
>> above) and then "fix" it. However, the notebook looks like a great guidance
>> for finding suitable candidates and assessing their quality.
>>
>> It appears to me that a simple yet effective way of coming up with a good
>> colormap would be to pick two points in the L*a*b* color space that can be
>> represented by RGB values, connect them by a line and use the interpolated
>> values for the resulting colormap. Since L*a*b* space is (close to)
>> perceptually linear, this would pretty much guarantee all the requirements
>> above.
>>
>> What's missing is an easy way of doing this. I'm envisaging a simply GUI
>> which allows the user to easily pick two points in L*a*b* space, generates
>> a colormap from them as described above and also generates a few sample
>> plots to evaluate the quality of the colormap (along the lines of [1] or
>> the numerous blog posts linked to in the discussion). I am close to having
>> a prototype for such a GUI which should allow to do this relatively
>> painlessly. I'll try to finish it up over the weekend and will post here
>> once it's ready. Btw, if anyone has suggestions for sample datasets that
>> can help in assessing the quality of colormaps they would be much
>> appreciated.
>>
>> Any comments or clarifications of points that I misunderstood are very
>> welcome.
>>
>> Best wishes,
>> Max
>>
>> [1] http://nbviewer.ipython.org/gist/krischer/d35096a9d3b6da5846a5
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>