Re: PNG pictures have gamma correction twice applied

[David Kastrup]

Richard Stallman <address@hidden> writes:

>     It would appear that you have lost track of the discussion a bit.
> 
> This discussion is about the problem of double gamma correction that
> you reported.  By all means raise other issues if you wish, but they
> were not raised in a clear way before your latest message.
> 
>       The double gamma correction issue
>     is only a side aspect, "fixed" easily enough.
> 
> In that case, how about if we fix that now?  At least we will get
> correct display.  The other present problems seem (from all I can tell
> from your message) to cause only slowness.

With several orders of magnitude.  That is entirely unnecessary on
direct color displays.  On paletted displays, Emacs will cause color
hogging: it allocates colors and never frees any of them.

I am thinking about how to arrive at a usable solution.  Since Emacs
uses a toolbar by default, one can't really claim that image display
is a special case.

The standard manner in X to avoid color hogging is to allocate a
standard palette read-only that other applications would also be
using.  The color resolution of such a palette is coarse, so Stefan
objected that such a solution would, in contrast to the current
approach, not permit accurate representation of text colors.

One problem with the current approach is that there is no tracking
about what colors get used where: even if a color is no longer in use
on the display, its palette entry will remain permanently allocated.
While one could also imagine a mixed model, where a basic color set
was allocated in standard color maps, and text colors in addition
allocated color entries of their own, this would still imply that the
use of colors in on-screen objects should be tracked in order to be
able to free unused color slots again.  From what I have seen from the
current code base, I would consider this very hard to do.  For that
reason, it would have been my proposal to implement this using a fixed
colormap in general, also for text colors, with the resulting loss of
exact color representation on 8bit displays taken as a tribute to a
faster and more sane implementation in general.  The current
degenerate solution may be kept as a backup measure if not even a
standard palette is allocatable when Emacs gets started, but the
display will be pretty defective in colors in that case, anyway.

A further complication in the treatment of gamma correction is that
it is a frame-local variable.  This means that the same image may
need different Ximages to render on different frames, and that
changing the screen-gamma of a frame implies reevaluating all
objects' colors in the frame.  Probably a general redraw would be
appropriate in that case.  Color hashing and structures currently, as
far as I can make out, do not take into account that on different
frames the same text may have to render in different colors due to
gamma correction, but I have only glanced over this up to now.

In short, getting Emacs to handle colors in anything even approaching
sanity and consistence requires some work yet.

> 
>     That would be trivially solved by ripping out the gamma correction
>     the PNG library does.
> 
> We don't want to change the PNG library.  We want to use it
> unmodified.  Can you find a solution to this one problem
> that invoves changing Emacs and not the PNG library?

That's what I meant.  Emacs currently tells the PNG explicitly what
gamma factor it is assuming for its screen, and the PNGs get then
rendered for that gamma factor, which Emacs later corrects again.

Keeping the screen gamma secret from the PNG library will make only
Emacs do this correction.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum