ListDensityPlot, ColorFunction, and associated confusions

[AES/newspost]

I'm trying to show some rectangular arrays in two ways by creating
side-by-side ListPlot3D and ListDensityPlot displays in a GraphicsArray.

Each of the arrays contains a primary "mountain peak" that arises out of
a flat plane at a base elevation close to zero, plus several secondary
hillocks only 1/3 to 1/2 as high as the main peak -- and that's how they
show up in the ListPlot3D,

In the ListDensityPlot, however, using the standard ColorFunction->Hue,
the tops of some of the secondary hillocks show up in the same bright
red as the top of the main peak, even though they appear in the
ListPlot3D to be less than 1/2 as high as the main peak. It's as if
ColorFunctionScaling is being applied locally to each individual peak
somehow.

What might be going on here? (And secondarily, because of the way Hue
functions, the flat background plain ends up in close to the same red as
the top of the peaks. Any easy way to fix that?)

[AES/newspost]

Post by AES/newspost
I'm trying to show some rectangular arrays in two ways by creating
side-by-side ListPlot3D and ListDensityPlot displays in a GraphicsArray.
Each of the arrays contains a primary "mountain peak" that arises out of
a flat plane at a base elevation close to zero, plus several secondary
hillocks only 1/3 to 1/2 as high as the main peak -- and that's how they
show up in the ListPlot3D,
In the ListDensityPlot, however, using the standard ColorFunction->Hue,
the tops of some of the secondary hillocks show up in the same bright
red as the top of the main peak, even though they appear in the
ListPlot3D to be less than 1/2 as high as the main peak. It's as if
ColorFunctionScaling is being applied locally to each individual peak
somehow.
What might be going on here?

Answering my own question on this: Adding PlotRange->All as an option
to ListDensityPlot makes it function as it should.

But, some further, and critical, commentary: Seems to me this should be
the _default_ for this function.

If you make a Plot3D or ListPlot3D and the function goes off scale in
the z direction, you can tell this from the plot: the peaks that go off
scale are visibly cut off, have an obviously truncated or chopped-off
flat top, where they protrude through the top of the box. You receive a
visible warning.

With ListDensityPlot, this is not nearly so obvious -- you don't get
nearly as obvious a visual indication that the plot has been truncated.
I would never have realized it was happening if I didn't have the
ListPlot3D and ListDensityPlot side by side.

Further, haven't rechecked this, but I believe the Help for
ListDensityPlot says ColorFunctionScaling->True is the default. My
arrays were not unusual -- didn't have any wild outliers, just a central
tallest gaussian-like "big peak" covering 10% to 15% of the plot area,
with some lower (i.e., 30% to 50% of peak height) secondary peaks around
it. Default conditions for ListDensityPlot should have scaled and
handled them properly. Instead, it brought the secondary peaks up to
full scale (they would have been perfectly visible without doing this),
and truncated the "big peak" with no warning. Not good.

(By the way, this is Mac OS 9.2, Mathematica 4.2.0.)

[Selwyn Hollis]

Post by AES/newspost
I'm trying to show some rectangular arrays in two ways by creating
side-by-side ListPlot3D and ListDensityPlot displays in a
GraphicsArray.
Each of the arrays contains a primary "mountain peak" that arises out
of
a flat plane at a base elevation close to zero, plus several secondary
hillocks only 1/3 to 1/2 as high as the main peak -- and that's how
they
show up in the ListPlot3D,
In the ListDensityPlot, however, using the standard ColorFunction->Hue,
the tops of some of the secondary hillocks show up in the same bright
red as the top of the main peak, even though they appear in the
ListPlot3D to be less than 1/2 as high as the main peak. It's as if
ColorFunctionScaling is being applied locally to each individual peak
somehow.
What might be going on here? (And secondarily, because of the way Hue
functions, the flat background plain ends up in close to the same red
as
the top of the peaks. Any easy way to fix that?)

Have you tried something like ColorFunction->(Hue[#^2]&) or
ColorFunction->(Hue[#^(1/2)]&) ?


-----
Selwyn Hollis
http://www.appliedsymbols.com
(edit reply-to to reply)

[Wolf, Hartmut]

-----Original Message-----
Sent: Thursday, July 29, 2004 1:46 PM
Subject: ListDensityPlot, ColorFunction, and associated
confusions
I'm trying to show some rectangular arrays in two ways by creating
side-by-side ListPlot3D and ListDensityPlot displays in a
GraphicsArray.
Each of the arrays contains a primary "mountain peak" that
arises out of
a flat plane at a base elevation close to zero, plus several secondary
hillocks only 1/3 to 1/2 as high as the main peak -- and
that's how they
show up in the ListPlot3D,
In the ListDensityPlot, however, using the standard
ColorFunction->Hue,
the tops of some of the secondary hillocks show up in the same bright
red as the top of the main peak, even though they appear in the
ListPlot3D to be less than 1/2 as high as the main peak. It's as if
ColorFunctionScaling is being applied locally to each individual peak
somehow.
What might be going on here? (And secondarily, because of the way Hue
functions, the flat background plain ends up in close to the
same red as
the top of the peaks. Any easy way to fix that?)

Well, an example might simplify discussion.
Possibly your problems are related to:

Options[ListPlot3D, PlotRange]
{PlotRange -> Automatic}


Options[ListDensityPlot, PlotRange]
{PlotRange -> Automatic}


Please compare:

a=10;
data=Table[ 1/(1+a(x^2+y^2)),{x,-1,1,.1},{y,-1,1,.1}];

ListPlot3D[data]
ListDensityPlot[data, ColorFunction -> Hue]

with

ListPlot3D[data, PlotRange -> All]
ListDensityPlot[data, ColorFunction -> Hue, PlotRange -> All]


The bottom and top are both red because Hue[0] == Hue[1] == RGBColor[1,0,0]
If you don't like that, customize your ColorFunction.


--
Hartmut Wolf

[Bill Rowe]

Post by AES/newspost
Answering my own question on this: Adding PlotRange->All as an
option to ListDensityPlot makes it function as it should.
But, some further, and critical, commentary: Seems to me this
should be the _default_ for this function.

This merely trades one problem for a different problem. But it is easy to arrange for PlotRange->All to be the default for your usage. Simply place in the init.m file that Mathematica executes when you begin a session SetSoptions[ListDensityPlot, PlotRange->All]. Once done, PlotRange->All will the the default for you. This can be repeated for other plot functions where you might like this behaviour.

Post by AES/newspost
If you make a Plot3D or ListPlot3D and the function goes off scale
in the z direction, you can tell this from the plot: the peaks that
go off scale are visibly cut off, have an obviously truncated or
chopped-off flat top, where they protrude through the top of the
box. You receive a visible warning.
With ListDensityPlot, this is not nearly so obvious -- you don't
get nearly as obvious a visual indication that the plot has been
truncated. I would never have realized it was happening if I didn't
have the ListPlot3D and ListDensityPlot side by side.
Further, haven't rechecked this, but I believe the Help for
ListDensityPlot says ColorFunctionScaling->True is the default. My
arrays were not unusual -- didn't have any wild outliers, just a
central tallest gaussian-like "big peak" covering 10% to 15% of the
plot area, with some lower (i.e., 30% to 50% of peak height)
secondary peaks around it. Default conditions for ListDensityPlot
should have scaled and handled them properly. Instead, it brought
the secondary peaks up to full scale (they would have been
perfectly visible without doing this), and truncated the "big peak"
with no warning. Not good.

Consider what would happen with different data if PlotRange->All were the default. For example, I have an experiment where I measue optical power in dBm. I expect data to vary over a range of about 10 dB. This particular instrument gives me a output value of 9E+037 when values are out of range. With the default settings in Mathematica's plotting routines, such values are ignored and I see useful plots. With PlotRange->All, I single overrange value would cause the trend in the valid values to become unobservable. And if the power was expected to be constant, this could be interpreted as expected behaviour with potential problems going unnoticed. A single overrange value would be one point which would likely be unnoticed.

The point is, no matter what is chosen for the default graphic settings, there will be some dataset prone to misinterpretation with those particular settings. The only way to avoid misinterpretation of plots is to plot the data in several different ways.
--
To reply via email subtract one hundred and four

[Peltio]

Post by AES/newspost
I'm trying to show some rectangular arrays in two ways by creating
side-by-side ListPlot3D and ListDensityPlot displays in a GraphicsArray.
Each of the arrays contains a primary "mountain peak" that arises out of
a flat plane at a base elevation close to zero, plus several secondary
hillocks only 1/3 to 1/2 as high as the main peak -- and that's how they
show up in the ListPlot3D,
In the ListDensityPlot, however, using the standard ColorFunction->Hue,
the tops of some of the secondary hillocks show up in the same bright
red as the top of the main peak, even though they appear in the
ListPlot3D to be less than 1/2 as high as the main peak. It's as if
ColorFunctionScaling is being applied locally to each individual peak
somehow.

Advice from Selwyn Hollis and Hartmut Wolf has prolly solved your problem,
but I'd rather add a little footnote, if I may do so.
If ListDensityPlot stands to ListPlot3D as DensityPlot stands to Plot3D, a
difference in the plot's colors can be traced back to the different way
these procedures handle the values to be plotted.
The color of a DensityPlot 'tile' is given by the value at its center; the
color of a Plot3D 'tile' is given by the values at its four corners.

If this 'staggering' is kept in their list counterparts, it could cause some
further color discrepancy. And in this case I'm afraid there's no simple
scaling function to make them the same.

cheers,
Peltio
my two cents.
--
Invalid address in reply-to. Crafty demunging required to mail me.