Bug 120747 - Kst should properly display fits images with reversed axes.
Summary: Kst should properly display fits images with reversed axes.
Status: CONFIRMED
Alias: None
Product: kst
Classification: Applications
Component: general (show other bugs)
Version: 1.10.0
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: kst
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-25 00:03 UTC by Matthew Truch
Modified: 2011-01-14 22:50 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Truch 2006-01-25 00:03:11 UTC
Version:           1.2.0_svn_502068 (using KDE KDE 3.5.0)
OS:                Linux

Fits files encode the scale of the fits file in the CDELT1 and CDELT2 fits parameters.  If either is negative, that indicates that the corresponding axis should be displayed reversed.  

When opening a fits image for the first time, kst should check the sign of CDELT1 and CDELT2 and set the reversal of the axes appropriatly.
Comment 1 Andrew Walker 2006-05-03 17:46:08 UTC
If a FITS file is used to encode something like a spectrum then the x-axis values can be given in the form:

f(i) = CRVAL1 + (i-CRPIX1)*CDELT1

where, for example, f(i) gives the wavelength of a spectrum at each detector pixel. Thus, the fits datasource should probably provide an additional vector(s) (similar to INDEX) which provides these f(i) values for each i.
Comment 2 Ted Kisner 2006-05-03 18:13:32 UTC
Just FYI, I have plans to combine the current LFIIO and fitsimage datasources 
into a single data source which can return both columns of tables and images 
from all extensions in the file.  Will not get to this for a couple weeks 
though...

| ------- If a FITS file is used to encode something like a spectrum then the
| x-axis values can be given in the form:
|
| f(i) = CRVAL1 + (i-CRPIX1)*CDELT1

So are the "i" values stored in a table column?  Or are they simply the row 
number of the table?  Imagine we have a FITS file with a primary image and 
then 2 extra table extensions.  I could imagine having the datasource provide 
a fieldlist like this:

INDEX
EXT 1 Pixel Index
EXT 1 Pixel Value
EXT 2 Row Number
EXT 2 Column 1
EXT 2 Column 2
EXT 3 Row Number
EXT 3 Column 1

and a matrixlist like this:

EXT 1 Image
EXT 2 Table as Image
EXT 3 Table as Image

would this address your problem?  A user could then select the row index for 
that table as the X vector, and a table column as the Y vector.

-Ted
Comment 3 Andrew Walker 2006-05-03 23:38:28 UTC
The "i" values are the row number of the table.

Right, I think the only thing we need to add for one-dimensional data is an additional vector giving the pixel index according to CRVAL, CRPIX, CRDELT.
Comment 4 Ted Kisner 2006-05-04 01:43:48 UTC
On Wednesday 03 May 2006 14:38, Andrew Walker wrote:
| Right, I think the only thing we need to add for one-dimensional data is an
| additional vector giving the pixel index according to CRVAL, CRPIX, CRDELT.

I was curious about these keywords, so I did some web searching.  I found the 
proposed WCS extensions to the FITS standard here:

http://fits.gsfc.nasa.gov/fits_wcs.html

It is a way of specifying the coordinates of pixels in a FITS image.  Also, I 
see that just a few days ago, a new Healpix FITS format was approved!

http://fits.gsfc.nasa.gov/wcs/mhg_20050615.pdf

It seems like these extensions currently require the WCS library in order to 
be used.  Does anyone know if this library is eventually going to be merged 
into cfitsio proper?

It seems to me that our FITS datasource should conditionally support WCS if 
the library is present.  I'll investigate this and try to come up with a 
design document for the new FITS datasource.

-Ted
Comment 5 Ted Kisner 2006-05-04 08:18:41 UTC
On Wednesday 03 May 2006 14:38, Andrew Walker wrote:
| Right, I think the only thing we need to add for one-dimensional data is an
| additional vector giving the pixel index according to CRVAL, CRPIX, CRDELT.

After playing with the latest version of the WCS library, I think we need to 
procede carefully.  This library provides ways of specifying arbitrary 
coordinates to each pixel in a FITS image.  There is NO WAY that kst can 
support all the features, because we do not have arbitrary 3D plotting.

I think we should choose the most commonly used types of rectangular 
coordinate systems and support those.  The keywords mentioned above are 
listed as "deprecated" in the CFITSIO documentation.  They say that people 
should use WCS instead.

So to summarize, the most general way of handling these files is to use the 
WCS routines that read special keywords and return coordinates for a 
specified pixel in the image.  We can then compute the coordinates of 
the "corners" of the image to find the X and Y range of the image.

Does this make sense?

-Ted
Comment 6 Peter Kümmel 2010-08-14 14:10:31 UTC
Could be still open in Kst 1.
Comment 7 Netterfield 2011-01-14 22:50:24 UTC
The original bug has been fixed in 2.x, but the issues brought up by Ted have not been (ie, using WCS, etc).