[boost] Re: A preliminary proposal: AGG project

From: Mika Heiskanen (Mika.Heiskanen_at_[hidden])
Date: 2002-05-13 10:27:50

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

> It depends. If you're modeling a real world transparency, such as 
> looking through a 50% transparent glass to a picture, you're absolutely 
> right. But, the anti-aliasing also works with transparency, it's another 
> case of thransparency, and, IMO, the value of a pixel that has 50% 
> coverage should be namely yellow.

This is not a choice to be made by AGG, but by the user of the rasterizer. 
The user should be able to pass either via a functor or via a template 
parameter the method to be used when blending two colours is required.

The list of methods built-in into AGG should include the regular 
Porter-Duff rules as well as those proposed for the SVG 1.2 standard 
(which are modeled after the respective options in Adobe products).

The complete list of blending modes provided by the library should thus 
include over, in, out, atop, xor and general arithmetic to cover all the 
Porter-Duff rules, plus multiply, screen, darken and lighten as in 
feBlend, and finally overlay, soft light, hard light, color dodge,
color burn, difference and exclusion as in PDF 1.4 as suggested for SVG 
1.2.

Personally, I would like to extend the list more, for example I would like 
to be able to change hue, light etc separately without affecting other 
components. For example, I would like to be able to change a region of the 
image into greyscale. However, such great extensibility does require 
either a functor or a template parameter argument. The latter may be faster,
but given the very large number of possible blending modes for example a 
graphics scripting environment may have to support, the functor approach 
might be more space conserving. For speed, perhaps trivial copy and the 
default blending mode (over?) should be specialized though. Depends on AGG 
internals, which I'm still not too aware of.

In summary, AGG should not decide what blending mode to use, but take it 
as a parameter. Depending on the interface one may have to provide a 
default though. In that case the 'over' Porter-Duff rule might be the best one.

--> Mika.Heiskanen_at_[hidden]
    Finnish Meteorological Institute