Re: PNG pictures have gamma correction twice applied

[David Kastrup]

Richard Stallman <address@hidden> writes:

>     When a PNG image is displayed, first all the gamma correction factors
>     of the screen and image are taken into account, and the PNG library
>     is called with that information.  The resulting color triples are in
>     properly gamma-adjusted 24bit color space, ready for putting on the
>     screen.
> 
> Is the same thing true for other image formats, or only for PNG?

As far as I have checked, this double correction occurs just with PNG
since it is apparently just the PNG library that offers gamma
correction straight from inside the library.

> 
>            Then Emacs looks up every pixel in a lookup table, and if it
>     does not find it there, it again does gamma correction and other
>     stuff.
> 
> The fix would seem to be to delete the second gamma correction.

The whole lookup business is a major performance hog.  Every single
pixel is searched for in that color table.  This table is used as
some sort of a cache, in addition, and this cache is apparently not
cleared or reused consistently when the gamma correction factor of
the frame (gamma correction is a frame-local property) changes:
changing the gamma factor leads to some colors being corrected
according to the new factor, and some remain at the old factor.  In
particular, the frame background color and the default face
background color tend to diverge afterwards (areas with no letters on
them get a different background color than areas with letters).

In short: it appears to be a bit of a mess.

> The two hard questions are (1) where this code is

src/xfns.c: png_load this one loads the files in (with gamma
correction applied).  After they have been read in with
png_read_image, the image is copied pixel per pixel (with XPutPixel)
to an X Pixmap.  That is a bad idea.  One should rather declare an
XImage with the layout/color arrangement of the read data and let the
X library convert this XImage with a single call into an XImage in
server data layout.  Every pixel's color is looked up separately with
lookup_rgb_color here.

Now lookup_rgb_color is defined in src/xfns.c also.  It generates a
hash value from the color with the help of the hash function
CT_HASH_RGB and does a linear search through the linear list
associated with the slot of ct_table.  This hash table appears to be
global (even though Emacs might have frames open on several
displays).  If the color is not found in the hash, it is allocated
with x_alloc_nearest_color.  The size of the hash table is 101
entries, so if things like JPEG images are displayed, easily 100000
different colors can be achieved, and thus a single hash bucket might
contain thousands of pixels.

It would appear to me that the pictures should be made to bypass this
lookup mechanism entirely: when just colored text is concerned, this
hashing scheme will prove sufficient, but coloring entire images will
put a disastrous load on this scheme.

Now x_alloc_nearest_color is defined in src/xterm.c.  It first calls
gamma_correct on the function in question (which does the gamma
correction with a very expensive floating point operation), then
calls x_alloc_nearest_color_1, which does a costly operation of
figuring out a closest color.

All this is very much over the top where images are concerned: an
operation far too costly to do for every pixel anew.

> and (2) whether the change needs to be made for all image formats or
> just for PNG.

The double gamma correction problem is just that of PNG, but the
appallingly inefficient execution path for every pixel is the same for
other images as well.

This is not mere academic: scrolling through a buffer littered with
images (such as the WYSIWYG editing environment preview-latex
provides) is quite sluggish under Emacs, particular in comparison to
the behavior under XEmacs.

With hicolor and truecolor devices (which are most prevalent
nowadays), the whole pixel lookup and color allocation business is
utterly unnecessary, anyway, since one can directly map requested
color to available color (and the X library is capable of doing that
mapping on its own for the entire Ximage at once).  Even if one were
to keep the overhead where X displays with writable 8bit palettes were
concerned, 90% of the users would benefit if the mass of pictures
entirely bypassed the whole folderol, and I would guess that for the
rest 10% of users with 8bit per pixel devices, some low quality
fallback (such as getting 64 fixed colors for 8bit display devices)
would still be appreciated more than the current slow behavior of
images.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum