[Kst] HPIC update

[Theodore Kisner]

I was re-reading my previous response and I think I wasn't quite clear, here 
is another attempt to straighten out any confusion...  Also see very bottom 
of this mail for another proposed way of implementing all this.

> what do you plan for part-sphere maps (like b2k deep)?  Will there be a way
> to auto-scale in xy?

ok, if you are talking about storing partial-sky maps in memory, this will not 
be supported initially.  Every FITS file (cut sky or full sky) will be read 
into a full-sky vector in memory.  Once HPIC supports tree-based storage, it 
will be possible to read a cut-sphere FITS file into a smaller memory 
footprint, in exchange for a slight hit in acess time.

Also, just to be clear how the projection works, if I have an N_x by N_y 
rectangular grid that represents an angular range (Theta_min, Phi_min) to 
(Theta_max, Phi_max), then I have functions in HPIC that do the 
forward/reverse projection from pixels to (theta, phi).  So I'm NOT talking 
about projecting the whole sphere, just a defined range.

So I was going to obtain the current theta/phi range and window size from 
Kst2DPlot and project the data accordingly onto the backbuffer.

> The problem with this is that it seems to add a parallel map structure to
> the Matrix/Image stuff, (which already has UI issues in actually accessing
> maps.)

ok, I think we are just using slightly different terminology here, and I think 
I see what you are getting at.  KstMatrix + KstImage + Kst2DPlot::plotImages 
is also a way of taking a KstVector and painting it to a buffer.  So the 2 
"analogous" methods we have are:

KstVector (flat-packed matrix) 
 --> KstMatrix (vector "projected" onto a 2D grid)
  --> KstImage (describes parameters of how matrix is painted 
      with a palette and contours) 
   --> Kst2DPlot::plotImages (actually does the painting)

KstVector (healpix map vector)
 --> KstHpic (describes parameters of how the map should be 
     projected, including palette, etc)
  --> Kst2DPlot::plotHpic (actually does the projection and 
      painting in a single step)

Sooo, it seems like the concerns are:  (1) can we merge any redundant features 
and (2) should we do the projection outside of Kst2DPlot for speed reasons.

I now see what you were saying earlier, Barth.  If we move the projection into 
the datasource and output an already-projected KstMatrix, that would 
certainly be faster for zooming.  However- if we project a subset of the data 
to a limited range of theta/phi, what happens when the user scrolls outside 
that range?  Do we regenerate the projection?  Do we just show white space 
until they click the "re-render" option?  This is the reason I was going to 
try to reproject the data at each redraw...

Also, we still need a way of taking 2 maps, using them as vector components, 
and outputting the projected coordinates of vector heads/tails.  I was 
originally going to have all the necessary vectors stored in KstHpic and then 
do the vectorfield projection in the paint function.  I guess that *would* be 
slow...

So here is another option that would be fast and require minimal code 
modifications:

1.  add a virtual function to KstDataSource that returns a field as a matrix 
(readFieldMatrix?)

2.  for datasources that define the readFieldMatrix function, make sure that 
all of the necessary projection information is either read from the file or 
obtained via the datasource config dialog.

3.  for the HPIC datasource, readFieldMatrix would return a given field 
projected onto a matrix, using projection range and parameters set from the 
config dialog.  The defaults for the projection range would be set initially 
so that the theta/phi range of the projection was big enough to include all 
non-null pixels.

4.  for the HPIC datasource, readField would return the same healpix map 
vectors that it currently does.

5.  I could create a plugin that takes 2 healpix map vectors, treats them as 
vector field components, and outputs a vector of head/tail coordinates to be 
plotted as lines.  (not sure where this would go)

So with this scheme, maps would be projected at read time and when the user 
changed the projection parameters.  These projections would be stored as 
KstMatrices and plotted using the KstImage formalism.  Vector fields would be 
plotted somewhere else, to be determined.  

When the user zooms/scrolls outside the defined projection region, they get 
white space.  They can go into the datasource config dialog and change the 
size (pixel dimensions) of the projection and also the min/max theta/phi 
values.

Does this scheme sound more feasible/sane?

thanks for all the feedback,

-Ted