Re: [Plplot-devel] How to support gradients within PLplot

[Alan W. I. <ir...@be...>]

On 2008-10-09 22:42-0500 Maurice LeBrun wrote:

> On Thursday, October 9, 2008 at 12:04:56 (-0700) Alan W. Irwin writes:
> > ...
> > Note, the question of PLplot support for gradients has internal core library
> > implications (e.g., triangle representation for surfaces), API implications
> > (what is the most convenient way to let PLplot users specify gradients?),
>
> That's what cmap1 was created for.  In its simplest application, only two
> points must be specified to map functional value to color space value.  The
> color at intermediate points is determined by interpolation.  Arbitrarily many
> "control points" can be added to achieve a great variety of effects.  If there
> is a "jaggedness" to the final plot, I would look at:
>
> - number of shade levels chosen by plot driver (e.g. plshades)
> - number of cmap1 color entries chosen to allocate by device driver
>
> as the culprit.  The underlying cmap1 model is independent of these.
>
> Note, there are some good reasons to increase the number of cmap1 color
> entries in both the shade plot call or the device driver: to get the very
> smooth color gradient you describe, and to better take advantage of today's
> hardware capabilities.  There are also some downsides: plshade becomes quite
> slow with high resolution plots and lots of colors due to all the triangles
> being filled, and nowadays lots of people are running VPN'ed Xwindows apps at
> great distance, where use of a large color space definitely impacts
> responsiveness.  Ideally in the latter case, you could choose the number of
> colors for the driver to allocate through a resource setting or runtime flag.
>
> As you mention, utilizing hardware gradient support in the driver is an
> intriguing possibility, but there is the SW fallback issue.  One could go with
> rasters instead of the plshade approach, but in this case you have to deal
> with scaling issues (redrawing plot at different size/shape, zooms).  I never
> thought the headache in that case was worth it once plshade was available.

See examples/python/plplot_logo.py (revision exactly 8923 since I plan to
remove this plshades-based gradient attempt later) for an illustration of
the gradient issues for PLplot with the plshades approach. I believe the
problem is that PLplot cannot draw the edges of individual rectangles
perfectly.  I don't think PLplot even attempts to account for the pen width
when butting two filled rectangles against each other.  The limited 16-bit
internal resolution of PLplot may be an issue as well. Anyhow, the result
seems to be that the individual rectangles plotted by plshade (as called by
plshades) overlap each other to a small degree.  This does not cause much of
a problem for simple RGB color, but the positioning issue implies the
opacity of one edge is applied _on top of_ the opacity of the next so that
all rectangle edges have the square of the specified opacity (which looks
pretty ugly for the revision 8923 case). Example 30, page 2 is another
illustration of the same problem for all our opacity-enabled devices.

It turns out increasing the levels is not a very good solution for this
positioning issue. If you make the rectangles extremely thin (nlevels =
1001, say), then their width is less than the pen width, and the overlapping
occurs for a number of rectangles leading to an effective opacity equal to a
high power of the specified opacity.  There might also be internal PLplot
errors or viewer errors for this case because there were some strange
looking colors in the results. There might be an intermediate value of
nlevels where you could get good results for one specific device driver with
a particular pen width, but that is way too specific, and I must say I tried
pretty hard and was unable to get anything that looked good.  Also, even if
I did find a number of levels that looked good on my monitor for a
particular device format viewer, there is no guarantee it will look good on
other monitors/viewers, and also the number of rectangles is going to be so
high that it will probably chew up a lot of filesize/bandwidth.

I think the only way out of this mess for opacity gradients is for PLplot to
support gradients native to the device as has been discussed previously on
this thread. That will allow us to produce good-looking PLplot logo and
example 30 results in house without the necessity of using external image
editors to make gradients in opacity results look good after the fact. It
should also allow us to produce RGB gradients that look as good or better
than now for a much smaller file size/bandwidth.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________