[Kst] HPIC update

[Theodore Kisner]

On Wednesday 08 June 2005 17:51, Barth Netterfield wrote:
> what do you plan for part-sphere maps (like b2k deep)?  Will there be a way
> to auto-scale in xy?

my plan was to check for the theta/phi range of non-null pixels when the file 
is initially read and after that only if the update indicates that the file 
has changed.  So this info could be stored in the datasource _metadata I 
guess.  I think the initial plot range should be auto scaled, and then the 
user can zoom however they like (similar to curve behaviour).  

Not sure if this was your question.  If you are talking about *only storing 
hit pixels in memory*, that is a separate issue.  The only way you can do 
that and still have an efficient way of accessing the pixels is to have some 
kind of "lookup table".  Obviously a full-sphere lookup table defeats the 
purpose of having a cut-sphere map in memory :-)  My solution in HPIC is to 
create a tree-based structure using the bits of the nested pixel number to 
follow each branch.  This is not finished being implemented.

> Lets just include it.  If HEALPIX comes up with a GPL C implementation, we
> can re-visit the question.  As long as they don't, there is no question to
> visit. I have talked to Eric about HEALPIX in kst for some years now, it
> hasn't happened, so we don't really need to wait any longer, as far as I am
> concerned.

sounds good to me- just apply the previously posted patchset and add the 
datasources/hpic directory to svn :-)

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

I think that for speed issues, it is more efficient to do the projection from 
from a vector of map data directly to the buffer.  The problem is that 
healpix maps are more naturally described as a vector (indexed by pixel 
number), not a matrix.

> Convince data sources to output matrixes as well as vectors 

but healpix maps "want" to be vectors, not matrices ;-)  I plan on 
re-projecting the healpix vector when the zooming changes.  So that means 
that each time the user zooms, the healpix vector must be reprojected onto 
the buffer.

> (this solves 
> the current Matrix UI issues)

I'm not familiar enough to know what these are- trying to get up to speed 
quickly, sorry...

> It also means that the projection gets done at read time, not render time,
> and so should be faster.  The down-side is that one might want to
> over-sample the healpix map in the projection to preserve the non-square
> pixels....  But this could be a read-time option.

aha!  this is the crux of the matter- I think we should re-render on user 
zooming.  Rick and I had talked about adding options to reduce the resolution 
of the "projection buffer", so that this redrawing could happen more quickly.  
This should be a user controlled setting.  For example, select coarse 
resolution projection for quick-and-dirty display.  Select high-resolution 
projection for making publication plots.

So to summarize, healpix maps are most naturally stored in vectors, so the 
current datasource model works great.  As for bloating Kst2DPlot, that's why 
I thought maybe a plugin model would work for handling different ways of 
painting the data stored in a vector...

Sorry if some of this doesn't make sense- I'm still figuring out the 
subtleties of kst's code base...

-Ted