matplotlib-users Mailing List for matplotlib

Hi
I am using blitting and am not able to get it to work as I want.
I am using copy_from_bbox during the setup of my PyQt GUI to save a meshgrid as a starting empty background.
Then, once the GUI is loaded, the user can click on the meshgrid and a square is displayed on the selected pixel with blitting, so that no re-plotting needs to be done.
The problem is that between the copy_from_bbox call and the final GUI setup, there is some movement of the widgets (don’t really know why, surely PyQt layout adjustments).
This leads to a shift of the restored region, because the saved one (after the draw() call) is not the one which is finally displayed in the GUI. This can lead to strange display errors ...
I tried to trim down my code to the essential, I hope it’s short enough.
I am using Matplotlib 1.3.1 on OS X, but I am having this problem one or two years and had never time to tackle it (I have it also on Windows and Fedora)
Here is my code, just run it and click on the meshgrid, you will see it move down, so that the top of the red square is not drawn correctly.
https://gist.github.com/iMichka/9901318
In the case of my example the shift is quite small (I could live with a shift of one pixel ...), but in my real app there is more stuff and the shift is bigger ... the plot even overlaps with PyQt buttons ...
Is there any way to call copy_from_bbox when the PyQt GUI has stabilized ? This means after the PyQt event loop has finished refreshing, and not before the refreshing ?
Any help would be much appreciated :)
Michka

Hello Marry,
I am highly interested in getting "wrf_cape_3d" wrapped to be accessible in
Python. So far, that's how I calculate CAPE and CIN for my WRF outputs.
wrf_cape_3d is more robust comparing to the function in the SkewT script.
For some reason, I have no luck getting wrf_cape_2d working properly as it
throws a NaN error.
On Mon, Mar 31, 2014 at 2:25 PM, Mary Haley <ha...@uc...> wrote:
> Hi all,
>
> I’ve been following this thread somewhat peripherally.
>
> I’ve slowly started creating Python wrappers of some of the WRF Fortran
> calculation functions (not the graphical ones) that are used in NCL.
>
> You can see the list of the NCL ones at:
>
> http://www.ncl.ucar.edu/Document/Functions/wrf.shtml
>
> So far I’ve only wrapped these six: wrf_avo, wrf_tk, wrf_td, wrf_slp,
> wrf_rh, wrf_dbz.
>
> Would the wrf_cape_2d and wrf_cape_3d routines be of interest? These are
> specific to WRF data. I believe these are the same ones that Wanli is
> referring to.
>
> We also have the ones that we use for the basic Skew-T code in NCL, that
> Gökhan has been corresponding with Dennis on.
> I could wrap these as well. These routines are not advertised in NCL, but
> they are used by the Skew-T examples you see at:
>
> http://www.ncl.ucar.edu/Applications/skewt.shtml
>
> --Mary
>
> On Mar 31, 2014, at 11:41 AM, Wanli Wu <wu...@gm...> wrote:
>
> All,
>
> Another good example of Skew-T with all Parcel stability info including
> CIN, CAPE is produced through RIP4 (see this example:
> http://www.mmm.ucar.edu/mm5/WRF_post/RIP4/pages/rip_sample_cgm030_gif.htm).
> If this one can be duplicated with python, it'd great for the community.
>
> Wanli Wu
>
>
>
> On Mon, Mar 31, 2014 at 7:49 AM, Gökhan Sever <gok...@gm...>wrote:
>
>> Hi James,
>>
>> I have managed to run CLIMT's thermodyn.py . Most of the functions I
>> tested from within the Driver.f90 works fine except the CAPE and CIN
>> routines. I sent an e-mail to the author regarding this but nothing back
>> from him so far. Would you give a test if I send you a simple sounding
>> data? My system is Window 7 (x64) and using Python(XY). f2py uses the
>> gfortran provided in MinGW32 folder.
>>
>> Could you provide an example (with some test data) for Kerry Emanuel's
>> code? That code has definitely more functions than I need but it might be a
>> valuable source.
>>
>> As for the NCL, it is easy to interface to a WRF output, it also includes
>> a SkewT/LogP [https://www.ncl.ucar.edu/Applications/skewt.shtml], but
>> the CAPE estimation in this script is very sensitive to the number of
>> data-points, which I have bitten a couple of times. Dennis Shea has
>> provided some CAPE calculation routines coded in fortran. [Check under
>> http://www.cgd.ucar.edu/~shea/ for the files starting with cape*]. Yet I
>> have no luck wrapping them via f2py.
>>
>>
>> On Sat, Mar 29, 2014 at 7:11 PM, James Boyle <jsb...@gm...>wrote:
>>
>>> I have used the CAPE and CIN from ClMT - a bit of overkill but many
>>> useful functions:
>>> http://people.su.se/~rcaba/climt/
>>>
>>> I have also wrapped using f2py the the Fortran CAPE and CIN of Kerry
>>> Emanuel ( a prestigious source) in his convect code:
>>> http://eaps4.mit.edu/faculty/Emanuel/products
>>>
>>> If you prowl about in the NCL source distribution, you will find the
>>> fortran that the NCL skew - T uses.
>>> If you ask, Dennis Shea of NCAR might break the code out for you. It is
>>> trivial to wrap using f2py ( f77).
>>>
>>>
>>> On Mar 29, 2014, at 3:32 PM, Gökhan Sever <gok...@gm...> wrote:
>>>
>>> Hello,
>>>
>>> Lately, I am working on plotting sounding profiles on a SkewT/LogP
>>> diagram. The SkewT package which is located at
>>> https://github.com/tchubb/SkewT has a nice feature to lift a parcel on
>>> dry/moist adiabats. This is very useful to demonstrate the regions of CIN
>>> and CAPE overlaid with the full sounding.
>>>
>>> However, the package misses these diagnostic calculations. This is the
>>> only step holding me back to use Python only (migrating from NCL) for my
>>> plotting tasks. I am aware that these calculations are usually performed
>>> in fortran. Are there any routines wrapped in Python to calculate CAPE and
>>> CIN parameters? Any suggestions or comments would be really appreciated.
>>>
>>> --
>>> Gökhan
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>>
>>>
>>
>>
>> --
>> Gökhan
>>
>> _______________________________________________
>> Pyaos mailing list
>> Py...@li...
>> http://lists.johnny-lin.com/listinfo.cgi/pyaos-johnny-lin.com
>>
>>
> _______________________________________________
> Pyaos mailing list
> Py...@li...
> http://lists.johnny-lin.com/listinfo.cgi/pyaos-johnny-lin.com
>
>
>
-- 
Gökhan

I expected that floor(x) would return an integer especially since the docs
state:
Return the floor of the input, element-wise.
The floor of the scalar `x` is the largest integer `i`, such that
`i <= x`. It is often denoted as :math:`\lfloor x \rfloor`.
Any reason why it returns a float? Bug/feature?
Thanks, Mark

As for the rest of the two suggestions: [
https://github.com/pmarshwx/SHARPpy/tree/gui
https://github.com/PyAOS/aoslib]
there doesn't seem be routines included for CAPE and CIN calculations.
I am working on idealized orographic precipitation simulations in WRF that
will hopefully be presented in the Mountain Meteorology conference in
August. Perhaps I am extra cautious, but I need a good control especially
on CAPE calculation (independent of data-points, being able to specify
where to lift the parcel and specify mixed layer depth etc.).
This could be a good subject to discuss on the coming SciPy conference. The
abstract deadline is tomorrow. I might join if I can get some funding to
attend the conference. Is there any symposium planned for atmospheric
science people? Thanks again.
On Sat, Mar 29, 2014 at 6:32 PM, Gökhan Sever <gok...@gm...> wrote:
> Hello,
>
> Lately, I am working on plotting sounding profiles on a SkewT/LogP
> diagram. The SkewT package which is located at
> https://github.com/tchubb/SkewT has a nice feature to lift a parcel on
> dry/moist adiabats. This is very useful to demonstrate the regions of CIN
> and CAPE overlaid with the full sounding.
>
> However, the package misses these diagnostic calculations. This is the
> only step holding me back to use Python only (migrating from NCL) for my
> plotting tasks. I am aware that these calculations are usually performed
> in fortran. Are there any routines wrapped in Python to calculate CAPE and
> CIN parameters? Any suggestions or comments would be really appreciated.
>
> --
> Gökhan
>
-- 
Gökhan

Thanks Daniel. Your CAPE calculation approach looks robust. I will give it
a try with my sounding data. In the mean time, do you plan on putting a
function for CIN calculation?
On Sun, Mar 30, 2014 at 10:37 AM, Daniel Rothenberg <dar...@mi...>wrote:
> Hello Gokhan,
>
> I've written my own SkewT/LogP code with some lifted parcel calculations -
> it's included in a GitHub repo I use to maintain a collection of utilities
> I've written for analyzing output from a cloud resolving model I use. You
> can find my code for this purpose at
> https://github.com/darothen/crm-tools/blob/master/vis/soundings.py, along
> with other useful scripts.
>
> - Daniel Rothenberg
>
>
> On Sat, Mar 29, 2014 at 6:32 PM, Gökhan Sever <gok...@gm...>wrote:
>
>> Hello,
>>
>> Lately, I am working on plotting sounding profiles on a SkewT/LogP
>> diagram. The SkewT package which is located at
>> https://github.com/tchubb/SkewT has a nice feature to lift a parcel on
>> dry/moist adiabats. This is very useful to demonstrate the regions of CIN
>> and CAPE overlaid with the full sounding.
>>
>> However, the package misses these diagnostic calculations. This is the
>> only step holding me back to use Python only (migrating from NCL) for my
>> plotting tasks. I am aware that these calculations are usually performed
>> in fortran. Are there any routines wrapped in Python to calculate CAPE and
>> CIN parameters? Any suggestions or comments would be really appreciated.
>>
>> --
>> Gökhan
>>
>> _______________________________________________
>> Pyaos mailing list
>> Py...@li...
>> http://lists.johnny-lin.com/listinfo.cgi/pyaos-johnny-lin.com
>>
>>
>
-- 
Gökhan

Thanks Alex. This seems to be the easiest way to approach the problem.
However, for the sake of reproducibility, I am looking for a way to
interface to one of the common fortran routines for the task. Your
suggested approach will require some sort of interpolation at the very
least to make the estimation number of data point insensitive. Putting this
in my TODO list.
On Sat, Mar 29, 2014 at 7:56 PM, Alex Goodman <ale...@co...>wrote:
> You can easily visualize the CAPE and CIN with matplotlib using
> fill_between() on the environmental and parcel temperature curves. As for
> actually calculating it though, I don't know of a way to do it directly
> from matplotlib. There are probably several other python packages out there
> that can, but I am not familiar with them. In any case, why not just write
> your own function for calculating the CAPE and CIN? It is a bit surprising
> that this functionality isn't be included in the SkewT package, but since
> you can use it to get the parcel temperature curve, you should be able to
> calculate the CAPE and CIN rather easily by simply discretizing their
> respective formulas. Here's a rough example:
>
> import numpy as np
> cape = 9.8 * np.sum(dz * (Tp - T) / T)
>
> Where Tp and T are the parcel and environmental temperature arrays
> respectively, and dz are the height differences between layers. You would
> of course need to perform the sum from the LFC to EL for CAPE, so the
> arrays would have to to be subsetted. With numpy the easiest way to do this
> is with fancy indexing, eg:
>
> levs = (z >= LFC) & (z <= EL)
> Tp = Tp[levs]
> T = T[levs]
> where z is your array of heights (or pressure levels).
>
> Does this help?
>
> Alex
>
>
> On Sat, Mar 29, 2014 at 4:32 PM, Gökhan Sever <gok...@gm...>wrote:
>
>> Hello,
>>
>> Lately, I am working on plotting sounding profiles on a SkewT/LogP
>> diagram. The SkewT package which is located at
>> https://github.com/tchubb/SkewT has a nice feature to lift a parcel on
>> dry/moist adiabats. This is very useful to demonstrate the regions of CIN
>> and CAPE overlaid with the full sounding.
>>
>> However, the package misses these diagnostic calculations. This is the
>> only step holding me back to use Python only (migrating from NCL) for my
>> plotting tasks. I am aware that these calculations are usually performed
>> in fortran. Are there any routines wrapped in Python to calculate CAPE and
>> CIN parameters? Any suggestions or comments would be really appreciated.
>>
>> --
>> Gökhan
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>
>
> --
> Alex Goodman
> Graduate Research Assistant
> Department of Atmospheric Science
> Colorado State University
>
-- 
Gökhan

Hi James,
I have managed to run CLIMT's thermodyn.py . Most of the functions I tested
from within the Driver.f90 works fine except the CAPE and CIN routines. I
sent an e-mail to the author regarding this but nothing back from him so
far. Would you give a test if I send you a simple sounding data? My system
is Window 7 (x64) and using Python(XY). f2py uses the gfortran provided in
MinGW32 folder.
Could you provide an example (with some test data) for Kerry Emanuel's
code? That code has definitely more functions than I need but it might be a
valuable source.
As for the NCL, it is easy to interface to a WRF output, it also includes
 a SkewT/LogP [https://www.ncl.ucar.edu/Applications/skewt.shtml], but the
CAPE estimation in this script is very sensitive to the number of
data-points, which I have bitten a couple of times. Dennis Shea has
provided some CAPE calculation routines coded in fortran. [Check under
http://www.cgd.ucar.edu/~shea/ for the files starting with cape*]. Yet I
have no luck wrapping them via f2py.
On Sat, Mar 29, 2014 at 7:11 PM, James Boyle <jsb...@gm...> wrote:
> I have used the CAPE and CIN from ClMT - a bit of overkill but many useful
> functions:
> http://people.su.se/~rcaba/climt/
>
> I have also wrapped using f2py the the Fortran CAPE and CIN of Kerry
> Emanuel ( a prestigious source) in his convect code:
> http://eaps4.mit.edu/faculty/Emanuel/products
>
> If you prowl about in the NCL source distribution, you will find the
> fortran that the NCL skew - T uses.
> If you ask, Dennis Shea of NCAR might break the code out for you. It is
> trivial to wrap using f2py ( f77).
>
>
> On Mar 29, 2014, at 3:32 PM, Gökhan Sever <gok...@gm...> wrote:
>
> Hello,
>
> Lately, I am working on plotting sounding profiles on a SkewT/LogP
> diagram. The SkewT package which is located at
> https://github.com/tchubb/SkewT has a nice feature to lift a parcel on
> dry/moist adiabats. This is very useful to demonstrate the regions of CIN
> and CAPE overlaid with the full sounding.
>
> However, the package misses these diagnostic calculations. This is the
> only step holding me back to use Python only (migrating from NCL) for my
> plotting tasks. I am aware that these calculations are usually performed
> in fortran. Are there any routines wrapped in Python to calculate CAPE and
> CIN parameters? Any suggestions or comments would be really appreciated.
>
> --
> Gökhan
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
-- 
Gökhan

On Sun, Mar 30, 2014 at 4:36 PM, Thomas Chubb <tho...@mo...>wrote:
> Gokhan [and others],
>
> Thanks for showing an interest in SkewT. This has been a side project for
> me for a little while now, and only publicly available on PyPI in the last
> 12 months or so. I haven't been maintaining the github repository, so
> please get the latest version from here:
>
> https://pypi.python.org/pypi/SkewT
>
> I'll take the github repository down in the very near future unless I hear
> howls of protest.
>
> Regarding CAPE and CIN, these have been on my to-do list for a while. I
> agree that it would be a nice feature to include on the SkewT plots, but I
> don't really know the best way to proceed, but it would be nice to get some
> thoughts from the community.
>
>
Thomas (and others),
As the author of the original matplotlib code that you ran with (and
extended greatly!) I wanted to note two things:
1) Fixes to matplotlib to add skew transforms and make them work better for
plots is in master and should go out in 1.4. A basic version
of the SkewT plot is in the tree under examples/api/skewt.py
2) I've been (slowly) working on fleshing out that script with more
features (and more class-based) on a branch here:
https://github.com/metpy/MetPy/blob/skewt/metpy/plots/skewt.py
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

plt.clf()
solved all my problems. I simply did not notice this simple solution. 
Whenever I saw "memory leak" there was given the advice to upgrade older 
versions.
Thanks a lot,
Foehn
Am 2014年03月30日 13:55, schrieb Remo Goetschi:
> Hi Föhn,
>
> By default, the pyplot interface (recall that it is a Matlab-like state
> machine) does not release a figure's memory. You need to do this by hand
> by calling the clf() method after every plot you make:
> ...
> plt.close()
> plt.clf()
>
> Stackoverflow contains a few threads about the subject.
>
> Best,
> Remo
>
>

Hi Föhn,
By default, the pyplot interface (recall that it is a Matlab-like state 
machine) does not release a figure's memory. You need to do this by hand 
by calling the clf() method after every plot you make:
...
plt.close()
plt.clf()
Stackoverflow contains a few threads about the subject.
Best,
Remo
On 30.03.2014 13:33, Foehn wrote:
> I am using the matplotlib, basemap and numpy versions delivered with
> Ubuntu 12.04. I know the versions are outdated and should be replaced by
> something new. But I do not want to install "alien" versions, because
> sometimes you can run into problems with dependencies and so on.
>
> My problem now is a more elaborated basemap application that dies of
> memory hunger in course of the time. I have a workaround that splits
> the program into chunks small enough not to die. For several reasons his
> is not ideal.
>
> I condensed the memory leak problem for my machine down to a rudimentary
> program. My question to the community with up to date
> (LINUX-)maplotlibs: Does it still cause a memory problem or not. If
> "yes" I will stick to my old matplotlib version, if "no" I consider a
> change.
>
> The Program can be found here:
>
> https://www.wuala.com/Foehn/Sonstiges/testmplmemleak/?key=nEhr83BTW4tx
>
>
> Thanks for the help,
> Föhn
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

I am using the matplotlib, basemap and numpy versions delivered with 
Ubuntu 12.04. I know the versions are outdated and should be replaced by 
something new. But I do not want to install "alien" versions, because 
sometimes you can run into problems with dependencies and so on.
My problem now is a more elaborated basemap application that dies of 
memory hunger in course of the time. I have a workaround that splits 
the program into chunks small enough not to die. For several reasons his 
is not ideal.
I condensed the memory leak problem for my machine down to a rudimentary 
program. My question to the community with up to date 
(LINUX-)maplotlibs: Does it still cause a memory problem or not. If 
"yes" I will stick to my old matplotlib version, if "no" I consider a 
change.
The Program can be found here:
https://www.wuala.com/Foehn/Sonstiges/testmplmemleak/?key=nEhr83BTW4tx
Thanks for the help,
Föhn

You can easily visualize the CAPE and CIN with matplotlib using
fill_between() on the environmental and parcel temperature curves. As for
actually calculating it though, I don't know of a way to do it directly
from matplotlib. There are probably several other python packages out there
that can, but I am not familiar with them. In any case, why not just write
your own function for calculating the CAPE and CIN? It is a bit surprising
that this functionality isn't be included in the SkewT package, but since
you can use it to get the parcel temperature curve, you should be able to
calculate the CAPE and CIN rather easily by simply discretizing their
respective formulas. Here's a rough example:
import numpy as np
cape = 9.8 * np.sum(dz * (Tp - T) / T)
Where Tp and T are the parcel and environmental temperature arrays
respectively, and dz are the height differences between layers. You would
of course need to perform the sum from the LFC to EL for CAPE, so the
arrays would have to to be subsetted. With numpy the easiest way to do this
is with fancy indexing, eg:
levs = (z >= LFC) & (z <= EL)
Tp = Tp[levs]
T = T[levs]
where z is your array of heights (or pressure levels).
Does this help?
Alex
On Sat, Mar 29, 2014 at 4:32 PM, Gökhan Sever <gok...@gm...> wrote:
> Hello,
>
> Lately, I am working on plotting sounding profiles on a SkewT/LogP
> diagram. The SkewT package which is located at
> https://github.com/tchubb/SkewT has a nice feature to lift a parcel on
> dry/moist adiabats. This is very useful to demonstrate the regions of CIN
> and CAPE overlaid with the full sounding.
>
> However, the package misses these diagnostic calculations. This is the
> only step holding me back to use Python only (migrating from NCL) for my
> plotting tasks. I am aware that these calculations are usually performed
> in fortran. Are there any routines wrapped in Python to calculate CAPE and
> CIN parameters? Any suggestions or comments would be really appreciated.
>
> --
> Gökhan
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
-- 
Alex Goodman
Graduate Research Assistant
Department of Atmospheric Science
Colorado State University

On 28.03.2014 19:13, Pierre Haessig wrote:
> Hi,
>
> I just ran across this new Qt "add-on" for data visualization :
> blog.qt.digia.com/blog/2014/03/26/qt-data-visualization-1-0-released/
>
> It's a bit off-topic because I think there is not (yet?) a Python
> binding,
 From the PyQt mailing list:
"""
PyQtDataVisualization v1.0 has been released. These are Python bindings
for Digia's Qt Data Visualization library and PyQt5, see...
http://qt.digia.com/Product/Qt-Enterprise-Features/Advanced-Data-Visualization/
PyQtDataVisualization is bundled with PyQt. It is not available under 
an open source license.
Phil
"""
Anyways, being not open source products, the interest is limited.
For Qt the natural choice would be Qwt but then the problem would be to 
get a wrapper able to work with PySide, PyQt4 and PyQt5.
Because of those (an other) issues I am currently using matplotlib in 
my PyQt applications.
Armando

Hello,
Lately, I am working on plotting sounding profiles on a SkewT/LogP diagram.
The SkewT package which is located at https://github.com/tchubb/SkewT has a
nice feature to lift a parcel on dry/moist adiabats. This is very useful to
demonstrate the regions of CIN and CAPE overlaid with the full sounding.
However, the package misses these diagnostic calculations. This is the only
step holding me back to use Python only (migrating from NCL) for my
plotting tasks. I am aware that these calculations are usually performed
in fortran. Are there any routines wrapped in Python to calculate CAPE and
CIN parameters? Any suggestions or comments would be really appreciated.
-- 
Gökhan

http://2sn.org/python3/color.py
On 30 March 2014 07:27, Emilia Petrisor <emi...@gm...> wrote:
> Hi all,
>
> While working on this IPython Notebook
> http://nbviewer.ipython.org/github/empet/Math/blob/master/DomainColoring.ipynb
> I wanted to compare the visual images of the same complex-valued function
> generated by the classical domain coloring method, using HSV, respectively
> HSL color model.
>
> Unfortunately there is no matplotlib.colors.hsl_to_rgb(array) function,
> only colorsys.hsl_to_rgb(h,s,l). The latter acts on each pixel and is time
> consuming.
>
> My question is, there is a special reason for which hsl_to_rgb is not
> implemented in matplotlib.colors for arrays?
> I also looked in skimage.color
> http://scikit-image.org/docs/dev/api/skimage.color.html and couldn't find
> such a function.
>
> Is there a package containing such a conversion?
> Thank you!
>
> Em
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hi all,
While working on this IPython Notebook
 http://nbviewer.ipython.org/github/empet/Math/blob/master/DomainColoring.ipynb<about:invalid#zClosurez>
I wanted to compare the visual images of the same complex-valued function
generated by the classical domain coloring method, using HSV, respectively
HSL color model.
Unfortunately there is no matplotlib.colors.hsl_to_rgb(array) function,
only colorsys.hsl_to_rgb(h,s,l). The latter acts on each pixel and is time
consuming.
My question is, there is a special reason for which hsl_to_rgb is not
implemented in matplotlib.colors for arrays?
 I also looked in skimage.color
http://scikit-image.org/docs/dev/api/skimage.color.html and couldn't find
such a function.
Is there a package containing such a conversion?
Thank you!
Em

sometimes, we need to plot array value on a grid, for example
a=np.array([[1,3,5], [2,4,6]])
is shown as
+------+------+------+
| 1 | 3 | 5 |
 +------+------+------+
| 2 | 4 | 6 |
 +------+------+------+
Is there any ready-to-use method?
thanks

Hi Ian
Thanks for your reply and help. I see your point. I guess it is only the
BoundaryNorm where it would make sense to have contourf use the boundary
levels from the norm. In my real problem described by the above example I
have long forgotten the levs variable when I arrive at the contourf point.
I will therefore instead just use levels=norm.boundaries.
Best regards,
Jesper
2014年03月28日 15:17 GMT+01:00 Ian Thomas <ian...@gm...>:
> On 28 March 2014 12:56, Jesper Larsen <jes...@gm...> wrote:
>
>> I believe the normalization behaviour is wrong for contourf at least when
>> using a BoundaryNorm. In the script below I am using the same norm to plot
>> the same data using contourf and pcolormesh. The color should change around
>> an x value of 0.15 but it is shifted somewhat for contourf. I do realize
>> that the pcolormesh is in principle shifted a little - but with a grid
>> spacing of 0.001 that should not matter. Please see the example script
>> below.
>>
>> Best regards,
>> Jesper
>>
>> """
>> Test inconsistent normalization behaviour for matplotlib
>> """
>> import numpy as np
>> import matplotlib.pyplot as plt
>> from matplotlib.colors import from_levels_and_colors
>>
>> # Make custom colormap and norm
>> levs = [0.0, 0.1, 0.2]
>> cols = [[0.00392156862745098, 0.23137254901960785, 0.07450980392156863],
>> [0.00392156862745098, 0.49019607843137253, 0.15294117647058825]]
>> extend = 'neither'
>> cmap, norm = from_levels_and_colors(levs, cols, extend)
>>
>> # Setup testdata
>> a = np.arange(0.05, 0.15, 0.001, dtype=np.float_)
>> a, b = np.meshgrid(a, a)0
>> plt.contourf(a, b, a, norm=norm, cmap=cmap, antialiased=False)
>> plt.savefig('contourf.png')
>> plt.clf()
>> plt.pcolormesh(a, b, a, norm=norm, cmap=cmap, antialiased=False)
>> plt.savefig('pcolormesh.png')
>>
>
> Jesper,
>
> Regardless of whether you specify a colormap and norm, if you want
> contourf to calculate contours at particular levels
> then you need to specify those levels. If you don't then contourf will
> choose the levels for you, and in your case these are chosen to be
> [0.045 0.06 0.075 0.09 0.105 0.12 0.135 0.15 ]
> which is why you see the color transition at x=0.105.
>
> To fix this, change your contourf line from
> plt.contourf(a, b, a, norm=norm, cmap=cmap, antialiased=False)
> to
> plt.contourf(a, b, a, norm=norm, cmap=cmap, antialiased=False, levels=levs)
> and you will get exactly what you want.
>
> Ian
>

By the way.. don't know if it's important but I'm running that under OSX
Mavericks 10.9.2
On Fri, Mar 28, 2014 at 8:40 PM, Jorge Ferrando <jor...@gm...> wrote:
> Hi Sterling.
>
> Sorry, the line is this:
>
> asfdll = loadLibrary('libAPI.dylib')
>
>
> On Fri, Mar 28, 2014 at 8:38 PM, Sterling Smith <sm...@fu...>wrote:
>
>> You forgot to add the line that causes the problems.
>>
>> You might want to give a minimum self contained working example.
>>
>> -Sterling
>>
>> On Mar 28, 2014, at 12:20PM, Jorge Ferrando wrote:
>>
>> > Hello
>> >
>> > I'm workign on a project where we are using ctypes and I wanted to plot
>> some data with matplotlib.
>> >
>> > Everything is running fine, but as soon as I add this line:
>> >
>> > The project crashes with this error:
>> >
>> > File "........./myfile.py", line 117, in loadLibrary
>> > return cdll.LoadLibrary(library)
>> > File
>> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py",
>> line 443, in LoadLibrary
>> > return self._dlltype(name)
>> > File
>> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py",
>> line 365, in __init__
>> > self._handle = _dlopen(self._name, mode)
>> > OSError: dlopen(libAPI.dylib, 6): initializer function 0x7fff9568c26e
>> not in mapped image for /Users/jorfermo/Desarrollo//libAPI.dylib
>> >
>> > It seems to be that there's a conflict between ctypes library and
>> matplotlib but i failed to find a workaround to this error.
>> >
>> > Any Idea how to solve it?
>> >
>> > Thank you
>> >
>> > Jorge
>> >
>> ------------------------------------------------------------------------------
>> > _______________________________________________
>> > Matplotlib-users mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>

Hi Sterling.
Sorry, the line is this:
asfdll = loadLibrary('libAPI.dylib')
On Fri, Mar 28, 2014 at 8:38 PM, Sterling Smith <sm...@fu...>wrote:
> You forgot to add the line that causes the problems.
>
> You might want to give a minimum self contained working example.
>
> -Sterling
>
> On Mar 28, 2014, at 12:20PM, Jorge Ferrando wrote:
>
> > Hello
> >
> > I'm workign on a project where we are using ctypes and I wanted to plot
> some data with matplotlib.
> >
> > Everything is running fine, but as soon as I add this line:
> >
> > The project crashes with this error:
> >
> > File "........./myfile.py", line 117, in loadLibrary
> > return cdll.LoadLibrary(library)
> > File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py",
> line 443, in LoadLibrary
> > return self._dlltype(name)
> > File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py",
> line 365, in __init__
> > self._handle = _dlopen(self._name, mode)
> > OSError: dlopen(libAPI.dylib, 6): initializer function 0x7fff9568c26e
> not in mapped image for /Users/jorfermo/Desarrollo//libAPI.dylib
> >
> > It seems to be that there's a conflict between ctypes library and
> matplotlib but i failed to find a workaround to this error.
> >
> > Any Idea how to solve it?
> >
> > Thank you
> >
> > Jorge
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

You forgot to add the line that causes the problems.
You might want to give a minimum self contained working example.
-Sterling
On Mar 28, 2014, at 12:20PM, Jorge Ferrando wrote:
> Hello
> 
> I'm workign on a project where we are using ctypes and I wanted to plot some data with matplotlib.
> 
> Everything is running fine, but as soon as I add this line:
> 
> The project crashes with this error:
> 
> File "........./myfile.py", line 117, in loadLibrary
> return cdll.LoadLibrary(library)
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 443, in LoadLibrary
> return self._dlltype(name)
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 365, in __init__
> self._handle = _dlopen(self._name, mode)
> OSError: dlopen(libAPI.dylib, 6): initializer function 0x7fff9568c26e not in mapped image for /Users/jorfermo/Desarrollo//libAPI.dylib
> 
> It seems to be that there's a conflict between ctypes library and matplotlib but i failed to find a workaround to this error.
> 
> Any Idea how to solve it?
> 
> Thank you
> 
> Jorge
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hello
I'm workign on a project where we are using ctypes and I wanted to plot
some data with matplotlib.
Everything is running fine, but as soon as I add this line:
The project crashes with this error:
File "........./myfile.py", line 117, in loadLibrary
 return cdll.LoadLibrary(library)
 File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py",
line 443, in LoadLibrary
 return self._dlltype(name)
 File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py",
line 365, in __init__
 self._handle = _dlopen(self._name, mode)
OSError: dlopen(libAPI.dylib, 6): initializer function 0x7fff9568c26e not
in mapped image for /Users/jorfermo/Desarrollo//libAPI.dylib
It seems to be that there's a conflict between ctypes library and
matplotlib but i failed to find a workaround to this error.
Any Idea how to solve it?
Thank you
Jorge

Hi,
I just ran across this new Qt "add-on" for data visualization :
blog.qt.digia.com/blog/2014/03/26/qt-data-visualization-1-0-released/
It's a bit off-topic because I think there is not (yet?) a Python
binding, but there is a demo video which is worth taking a look at.
The video doesn't mention the API so the question is open : how easy is
it to build these visualization GUIs, compared to Mayavi for instance ?
(one minor difference at least... not open source)
In the same category, but focusing on 2D plots, I see that Digia has
also produced a "Qt Charts" add-on. This one has a Python binding
http://www.riverbankcomputing.co.uk/software/pyqtchart/intro (commercial
license only)
-- 
Pierre

On 28 March 2014 12:56, Jesper Larsen <jes...@gm...> wrote:
> I believe the normalization behaviour is wrong for contourf at least when
> using a BoundaryNorm. In the script below I am using the same norm to plot
> the same data using contourf and pcolormesh. The color should change around
> an x value of 0.15 but it is shifted somewhat for contourf. I do realize
> that the pcolormesh is in principle shifted a little - but with a grid
> spacing of 0.001 that should not matter. Please see the example script
> below.
>
> Best regards,
> Jesper
>
> """
> Test inconsistent normalization behaviour for matplotlib
> """
> import numpy as np
> import matplotlib.pyplot as plt
> from matplotlib.colors import from_levels_and_colors
>
> # Make custom colormap and norm
> levs = [0.0, 0.1, 0.2]
> cols = [[0.00392156862745098, 0.23137254901960785, 0.07450980392156863],
> [0.00392156862745098, 0.49019607843137253, 0.15294117647058825]]
> extend = 'neither'
> cmap, norm = from_levels_and_colors(levs, cols, extend)
>
> # Setup testdata
> a = np.arange(0.05, 0.15, 0.001, dtype=np.float_)
> a, b = np.meshgrid(a, a)0
> plt.contourf(a, b, a, norm=norm, cmap=cmap, antialiased=False)
> plt.savefig('contourf.png')
> plt.clf()
> plt.pcolormesh(a, b, a, norm=norm, cmap=cmap, antialiased=False)
> plt.savefig('pcolormesh.png')
>
Jesper,
Regardless of whether you specify a colormap and norm, if you want contourf
to calculate contours at particular levels
then you need to specify those levels. If you don't then contourf will
choose the levels for you, and in your case these are chosen to be
[0.045 0.06 0.075 0.09 0.105 0.12 0.135 0.15 ]
which is why you see the color transition at x=0.105.
To fix this, change your contourf line from
plt.contourf(a, b, a, norm=norm, cmap=cmap, antialiased=False)
to
plt.contourf(a, b, a, norm=norm, cmap=cmap, antialiased=False, levels=levs)
and you will get exactly what you want.
Ian

Hi matplotlib users,
I believe the normalization behaviour is wrong for contourf at least when
using a BoundaryNorm. In the script below I am using the same norm to plot
the same data using contourf and pcolormesh. The color should change around
an x value of 0.15 but it is shifted somewhat for contourf. I do realize
that the pcolormesh is in principle shifted a little - but with a grid
spacing of 0.001 that should not matter. Please see the example script
below.
Best regards,
Jesper
"""
Test inconsistent normalization behaviour for matplotlib
"""
import numpy as np
import matplotlib.pyplot as plt
from matplotlib.colors import from_levels_and_colors
# Make custom colormap and norm
levs = [0.0, 0.1, 0.2]
cols = [[0.00392156862745098, 0.23137254901960785, 0.07450980392156863],
[0.00392156862745098, 0.49019607843137253, 0.15294117647058825]]
extend = 'neither'
cmap, norm = from_levels_and_colors(levs, cols, extend)
# Setup testdata
a = np.arange(0.05, 0.15, 0.001, dtype=np.float_)
a, b = np.meshgrid(a, a)
plt.contourf(a, b, a, norm=norm, cmap=cmap, antialiased=False)
plt.savefig('contourf.png')
plt.clf()
plt.pcolormesh(a, b, a, norm=norm, cmap=cmap, antialiased=False)
plt.savefig('pcolormesh.png')