Re: [matplotlib-devel] Matplotlib's new default colormap
Hi all, I was made aware of this thread and thought I’d share a notebook I recently made for a similar purpose: http://nbviewer.ipython.org/gist/krischer/d35096a9d3b6da5846a5 http://nbviewer.ipython.org/gist/krischer/d35096a9d3b6da5846a5 (takes a while to load…) It attempts to “optimize colormaps by defining optimality as having a linear lightness across the colormap in LAB color space. It is very simple and not a proper optimization procedure. It just goes to LAB space, sets the lightness to the target lightness, and goes back to sRGB space. This does not always work as the LAB color space is much bigger than the RGB one but in many cases it produces fairly good results. The nice thing about this is that the lightness range can be chosen so it is does not always have to be stark white or black at the ends and some hue can be preserved. I am not sure if some similar functionality is useful to include into matplotlib (I don’t really think so) but if yes, let me know and I’ll give it a try. I guess it could also be extended to optimize towards monotonic changes in hue. Cheers and all the best! Lion -- 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=157005751iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib's new default colormap
I, for one, would love to see a pull request for this if you're game. Mike On 11/24/2014 04:27 AM, Lion Krischer wrote: Hi all, I was made aware of this thread and thought I’d share a notebook I recently made for a similar purpose: http://nbviewer.ipython.org/gist/krischer/d35096a9d3b6da5846a5 (takes a while to load…) It attempts to “optimize colormaps by defining optimality as having a linear lightness across the colormap in LAB color space. It is very simple and not a proper optimization procedure. It just goes to LAB space, sets the lightness to the target lightness, and goes back to sRGB space. This does not always work as the LAB color space is much bigger than the RGB one but in many cases it produces fairly good results. The nice thing about this is that the lightness range can be chosen so it is does not always have to be stark white or black at the ends and some hue can be preserved. I am not sure if some similar functionality is useful to include into matplotlib (I don’t really think so) but if yes, let me know and I’ll give it a try. I guess it could also be extended to optimize towards monotonic changes in hue. Cheers and all the best! Lion -- 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=157005751iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Michael Droettboom Science Software Branch Space Telescope Science Institute http://www.droettboom.com -- 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=157005751iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib's new default colormap
That is super cool. I was thinking about doing something similar, glad it has already been so well done. The example figures at the bottom bring up another point, we should have a canonical set of test figures, both for the color map and the defaults in general, I think that will really help with this discussion. That example could also be reused as a standard show-case for style-files. Tom On Mon Nov 24 2014 at 11:32:41 AM Michael Droettboom md...@stsci.edu wrote: I, for one, would love to see a pull request for this if you're game. Mike On 11/24/2014 04:27 AM, Lion Krischer wrote: Hi all, I was made aware of this thread and thought I’d share a notebook I recently made for a similar purpose: http://nbviewer.ipython.org/gist/krischer/d35096a9d3b6da5846a5 (takes a while to load…) It attempts to “optimize colormaps by defining optimality as having a linear lightness across the colormap in LAB color space. It is very simple and not a proper optimization procedure. It just goes to LAB space, sets the lightness to the target lightness, and goes back to sRGB space. This does not always work as the LAB color space is much bigger than the RGB one but in many cases it produces fairly good results. The nice thing about this is that the lightness range can be chosen so it is does not always have to be stark white or black at the ends and some hue can be preserved. I am not sure if some similar functionality is useful to include into matplotlib (I don’t really think so) but if yes, let me know and I’ll give it a try. I guess it could also be extended to optimize towards monotonic changes in hue. Cheers and all the best! Lion -- 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, FREEhttp://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing listMatplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Michael Droettboom Science Software Branch Space Telescope Science Institute http://www.droettboom.com -- 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=157005751iu=/ 4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- 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=157005751iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] subtle design difference with Wx backend from others
On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing efir...@hawaii.edu wrote: On 2014/11/23, 12:18 PM, Benjamin Root wrote: Reading through the backend_wx.py code, I noticed a small deviation from the other interactive backends. All other new_figure_manager_given_figure() separately creates a canvas and manager object (which, in turn, creates the window object) and hooks them all up. The manager would handle all window responsibilities such as creation/destruction and sizing. However, for the WX backend, this function just creates a FigureFrameWx object, which is the window widget. This object also becomes responsible for creating the canvas and the manager. This setup seems a bit backwards to me, but I am not entirely sure. It is definitely different. Does anybody know if it is merely a remnant of older designs (I think WX was the first backend)? What are the limitations of this approach, if any? Is there any interest in normalizing this backend design with the others (or vice versa)? In general, making the backends as similar as possible (and factoring out as much as possible) is good; but actually messing around with these things can be time consuming, painful, and hazardous. It's hard to test with all the different platforms and versions. Last I looked, and I doubt much has changed, the wx back-end required a fair bit of love -- there was a lot of extra refresh() calls being made in various places, most of which were unnecessary most of the time -- i.e. a bunch of extra refreshes. I've been hoping for literally years to find the time to go in an clean that up, but not yet So -- if someone can dedicate some time to clean up the wx back-end, then it wold make sense to look into normalizing this, too. But I agree with Eric, this is likely to be a significant job -- wouldn't tough unless your'e ready to commit to some real work. If it ain't broke. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- 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=157005751iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] subtle design difference with Wx backend from others
It is odd you mentioned the extra refreshes. I have to double-check my book examples, but I think I found that I needed to add some extra draw_idle() calls when using native wx widgets. This does raise another point. As a development policy, how should we treat the backends? Should we be free to change it up so long as it works well with Matplotlib, or should we be cautious and recognize that there are users who go down beyond the canvas layer? Ben Root On Mon, Nov 24, 2014 at 12:28 PM, Chris Barker chris.bar...@noaa.gov wrote: On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing efir...@hawaii.edu wrote: On 2014/11/23, 12:18 PM, Benjamin Root wrote: Reading through the backend_wx.py code, I noticed a small deviation from the other interactive backends. All other new_figure_manager_given_figure() separately creates a canvas and manager object (which, in turn, creates the window object) and hooks them all up. The manager would handle all window responsibilities such as creation/destruction and sizing. However, for the WX backend, this function just creates a FigureFrameWx object, which is the window widget. This object also becomes responsible for creating the canvas and the manager. This setup seems a bit backwards to me, but I am not entirely sure. It is definitely different. Does anybody know if it is merely a remnant of older designs (I think WX was the first backend)? What are the limitations of this approach, if any? Is there any interest in normalizing this backend design with the others (or vice versa)? In general, making the backends as similar as possible (and factoring out as much as possible) is good; but actually messing around with these things can be time consuming, painful, and hazardous. It's hard to test with all the different platforms and versions. Last I looked, and I doubt much has changed, the wx back-end required a fair bit of love -- there was a lot of extra refresh() calls being made in various places, most of which were unnecessary most of the time -- i.e. a bunch of extra refreshes. I've been hoping for literally years to find the time to go in an clean that up, but not yet So -- if someone can dedicate some time to clean up the wx back-end, then it wold make sense to look into normalizing this, too. But I agree with Eric, this is likely to be a significant job -- wouldn't tough unless your'e ready to commit to some real work. If it ain't broke. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- 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=157005751iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- 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=157005751iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] subtle design difference with Wx backend from others
On Mon, Nov 24, 2014 at 9:41 AM, Benjamin Root ben.r...@ou.edu wrote: It is odd you mentioned the extra refreshes. I have to double-check my book examples, but I think I found that I needed to add some extra draw_idle() calls when using native wx widgets. I haven't messed with widgets within MPL at all -- so I'm no help there. This does raise another point. As a development policy, how should we treat the backends? Should we be free to change it up so long as it works well with Matplotlib, or should we be cautious and recognize that there are users who go down beyond the canvas layer? I've toyed with using the guts of MPL as a generic for-something-other-than-plotting AGG renderer. But I think it's fair to not support that kind of use-case with guarantees of backwards compatibility. I do think a just-agg-drawing lib would be a nice think to have. So some day, it may make sense to spilt it our out of MPL, and then we'd need to worry about preserving the API, but while it's built into MPL, I wouldn't worry about it. -CHB Ben Root On Mon, Nov 24, 2014 at 12:28 PM, Chris Barker chris.bar...@noaa.gov wrote: On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing efir...@hawaii.edu wrote: On 2014/11/23, 12:18 PM, Benjamin Root wrote: Reading through the backend_wx.py code, I noticed a small deviation from the other interactive backends. All other new_figure_manager_given_figure() separately creates a canvas and manager object (which, in turn, creates the window object) and hooks them all up. The manager would handle all window responsibilities such as creation/destruction and sizing. However, for the WX backend, this function just creates a FigureFrameWx object, which is the window widget. This object also becomes responsible for creating the canvas and the manager. This setup seems a bit backwards to me, but I am not entirely sure. It is definitely different. Does anybody know if it is merely a remnant of older designs (I think WX was the first backend)? What are the limitations of this approach, if any? Is there any interest in normalizing this backend design with the others (or vice versa)? In general, making the backends as similar as possible (and factoring out as much as possible) is good; but actually messing around with these things can be time consuming, painful, and hazardous. It's hard to test with all the different platforms and versions. Last I looked, and I doubt much has changed, the wx back-end required a fair bit of love -- there was a lot of extra refresh() calls being made in various places, most of which were unnecessary most of the time -- i.e. a bunch of extra refreshes. I've been hoping for literally years to find the time to go in an clean that up, but not yet So -- if someone can dedicate some time to clean up the wx back-end, then it wold make sense to look into normalizing this, too. But I agree with Eric, this is likely to be a significant job -- wouldn't tough unless your'e ready to commit to some real work. If it ain't broke. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- 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=157005751iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- 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=157005751iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] subtle design difference with Wx backend from others
On 24 Nov 2014 12:42, Benjamin Root ben.r...@ou.edu wrote: It is odd you mentioned the extra refreshes. I have to double-check my book examples, but I think I found that I needed to add some extra draw_idle() calls when using native wx widgets. This does raise another point. As a development policy, how should we treat the backends? Should we be free to change it up so long as it works well with Matplotlib, or should we be cautious and recognize that there are users who go down beyond the canvas layer? Because the backends are pretty close I would like to think we can modify them, but by my own experience this is not the case. Whenever you want to do something more (but not too much) you as user just tweak the backend. That is one of the reasons behind MEP22. To offer a clean way to modify the backend without actually modifying it. @tacaswell was working on a PR along the lines of making the backend components reusable (not just the canvas) Ben Root On Mon, Nov 24, 2014 at 12:28 PM, Chris Barker chris.bar...@noaa.gov wrote: On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing efir...@hawaii.edu wrote: On 2014/11/23, 12:18 PM, Benjamin Root wrote: Reading through the backend_wx.py code, I noticed a small deviation from the other interactive backends. All other new_figure_manager_given_figure() separately creates a canvas and manager object (which, in turn, creates the window object) and hooks them all up. The manager would handle all window responsibilities such as creation/destruction and sizing. However, for the WX backend, this function just creates a FigureFrameWx object, which is the window widget. This object also becomes responsible for creating the canvas and the manager. This setup seems a bit backwards to me, but I am not entirely sure. It is definitely different. Does anybody know if it is merely a remnant of older designs (I think WX was the first backend)? What are the limitations of this approach, if any? Is there any interest in normalizing this backend design with the others (or vice versa)? In general, making the backends as similar as possible (and factoring out as much as possible) is good; but actually messing around with these things can be time consuming, painful, and hazardous. It's hard to test with all the different platforms and versions. Last I looked, and I doubt much has changed, the wx back-end required a fair bit of love -- there was a lot of extra refresh() calls being made in various places, most of which were unnecessary most of the time -- i.e. a bunch of extra refreshes. I've been hoping for literally years to find the time to go in an clean that up, but not yet So -- if someone can dedicate some time to clean up the wx back-end, then it wold make sense to look into normalizing this, too. But I agree with Eric, this is likely to be a significant job -- wouldn't tough unless your'e ready to commit to some real work. If it ain't broke. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- 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=157005751iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- 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=157005751iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- 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=157005751iu=/4140/ostg.clktrk___
