matplotlib-devel Mailing List for matplotlib

Not sure why my message didn't go through earlier, but yes, the issue 
already exists in the system, see 
https://github.com/matplotlib/matplotlib/issues/4092
On 07/04/15 19:07, Benjamin Root wrote:
> Yes, this was discovered recently in connection to changes in how idle 
> events were handled. I don't recall if there was an issue created for 
> it, though.
>
> On Tue, Apr 7, 2015 at 11:48 AM, Michael Kaufman <kau...@or... 
> <mailto:kau...@or...>> wrote:
>
> Hi All,
>
> I don't have time at the moment to submit a ticket, but I thought I'd
> see if anyone else is having this problem:
>
> With latest master on 1.5-devel using GTKAgg backend, (and in ipython
> 3.0.0-dev, python 2.7.8, MacOSX 10.9.5) if I do figure() and nothing
> else, and then run 'top', I see Python running 100% CPU for the
> process.
> Closing the figure stops Python hogging the CPU.
>
> With latest 1.4.x, I do not see it.
>
> M
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Yes, this was discovered recently in connection to changes in how idle
events were handled. I don't recall if there was an issue created for it,
though.
On Tue, Apr 7, 2015 at 11:48 AM, Michael Kaufman <kau...@or...> wrote:
> Hi All,
>
> I don't have time at the moment to submit a ticket, but I thought I'd
> see if anyone else is having this problem:
>
> With latest master on 1.5-devel using GTKAgg backend, (and in ipython
> 3.0.0-dev, python 2.7.8, MacOSX 10.9.5) if I do figure() and nothing
> else, and then run 'top', I see Python running 100% CPU for the process.
> Closing the figure stops Python hogging the CPU.
>
> With latest 1.4.x, I do not see it.
>
> M
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi All,
I don't have time at the moment to submit a ticket, but I thought I'd 
see if anyone else is having this problem:
With latest master on 1.5-devel using GTKAgg backend, (and in ipython 
3.0.0-dev, python 2.7.8, MacOSX 10.9.5) if I do figure() and nothing 
else, and then run 'top', I see Python running 100% CPU for the process. 
Closing the figure stops Python hogging the CPU.
With latest 1.4.x, I do not see it.
M

I guess you could just load some test patterns into any commercial software
graphics or design package that supports color gamut alarms, and try some
typical printer settings to make sure that the candidate color maps aren't
excessively blowing the boundaries. I'm not advocating that the default
color map needs to be perfectly reproducible in print, but it might be
worth sanity checking this; it might mean avoiding bright greens and
yellows for example. I see that PIL/pillow contains littlecms support and I
see its ImageCms.py file contains a GAMUTCHECK flag, so it might be
possible to use that, along with some common icc profiles to automate the
checking, or build it into an optimiser as a constraint.
On 6 April 2015 at 15:57, Nathaniel Smith <nj...@po...> wrote:
> On Apr 5, 2015 8:29 PM, "gary ruben" <gar...@gm...> wrote:
> >
> > Just wondering whether anyone has suggested checking candidate colormaps
> against typical printer color gamuts?
>
> How would you go about doing this in practice? Is it even possible to
> choose a subset of sRGB space and have printers take advantage of that when
> doing gamut mapping? (I guess I always assumed that printer gamut mapping
> applied to an RGB image would map all of RGB into their gamut, so there
> would be no advantage to restricting oneself go a subspace. But maybe I'm
> wrong -- color management is pretty fancy these days.)
>
> -n
>