Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2005-07-28 07:35:07
|
Below is a answer to the bug report by ghostscript people. The referenced
bug 687742 refers to ghostscript documentation, where, amazingly, you can
read the following:
-dTextAlphaBits=n
-dGraphicsAlphaBits=n
These options control the use of subsample antialiasing. Their use is
highly recommended for producing high quality rasterizations. The
subsampling box size n should be 4 for optimum output, but smaller values
can be used for faster rendering. Antialiasing is enabled separately for
text and graphics content. Allowed values are 1, 2 or 4.
Note that because of the way antialiasing blends the edges of shapes
into the background when they are drawn some files that rely on joining
separate filled polygons together to cover an area may not render as
expected with GraphicsAlphaBits at 2 or 4. If you encounter strange lines
within solid areas, try rendering that file again with
-dGraphicsAlphaBits=1.
I'm asking about how to switch GraphicsAlphaBits from within the ps code...
---------- Forwarded message ----------
Date: Wed, 27 Jul 2005 13:10:25 -0700 (PDT)
From: bug...@gh...
Subject: [Bug 688243] Spurious lines between joined filled rectangles and
antialiasing
http://bugs.ghostscript.com/show_bug.cgi?id=688243
------- Additional Comments From ale...@co... 2005-07-27 13:10 -------
Created an attachment (id=1578)
--> (http://bugs.ghostscript.com/attachment.cgi?id=1578&action=view)
foo.ps -- modified sample
This is an old and rather difficult to fix issue. See the bug 687742 for the
discussion. gnuplot can try to write adjacent boxes in the single fill
operation but this is not possible when the bxes have different colors.
See the modified sample file.
|
|
From: Daniel J S. <dan...@ie...> - 2005-07-28 08:33:23
|
Petr, My somewhat limited experience with ghostscript was disappointing. I appreciate what it does, but it seems less than elegant. I looked at some of the PostScript code it generates when translating and it appeared bloated in a major way. I've seen this before with some of your demo examples. It bewildered me. Not only were the white lines present, but the color scheme was incorrect for a large percentage of the parallelograms. But I thought it was fixed since I no longer saw the effect in ghostview after I upgraded to Fedora 3. This doesn't seem like a problem that should exist as it is described below in the manual. It sounds to me like it has something to do with the lowpass filter kernel used to rid aliasing. Perhaps it was originally written to render in a way that stuck them in a corner without a lot of rewrite. > I'm asking about how to switch GraphicsAlphaBits from within the ps code... I'd be careful to not add such a thing *unless* it is standard PostScript. Dan Petr Mikulik wrote: > Below is a answer to the bug report by ghostscript people. The > referenced bug 687742 refers to ghostscript documentation, where, > amazingly, you can read the following: > > -dTextAlphaBits=n > -dGraphicsAlphaBits=n > These options control the use of subsample antialiasing. Their use > is highly recommended for producing high quality rasterizations. The > subsampling box size n should be 4 for optimum output, but smaller > values can be used for faster rendering. Antialiasing is enabled > separately for text and graphics content. Allowed values are 1, 2 or 4. > > Note that because of the way antialiasing blends the edges of shapes > into the background when they are drawn some files that rely on joining > separate filled polygons together to cover an area may not render as > expected with GraphicsAlphaBits at 2 or 4. If you encounter strange > lines within solid areas, try rendering that file again with > -dGraphicsAlphaBits=1. > > I'm asking about how to switch GraphicsAlphaBits from within the ps code... > > > ---------- Forwarded message ---------- > Date: Wed, 27 Jul 2005 13:10:25 -0700 (PDT) > From: bug...@gh... > Subject: [Bug 688243] Spurious lines between joined filled rectangles and > antialiasing > > http://bugs.ghostscript.com/show_bug.cgi?id=688243 > > ------- Additional Comments From ale...@co... 2005-07-27 13:10 > ------- > Created an attachment (id=1578) > --> (http://bugs.ghostscript.com/attachment.cgi?id=1578&action=view) > foo.ps -- modified sample > > This is an old and rather difficult to fix issue. See the bug 687742 for > the > discussion. gnuplot can try to write adjacent boxes in the single fill > operation but this is not possible when the bxes have different colors. > See the modified sample file. > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September > 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Petr M. <mi...@ph...> - 2005-07-28 09:50:33
|
> This doesn't seem like a problem that should exist as it is described below > in the manual. It sounds to me like it has something to do with the lowpass > filter kernel used to rid aliasing. Perhaps it was originally written to > render in a way that stuck them in a corner without a lot of rewrite. I wonder what's the algorithm for antialiasing is & should be. Currently, it seems that they antialias the current drawn rectangle with its current surrounding (e.g. white background), instead of waiting for some potential future object (rectangle) that will be drawn closely. It would probably need much more memory to antialias the final image (and to remember all graphics elements there). It seems that my proposed "stroke" to /f and /h and redrawing the interior of the color box twice improve the rendering fine. >> I'm asking about how to switch GraphicsAlphaBits from within the ps code... > I'd be careful to not add such a thing *unless* it is standard PostScript. Not without discussion. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2005-07-28 16:01:21
|
Petr Mikulik wrote: >> This doesn't seem like a problem that should exist as it is described >> below in the manual. It sounds to me like it has something to do with >> the lowpass filter kernel used to rid aliasing. Perhaps it was >> originally written to render in a way that stuck them in a corner >> without a lot of rewrite. > > > I wonder what's the algorithm for antialiasing is & should be. > Currently, it seems that they antialias the current drawn rectangle with > its current surrounding (e.g. white background), instead of waiting for > some potential future object (rectangle) that will be drawn closely. Well, of course in the case of nonuniform sampling it is a huge issue. That's a theoretical issue in the realm of research, if ever it has a solution. But in the case of a grid of points one would average the colors of surrounding pixels; how many depends on the resolution of the original image versus the resolution of the display. I'm getting into ghostview more than I care to know, but a rhetorical question would be, Is the 1, 2, 4 something having to do with the number of surrounding pixels or elements that are averaged (i.e., the kernel)? And if 1 is chosen it means no smoothing? (I.e., no antialiasing.) A good routine would figure out how big the kernel should be. > It > would probably need much more memory to antialias the final image (and > to remember all graphics elements there). That is true, but the correct way. But it shouldn't be too much extra memory in the case of a rectangular grid. (Perhaps that is why ghostview's image doesn't have this problem.) Also, I would think there are multirate approaches, e.g., rather than attempting to get the final antialiased image in one pass, use gradual smoothing and several passes to get to the final resolution. I'll admit that when I did the imaging for the X11 driver I disregarding aliasing (i.e., no averaging is done when the image is decimated). But I felt that was a case of speed/usefulness versus complete correctness. If ever the issue comes up, I can address it. But given the nature of typical image data, it often isn't a problem and it doesn't have a consistent, glaring characteristic like white lines. Like I said, I'm not seeing this problem anymore. Don't know why. Dan |
|
From: Robert H. <en...@no...> - 2005-07-28 16:43:43
|
On Thu, 2005-07-28 at 11:02 -0500, Daniel J Sebald wrote: > I'm getting into ghostview more than I care to know, but a rhetorical question would be, Is the 1, 2, 4 something having to do with the number of surrounding pixels or elements that are averaged (i.e., the kernel)? And if 1 is chosen it means no smoothing? (I.e., no antialiasing.) A good routine would figure out how big the kernel should be. I thought the 1, 2, 4 bit is adding an alpha channel to the image. When any object is drawn, this is set to a value that represents the proportion of a pixel that has been "used". When subsequent objects are drawn, then a new colour can be assigned to the pixel based on the current colour and alpha value and the new colour and alpha. Thus with 1bit, each pixel is either used or not used. With 2bits, there are 4 levels - not used, 1/3 used, 2/3 used, fully used, and with 4bits there are 16 levels. Presumeably what we are seeing is some kind of rounding error, where our two adjoining polygons don't lead to a final alpha value of one. By having a positive thickness to the lines around the objects, they effectively overlap (albeit slightly) and hence are more likely to get it right. An alternative approach, which may produce better results, is to rended the image at a higher resolution, and then reduce the resolution. This may not necessarily need more memory, as the image could be split into smaller tiles, but that is getting off topic. > > It > > would probably need much more memory to antialias the final image (and > > to remember all graphics elements there). > > I'll admit that when I did the imaging for the X11 driver I > disregarding aliasing (i.e., no averaging is done when the image is > decimated). But I felt that was a case of speed/usefulness versus > complete correctness. If ever the issue comes up, I can address it. > But given the nature of typical image data, it often isn't a problem > and it doesn't have a consistent, glaring characteristic like white > lines. I think the situation is slightly better for the X11 driver, because the resolution of the output device is known in advance, you can therefore round coordinates to get better results. (I think ghostscript antialiased images can look quite blurry especially for vertical and horizontal lines) The openGL terminal driver I wrote had an optional antialias mode. I don't recall getting any major problems, but I may not have tried the specific cases that we are seeing here. I think OpenGL uses an 8-bit alpha channel, so maybe that is why. Rob -- Robert Hart <en...@no...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
|
From: Daniel J S. <dan...@ie...> - 2005-07-28 17:45:45
|
Robert Hart wrote: > On Thu, 2005-07-28 at 11:02 -0500, Daniel J Sebald wrote: > <snip> > Presumeably what we are seeing is some kind of rounding error, where our > two adjoining polygons don't lead to a final alpha value of one. By > having a positive thickness to the lines around the objects, they > effectively overlap (albeit slightly) and hence are more likely to get > it right. Oh, I see. That might also explain the odd polygon colors I used to see. Actually, I just found that the problem hasn't gone away with the software in Fedora 3. It is obviously much better so perhaps there were multiple issues. Anyway, I'm using GhostView right now to view one of Petr's b/w sinc-like, 2D-projected, grayscale images. There are lines; but turning off antialiasing from the "State" menu causes the lines to go away. (Of course, this demo example doesn't have high enough spatial frequency to cause aliasing.) The color bar also looks much better. (No aliasing possible there in monochrome, unless intentional.) > An alternative approach, which may produce better results, is to rended > the image at a higher resolution, and then reduce the resolution. This > may not necessarily need more memory, as the image could be split into > smaller tiles, but that is getting off topic. That's on topic. > I think the situation is slightly better for the X11 driver, because the > resolution of the output device is known in advance, you can therefore > round coordinates to get better results. (I think ghostscript > antialiased images can look quite blurry especially for vertical and > horizontal lines) Perhaps. Dan |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-29 12:10:27
|
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. > The color bar also looks much better. (No aliasing possible there in > monochrome, unless intentional.) 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. For all plot features that have at least one dimension not larger than one pixel (i.e. dots, lines, and any borders between solid-filled areas, and vertices of solid-filled polygons), you invariably get aliasing. It manifests itself in the fact that the feature will be displayed up to half a pixel away from its "true" position. >> I think the situation is slightly better for the X11 driver, >> because the resolution of the output device is known in advance, >> you can therefore round coordinates to get better results. 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. |
|
From: Daniel J S. <dan...@ie...> - 2005-07-29 16:04:28
|
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] 3) replot 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. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-29 16:59:42
|
This discussion seems to be veering off on a tangent,
since the bug has been confirmed to lurk on the ghostscript side
rather than in gnuplot's driver.
As I understand it, we're waiting to hear back from
the ghostscript people if there is a PostScript command that can
be embedded in the file which would set GraphicsAlphaBits to 1.
I imagine this would be some variant of
/GraphicsAlphaBits where
{(%something identifying ghostscript%)
<</GraphicsAlphaBits 1>> setdevparams} if
(obviously not tested by me)
But I fear this will encounter a number of problems,
such as not being allowing inside an EPSF file.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-29 17:39:06
|
Daniel J Sebald wrote:
> 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.
I think we're talking about two different sampling processes here.
A PM3D function plot that ends up on any raster device (no matter
through which driver) always involves at least two sampling processes:
one from a (hopefully) continuous 3D surface to a polygon mesh, the from
from that polygon mesh to pixels. The sampling frequency for the first
one (controlled by "set isosamples" and "set samples" in gnuplot) may be
as smoothly and adequately sampled as it wants: the polygon mesh that
comes out of this process still has sharply defined corners and edges
(e.g. a sharp boundary between two uniformly gray rectangles of
different gray values), and those will quite certainly alias as they get
scan-converted to pixels. It's this latter sampling process and the
aliasing it generates that we're having problems with.
The only way to keep that from happening would be to match the "set
{iso}samples" settings in gnuplot exactly to the actual output
resolution. For drives like GD, X11 and some others, that's possible;
for PostScript it's not.
> 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.
For gnuplot output, the image is pretty much always of infinite spatial
resolution: we have razor-sharp edges all over the place. Ghostscript
trying to antialias its display of what we give it is therfore perfectly
justified. The problem is not that gs tries to antialias, it's that it
fails to get it done.
> 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.
You're missing an important details: PostScript doesn't *have* pixels.
It's a vector-based graphics description format. Pixels and aliasing
only get involved as this continuous description gets mapped to discrete
output formats.
|
|
From: Daniel J S. <dan...@ie...> - 2005-07-29 17:49:33
|
Hans-Bernhard Broeker wrote: [...] I agree with everything you said... > You're missing an important details: PostScript doesn't *have* pixels. > It's a vector-based graphics description format. Pixels and aliasing > only get involved as this continuous description gets mapped to discrete > output formats. but I think this is what the issue is. Those lines we are seeing aren't a problem with PostScript. They are a problem with the interpretter's antialiasing routine. When the mesh lines are turned on, they cover up the artifact (the bug) in GhostView and all its related software (gs, ps2pdf, etc.). That's the way I'm understanding it. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-29 17:57:55
|
On Friday 29 July 2005 10:54 am, Daniel J Sebald wrote: > > Those lines we are seeing aren't a problem with PostScript. right > They are a problem with the interpretter's antialiasing routine. not so much a problem with the routine itself, as a bad choice of which elements to apply it to. > When the mesh lines are turned on, they cover up the artifact (the bug) > in GhostView and all its related software (gs, ps2pdf, etc.). > That's the way I'm understanding it. Not quite. The ghostscript bug should not affect conversion to pdf, because that is a conversion from one vector description to another. Acrobat, or xpdf, would have to introduce their own separate aliasing bug to get the display wrong. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2005-07-29 18:13:43
|
Ethan Merritt wrote: > Not quite. The ghostscript bug should not affect conversion to pdf, > because that is a conversion from one vector description to another. > Acrobat, or xpdf, would have to introduce their own separate aliasing > bug to get the display wrong. Well, I know what you are thinking, but I'm not so sure that is the case with ghostscript. It may be. However, my experience is that if something is wrong in one variation of ghostscript software (e.g., ghostview) it is a problem in all variations of ghostscript (e.g., translator). Dan |
|
From: Petr M. <mi...@ph...> - 2005-08-11 08:21:15
|
Does somebody knows whether this directive << ... /Interpolate false ... >> would help? (And how/where to use it? Inside some gsave/grestore?) --- PM |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-08-11 16:43:56
|
On Thursday 11 August 2005 01:21 am, Petr Mikulik wrote: > Does somebody knows whether this directive > > << ... /Interpolate false ... >> > > would help? As I understand it, this is an optional dictionary value that is passed on to the interpreter (printer, or in this case ghostscript). So any effect it has will vary depending on the output device. Newer versions of ghostscript claim to process this value, but I have not found any explicit statement of exactly what they do with it. > (And how/where to use it? Inside some gsave/grestore?) I think you would have to load it into a dictionary during the prolog. So far as I know, dictionary values are unaffected by gsave/grestore. It is disappointing that this is all so poorly documented. The closest I can find is from the notes to ghostscript version 6, which is quite out of date. And even so it's not very helpful: The image operator honors the Interpolate flag in the image dictionary only for ImageType 1 and 3 images, only if the combined transformation (ImageMatrix + CTM) doesn't involve rotation, skewing, or X-reflection, and only for certain scalings and color spaces; imagemask doesn't honor Interpolate at all. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
