[Kst] Image data type

[Barth Netterfield]

On July 21, 2004 04:35 pm, Barth Netterfield wrote:
> I thought sent out a note on this a while ago, but can't find it.  Does
> anyone else have it?  Am I imagining things?

Thanks to Ted, I found it...
https://mail.kde.org/pipermail/kst/2004-April/001532.html

I inlcude it below with ***annotations.
Hi,

We need to think about this mapping stuff for a moment (which I actually have 
for a couple years now...)

There are several ways to imagine '3d' data...

A) Data on a regular grid, expressed as an array.
        (imagine 'kst -z 1 -nx 200 -ny 200 array.dat')
B) Data as a list of (x,y,z) points (as 3 arrays)  
        (imagine 'kst -x 1 -y 2 -z 3 map.dat')
C) Data as a list of points, with an implicit pixel index (eg, healpix)
        (imagine 'kst -z 1 healpixmap.fits')
D) various representations of surfaces which are not functions (eg, the 
surface of a sphere)
        (don't imagine anything - we're not going here!)

I suggest that we implement support for A and B at the data type level:

A): kstarray which takes:
        vector, nx, ny, minx, miny 
*** note 'vector' is of length nx*ny
and outputs:
        nx by ny array. 

B) kstTriLinearArray which takes:
        vector X, vector Y, vector Z, nxpix, nypix, 
and outputs 
        a trilinear interpolated nx by ny array from Xmax to Xmin and Ymax to 
Ymin.

C) could be a data source converted type...  or do we want a KstHealPixArray?

To the plot classes, both arrays appear the same.

-----------

There are two main classes of presentation of the data: 
 1) flat maps: (ie, pixel maps, contour plots)
 2) 3d images (ie, isometric plots, rendered surfaces...)

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

Class (2) are openGL type objects, and will need a hightly modified mouse 
interface, etc.

I suggest we do (1) now (kstmap) and leave (2) (kst3dplot) for later.

*** upon further thinking, I think that (1) should be handled by kst2dplot.

Andrew, do you want to create the data types so Ted can start on the healpix 
data source?

*** I guess that would be 'Rick, do you want to .... '

cbn