kisner at physics.ucsb.edu
Wed Apr 28 16:17:44 CEST 2004
> C) Data as a list of points, with an implicit pixel index (eg, healpix)
> (imagine 'kst -z 1 healpixmap.fits')
this sounds like a very nice, intuitive way of choosing which column of the
binary table to plot.
> C) could be a data source converted type... or do we want a
I'm definitely not an expert here, but I have code that could read the FITS
file and create a "kstarray" based on type of projection, plot limits, etc.
The main reason we might need a special KstHealPixArray is if there are
features that can't be handled with the normal array. For example, in
non-cartesian projections, the top and bottom of the plot window have
different tick spacings. Of course I'm not sure it this info is part of the
data type or part of the plotting view (I really need to get up to speed on
the code base and layout- just started yesterday, I'm working on it).
> Class (1) does not need or benifit from openGL, and there is no concept of
> rotation. These are fundamentally 2d objects + 'color'. They would mainly
> have the same interface as the 2dplots currently do, but with, an eg,
> colormap entry and 'show pixels' and 'show contours' and 'contour interval'
> options in various places (the rmb menu and various dialogs.)
> Andrew, do you want to create the data types so Ted can start on the
> healpix data source?
In addition to getting up to speed on the kst codebase, I need to finish the
documentation for my GPL'd Healpix library (HEALPIC), so that I can release
it into the wild. This library is already good enough for basic pixel
functions, projection, etc, but does not (yet) include spherical harmonic
transforms, filtering, ...
We can't have kst depending on a library that is not yet released ;-)
More information about the Kst