-
Just been reminded of a thought I had some years back. I'm curious as to what algorithm Xara actually uses for its antialiasing or (assuming that's a trade secret) what assumptions it makes about the display.
It would appear that the results are slightly better on a CRT than an LCD - although it may just be that my laptop has a cheap screen. I was wondering whether there's any scope for expanding the display options. Targetting an LCD - with rectangular, limited pixels and the possibility of doing ClearType style resolution enhancement - is quite different from targetting a CRT with a gaussian blurred pixel. As more professional artists get to play with desktop LCD panels, this may become more relevant.
The same issue appears with sampling for printing - I hear Xara may be improving upon nearest-neighbour for bitmap printing; might there be some scope for supporting various sized filter kernels for image export, too? There might also be some scope in automatic hinting, given knowledge of the printer screen, but there's probably a PhD project in there somewhere...
There may be some correlation between trying to do this and the "group transparency" (which I take to mean the equivalent of rendering the group to an appropriate resolution bitmap and then placing the bitmap on the page with a given transparency - allowing for group components to be partly transparent as well; but it could mean something totally different for all I know) which got pulled from Xara X. Being able to create a shape which antialiases to the background, rather than components of itself (for overlaid edges) would be useful. As would the general concept of being able to lock a group to, for example, the transparency channel (in place of bitmap transparency - perhaps this is in fact what group transparency does?)
Whatever Xara does, it's certainly very effective - and fast; I'm just interested in whether there's a chance of future improvements in quality, at least for output where speed is less important.
Yours technically,
Andrew Garrard
-
Just been reminded of a thought I had some years back. I'm curious as to what algorithm Xara actually uses for its antialiasing or (assuming that's a trade secret) what assumptions it makes about the display.
It would appear that the results are slightly better on a CRT than an LCD - although it may just be that my laptop has a cheap screen. I was wondering whether there's any scope for expanding the display options. Targetting an LCD - with rectangular, limited pixels and the possibility of doing ClearType style resolution enhancement - is quite different from targetting a CRT with a gaussian blurred pixel. As more professional artists get to play with desktop LCD panels, this may become more relevant.
The same issue appears with sampling for printing - I hear Xara may be improving upon nearest-neighbour for bitmap printing; might there be some scope for supporting various sized filter kernels for image export, too? There might also be some scope in automatic hinting, given knowledge of the printer screen, but there's probably a PhD project in there somewhere...
There may be some correlation between trying to do this and the "group transparency" (which I take to mean the equivalent of rendering the group to an appropriate resolution bitmap and then placing the bitmap on the page with a given transparency - allowing for group components to be partly transparent as well; but it could mean something totally different for all I know) which got pulled from Xara X. Being able to create a shape which antialiases to the background, rather than components of itself (for overlaid edges) would be useful. As would the general concept of being able to lock a group to, for example, the transparency channel (in place of bitmap transparency - perhaps this is in fact what group transparency does?)
Whatever Xara does, it's certainly very effective - and fast; I'm just interested in whether there's a chance of future improvements in quality, at least for output where speed is less important.
Yours technically,
Andrew Garrard
-
I don't have any of the technical answers to your questions but what impressed me a lot about Xara's anti-aliasing is when I did the chrome pretzel tutorial using Xara X which is a 900-step blend on a path of two fountain filled circles.
When I compared Xara's image to the same image created in CorelDRAW 9, the difference was night and day. Xara's image was incredible smooth and fluid whereas DRAW's, even with 900 steps in the blend, as noticably rough and jagged.
Gary
Gary Priester
Moderator Person
Be It Every So Humble...
-
<BLOCKQUOTE><font size="-1">quote:</font><HR>I'm curious as to what algorithm Xara actually uses for its antialiasing<HR></BLOCKQUOTE>
AFAIK Xara simply works out what proporition of each pixel is covered when drawing each path, and draws onto that pixel using the proportion covered as an opacity value.
This means, for example, that a white pixel half-covered by two identical black shapes will end up 75% black instead of 50%. You can see this in effect by drawing a shape and cloning it repeatedly; the border will become darker and less anti-aliased for each copy.
You can also see artefacts of this type of antialiasing if you lay two rectangles together so that their adjoining edges are not on a pixel boundary. You can get a thin 'break' between them.
The other way of doing anti-aliasing - that of rendering the entire viewport at a much higher resolution and then rescaling the image to fit using bilinear interpolation - is much slower, and you probably need about a 4x (linear, 16x area) supersample to produce similar gradations to Xara's method. When you see 'full-screen anti-aliasing' on newer 3D graphics cards, supersampling is what you're getting. I imagine other drawing programs do it this way too since it requires less rewriting than Xara's way.
When saving graphics for the web (where every pixel counts), I often combine the two by grabbing Xara-anti-aliased graphics at 2x resolution and scaling down. It would be nice to have this as a Window->Quality option too I suppose.
<BLOCKQUOTE><font size="-1">quote:</font><HR>Targetting an LCD - with rectangular, limited pixels and the possibility of doing ClearType style resolution enhancement - is quite different from targetting a CRT with a gaussian blurred pixel.<HR></BLOCKQUOTE>
Indeed so. Unfortunately Microsoft have patented ClearType so it's unlikely Xara could include any built-in features along similar lines without getting sued.
(for those who've not seen it: ClearType is Microsoft's name for supersampling fonts, but on scaling down, taking advantage of the known arrangement of coloured pixels in an LCD display, tinting each part-pixel slightly to 'push' it slightly in one direction on LCDs. There's no reason why it should be limited to text, but it does work best on B/W output to avoid spoiling the colour.)
I'd be happy to write a simple scale-down-and-optimise-for-LCD Python script myself, if anyone's interested. The idea in itself seems fairly obvious, and I'm already going to Patent Hell for my LZW-compressing gifWriter script in any case. [img]/infopop/emoticons/icon_razz.gif[/img]
-
Algorithms which draw at a higher resolution and then scale down are naive and inherently slow. "Foley & Van Dam" + table-driven assembler + fine tuning works a lot faster. And it gives the _correct_ results, unlike the claimed AA of eg. Adobe Acrobat; Windows "smoothed" fonts; my Linux desktop jappedly starring back at me etc etc
-
It's the pixels, innit? They overlap on the CRT so there's a kind of built in AA.
(Or you could try smearing Vaseline on the screen. No performance degradation either with that approach.)
-
The red, green and blue dots on a CRT screen are fixed, separate and not blurred, by virtue of a physical screen within the tube. Unlike an LCD however, the ratio of dots per pixel and the position of the dots within a given pixel cannot be guaranteed because of distortion and user settings etc. The apparent smoothing is probably caused by imperfect beam focus, dot (cluster) shape (i.e. round) and a non-integer ratio of pixels to dots.
Although ClearType will be heavily patented by Microsoft, the underlying concept is twenty years (or more) old. It's possible that an enterprising panel manufacturer will develop a vector based screen driver which does all the work, so programs like Xara could just treat the screen like they would a PostScript printer.
Regards - Sean
[This message was edited by Sean Sedwards on August 24, 2000 at 02:39 AM.]
-
Oops. That'll teach me not to start a thread and then get dragged away from my computer for weeks on end... [img]/infopop/emoticons/icon_frown.gif[/img]
As Andrew says, I'm sure Xara works out coverage while rendering each component of a path in comparison to what's under it - hence, as you say, the multiple copies trick to kill the antialiasing on a boundary. I'm assuming control over this might have been addressable by the "group transparency" code that got pulled from X; the concepts aren't entirely disassociated. And as Justin says, I'm sure it's done algorithmically, not by rendering then scaling down (which is essentially what would be required for antialiasing at the per-group level, although there may be a cunning optimisation).
As Sean says, Micro$oft didn't come up with the idea of ClearType, and I'm not quite sure what the content of their patent *is* (I know what the technology does, just not which precise bit is patented). I have a feeling it's up their with the patents on stochastic sampling for antialiasing, reversible mathematical operations for cursor rendering, and a colon in the time on an alarm clock that flashes every second. Someone should fire bomb the patent office. (Er, just kidding, Echelon).
What I was actually trying to get at was that the pixel produced by a CRT is, as Justin says, blurred. By incorporating the right kernel into the antialiasing code it's possible to allow for this to make the antialiasing look better; I don't know whether Xara does so, or whether they decided that it would either slow down the rendering or be impossible to calibrate sensibly for all possible monitors out there.
My expectation, and I haven't actually seen a study on this (although I'm sure they exist) is that a different kernel would do a better job of the image on an LCD display, with clearly bounded rectangular pixels. The ClearType business is an extention to that. Further to Sean's description, there's some coverage of the technology at http://grc.com/cleartype.htm
There's a treatment on filtering images to get a more faithful result on an NTSC display in Jim Blinn's "Dirty Pixels". I would have thought a similar technique might have been appropriate. But of course all of this may have an unpleasant effect on the rendering speed we all know and love - I don't know, it depends (mostly) on whether there's a filter already being applied.
Oh, and Justin, I'm *not* going to smear Vaseline on my Libretto. You'll get me ranting about the difference between proper text antialiasing (I come from an Acorn background - they were doing it in 1987) and Micro$oft's "inserting grey pixels around the text". At least, that's what it looks like... (or did when they first implemented it). I've had enough of articles advising against antialiased text at small font sizes "because it's less legible". :-7
Cheers,
Andrew Garrard
-
Actually, Steve Gibson's site doesn't have anything like the correct low-down on ClearType... this site on the other hand, does:
http://research.microsoft.com/~jplat...pe/default.htm
Particularly, the papers submitted to the IEEE.
Simon
