Re: [Bug 688243] Spurious lines between joined filled rectangles and antialiasing (fwd)

[Robert H. <en...@no...>]

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.