[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Devel] Freetype2 & gamma correction
From: |
Matthijs Melchior |
Subject: |
[Devel] Freetype2 & gamma correction |
Date: |
Fri, 28 Mar 2003 23:49:14 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030319 Debian/1.3-3 |
Freetype2 & gamma correction
Where I am coming from
----------------------
My Linux machine runs Debian/unstable and with the installation
of Gnome 2.2 and Mozilla 1.3, the use of freetype anti-aliassed
fonts was increased considerably. Despite all the positive noise
I saw, I did not like the way the text looked, it was rather
uneven... Soo.., I have investigated this problem and found the
reason for this effect. I like to have correct colors on my
screen and to get the best results I have X running with
-gamma 2.2 [Looking at the anti-aliased fonts with gamma = 1
gives very good results indeed! (for text, colors are too dark)]
Going back to running X with -gamma 1 is not an option! So, I
want to modify freetype to do better anti-aliassing for gamma
settings other than 1.
Where I want to go
------------------
The ideal situation would be that freetype automatically ajusts
to the gamma setting of the output device it is using. But,
realistically, I think that is asking too much.
A situation we can arrive at is one where a user can set the
gamma correction for the current output device. Flexibility,
like the X11 “xgamma” command, is too much because I do not
expect to be able to regenerate all characters on screen and in
off screen caches... So, the management interface must clearly
imply that the setting is only valid for glyphs generated after
setting the freetype gamma correction.
How to get there
----------------
So, I have been looking at the freetype code, found the
ftgrays.c file and, lo and behold, it was already implemented
as an experimental feature and disabled!
The disabled code contains a 2 segment aproximation to
gamma = 2.4, and indeed, enabling that gives better results.
In an attempt to improve on this, I have coded a 6 segment
aproximation and even built a python program to generate a
correct gamma table.
This last activity gave me the idea for the gamma solution I
will now propose.
Put the gamma table in a separate shared object file.
This makes it easy to change the table on a per process basis,
and the default can just be the simplest table with gamma = 1.
The table does not have to be generated each time and is sure to
to have the same lifetime as the characters generated using it
(modulo screen shots, and font servers, off course).
I have expanded my python program somewhat, and now it generates
a full C module that can be compiled into a fully functional .so
library.
However, I have not been able to integrate this into the
freetype2 build mechanism...
I would like for someone to help me with this.
And there are more things to be discussed.....
- is this portable enough.
- how about programs to be linked statically.
- can we require Python and a C compiler on the end user's system
just to change the freetype gamma value to be correct for the
display.
If you want to look at the differences, please have a look at
the screen shots from “ftview -r100 12 times.ttf” with gamma = 1
and gamma = 2.2 that are available at
http://www.xs4all.nl/~mmelchio/ftgamma
Please give me your opinion.
--
Regards,
---------------------------------------------------------------- -o)
Matthijs Melchior Maarssen /\\
address@hidden Netherlands _\_v
---------------------------------------------------------------- ----