Since I now believe that gamma correction is important for
good appearing aa-text, I spent some time thinking about how
it (and to some extent, color management in general) should
work in RENDER.
Regards,
Owen
The really simple model is:
- All pictures contain sRGB information
- Compositing can be done either with or without gamma
correction as a binary switch.
The really "complete" model (scary word) is:
- All pictures have an associated color profile that determines
how the RGB data maps onto a calibrated color space.
- A compositing operation has an associated color profile for the
compositing operation.
- Compositing is done as: convert colors to the compositing
profile, composite with Porter-Duff arithmetic. convert
back.
- Conversion could, if necessary, be modified by a ICC-style
rendering intent. (But gamut compression isn't generally
a big factor between different screen displays.)
I think there is a natural subset of the complete model that
gives us the simple model without much extra overhead, but
allows expansions in the future.
- We leave "color profiles" unspecified; they could be
ICC profiles, XDCCC properties, or even simply single
gamma values.
We identify "color profiles" with XID's and provide
three standard values:
sRGB - sRGB
sRGBLinear - sRGB primaries, intensity linear
deviceRGB - Determined from the drawable of the Picture --
For windows, an approximation to the color
space of the the device that allows efficient
conversion to and from sRGB [*]. For
pixmaps, sRGB.
For now, we don't provide any facilities for creating
color profiles, or even for copying the color profile
associated with a particular drawable.
We also strongly encourage poeple to set things up
so that deviceRGB == sRGB. (What's the gamma of
XFree86 on OS/X?)
A color profile is attached to each device, defaulting
to deviceRGB.
- Every picture also has an "OperationColorProfile"
that determines the intermediate color space. This defaults
to sRGB.
[*] This would typically be a lookup tabled pe primary.
Earlier, Keith wrote:
> I think the concensus is that gamma correction would be useful, but there
> are several unanswered questions:
Here are my attempts to answer the questions.
> 1) Are there other modifications to the compositing computation that
would also be useful?
I don't think so. Yes, you could get more general - e.g.,
allow different forward and reverse transformations for
the destination drawable. But I don't see it as useful.
> 2) Where are the intensity<->value conversions stored?
I think this is answered by my proposal above; if in
a complex way.
> 3) What precision is required in this computation?
At least 12 bits are required to do "linear sRGB" <=> SRGB
conversion reasonably. Perhaps going up to 16 bits makes
sense for a round number; this would also give us headroom
for 10-bit images. But this inflates the size of the
lookup tables a lot.
> 4) How does this relate to XDCCC?
Doesn't really. A server would presumably use the same
information to set the XDCCC properties and to device
deviceRGB.
My questions:
- What's the performance impact? I think defaulting
to sRGB for the intermediate space (no gamma correction)
is necessary because gamma corrected isn't going to be
hardware accelerated in most cases and isn't that
amenable to software acceleration such as via MMX.
- How does it correlate to hardware? The new Matrox
card apparently does gamma-corrected alpha compositing
for text in hardware.
- What to do about premultiplied alpha? It makes the
computations much more expensive, especially when
you have destination alpha.
It's possible that working in 16/16/16/16 linear
sRGB might actually be easier for heavy compositing
into destination alpha in some apps.
- How easy is it to implement? It should be pretty
trivial to stick into the fallback operations, but
it makes figuring out what operations need to be
special-cased and optimized even more of
a needle-in-the-haystack affair than currently.
- What does it mean for DirectColor visuals? I guess
deviceRGB could be interpreted relative to the
colormap for the drawable, not just the visual
but it sounds complicated.
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
