Pixman Projects

[Carsten Haitzler (The Rasterman)]

On 07 Feb 2009 03:12:23 +0100 Soeren Sandmann <sandmann at daimi.au.dk> said:

> Simon Thum <simon.thum at gmx.de> writes:
> 
> > The issues I mean are:
> > > Higher Quality Image Filtering
> > > Add better filtering, especially for downscaling transformations.
> > 
> > > Color Management/Gamma Correction
> > > Find out what color management support is needed in cairo, XRender, and
> > > pixman. 
> > 
> > I'd just like t point out there is a close relation often overlooked.
> > 
> > Basically, if you scale down using 'super sampling' (I didn't find it in
> > pixman, but it's a likely choice. Also called a box filter.) quality
> > suffers more the more you scale down.
> 
> Super sampling would be a likely choice, yes, but sadly pixman doesn't
> even do that. The best thing it has to offer is a bilinear filter. For
> downscaling with a scale factor larger than 2, that is so ugly that
> it's not even funny. [1]
> 
> > 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.
> 
> I do think a high-quality filter such as Lanczos would be a useful
> thing to have, but getting to even passable quality is more important.
> 
> > I extensively researched that during my diploma, and if you can point me
> > to the right spots in pixman, I may be able to draw up a patch.
> 
> The right spot in pixman is in ACCESS(fbFetchTransformed)() in
> pixman-transformed.c, where a new supersampling fetcher would be put
> in.

the only problem here is the fact that it's prohibitively slow doing it this
way. it's nice in all the theoretical code design etc. ways... but performance
is totally unacceptable. any kind of filtered downscaling beyond nearest or
bilinear is absolutely needed. no need to go silly with gamma-correct filtering
and a bunch of theoretical goop that will in the end just make it even slower
than it already is. just something that looks decent when downscaling... and
runs fast enough to not warrant saying "screw it" and bypassing xrender
entirely by doing your own software.

> 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.

agreed. do a normal box filter first and make it fast.. before worrying about
other esoteric modes. (hell i'd go for a limited N-tap filter before worrying
about gamma correction just to keep speed up).

> > As for gamma correction in general, It's an extensive work and change.
> > Basically, you need to check every single pixel-level computation
> > whether it is gamma-invariant, if not, make it so. I devised a small
> > calculus allowing to judge that matter. Maybe I can find it again, if
> > there's interest.
> > 
> > That said, it would certainly be worth to do it. However I'm far from
> > having the time to do so.
> 
> I did an experiment a while back - the result is in the gamma branch of
>         
>         git://freedesktop.org/~sandmann/pixman/
> 
> If you install it, all cairo rendering, including filtering, will be
> gamma correct, and if you run a Render based compositing manager, you
> will get gamma correct alpha blended windows.
> 
> 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.
> 
> 
> Thanks,
> Soren
> 
> 
> [1] This is not the fully story, because pixman and Render also allow
> general filter kernels to be uploaded. This is not exactly fast,
> though.

the eternal problem... quality AND speed. right now, pixman needs help in
getting at least 1 right... if not also improvements in the other. :)

i'm tossing up making a pixman engine for evas (bypassing xrender protocol),
but i definitely will need major speedups and quality improvements to make such
a thing ultimately worthwhile (as if all i do is make the engine - i am going
to just lose in both departments), so if i do - i'm going to have to show some
love to pixman.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com