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 __________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
