Keith Packard <[EMAIL PROTECTED]> writes:
> Around 23 o'clock on Jun 23, Owen Taylor wrote:
>
> > The really simple model is:
> >
> > - All pictures contain sRGB information
> > - Compositing can be done either with or without gamma
> > correction as a binary switch.
>
> I'd prefer an even simpler model which preserves as much color resolution
> as the target device can provide:
>
> - All pictures contain RGB information directly displayable on
> the device. Any color space conversion is done in the client.
Using the device's color space always certainly has the big
appeal in that it separates out gamma correction from the
more complex issues of gamut and what the primaries are.
I was uncertain about:
A) Whether it was reasonable to ask simple clients to do
conversion themself. (Presumably you'd need the toolkit
to do it.)
B) Whether it is reasonable to assume that all pictures
need the same color correction.
XDCCC allows a table per visual. Is this realistic?
DirectColor can probably be ignored. What about multiple
screens? I was under the vague impression that with
RENDER you could share picture between screens.
If the answer to either of those is false, you need to either:
1) Assume that all possible device color spaces are close
enough to each other (and presumably to sRGB) so it
doesn't matter. (My simple model.)
2) Allow for different lookup tables for different pictures.
(my proposal.)
> - Gamma correction comes from the XDCCC tables loaded in the server.
> The server may set default XDCCC tables from the DDC information,
> or a "gamma" value may be set in the server configuration. Yes,
> I know most monitor gamma values are garbage.
>
> - Gamma correction can be turned of in each destination picture; it's
> on by default.
Hmm, guess we need some benchmarking then to see what software
speeds are for gamma correction :-)
> > > 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.
>
> The question was intended to be broader than this; I'm interested to know
> what other useful extensions we might make to the P/D compositing algebra.
OK. Sticking gamma correction around the core operations seems
like a reasonably connected chunk of extensions. Anything
else was beyond the scope of what I was thinking about.
> > 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.
>
> The XDCCC tables provide linear interpolation to allow the lower end of
> the tables to be compressed. I'd much rather use 16 bits with linear
> interpolation than 12 bits without.
I got the impression that compression in the XDCCC tables was
to reduce storage for the properties, and that someone using
the tables would presumably do the interpolation once.
Do you think linear interpolation per pixel is really reasonable?
> > - 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.
>
> A related question is how current hardware exposes gamma corrected
> compositing; we need to make sure any model we expose can be met by that
> hardware so that gamma corrected compositing can be the default for most
> people.
Yes, this was one of my other questions.
> > 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.
>
> We don't have 64 bit pixels in the X server yet, and I also don't want to
> expose multiple colorspaces to applications.
Just trying to find some way to avoid having to continually
premultiply than de-premultiply again...
Regards,
Owen
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
