[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