Pixman Projects

[Simon Thum]

Soeren Sandmann wrote:
> Simon Thum <simon.thum at gmx.de> 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).