Soeren Sandmann wrote: > Simon Thum <[email protected]> writes: >> However, when you implement super sampling with respect to gamma, the >> quality loss drops to nearly zero. I'd say typically you need no more >> strange "higher quality" filters when that's done. > > Even a simple non-gamma-correct supersampling filter would be good > enough for many purposes. As I recall, GdkPixbuf, which has provided > acceptable quality in GNOME for many years, does essentially this. Well, AFAICT the other OS - 12 Years after its vendor crafted sRGB - starts getting things right. IMO time to do so too.
> I agree that gamma correct filtering would look even better, but > whether that's interesting on its own instead of as a side effect of a > general SRGB surface, I don't know. It seems a little iffy to me to > have a PIXMAN_BOX_FILTER_GAMMA_CORRECT, instead of a general SRGB > surface that could be filtered with a normal PIXMAN_FILTER_BOX. AIUI, pixman is widening to 16bit anyway. So I think a LUT-based approach to widening wouldn't hurt much but provide what you suggest. > I don't intend it as anything other than a demonstration, since gamma > correction should probably be considered along with color management > in general. And I did it in the dumbest way possible, so it's way too > slow to be practical. If you don't intend on raising all surfaces along the pipe to 16 bit per component, gamma will stay a compositing issue anyway. Though it would be nice to get the corresponding gamma (xdccc did something sufficient for this purpose) from a X CMS, it would be impractical to know in all circumstances what gamma to use. So you'll end up with some sensible gamma anyway. Bottom line: If LUT-based widening was efficient enough, why dump that implementation? sRGB, which you recently added, keeps the LUT small enough to fit in even modest caches (1024 entries * 16bit * 2 = 4k). _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
