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'?
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.
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)?
Sorry for not responding until now, I've been tied up until today.
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
···
On Jun 14, 2005, at 7:30 PM, Stephen Walton 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.
To have the same view with matshow you must use something like:
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
Matplotlib-users@lists.sourceforge.net matplotlib-users List Signup and Options
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.
···
On Jun 14, 2005, at 7:30 PM, Stephen Walton 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.
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.
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.
and move on.