Road map for remaining pixman refactoring

[Soeren Sandmann]

Simon Thum <simon.thum at gmx.de> writes:

> For the more artistic cases directed at perceptual qualities (like
> some gradients, but not the WM shadow gradient!), luma modulation is
> of course desirable. But there are better tools for this purpose, like
> the L*a*b* space. So why go to such great lengths with luma mod?

Compositing in sRGB is hardly going to great lengths. All I'm saying
is that compositing in linear RGB it not always the right choice.

>  > On the other hand, when the alpha value comes from antialiased polygon
>  > rasterization, an intensity modulation is clearly desired.
>  >
>  > Ideally, images would have both a coverage and a translucency channel.
> I agree to your assertion buty not your conclusion.
> 
> AFAIK pixman does, by proxy, also inkscape's rendering. The svg spec
> 1.1 allows to specify in which space composition should happen; sRGB
> and linearRGB are amongst them.
> 
> http://www.w3.org/TR/2003/REC-SVG11-20030114/painting.html#ColorInterpolationProperty
> 
> So I'd say whether to use coverage or luma modulation is a property of
> the operation, not an additional channels' job.
>
> Down in pixman this simply means 'let the caller decide'. Some ops are
> done linear (the Xrender stuff), some are done gamma-encoded. Ideally
> with the default left to an environment variable to ease transition.
> 
> Does that make sense?

Consider what should happen if someone wants to composite a 50%
translucent white polygon on top of a black background. In render, you
do that by first generating a mask for the polygon, then doing

        (0x80808080) IN mask OVER (0xff000000)

The desired outcome here is correct antialiasing while producing a
triangle that is visually close to 50% gray. If you mark the source
and destination images as brightness and intensity respectively, you
can work out a formula that looks something like this:

    (m * s ** 2.2 + (1 - m) d ** 2.2) ** 1/2.2 + (1 - s_a * m) * d

With current pixman you get the right color, but wrong antialiasing -
if you treated alpha as coverage, you'd get the wrong color, but the
right default. I don't think this can be broken into a simple property
on the operation; you really need an indication what the alpha channel
actually means. I don't see how L*a*b bails you out either, because it
doesn't deal with translucency/coverage at all.


Soren