[Kst] HPIC update

[Barth Netterfield]

Sounds good.

We need to think about how data sources present matrixes.  vectors can be read 
by index, or for special data sources, by time.  How about matrixes?

I think that the new/edit matrix dialog gets an option like the vector dialog 
has which allows the user to read a matrix from a data source.  It will have 
entries for xmin, xmax, ymin, ymax with some feedback in the dialog which 
tells the user what the datasource has to offer (minx, maxx, nx, etc).  This 
would be generic to all matrix reading.

Then the data source configuration for hpic would also offer up resolution and 
projection options.  There would be a sensible default so in general the user 
would not have to do anything.

So reading in/projecting only part of a matrix would be analogous to only 
reading part of a vector.

This will likely break binary compatibility, which is fine with me, as long as 
we maintain source code compatibility with old data sources.  Full matrix 
support is big enough a change to generate a 2.0 name change.

cbn

On June 9, 2005 07:10, Theodore Kisner wrote:
> 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
>
>
>
>
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst