[boost] Re: RE: A preliminary proposal: AGG project

From: Martijn W. van der Lee (martijn_at_[hidden])
Date: 2002-05-10 12:55:27

> > So how are you coping with floating point coordinates, assuming AGG
> supports
> > these?
>
> I simply convert them to integers before the rasterization:
>
> polyfill.move_to(int(x * 256.0), int(y * 256.0));
> where x and y - FP pixel coordinetes.

Is this exposed in the interface, i.e. can you draw a line from point (10,
2) to (10.5, 223.4212)?

Also this brings up another limitation, namely the maximum dimensions of a
canvas. If 32-bit ints are used, the max. width would be about 16.7M. No
problem here, however, if in the future AGG were to support 16-bit color,
you'd have to shift the ints by 16 bits, limiting the resolution to 32K,
enough for screen display but not so for modern printers. Then again, if
16bpc is never supported, no >real< problem though it would be nice to be
able to request maximum canvas size from AGG for cross-compatibility.

> > > > 5. Is 16bit-per-channel supported or, any other non-8bpc mode.
> > >
> > > Yes. Although it's not implemented now, I plan to do that. Actually,
> > > any mode is considered as a colorspace and all you need is to
implement
> > > a very simple scanline renderer class.
> >
> > Considering the fact that you're using integers internally, what is the
> > maximum colordepth supported?
>
> Good question :-)
> It depends on the fact whether you can afford to use 64-bit arithmetic
> to calculate mixed color values. If you can it's up to 16 bits per channel
> and it's only because the color structure uses 16-bit values for color
> components. If you use only 32 bits integers, it's less, but, the
> internal representation of, say, 10Red, 12Green, 10Blue can be
> implemented. It really is a good questions, because:
> 1. The majority of applications does not require using more than
> 8bit/channel.
> 2. There's a number of a sort of "Hi-End" applications where it's
> important to use more than 8 bits. For example, when superimposing
> many layers on one canvas with different alpha-mixing values, the
> canvas accumulates errors and they can be great when using 8-bit
> representation. But in this case we can sacrifice the performance
> for the sake of quality.
>
> Another concern is that I use only 256 level anti-aliasing. I'm not sure
> it's enough for all cases and this is an issue for the next version
> of AGG. Now it's restricted by the representation of pixel
> coverage values in the scanline container. I probably will use
> a template class for it.

This was the one I was going for. Perhaps is a scanline could consist of
structures for this (not sure if this is what you meant in that last
sentence). This would probably also easy conversion to hardware-dependant
bitmaps.

> > Once again, these are only usefull when you've got a
> > putpixel() with floating point coordinates.
>
> It's also a good question. It's possible to render wu-pixels of any
> shape using the common AGG rendering approach. But the
> performance of it is relatively low. The only interface function
> that the rasterizer requires is a sort of render_scanline().
> I'm thinking about extending this interface in order to eliminate
> the overhead in some particular cases such as putpixel().

In theory, does the design of the pipeline allow for other implementations
of AGG to specialize these primitives?

> > Perhaps you could implement a callback, simple one which passes a color
> out
> > and returns the corrected color, or for the gamut detection, a boolean
> > value?
>
> The general approach in AGG is that it's an open library.
> It means that if I add all the possibilities in one rendering class
> it will seriously affect it's performance, so, I prefered to start
> with simple and obvious things. But it does not excude
> the possibility to write more complicated templetized
> classes with all possible callbacks, and a lot of internal
> logic.

I'd prefer this unless it would impact performance unreasonably, if only to
allow the widest possible usage of AGG.

> > This is a thing a lot of people get wrong. It's quite a mathematical
> problem
> > and I only know the formula for a reasonable approximation but this is a
> > >very< important issue.
>
> Again, it's an issue of quality vs performance. I don't claim my approach
> in mixing is good, but I'd say it's _appropriate_ for many applications.
> I agree in cases of high qiality image composing it'll give bad result,
> but you can create your own rendering class. All of it will be desribed
> soon.

It's not so much a quality problem as it is a problem of the result being
visually wrong. Imagine a red pixel at 50% transparency, now add a green
pixel at 50% transparency. What result will this mixing yield? It _should_
be a very green shade, not yellow. PhotoShop reports this test as 25% red,
75% green, no blue at about 89% transparency (after flattening, during
drawing PhotoShop uses approximation).

> > I meant
> > things like desktop publishing software and other applications whose
sole
> > purpose is to render those primitives.
>
> IMO this kind of applications is most developed. And as I see you're an
> expert in it. Is http://www.v-d-l.com yours?

Yup, it's my site but I am by no means an expert. This site is only a
grown-out-of-proportions hobby and I have no intention to do any "big"
graphics projects. My prime interest in AGG is a possible integration of it
into the FilterMeister program (www.filtermeister.com) which I use for my
own plug-ins.

> My orientation is different - it's basically engineering tasks. The
amazing
> thing is that there lots of research in publishing, in 3D graphics, and so
> on
> but somewhere in the middle, there's absolute emptyness. I mean all the
> scientists and engineers use obsolete rough graphics.

I can imagine anti-aliassing being useful in analog electronics simulation
(where I have some experience), especially with AGG's correction allowing
crisper or "thinner" lines and CAD (certified AutoCAD doodler) could
probably do with anti-aliassing on screen, though it should also be able to
not anti-alias (perhaps the correction can be set to correct-away the
anti-alias?) for precision when making selections. Also; CAD is notorious
for it's graphics performance problems, after all, the best graphics
hardware made is made for CAD.

> All the questions you arose are great because they make me
> think more about the design, the approaches, and the algorithms
> and finally to issue a high quality product.

That's why I asked them. If I didn't see a future for AGG, I wouldn't have
bothered :)

> > As for complaints about support for specific hardware architectures,
> > you may
> > have noted I did not mention these since I wholeheartedly agree with
> > drawing
> > raw data only.
>
> When the high quality anti-aliased rendering is standardized in
> hardware it'll be possible to use underlying APIs. But I don't believe
> it'll happen soon. All I see now gigantic efforts of such
> companies as nVidia, ATI, and others with quite miserable result.

Try the WildCat cards (I believe from 3DLabs), they're for the professional
CAD workstations and will probably include some high-quality stuff.
As for libraries, have you thought of Intels' high-performance graphics
library?

regards,
Martijn van der Lee