Hi Bob,
> Another question(s) about colors:
> One of the parameters to the Gridded3DSet.makeIsoSurface() method looks
> like an R,G,B tuple for each point in the gridded set. My question(s) is,
>
> 1) Where are these values computed? In other words, what class(es) is/are
> responsible for this? and
Values from various RealTypes are collected in doTransform()
implementations in various subclasses of ShadowType, then
these are assembled into R, G, B and A components in
ShadowType.assembleColor(). This is pretty complex, because
there can be any number of RealTypes mapped to Red, Green,
Blue, Aalpha, RGB, RGBA, Cyan, Magenta, Yellow, CMY, Hue,
Saturation, Value and HSV. Multiple RealTypes may be
mapped to any one of the DisplayRealTypes.
> 2> How are these values computed (conceptually)? Or perhaps another way
> of asking would be, on what basis are these color values computed?
> Is there a mapping from grid values to color values? and
It all depends on which RealTypes are mapped to the color
DisplayRealTypes listed above.
> 3) Could the inverse computation be done? Could one write a function that
> computed the original sample point from the color values (within some
> margin of error)?
Not in general, because multiple RealTypes can be mapped
to DisplayRealTyoes (in which case they are added and this
is not invertible).
The various direct manipulation renderers (e.g.,
visad.java3d.DirectManipulationRendererJ3D) check on
ScalarMaps and through Exceptions if spatial mappings
are not invertible. It would be possible to write
DataRenderer extensions that check to insure that color
mappings are invertible, and then exploit it in some
way.
Cheers,
Bill
----------------------------------------------------------
Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI 53706
hibbard@xxxxxxxxxxxxxxxxx 608-263-4427 fax: 608-263-6738
http://www.ssec.wisc.edu/~billh/vis.html
