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.
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.
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
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.
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
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
Could be still open in Kst 1.
The original bug has been fixed in 2.x, but the issues brought up by Ted have not been (ie, using WCS, etc).