Learning how to turn your Maple plots into effective web graphics involves understanding three different processes:
As we discussed last time there are two major graphics file formats used in web pages today: GIF and JPEG. Both formats typically use 24 bits of information to describe a colour. The maximum number of distinct colours in a GIF image is 256, while with JPEG images the number of values is only limited by the colour model being used, 2 24 distinct colours being typical. The particular collection of colours used in an image is often referred to as the palette of the image.
Now if most of the computers in the world provided 24-bit colour (often called true colour) graphics, it wouldn't really matter how many colours were contained in an image; a browser running on a 24-bit colour display could reasonably be expected to render an image with all the necessary colours. Unfortunately for web page authors the universe is not so tidy. While the models of desktop Macs, PC clones, and high-end Unix machines being sold today often do provide 24-bit colour, the majority of laptops, older desktop Macs and PCs, and lower-end Unix machines typically have 8-bit colour displays.
Since an 8-bit colour display allows us to show 256 colours, at first glance we might think that every GIF image will display properly. This would have been true in the early days of GIF when users of CompuServe would download an image that would take the entire screen real-estate to display; the only colours we would be displaying would be those contained in the palette of the image. In modern windowing environments we have many things happening on the screen at the same time, so some colours are already in use for window borders, desktop patterns, browser toolbars, and web page backgrounds. Those colours that are already in use by the surrounding environment may not correspond to the colours that a GIF image needs for proper display; this results in a palette mapping problem:
In computing environments that don't provide true colour, the palette of the image must somehow be mapped into the palette of the environment.This is probably where the GIF and JPEG standards differ the most. JPEG describes how an image should displayed when the environment provides fewer colours than the image requires; GIF doesn't address this issue at all. In the case of JPEG a colour-reduction algorithm is applied, typically sacrificing small details and perhaps reducing contrast while retaining the essential qualities of the image. In the case of GIF a variety of things can happen, depending on the decisions made by the developers of various browsers:
The real challenge for the web page author is that you have very little control over which of these implementations will be in effect for each member of your audience. In my experience, trying to make images with a small number of colours doesn't work; I've created grey-scale images with a dozen levels of grey that ended up mapped into pinks and yellows. Sometimes dithering results in a good image, and sometimes it doesn't; it really varies image by image. Browsers usually do a bad job of finding close matches between an image palette and an environmental palette (think of a GIF image of a sunset where you replace sky-blue pink with lime green, and you'll get the idea). As you include more and more images in a web page, the situation just gets worse as you need more and more colours simultaneously. The bottom line is that you really can't rely on the browser being able to overcome the limitations of the display hardware it is running on.
Right about now you are probably thinking that your only option is to throw your hands up in defeat, but the situation is really much better than that. The solution is to solve the problem in advance by making the image rendering choices yourself, instead of leaving it all up to the browser.
One piece of information that web page designers and graphic artists have picked up over time is that there is a common palette of about 216 colours that is supported by major browsers (eg: Netscape Navigator, Microsoft Internet Explorer) on both Macs and PCs. I've been finding that the same palette is also useful for browsers running on 8-bit colour Unix workstations like SPARCstations and DECstations. While there is (at least to my knowledge) no standards body requiring this to be the case, it is a very important piece of empirical information for the following reason:
If the palettes of all images exactly match the palette provided by the environment, the colour mapping problem can be avoided.This means that with suitably-coloured images we won't have to worry about what a browser will do to those images when they are displayed. I hesitate to say that there will never be instances of colour mapping problems simply because there is no physical or theoretical reason why some software developer couldn't produce a browser (or more likely, a browser display configuration option) that wouldn't provide that 216 browser-safe colour palette, but we can reasonably expect to have accounted for the overwhelming majority of the computing environments typically used by members of our audience.
For the most part I've been talking about the display of GIF images; that leaves the question of whether or not we should try and alter JPEG images to only use those same 216 browser-safe colours. There are a couple of reasons why I don't think this is usually necessary or even desirable:
Enough of the background information; time to discuss some specific methods for creating these browser-safe images. The methods I'll be presenting will be done in the context of Adobe Photoshop, but similar features are available in many packages for editing bitmap images.
The first thing you'll want to do is retrieve a file that contains the browser-safe colour table for Adobe Photoshop. The web page that explains the palette can be found at http://www.lynda.com/hex.html, and the actual palette files are at ftp://luna.bearnet.com/pub/lynda/ .
PC and Unix users will need to retrieve
and unzip the archive to get the
file that contains the colour table. Mac users will want the
file instead; just unbinex the file and rename it to
in order to follow through these instructions.
You'll need a Maple plot to work with; let's use the same GIF of a 3D plot we discussed last issue. With Maple V Release 3 just do the following:
plotsetup(gif, plotoutput=`sinplot.gif`, plotoptions=`height=216,width=288`); plot3d(sin(x*y),x=-Pi..Pi,y=-Pi..Pi, style=patch,scaling=constrained);
If you are using Maple V Release 4 you will need to generate a JPEG image instead:
eval(plotsetup): `plotsetup/devices`[jpeg]:=[jpeg,`plot.jpg`,,,``]: plotsetup(jpeg, plotoutput=`sinplot.jpg`, plotoptions=`height=216,width=288`); plot3d(sin(x*y),x=-Pi..Pi,y=-Pi..Pi, style=patch,scaling=constrained);
Start Adobe Photoshop, and use the File menu to Open the sinplot.gif (or sinplot.jpg) file. The plot will appear in a window and initially it should look pretty much the same as it would in Maple. You are now all prepared to convert this image into one that uses browser-safe colours.
Before you quit Photoshop you can use this opportunity to make other changes to the image of your plot; you can draw lines, give axes values, and create legends of any style that you like. While Maple is capable of doing many of these things when it outputs the plot, the quality of the rasterized text Maple generates is usually quite poor.
One of the difficulties with using Photoshop for these kinds of changes is that Photoshop is, by its nature, a bitmap editor. It doesn't really know what a line is, or what text is; it just modifies the pixels in the image to create the result of drawing those objects. The distinction becomes important when you want to modify something in the image. As an example, if you wanted to modify an axis value from 0 to 0.0, in Photoshop you would have to carefully paint the 0.0 over the original 0. You can't just treat the original 0 as text and append .0 to it. Photoshop really doesn't understand that the image contains text in it. Similarly you would find it time-consuming to change the thickness of all the lines in a 3D wireframe plot because with Photoshop you'd have to carefully paint over them one by one.
A better solution for such situations is to use a software package that doesn't think in terms of bitmaps, but in terms of logical drawing concepts like lines, characters, and polygons. The difficulty of course is in getting the Maple plot into such a graphics package. Unfortunately the loosely-structured Encapsulated PostScript files that are produced by Maple don't make this task any easier; the only option I know of that will work with any degree of consistency is to use Adobe Illustrator 6.0 on a Macintosh. All the other packages I've tried (even Illustrator 4.0 for Windows) lack a PostScript interpreter of sufficient robustness to make much sense out of Maple plot files. Discussion of all the strengths, weaknesses, and drawing options of Adobe Illustrator is beyond the scope of this article, but this package is definitely a powerful tool for a web-page author have at his or her disposal. Just to give you a taste of how you could use it, here is how you would alter the thickness of all the lines in a 3D Maple plot.
You'll need a colour Encapsulated PostScript version of a Maple plot to work with:
plotsetup(cps, plotoutput=`sinplot.ps`, plotoptions=`height=216,width=288`); plot3d(sin(x*y),x=-Pi..Pi,y=-Pi..Pi, style=patch,scaling=constrained);
When that is done you'll need to transfer sinplot.ps as a text file to a Macintosh that has Adobe Illustrator 6.0 on it. Illustrator 5.0 or 5.5 might work as well, but Illustrator 4.0 probably won't be sufficient.
Start Adobe Illustrator, and use the File menu to open the sinplot.ps file. The plot will appear in a window.
That pretty much wraps up our discussion of web-oriented image production for the present. In the next article (not yet written) we'll begin looking at ways of providing mathematical content in web pages.