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

From: Maxim Shemanarev (mcseem_at_[hidden])
Date: 2002-05-08 18:43:50

Hi Martijn,

Thanks a lot! This is a perfect set of questions for the FAQ.

First, some notes. AGG development is in process, and although it does
not support right now all you need, it's designed to be as open as possible
and what I'm working on is mostly the idea of the design and some nice
algorithms. The idea is to make a library whose concepts would allow anyone
to
add her own algorithms without any changes in the original distribution
package. The rendering process consists of three major steps:
1. Manipulations with data in vectorial representation. It's so called
   conversion pipeline. The example of using it:
   http://www.antigrain.com/agg_docs/doc_pipelines.html
2. Rasterization of the polygons. This part is the core of the anti-aliased
   rendering and it also can be replaced.
3. Sweeping - rendering a number of scanlines that are produces by
   the polygon rasterizer.

Some information about the rendering technique in the low level:
http://www.antigrain.com/agg_docs/doc_tutorial.html

> 1. Does it support colorspaces outside RGB like CMYK, bitmap, grayscale,
LAB
> (a.k.a. YCC), HSV, etc.?

Not yet, but all in good time. Potentially AGG can work with any
continuos colorspace, the set of available color spaces and pixel format
is not limited.
The only thing that confuses me is that the type agg::color has
different semantics in different colorspaces, and so, there probably
will be more than one such types. Temlpate mechanism activelly
used in AGG allows to do so.

> 2. How is anti-alias calculated, using FP-math or scaling?

It's completely in integers, usung subpixel accuracy in format 24.8.

> 3. Where in the pipeline is the anti-alias correction performed, before or
> after what stages?

It's not in the pipeline. The pipeline works only with vertices and
edges, not knowing anything about how it'll be rendered afterwards.
The responsibility of anti-alias takes the polygon rasterizer class
(agg::polyfill). It also does not use the traditional oversampling
technique and performs the rendering in one pass.

> 4. What primitive drawing algorithms are used (bresenham, finite state
> machines, etc..)

Well, the only low level primitive is polygon. agg::polyfill works
similar to glyph renderers with calculation the exact coverage
for each edge pixel. It does not use Bresenham directly.
Can you explain what do you mean "using finite state machine" when
rendering?

> 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.

> 6. How about reading pixel information. Are you using interpolation of any
> kind?

Can you explain it?
If you mean pixel image transformation algorithms, yes, I do use
interpolation.
(but you won't find it right now in the library - it's in process).

> 7. Are fixels/wu-pixels supported and, if so, are they rectangular or
> circular?

Well, afaik, fixels and wu-pixels are completely diffedrent things. Am I
wrong?
Wu pixels are not supported directly, but the rendering algorithm uses a
very similar idea: http://www.antigrain.com/img/subpixel_accuracy1.gif

> 8. Is there any posibility for aspect ratio and unit conversion (inch ->
> cm -> point -> etc.)?

Yes. It's simply a part of the conversion pipeline.

> 9. Is there any gamut detection/limiting ability?

Not yet. In general, Color Management topic is not covered. All AGG has
is a possibility to set a gamma-correction array for anti-aliasing.

> 10. Are colorspace conversion functions available (RGB <-> CMYK <-> HSV
<->
> LAB)?

It's gonna be functions of respective scanline rendering classes that
support
a particular colorspace.

> 11. How does AGG handle alpha mixing?

I use quite a traditional formula in the existing renderers. But,
again it's completely up to the scanline rendering classes.

> 12. Can the channel mixer be customized to allow for additive,
> multiplicative and other mixing modes?

Yes. The concepts of the library allow to customize it. I intend to
implement a whole bunch of rendering classes with all these possibilities.

> Granted, the above questions may not apply for the average application
doing
> graphs or chart but any serious graphics application can't do without
them.

What do you mean "any serious graphic application"? Does a GIS system need
to support YUV colorspace for example?
The variety of graphic applications is great and if it does not use
something
mentioned above it does not mean it's not serious :-)

Basically I develop AGG keeping the SVG standard in mind, but it does not
mean
it will have an interface similar to SVG's DOM one. The approach in AGG is
different. I'm trying to propose a sort of new design concepts for graphic
libraries accompanied with nice and high quality graphic algorithms.
Not all of it can be covered because my physical and mental abilities are
limited, I'm just trying to do what I can do well :-)

McSeem
http://www.antigrain.com