matplotlib-users Mailing List for matplotlib (Page 5)

Robert Kern wrote:
>> I guess that means that the data files are being installed outside of 
>> site-packages/matplotlib where would that be?
> 
> 
> Probably 
> /System/Libraray/Frameworks/Python.framework/Versions/Current/share/...
That's where they are put by the 2.3 package
> I always use the following setup.cfg when building matplotlib:
> 
> [install]
> install-data=/usr/local
> 
> You can check where the package is placing the data files by looking at 
> matplotlib-<etc>.mpkg/Contents/Packages/matplotlib-data-<etc>.pkg/Contents/Info.plist 
> under the IFPkgFlagDefaultLocation key. Note that this isn't quite the 
> same as the install-data. It is usually <install-data>/share/matplotlib.
> 
> At my request, matplotlib now searches /usr/local/share/matplotlib by 
> default on OS X.
The 2.4 package is putting it in:
/usr/local/share/share/matplotlib/
Note the double "share". I'm guessing that's the problem. I don't have 
the time to dig into this further right now, but if someone just knows 
how to fix it and can tell me, great!
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

I can no longer download the users guide from the matplotlib homepage. Can 
someone else check if it is corrupt?
That's the message I am getting.
thanks,
Danny

John Hunter wrote:
>>>>>>"Chris" == Chris Barker <Chr...@no...> writes:
> Chris> I've also enclosed my write-up of how to setup and build a
> Chris> static version on OS-X. Comments on that would be great
> Chris> too.
> 
> Chris> Other thoughts?
> 
> I think all of this looks good. My only comment is that I think it
> would save work in the long run to not use static libs in the static
> dir, but instead put in the src trees for zlib, libpng and freetype,
> because then it can be reused by all other platforms (win32, UNIX*,
> linux, OSX...)
This is a fine idea, but I'm not going to do it. If someone else does, 
I'll update my docs with the new info. Basically, I don't know how to 
make setup.py build the libs inside the tree, and I'm not sure I want to 
figure it out. I'm spent more time on this than I intended as it is.
A small note: OS-X includes zib, so that's not needed, at least for OS-X.
One other concern: This will mean that those libs might not match the 
versions used by other python packages. Would there be any conflict if 
there are essentially two versions of the same lib both linked to python 
at the same time?
 > freetype
> would take a little thought because of its more complicated dir
> structure.
True, but it does build with a simple "make", so it may not be a big deal.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hi,
I am having a problem with plotting a single piece of data on the graph.
This is the code I am trying to run:
a = [3]
d = [1118188800]
new_date = [dates.date2num(datetime.fromtimestamp(d[0]))]
fig = Figure()
canvas = FigureCanvasAgg(fig)
ax = fig.gca()
dayloc = dates.DayLocator()
datform = dates.DateFormatter('%b %d')
ax.plot_date(new_date, a, 'b-')
ax.xaxis.set_major_locator(dayloc)
ax.xaxis.set_major_formatter(datform)
ax.autoscale_view()
canvas.print_figure('plot.png', dpi=75)
What happens is that the date axis (x-axis) seems to get values printed very
close to each other, in fact they seems to be overlapping each other so much,
all I see is an uneven black line on the bottom of the graph where the dates
should be.
For this graph, usually there is more than one date and then I want the graph to
automatically set the range for me, but in this case I am not sure how to set
the axis to show the date I plot plus a few more on each side decently spaced.
The problem does not appear for the y-axis where it shows a few integers to each
side of '3'.
Any help with this will be appreciated.
Thanks,
Maria Khomenko
University of Toronto, Argon Team

Hi John,
When creating a py2exe version of my app with the 0.82 build it fails 
due to an import error on line 96 of numerix.
I use numeric and .matplotlibrc is configured accordingly.
These __import__ were not present in 0.8, can they savely be removed?
See you
Werner

>>>>> "Danny" == Danny Shevitz <sh...@la...> writes:
 Danny> I'm getting weird default behavior from imshow. Namely, the
 Danny> extent doesn't seem correct with aspect='preserve'. I think
 Danny> this was the subject of this post:
Yep, this is a known bug. As Fernando wrote, the suggested workaround
until we can fix it is to use matshow.
JDH

>>>>> "Chris" == Chris Barker <Chr...@no...> writes:
 Chris> Hi all, I've been working on my binary packages for
 Chris> I've also enclosed my write-up of how to setup and build a
 Chris> static version on OS-X. Comments on that would be great
 Chris> too.
 Chris> Other thoughts?
I think all of this looks good. My only comment is that I think it
would save work in the long run to not use static libs in the static
dir, but instead put in the src trees for zlib, libpng and freetype,
because then it can be reused by all other platforms (win32, UNIX*,
linux, OSX...). It's a little more work initially, but the work will
benefit many more platforms. We could then distribute this tar file
as a separate file to keep the distribution size down. I think that
zlib and png are pretty trivial (everything in one dir); freetype
would take a little thought because of its more complicated dir
structure.
JDH

Chris Barker wrote:
> Hi all,
> 
> As promised, I've been working on building my binary package for 
> matplotlib 0.82 for OS-X. I've got the one for Apple's python2.3 on OS-X 
> 10.3.* working now. I'm having a little trouble with a version for 
> Python 2.4. If I use:
> 
> $ sudo python2.4 setup.py install
> 
> It seems to work fine (Yahoo!)
> 
> But if I use bdist_mpkg, then install the package, I get this when I try 
> to import matplotlib:
> 
> >>> import matplotlib
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File 
> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/__init__.py", 
> line 509, in ?
> defaultParams = {
> File 
> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/__init__.py", 
> line 245, in wrapper
> ret = func(*args, **kwargs)
> File 
> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/__init__.py", 
> line 318, in _get_data_path
> raise RuntimeError('Could not find the matplotlib data files')
> RuntimeError: Could not find the matplotlib data files
> 
> I suspect this is a Py2app error (or a setup.py incompatibility with 
> matplotlib), but I don't know where it is looking for the matplotlib 
> data files, so I'm not sure how to debug this.
> 
> By the way, if I install with "setup.py install", then remove 
> site-packages/matplotlib, then install with the package, it works, so I 
> guess that means that the data files are being installed outside of 
> site-packages/matplotlib where would that be?
Probably 
/System/Libraray/Frameworks/Python.framework/Versions/Current/share/...
I always use the following setup.cfg when building matplotlib:
[install]
install-data=/usr/local
You can check where the package is placing the data files by looking at 
matplotlib-<etc>.mpkg/Contents/Packages/matplotlib-data-<etc>.pkg/Contents/Info.plist 
under the IFPkgFlagDefaultLocation key. Note that this isn't quite the 
same as the install-data. It is usually <install-data>/share/matplotlib.
At my request, matplotlib now searches /usr/local/share/matplotlib by 
default on OS X.
-- 
Robert Kern
rk...@uc...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

Hi all,
I've been working on my binary packages for OS-X. What I'd like to do is 
change the setupext.py to be able to "just work" on OS-X. this is a 
trick, because while OS-X is a very standardized platform (compared to 
Linux at least) that only applies to stuff Apple provides. If Apple 
doesn't provide it, we're left with:
fink
darwinports
gentoo
tarball+make
etc.
Each of these puts stuff in different places, so it's a pain to try to 
accommodate them.
My goal is to build a single installable package for mpl that an OS-X 
user can just install, without needing any non-python dependencies. I 
accomplish this by statically lining libpng and libfreetype in, and it 
all works pretty well. Unfortunately, the only way I know of to 
statically link libs is to make sure the linker finds only the static 
versions when linking. I've accomplished this by creating a StaticLibs 
directory inside the mpl source tree, putting that on the path, and 
putting the libs and needed header files in there.
What I propose for setup.py is to have a little section that looks at 
your system to figure out what you might have installed, and sets the 
paths accordingly. At the top of setupext.py, I've put:
## CHB: added the following for some "smarts" on OS-X
import sys
if sys.platform == 'darwin':
 ## This is OS-X is some form, but which?
 if os.path.isdir('StaticLibs'):
 # The StaticLibs dir is there, it should have everything needed.
 # that is: libfreeype.a and libpng.a, and the freetype include dir
 darwinpath = ['StaticLibs']
 elif os.path.isdir('/sw'):
 # It looks like this is a fink system, so let's look there too:
 # Someone please check this: I don't have fink.
 darwinpath = ['/sw/lib/freetype219', '/usr/local', '/usr', '/sw']
 else:
 #Let's just try some generic locations
 # there should be a darwinports option here too,
 # but I don't know what it would be.
 darwinpath = ['/usr/local', '/usr']
else:
 darwinpath = None
## Note: This is where you could put in whatever you want instead:
#darwinpath = ['/usr/local', '/usr', '/sw', '/usr/X11R6']
basedir = {
 'win32' : ['win32_static',],
 'linux2' : ['/usr/local', '/usr',],
 'linux' : ['/usr/local', '/usr',],
 # Charles Moad recommends not putting in /usr/X11R6 for darwin
 # because freetype in this dir is too old for mpl
 'darwin' : darwinpath,
 'freebsd4' : ['/usr/local', '/usr'],
 'freebsd5' : ['/usr/local', '/usr'],
 'freebsd6' : ['/usr/local', '/usr'],
 'sunos5' : [os.getenv('MPLIB_BASE') or '/usr/local',],
}
If people have fink, and darwinports, and the static libs installed, I 
figure they are on their own!
What do you all think? Perhaps, if nothing else, it could check in more 
detail that just the presence of those top level directories. I've only 
tested this with the StaticLibs approach.
I've also enclosed my write-up of how to setup and build a static 
version on OS-X. Comments on that would be great too.
Other thoughts?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hi all,
As promised, I've been working on building my binary package for 
matplotlib 0.82 for OS-X. I've got the one for Apple's python2.3 on OS-X 
10.3.* working now. I'm having a little trouble with a version for 
Python 2.4. If I use:
$ sudo python2.4 setup.py install
It seems to work fine (Yahoo!)
But if I use bdist_mpkg, then install the package, I get this when I try 
to import matplotlib:
 >>> import matplotlib
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File 
"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/__init__.py", 
line 509, in ?
 defaultParams = {
 File 
"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/__init__.py", 
line 245, in wrapper
 ret = func(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/__init__.py", 
line 318, in _get_data_path
 raise RuntimeError('Could not find the matplotlib data files')
RuntimeError: Could not find the matplotlib data files
I suspect this is a Py2app error (or a setup.py incompatibility with 
matplotlib), but I don't know where it is looking for the matplotlib 
data files, so I'm not sure how to debug this.
By the way, if I install with "setup.py install", then remove 
site-packages/matplotlib, then install with the package, it works, so I 
guess that means that the data files are being installed outside of 
site-packages/matplotlib where would that be?
thanks,
-Chris
PS: in another note, I'll post how I'm compiling all this, so you can 
comment on that.
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hi John
On Jun 14, 2005, at 1:11 PM, John Hunter wrote:
>>>>>> "William" == William Henney <wh...@gm...> writes:
>>>>>>
>
> William> Hi, I was trying to install the latest matplotlib from
> William> source on an ancient RH9 system but I get the following
> William> compilation error:
[ snip ]
> What is your python version? It looks like the macro PyMODINIT_FUNC
> is not being found. This is defined in pyport.h in python2.4, but you
> probably have a much older python installed.
Yes, it is python 2.2.
> The reason you cannot
> find _na_cntr.c is that it is autogenerated to support Numeric or
> numarray at compile time.
I suspected as much.
> The src dile is src/cntr.c. In that file,
> try replacing
>
> PyMODINIT_FUNC
>
> with
>
> extern "C" void
>
> or perhaps
>
> DL_EXPORT(void)
>
> and let me know if this helps
>
Hmm, neither of these work - pretty much the same error:
gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC - 
fPIC -I/usr/local/include -I/usr/include -I/usr/include/python2.2 -c 
src/_na_cntr.c -o build/temp.linux-i686-2.2/_na_cntr.o -DNUMARRAY=1
src/_na_cntr.c:1698: parse error before string constant
I suspect that supporting such an antique distro will be more trouble 
than it is worth. It would probably be easier for me to upgrade the 
machine.
Cheers
Will

Danny Shevitz wrote:
> I'm getting weird default behavior from imshow. Namely, the extent doesn't 
> seem correct with aspect='preserve'. I think this was the subject of this post:
You might want to look at matshow(), which I wrote more or less to give 
reasonable behavior in the case of matrix displays with the same visual 
aspect ratio as the row/column one of the array (along with other tweaks).
Cheers,
f

embarrassing, but that did it. I never uninstalled the previous version.
D
At 09:54 PM 6/15/2005 -0400, you wrote:
>Danny Shevitz wrote:
>
>>I just upgraded to matplotlib 0.82 on a Win2K box running Python 2.3.5. I 
>>used the matplotlib-0.82.win32-py2.3.exe installer.
>>
>>When I try to import matplotlib.pylab I get the following error:
>>
>>E:\>python
>>Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on 
>>win32
>>Type "help", "copyright", "credits" or "license" for more information.
>> >>> import matplotlib.pylab
>>Traceback (most recent call last):
>> File "<stdin>", line 1, in ?
>> File "D:\ENTHOU~1\Lib\site-packages\matplotlib\pylab.py", line 198, in ?
>> from axes import Axes, PolarAxes
>> File "D:\ENTHOU~1\Lib\site-packages\matplotlib\axes.py", line 13, in ?
>> from artist import Artist, setp
>> File "D:\ENTHOU~1\Lib\site-packages\matplotlib\artist.py", line 4, in ?
>> from transforms import identity_transform
>> File "D:\ENTHOU~1\Lib\site-packages\matplotlib\transforms.py", line 
>> 190, in ?
>> from _transforms import IDENTITY, LOG10, POLAR, Func, FuncXY
>>ImportError: cannot import name POLAR
>>
>>There was a post to this effect on matplotlib-users by Cory Davis on 
>>10/25/04 but no response. Any help would be appreciated.
>>
>>thanks,
>>Danny
>I think the thing to do is to completely remove site-pacages/matplotlib, 
>then reinstall. I think.

>>>>> "Gary" == Gary <pa...@in...> writes:
 Gary> I think the thing to do is to completely remove
 Gary> site-pacages/matplotlib, then reinstall. I think.
Yep, that's guaranteed to fix it. We see this kind of error all the
time when a module that was formerly python becomes replaced by
an extension code module with the same name (or vice-versa, I'm not
sure). When you install a new mpl over an old one and you have for
examples transforms.pyd and transforms.py, the wrong one is chosen and
you get the import error.
Danny, judging by the fact that you are seeing this in the transforms
module, my guess is you haven't upgraded matplotlib in a long time, so
you should be pleasantly surprised by better performance in certain
areas.
JDH

Danny Shevitz wrote:
> I just upgraded to matplotlib 0.82 on a Win2K box running Python 
> 2.3.5. I used the matplotlib-0.82.win32-py2.3.exe installer.
>
> When I try to import matplotlib.pylab I get the following error:
>
> E:\>python
> Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] 
> on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import matplotlib.pylab
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File "D:\ENTHOU~1\Lib\site-packages\matplotlib\pylab.py", line 198, 
> in ?
> from axes import Axes, PolarAxes
> File "D:\ENTHOU~1\Lib\site-packages\matplotlib\axes.py", line 13, in ?
> from artist import Artist, setp
> File "D:\ENTHOU~1\Lib\site-packages\matplotlib\artist.py", line 4, in ?
> from transforms import identity_transform
> File "D:\ENTHOU~1\Lib\site-packages\matplotlib\transforms.py", line 
> 190, in ?
> from _transforms import IDENTITY, LOG10, POLAR, Func, FuncXY
> ImportError: cannot import name POLAR
>
> There was a post to this effect on matplotlib-users by Cory Davis on 
> 10/25/04 but no response. Any help would be appreciated.
>
> thanks,
> Danny
>
I think the thing to do is to completely remove site-pacages/matplotlib, 
then reinstall. I think.

Stephen Walton wrote:
> John asked what MATLAB does at present. The answer is: MATLAB's 
> image() displays arrays as does imshow(origin='upper'), with first 
> index increasing downward and second index increasing left to right, 
> but it has the y axis increasing from top to bottom.
I will add, in fairness to all concerned, that MATLAB has the same issue 
as matplotlib with respect to image position readout. If one uses 
MATLAB's ginput() to read pixel coordinates from a displayed image, they 
have to be reversed to address the corresponding data in the displayed 
array. Maybe the fairest thing is to tell me "this is how it works, get 
over it" :-) and move on.

I just upgraded to matplotlib 0.82 on a Win2K box running Python 2.3.5. I 
used the matplotlib-0.82.win32-py2.3.exe installer.
When I try to import matplotlib.pylab I get the following error:
E:\>python
Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import matplotlib.pylab
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "D:\ENTHOU~1\Lib\site-packages\matplotlib\pylab.py", line 198, in ?
 from axes import Axes, PolarAxes
 File "D:\ENTHOU~1\Lib\site-packages\matplotlib\axes.py", line 13, in ?
 from artist import Artist, setp
 File "D:\ENTHOU~1\Lib\site-packages\matplotlib\artist.py", line 4, in ?
 from transforms import identity_transform
 File "D:\ENTHOU~1\Lib\site-packages\matplotlib\transforms.py", line 190, 
in ?
 from _transforms import IDENTITY, LOG10, POLAR, Func, FuncXY
ImportError: cannot import name POLAR
There was a post to this effect on matplotlib-users by Cory Davis on 
10/25/04 but no response. Any help would be appreciated.
thanks,
Danny

Humufr wrote:
> I think that the problem is more that when you're using matshow to 
> draw a fits file read with pyfits you don't have the same image if you 
> open the fits file with ds9, the y axis is inverted.
Yes, but even that is an illusion as it were. See below.
> import pyfits
>
> scidata = pyfits.open('test.fits')[0].data
> matshow(scidata)
>
> ylim(0,scidata.shape[0])
It is easier to use imshow(scidata,origin='lower') here. But the fact 
that the image then looks the same when displayed in matplotlib and ds9 
is something of a fluke. ds9 displays the first FITS index increasing 
horizontally and the second increasing vertically (no reason not to, 
it's just a convention). PyFITS effectively transposes the array when 
it is read, but imshow() puts the first array index vertical. The 
result is that the image orientation looks the same when displayed in 
ds9 or matplotlib even though pixel (x,y) as displayed in ds9 is 
scidata[y-1,x-1] in Python. I was badly confused by this earlier in the 
week when checking some image coordinate computations in Python against 
the original Fortran IRAF code. Hence my first post.

Perry Greenfield wrote:
> On Jun 14, 2005, at 7:30 PM, Stephen Walton wrote:
>
>> 1. Is anyone else bothered by the fact that imshow(array) displays 
>> array[i,j] at Cartesian coordinates [j,shape(array)[0]-i] if origin 
>> is 'upper' and at [j,i] if origin is 'lower'?
>
> As with John, I'm not sure what the complaint is.
Perry is correct that it is likely my main problem is that the order of 
indices of astronomical FITS images is reversed when read in via 
PyFITS. He has commented on that issue extensively today over on the 
AstroPy mailing list, so I won't belabor the point here as it is not 
directly relevant to matplotlib anyway.
> Is it that the order is j,i or that lower and upper are defined the 
> way they are. If the latter, I'm not sure what was expected.
I do understand John's desire to have a displayed image appear in the 
same orientation as a list of pixels on the screen. But I want to be 
able to easily read image coordinates from a display and use them to 
address the underlying data. The Cartesian coordinates are displayed as 
(x,y) when one rolls the mouse pointer over the image, and so you have 
to reverse them, plus if origin='upper' you have to flip the y 
coordinate (image.shape[0]-y).
Specific suggestion: when an array is displayed with origin='upper', 
the y axis should increase downward, not upward. At least this way, 
pixel [i,j] always appears at Cartesian coordinates (j,i) and a program 
which, for example, overlays points plotted as (x,y) on an image won't 
break if a user changes image.origin in the .matplotlibrc file.
John asked what MATLAB does at present. The answer is: MATLAB's 
image() displays arrays as does imshow(origin='upper'), with first index 
increasing downward and second index increasing left to right, but it 
has the y axis increasing from top to bottom.

What's new in 0.82
Subplot configuration
 All of the parameters of the subplots are now exposed at the rc,
 pylab and API layout. These are left, right, bottom, top, wspace
 and hspace which control how the subplots are placed on the screen.
 See figure.SubplotParams, figure.Figure.subplots_adjust and the
 pylab method subplots_adjust and examples/subplots_adjust.py . Also
 added a GUI neutral widget for adjusting subplots, see
 examples/subplot_toolbar.py. There is a new toolbar button on GTK*,
 WX* and TkAgg to launch the subplot configuration tool (which uses
 the new matplotlib cross GUI classes discussed below). 
 This also makes it easier to make ganged plots -- see
 examples/ganged_plots.py
 Note this required a small change to how the toolbar on some GUIs
 are imported; if you are using the mpl API in WXAgg and GTKAgg, see
 API_CHANGES.
GUI neutral widgets
 Matplotlib now has cross-GUI widgets (buttons, check buttons, radio
 buttons and sliders). You have to manually create properly sized
 Axes for them to live in, but otherwise they are pretty easy to use.
 See examples/widgets/*.py and
 http://matplotlib.sf.net/screenshots.html#slider_demo. This makes
 it easier to create interactive figures that run across backends.
Cap and join style
 Exposes line cap and join style via new rc params and Line2D
 properties
 lines.dash_joinstyle : miter # miter|round|bevel
 lines.dash_capstyle : butt # butt|round|projecting
 lines.solid_joinstyle : miter # miter|round|bevel
 lines.solid_capstyle : projecting # butt|round|projecting
Axes kwargs
 All Axes properties are now exposed via kwargs, so you can do, for
 example
 subplot(111, xlabel='time', ylabel='volts', autoscale_on=False,
 xlim=(-1,1), ylim =(0,10) )
Small bugfixes and features:
 Fixed a upper/right tick bug (thanks Baptiste), fixed invalid rc
 docstring vis-a-vis aliases, fixed bug #1217637 in ticker.py and a
 cleanup bug in usetex (thanks Darren), added Sean Richards hist bin
 fix (see API_CHANGES)
http://matplotlib.sf.net
Enjoy!
JDH

 Hello,
I think that the problem is more that when you're using matshow to draw 
a fits file read with pyfits you don't have the same image if you open 
the fits file with ds9, the y axis is inverted.
To have the same view with matshow you must use something like:
ylim(0,scidata.shape[0])
ex:
import pyfits
scidata = pyfits.open('test.fits')[0].data
matshow(scidata)
ylim(0,scidata.shape[0])
I must admit that I'm a little agree with him, it very perturbating at 
the beginning and before to plot any fits data with matplotlib I prefer 
to test that the orientation is good.
Regards,
N.
Perry Greenfield wrote:
> Sorry for not responding until now, I've been tied up until today.
>
> On Jun 14, 2005, at 7:30 PM, Stephen Walton wrote:
>
>> This was originally a much longer message with a great deal of 
>> context, but I'm going to make it a lot shorter as a series of 
>> questions in the hopes of getting a Socratic dialog going?
>>
>> 1. Is anyone else bothered by the fact that imshow(array) displays 
>> array[i,j] at Cartesian coordinates [j,shape(array)[0]-i] if origin 
>> is 'upper' and at [j,i] if origin is 'lower'?
>>
> As with John, I'm not sure what the complaint is. Is it that the 
> order is j,i or that lower and upper are defined the way they are. If 
> the latter, I'm not sure what was expected.
>
>> 2. In light of the above, how do you handle overlaying contours on 
>> an image? I see by experiment that contour(array) also treats 
>> array[i,j] the same way as imshow.
>>
> Yes, they are supposed to be consistent. Is that a problem?
>
>> 3. Are the astronomers as confused by all of this in relation to the 
>> FITS WCS standard as I seem to be? How do I do the computation 
>> correctly so that x[i,j] is the first WCS coordinate of FITS pixel 
>> (i,j) (which is at array[j-1,i-1] after a PyFITS read)?
>>
>
> Are you asking if it is possible to redefine the order of indices for 
> an array (it is, but I'm not sure I'd recommend that)? Or is the 
> 0-based indexing of Python (and IDL as well) vs the 1-based indexing 
> of FITS and IRAF the issue? Or both?
>
> As to the order of indexing, I agree that it is probably (by far) the 
> single biggest annoyance for astronomers (I don't think there is any 
> painless solution though). I won't go on at length about this unless 
> I'm sure that this is the primary issue that is bugging you.
>
> Perry
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Michael Twomey wrote:
> I'd recommend trying Chris's binary package when he gets it done
> (Chris, do you need any help on that front?).
Well, not for what I intend to do, but I wasn't planning on building in 
PyGTK support. In a way, doing that is contrary to my goal, which is a 
package that can be installed on a stock OS-X (except Numerix, of 
course). i.e. fink-free.
However, it would probably work fine to have GTK compiled into the 
binary, and it shouldn't break any of the other back-ends...it just 
wouldn't work with PyGTK if PyGTK wasn't there, which is kind of obvious.
So, if someone want to build a package with PyGTK support, I'll send you 
what I have to docs, and you can go to it. I'd love for there to be only 
one "official" package, so if someone makes a superset of mine, I won't 
distribute mine.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Sorry for not responding until now, I've been tied up until today.
On Jun 14, 2005, at 7:30 PM, Stephen Walton wrote:
> This was originally a much longer message with a great deal of 
> context, but I'm going to make it a lot shorter as a series of 
> questions in the hopes of getting a Socratic dialog going?
>
> 1. Is anyone else bothered by the fact that imshow(array) displays 
> array[i,j] at Cartesian coordinates [j,shape(array)[0]-i] if origin is 
> 'upper' and at [j,i] if origin is 'lower'?
>
As with John, I'm not sure what the complaint is. Is it that the order 
is j,i or that lower and upper are defined the way they are. If the 
latter, I'm not sure what was expected.
> 2. In light of the above, how do you handle overlaying contours on an 
> image? I see by experiment that contour(array) also treats array[i,j] 
> the same way as imshow.
>
Yes, they are supposed to be consistent. Is that a problem?
> 3. Are the astronomers as confused by all of this in relation to the 
> FITS WCS standard as I seem to be? How do I do the computation 
> correctly so that x[i,j] is the first WCS coordinate of FITS pixel 
> (i,j) (which is at array[j-1,i-1] after a PyFITS read)?
>
Are you asking if it is possible to redefine the order of indices for 
an array (it is, but I'm not sure I'd recommend that)? Or is the 
0-based indexing of Python (and IDL as well) vs the 1-based indexing of 
FITS and IRAF the issue? Or both?
As to the order of indexing, I agree that it is probably (by far) the 
single biggest annoyance for astronomers (I don't think there is any 
painless solution though). I won't go on at length about this unless 
I'm sure that this is the primary issue that is bugging you.
Perry

>>>>> "Maria" == Maria Khomenko <mar...@ut...> writes:
 Maria> Hi, I am using pylab to plot several graphs. One graph
 Maria> appears in one class where I do the following:
 Maria> plot_date(date, y, 'g-o') savefig(path, dpi=75)
 Maria> Later on, in a different class, I do the a similar call:
 Maria> plot_date(d, z, 'b-') savefig(path, dpi=75)
 Maria> My problem is that the second call to plot_date simply
 Maria> appends the new line to the original graph and I am not
 Maria> sure why since the new graph also has new axis and a new
 Maria> label.
 Maria> It seems that the problem can be solved by calling
 Maria> hold(False) after plotting the first line. Yet, I would
 Maria> think that when I call the plot command in a separate class
 Maria> and set up the axis labels, etc. that it would
 Maria> automatically create a new set of axis, not append to the
 Maria> existing saved file.
 Maria> Is there something I should know? I would appreciate any
 Maria> feedback on this matter.
matplotlib has no idea whether you call functions from separate
classes or not. The concept of the current figure is a pylab
construct, and if you don't like it you can be more explicit about
figure and construction and management. Here is a snippet using pylab
class A:
 def __init__(self):
 self.fig = figure()
 self.ax = self.fig.add_subplot(111)
 def makeplot(self):
 self.ax.plot([1,2,3]) 
class B:
 def __init__(self):
 self.fig = figure()
 self.ax = self.fig.add_subplot(111)
 def makeplot(self):
 self.ax.imshow(rand(100,100))
Here you do not use the "current figure" or "current axes" of the
pylab interface because you explicitly make calls on the figure and
axes objects in their respective classes.
For even more fine grained control, you can avoid pylab altogether and
use the API as described at
http://matplotlib.sourceforge.net/faq.html#OO
Hope this helps,
JDH

>>>>> "Stephen" == Stephen Walton <ste...@cs...> writes:
 Stephen> This was originally a much longer message with a great
 Stephen> deal of context, but I'm going to make it a lot shorter
 Stephen> as a series of questions in the hopes of getting a
 Stephen> Socratic dialog going?
 Stephen> 1. Is anyone else bothered by the fact that
 Stephen> imshow(array) displays array[i,j] at Cartesian
 Stephen> coordinates [j,shape(array)[0]-i] if origin is 'upper'
 Stephen> and at [j,i] if origin is 'lower'?
Just to make sure I understand, does it bother you that rows and
columns are reversed, or is there a specific gripe with the upper and
lower handling. My motivation in doing is illustrated in this example
In [10]: x = arange(50.); x.shape=5,10
In [11]: imshow(x, interpolation='nearest', origin='upper')
Out[11]: <matplotlib.image.AxesImage instance at 0xb5f00e6c>
In [12]: x
Out[12]:
[[ 0., 1., 2., 3., 4., 5., 6., 7., 8., 9.,]
 [ 10., 11., 12., 13., 14., 15., 16., 17., 18., 19.,]
 [ 20., 21., 22., 23., 24., 25., 26., 27., 28., 29.,]
 [ 30., 31., 32., 33., 34., 35., 36., 37., 38., 39.,]
 [ 40., 41., 42., 43., 44., 45., 46., 47., 48., 49.,]]
The voxels on the screen and the array as printed have the same
layout: 5 rows and 10 columns. Basically the inversion happens
because event though it is tradtional to think of x as the first axis
and y as the second, visually if you move along the x axis you are
moving across columns and if you move along the y axis you are moving
along rows.
In any case, I am not sure exactly what your complaint is (and how you
want it to work) so I am just offering a bit of explanation of why it
is the way it is. I think matlab behaves differently, but I don't
have matlab installed right now. I am not sure that the way we are
doing it is the right way, so feel free to offer suggestions.
 Stephen> 2. In light of the above, how do you handle overlaying
 Stephen> contours on an image? I see by experiment that
 Stephen> contour(array) also treats array[i,j] the same way as
 Stephen> imshow.
Right; does that answer your question? If you want to flip the
indices, you can always transpose....
 Stephen> 3. Are the astronomers as confused by all of this in
 Stephen> relation to the FITS WCS standard as I seem to be? How
 Stephen> do I do the computation correctly so that x[i,j] is the
 Stephen> first WCS coordinate of FITS pixel (i,j) (which is at
 Stephen> array[j-1,i-1] after a PyFITS read)?
I'll leave this one to the astronomers... If desired, we can probably
add an option to handle images in the layout that is typical for
astronomers, but the image and contour code is already a bit hairy
trying to deal with upper and lower origin.
JDH