matplotlib-users

[Matplotlib-users] Images, FITS files, and so on

[Stephen W. <ste...@cs...>]

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)?

Re: [Matplotlib-users] Images, FITS files, and so on

[John H. <jdh...@ac...>]

>>>>> "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

Re: [Matplotlib-users] Images, FITS files, and so on

[Perry G. <pe...@st...>]

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

Re: [Matplotlib-users] Images, FITS files, and so on

[Humufr <hu...@ya...>]

          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
>

Re: [Matplotlib-users] Images, FITS files, and so on

[Stephen W. <ste...@cs...>]

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.

Re: [Matplotlib-users] Images, FITS files, and so on

[Stephen W. <ste...@cs...>]

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.

Re: [Matplotlib-users] Images, FITS files, and so on

[Stephen W. <ste...@cs...>]

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.