[cairo] Mac Tiger Core Image

Bill Spitzak spitzak at d2.com
Thu Mar 10 21:05:12 PST 2005



Nathan Hurst wrote:
> On Thu, 10 Mar 2005 mental at rydia.net wrote:
> 
>> Quoting mental at rydia.net:
>>
>>>  2. dilate all shapes slightly before rendering so they overlap
>>> sufficiently to eliminate fringing [ this is the approach taken
>>> by the AntiGrain Geometry library ]
>>
>>
>> Speaking of which, it turns out the AntiGrain folks have a page with
>> sample images that illustrate the problem I'm talking about "in the
>> wild":
> 
> 
> This is due to computing the colours in the wrong space AFAICT.  I don't 
> think you get these if you live in sRGB or CIE.  Even getting the gamma 
> right probably solves 90% of this.  With hardware support changing 
> colour spaces becomes quite cheap (you do the colour space transform 
> using the stuff used for procedural textures, who's name escapes me).

No, this is not a colorspace issue.

Say the pixel is covered 50% by the first shape colored A, and 50% by 
the second colored B, and the original color is C.

The end result should be (A+B)/2.

But after drawing the first shape it will be (A+C)/2. There is not 
enough information to recover A so it is impossible to get a final 
result that has A but not C.

In fact in Cairo and probably every other graphics program the end 
result is going to be (A+B+2C)/4.

This does require turning off antialiasing of the edge pixels of the two 
polygons. In that case the result of the first shape is either A or C. 
If it is A then the second shape won't hit it and the result is still A, 
if it is C the other shape will hit it and it is B. Thus the final 
result is then either A or B. This is still not correct, but better than 
being able to see C through a supposedly opaque surface.



More information about the cairo mailing list