Convert 3D function into multi-color gradient bitmap?

Convert 3D function into multi-color gradient bitmap?

I am afraid that I am, as a math-starved ChemE, somewhat overwhelmed by a
lot of the terminology in this newsgroup.  Please bear this in mind if you
are kind enough to respond to this question.
I am looking for a reference to sample (complete is fine too) code to
display a set of observations z at different values of  (x,y) as a gradient
colored 2D bitmap. As the application is supposed to run in real time, code
optimization seems important.  The platform is NT 4.0 and later with at
least 24-bit color.  When z = 1.0, a pixel is green, when z = 0.75, a pixel
is yellow and when z = 0, a pixel is red, with interpolation between these
colors for values of z in between.  The number of (x,y) observations is much
smaller than the number of pixels, so interpolation between  x and y is
necessary too.  My gut feeling says that linear interpolation between
observations will not look as good as higher order interpolation.  Any
suggestions as to optimal order?

Your help will be greatly appreciated.

Henk Borsje

Convert 3D function into multi-color gradient bitmap?

> I am looking for a reference to sample (complete is fine too) code to
> display a set of observations z at different values of  (x,y) as a gradient
> colored 2D bitmap. As the application is supposed to run in real time, code
> optimization seems important.

I think you should expand on what "real time" means, here.  There are
at least two common meanings of that term in the context of
visualization:

1) just fast enough to handle full data sets at production speeds.

2) new data can be added to an existing plot as they stream in.  I.e. you
watch the plot grow incrementally more complex as new datapoints arrive.

Quote:> The platform is NT 4.0 and later with at
> least 24-bit color.  When z = 1.0, a pixel is green, when z = 0.75, a pixel
> is yellow and when z = 0, a pixel is red, with interpolation between these
> colors for values of z in between.

This one of the things you'll have to clarify further.
"Interpolation" between two given colours is by no means uniquely
defined.  Colorspace is three-dimensional, and there are lots of
possible coordinate systems people use in it.  Interpolation defines a
line along which the colour will move from one fixed point
(e.g. yellow) to another (red).  A line that seems to be "the" obvious
connection between two endpoints in once coordinate system may well
appear as a completely counter-intuitive mess if expressed in terms of
another.

Quote:> The number of (x,y) observations is much smaller than the number of
> pixels, so interpolation between x and y is necessary too.  My gut
> feeling says that linear interpolation between observations will not
> look as good as higher order interpolation.

"Looks good" should be a secondary goal.  First make sure your
visualization is honest to the viewer.  Presenting the data much
smoother than they actually are is deceptive.  Honest representation
is one of the things that distinguish between science and marketing.

Triangulate the plane given your datapoints, interpolate z linearly
for each triangle, and display the results by mapping z --> color.
--

Even if all the snow were burnt, ashes would remain.

Convert 3D function into multi-color gradient bitmap?

On 5 Nov 2002 13:52:53 GMT, Hans-Bernhard Broeker

>> The number of (x,y) observations is much smaller than the number of
>> pixels, so interpolation between x and y is necessary too.  My gut
>> feeling says that linear interpolation between observations will not
>> look as good as higher order interpolation.
>"Looks good" should be a secondary goal.  First make sure your
>visualization is honest to the viewer.  Presenting the data much
>smoother than they actually are is deceptive.  Honest representation
>is one of the things that distinguish between science and marketing.

I strongly agree with Hans-Bernhard about honest visualization. In
fact I would go further and suggest you carefully consider your choice
of false color map. Recommended reading:
<http://www.research.ibm.com/people/l/lloydt/color/color.HTM>
Also, if you have such a small number of data points, modern hardware
should have no trouble achieving interactive display rates, for either
interpretation of "real time".

One important question: Will your (x,y) values always lie on a regular
grid, or will they be scattered?

Convert 3D function into multi-color gradient bitmap?

Thanks for answering my question.  Here are some of my clarifications:

Real-time is relative and in my case not too demanding with current power of
PC's and graphic cards.
My (x,y,z) set of observations is a 30 x 40 matrix which must go into a
roughly 500 x 500 bitmap. The matrix is updated once every 5 seconds.  It is
possible that maybe only 10 % of the z's have changed between iterations, x
and y will not change.  But other things are going on concurrently in the
PC, so efficient code will have its benefits.  I was wondering if there was
a way to avoid the interpolation calculation for some pixels. From what you
suggest, I could do the triangulation once and only repeat the color
interpolation, but for each pixel.  I presume triangulation routines can be
found somewhere on the web.

I was not too concerned about the color interpolation in my case. I hope I
am not underestimating this, but I must admit I was going for the "obvious".
With the endpoints and breakpoint being pure red, yellow and green I assume
that I can make a linear interpolation between (255,0,0) and (255,255,0) to
move from red to yellow.  I am trying to convey a level of danger to a plant
operator.  It's a bit like a traffic light, the actual red, yellow (orange
in many countries) and green are not of prime importance, as long as the
proper associations are made by the viewer.  (I'm sorry I never gave any
thought to colorblind people, that's out of my league, but I do provide
other ways to interpret the observations.)

I like your reference to being honest to the viewer, in the old days some
astronomers ended up with egg on their face after massaging their
observations.  I certainly have no intention of going that route. However,
linear interpolation could show discontinuities in the gradient that do not
exist, isn't it? In addition, the observation error is not negligible. This
warrants smoothing of the data to a certain extent.

Henk Borsje

> > I am looking for a reference to sample (complete is fine too) code to
> > display a set of observations z at different values of  (x,y) as a
> > colored 2D bitmap. As the application is supposed to run in real time,
code
> > optimization seems important.

> I think you should expand on what "real time" means, here.  There are
> at least two common meanings of that term in the context of
> visualization:

> 1) just fast enough to handle full data sets at production speeds.

> 2) new data can be added to an existing plot as they stream in.  I.e. you
>    watch the plot grow incrementally more complex as new datapoints
arrive.

> > The platform is NT 4.0 and later with at
> > least 24-bit color.  When z = 1.0, a pixel is green, when z = 0.75, a
pixel
> > is yellow and when z = 0, a pixel is red, with interpolation between
these
> > colors for values of z in between.

> This one of the things you'll have to clarify further.
> "Interpolation" between two given colours is by no means uniquely
> defined.  Colorspace is three-dimensional, and there are lots of
> possible coordinate systems people use in it.  Interpolation defines a
> line along which the colour will move from one fixed point
> (e.g. yellow) to another (red).  A line that seems to be "the" obvious
> connection between two endpoints in once coordinate system may well
> appear as a completely counter-intuitive mess if expressed in terms of
> another.

> > The number of (x,y) observations is much smaller than the number of
> > pixels, so interpolation between x and y is necessary too.  My gut
> > feeling says that linear interpolation between observations will not
> > look as good as higher order interpolation.

> "Looks good" should be a secondary goal.  First make sure your
> visualization is honest to the viewer.  Presenting the data much
> smoother than they actually are is deceptive.  Honest representation
> is one of the things that distinguish between science and marketing.

> Triangulate the plane given your datapoints, interpolate z linearly
> for each triangle, and display the results by mapping z --> color.
> --

> Even if all the snow were burnt, ashes would remain.

Convert 3D function into multi-color gradient bitmap?

Quote:> One important question: Will your (x,y) values always lie on a regular
> grid, or will they be scattered?

of and with colors.

The (x,y) points are in an approximate (30 x 40) matrix.  Nothing is
equidistant, but 40 y's have the same x.

Henk Borsje

Convert 3D function into multi-color gradient bitmap?

> My (x,y,z) set of observations is a 30 x 40 matrix which must go into a
> roughly 500 x 500 bitmap. The matrix is updated once every 5 seconds.

That's comfortably far on the feasible side of things... ;-)

A regular matrix is triangulated trivially: choose on of the two
diagonal directions, and cut each rectangular cell of the matrix in
half along that diagonal.  Done.

For the actual rendering, using a 3D renderer to do a top-down view of
the vertex mesh, gouraud-shaded, may be the most obvious choice.

Quote:> PC, so efficient code will have its benefits.  I was wondering if there was
> a way to avoid the interpolation calculation for some pixels.

Probably, but that won't gain enough to make much sense.  Note that on
average, every changed z value will affect about 5 triangles that
share this vertex.  I.e. if you change 10 percent of the vertices, you
should expect roughly half the triangles to need a redraw.  May just
as well redraw them all as try to find out which those are.

Quote:> From what you suggest, I could do the triangulation once and only
> repeat the color interpolation, but for each pixel.

You wouldn't actually interpolate the colour itself if you do it in
software.  Interpolation would be in terms of the z coordinate.  Then
you look up or compute the colour's three components based on the
interpolated z.

Very roughly, for a strictly regular mesh with data at integer
positions, and shedding triangulation in favour of bi-linear
interpolation, the per-pixel code could look like this.

x_g = x_pixel / 500 * 40);
y_g = y_pixel / 500 * 30);

dx = x_g - integer(x_g);
dy = y_g - integer(y_g);

z = (1-dx)*(1-dy) * in_z[x_g]  [y_g]
+  dx  *(1-dy) * in_z[x_g+1][y_g]
+(1-dx)*  dy   * in_z[x_g]  [y_g+1]
+  dx  *  dy   * in_z[x_g+1][y_g+1]

R = find_R(z);
G = find_G(z);
B = find_B(z);

Quote:> I was not too concerned about the color interpolation in my case. I hope I
> am not underestimating this, but I must admit I was going for the "obvious".
> With the endpoints and breakpoint being pure red, yellow and green I assume
> that I can make a linear interpolation between (255,0,0) and (255,255,0) to
> move from red to yellow.

I'll assume you meant you'll keep R and B fixed, and just raise the G
proportional to the interval fraction.

Yes, you can do that.  But that's not necessarily the most visually
pleasing or even the most useful path to interpolate along.  To give
just one hint: is that linearized or direct-to-hardware RGB values
you're talking of?  "Perceptionally linear" may be quite different
from both, to boot.

Quote:> linear interpolation could show discontinuities in the gradient that do not
> exist, isn't it? In addition, the observation error is not negligible. This
> warrants smoothing of the data to a certain extent.

You can still do that as a post-processing step after generating a
linearly interpolated image, if need be.

--

Even if all the snow were burnt, ashes would remain.

Convert 3D function into multi-color gradient bitmap?

Thank you for your advice, I should be on my way now.

Henk Borsje

http://sumrallworks.com/freebies/buttonhole/psp/tutorials/multi-color...

Our other PSP Tutorials

Our Other PSP Resources

Our Other Graphic  Resources

http://www.sumrallworks.com/freebies/buttonhole/

Rip & Tim
Paint Shop Pro Resources
Sumrall Works Inc.
www.sumrallworks.com

---------------------------------------------------------------------------------------------------
The  ideas many of our tutorials are based on will be
usefull in other graphic programs. For that reason, this article has been crossposted to the
following geneal graphic newsgroups:
alt.graphics, comp.graphics.misc, alt.design.graphics
----------------------------------------------------------------------------------------------------