Hans-Bernhard Broeker wrote:
> Daniel J Sebald wrote:
>> course, this demo example doesn't have high enough spatial frequency
>> to cause aliasing.)
> That's quite exactly wrong. All pm3d plots, indeed almost exactly
> *every* plot gnuplot is capable of generating, contains ample amounts of
> infinitely high spatial frequency details --- every thing we output has
> perfectly sharp borders, including the coloured areas generated by pm3d.
No, the example I was referring to is a low frequency sinc function that is adequately sampled. When displayed on the screen, "perfectly sharp borders" is something different. That is what a reconstruction filter is for (different than an antialiasing filter), to smooth out the sharp edges after reconstructing a signal. A reconstruction filter is the case where an image "pixel" occupies multiple screen pixels. They really should be smoothed between image pixels before being displayed. If the image/screen is one-to-one pixels, then the smoothing is inherently done by the monitor screen (unless you place your eye real close to the screen to see individual dots).
You described aliasing below:
> Aliasing has nothing to do with monochrome vs. colour. Aliasing
> is the artefact invariably created whenever you point-sample (i.e.
> render to pixels) a signal at a frequency that's lower than the signal's
> actual bandwidth.
which is correct. From ghostview's perspective, whenever the display is of lower resolution than the image contained inside the PostScript file, there is the possibility of aliasing and antialiasing should be applied. (But applied correctly of course, not with strange lines.) For all I know, "antialiasing" in GhostView could mean both antialiasing (more image pixels than screen pixels) and reconstruction (more screen pixels than image pixels). In fact, that is probably the case. I say that because I have used GhostViews zoom function to greatly expand a few pixels in a subwindow. There is no need for GhostView to apply antialiasing to such an image, yet the lines still appear.
If I bumped up the frequency of that sinc function, I'm sure aliasing would begin to happen. Try this:
1) Run Petr's pm3d.dem demo until the grayscale example that says "gray map".
2) Break out of the demo and change the range as
set xrange [-1500:1500]
set yrange [-1500:1500]
And you will see strange patterns on the image that shouldn't be there because by choosing such a large range the frequency of the sinc within the plotted area is much too great to be displayed.
> More to the point: our x11.trm *knows* the (assumed) resolution of the
> X11 driver, and it does the reduction to integer coordinates itself.
> I.e. the entire rendering process is controlled by gnuplot alone.
> post.trm, OTOH, cannot even make an educated guess what the actual
> output device resolution --- so it just assumes it's 720 DPI.
Right, but the X11 windows can be scaled to have lower resolution. Hence there is a routine in gnuplot_x11 that does that conversion.