Re: PNG pictures have gamma correction twice applied

Re: PNG pictures have gamma correction twice applied

[Richard Stallman]

    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?

	     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
two hard questions are (1) where this code is and (2) whether the
change needs to be made for all image formats or just for PNG.

It sounds like you know the answer to (1).  Could you tell us?
Would someone like to investigate the answer to (2)?

Re: PNG pictures have gamma correction twice applied

[David Kastrup]

Richard Stallman <rms@gnu.org> 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

Re: PNG pictures have gamma correction twice applied

[Richard Stallman]

Would you like to rewrite the png code thoroughly?

      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:

If the lookup cannot be avoided completely, the caching may be worth
while as an optimization.  I am not saying that it is, since I have
not studied the code, just that this is something you should consider.

      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.

There needs to be a way to reallocate this hash table in case it gets
too full.

    It would appear to me that the pictures should be made to bypass this
    lookup mechanism entirely:

If that is possible, it would sure be better.

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

If only the png library does its own gamma correction, it would seem
Emacs should still do gamma correction for images itself.  But perhaps
it can do that in a more efficient way.

    nowadays), the whole pixel lookup and color allocation business is
    utterly unnecessary, anyway, since one can directly map requested
    color to available color

We could keep the ability to do the lookup but use it only on
devices where it is needed.

Anyway, please do clean up this mess.

Re: PNG pictures have gamma correction twice applied

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> Would you like to rewrite the png code thoroughly?

Unfortunately, it is not just the PNG code, it is the entire
color/image management that is involved here.

> If only the png library does its own gamma correction, it would seem
> Emacs should still do gamma correction for images itself.  But perhaps
> it can do that in a more efficient way.
> 
>     nowadays), the whole pixel lookup and color allocation business is
>     utterly unnecessary, anyway, since one can directly map requested
>     color to available color
> 
> We could keep the ability to do the lookup but use it only on
> devices where it is needed.
> 
> Anyway, please do clean up this mess.

It probably would not be the best idea to separate color handling of
text and images too much, or we will not be able to have images blend
seamlessly into the background of the buffer, the images being
rendered to a different palette part than the "exact match" colors.

Anyhow, the way I see it there is not much sense in reinventing the
wheel.  This sort of color management is rather tedious to do in X11,
and the work has been done already.  For example, the Gdk library
deals with all sorts of different color models, and there is even a
Windows port (avaunt!) available if I am not mistaken.

So it would make sense either to use Gdk where available, or probably
to borrow from its code base _if_ copyright issues would permit
that.

I don't know whether it would make sense to factor out the color
management into separate files, thus maybe better facilitating
exchanging one scheme for another.

Opinions?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: PNG pictures have gamma correction twice applied

[Richard Stallman]

    > Would you like to rewrite the png code thoroughly?

    Unfortunately, it is not just the PNG code, it is the entire
    color/image management that is involved here.

That is rather vague--could you be more concrete?  Are you saying that
Emacs does a spurious extra gamma correction for some of the other
image formats also?  If that is not what you mean then I have no idea
what the intended meaning is.

    It probably would not be the best idea to separate color handling of
    text and images too much,

Based on what you said before, we MUST separate them.
The PNG library does the gamma correction itself, whereas
for text Emacs has to do it.

It seems that there is only one correct thing to do, and that is make
Emacs *not* apply its own gamma correction to the images.  If that
means "separating" the color handling, then separate them we must.
What other alternative could there be?

			      or we will not be able to have images blend
    seamlessly into the background of the buffer, the images being
    rendered to a different palette part than the "exact match" colors.

I cannot follow the logic of the argument you are trying to make.  As
far as I can see, eliminating the spurious extra gamma correction
will make text and images MORE compatible, not less so.

    Anyhow, the way I see it there is not much sense in reinventing the
    wheel.  This sort of color management is rather tedious to do in X11,
    and the work has been done already.  For example, the Gdk library
    deals with all sorts of different color models, and there is even a
    Windows port (avaunt!) available if I am not mistaken.

I doubt it would work to make Emacs use GDK all the time, but if you
can adapt the color management code from GDK, maybe we could make
Emacs call a stripped-down version of it.

But I think this is all irrelevant.  We are talking about eliminating
a duplicate gamma correction step.  That is a very simple issue to
think about.  Bringing in lots of other things makes a simple issue
complex, and that is an impediment to solving it.

Would you like to get rid of the extra gamma correction?

Re: PNG pictures have gamma correction twice applied

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > Would you like to rewrite the png code thoroughly?
> 
>     Unfortunately, it is not just the PNG code, it is the entire
>     color/image management that is involved here.
> 
> That is rather vague--could you be more concrete?  Are you saying that
> Emacs does a spurious extra gamma correction for some of the other
> image formats also?  If that is not what you mean then I have no idea
> what the intended meaning is.

It would appear that you have lost track of the discussion a bit.  The
double gamma correction was just one of the problems with the current
code base.

Further problems included that the current code base became incredibly
inefficient where images got involved, because it used the code
intended for text pixel-by-pixel.  On direct color displays, the
involved hash stuff is completely unnecessary, and on paletted
displays, showing colored images results in self-defeating
color-hogging from Emacs (which would use up the palette on the first
part of an image, not having suitable colors left afterwards).  Since
those colors are only allocated, but never deallocated, this
color-hogging is completely irreversible within one Emacs session.

Emacs color-handling is broken as it is.  The discussion has moved on
to what one might do about this.  The double gamma correction issue
is only a side aspect, "fixed" easily enough.

> 			      or we will not be able to have images blend
>     seamlessly into the background of the buffer, the images being
>     rendered to a different palette part than the "exact match" colors.
> 
> I cannot follow the logic of the argument you are trying to make.  As
> far as I can see, eliminating the spurious extra gamma correction
> will make text and images MORE compatible, not less so.

Of course.  The current behavior is appallingly wrong.  I was
discussing with what should replace it.  What was suggested that for
paletted displays, a fixed palette for images could be allocated, but
the current behavior retained for texts.  I pointed out that this
would mean that images could not be created in order to exactly match
colors from the text display, such as the frame background.

>     Anyhow, the way I see it there is not much sense in reinventing
>     the wheel.  This sort of color management is rather tedious to
>     do in X11, and the work has been done already.  For example, the
>     Gdk library deals with all sorts of different color models, and
>     there is even a Windows port (avaunt!) available if I am not
>     mistaken.
> 
> I doubt it would work to make Emacs use GDK all the time, but if you
> can adapt the color management code from GDK, maybe we could make
> Emacs call a stripped-down version of it.

Yes, that was about the idea.

> But I think this is all irrelevant.  We are talking about
> eliminating a duplicate gamma correction step.  That is a very
> simple issue to think about.  Bringing in lots of other things makes
> a simple issue complex, and that is an impediment to solving it.
> 
> Would you like to get rid of the extra gamma correction?

That would be trivially solved by ripping out the gamma correction
the PNG library does.  Then PNG would "just" behave like the other
image formats and the text.

I am just saying that this is not going to make Emacs color/image
handling near to sane.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: PNG pictures have gamma correction twice applied

[Richard Stallman]

    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.

    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?

Re: PNG pictures have gamma correction twice applied

[David Kastrup]

Richard Stallman <rms@gnu.org> 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

Re: PNG pictures have gamma correction twice applied

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

Richard Stallman <rms@gnu.org> writes:

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

I have verified that the following patch will stop the double gamma
correction particular to PNG images.  I _strongly_ stress that this
is _not_ the proper way to fix Emacs' lack of proper color handling
here and elsewhere.

For that reason, I will not apply this patch myself.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Don't tell PNG library about gamma which we do ourselves --]
[-- Type: text/x-patch, Size: 1526 bytes --]

*** xfns.c.~1.565.~	2002-11-14 17:21:29.000000000 +0100
--- xfns.c	2002-12-05 17:35:07.000000000 +0100
***************
*** 9004,9010 ****
    screen_gamma = (f->gamma ? 1 / f->gamma / 0.45455 : 2.2);
  
    /* Tell the PNG lib to handle gamma correction for us.  */
! 
  #if defined(PNG_READ_sRGB_SUPPORTED) || defined(PNG_WRITE_sRGB_SUPPORTED)
    if (png_get_sRGB (png_ptr, info_ptr, &intent))
      /* The libpng documentation says this is right in this case.  */
--- 9004,9010 ----
    screen_gamma = (f->gamma ? 1 / f->gamma / 0.45455 : 2.2);
  
    /* Tell the PNG lib to handle gamma correction for us.  */
! #if 0
  #if defined(PNG_READ_sRGB_SUPPORTED) || defined(PNG_WRITE_sRGB_SUPPORTED)
    if (png_get_sRGB (png_ptr, info_ptr, &intent))
      /* The libpng documentation says this is right in this case.  */
***************
*** 9017,9023 ****
    else
      /* Use the standard default for the image gamma.  */
      png_set_gamma (png_ptr, screen_gamma, 0.45455);
! 
    /* Handle alpha channel by combining the image with a background
       color.  Do this only if a real alpha channel is supplied.  For
       simple transparency, we prefer a clipping mask.  */
--- 9017,9023 ----
    else
      /* Use the standard default for the image gamma.  */
      png_set_gamma (png_ptr, screen_gamma, 0.45455);
! #endif
    /* Handle alpha channel by combining the image with a background
       color.  Do this only if a real alpha channel is supplied.  For
       simple transparency, we prefer a clipping mask.  */

[-- Attachment #3: Type: text/plain, Size: 52 bytes --]



-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: PNG pictures have gamma correction twice applied

[Richard Stallman]

      I _strongly_ stress that this
    is _not_ the proper way to fix Emacs' lack of proper color handling
    here and elsewhere.

If someone wants to implement the proper way, that would be good--but
since it is a big job, we cannot take for granted that someone will do
it in the near future.  So it is better if we install this patch.

Thanks for writing it.

Re: PNG pictures have gamma correction twice applied

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>       I _strongly_ stress that this
>     is _not_ the proper way to fix Emacs' lack of proper color handling
>     here and elsewhere.
> 
> If someone wants to implement the proper way, that would be good--but
> since it is a big job, we cannot take for granted that someone will do
> it in the near future.  So it is better if we install this patch.
> 
> Thanks for writing it.

Well, commenting out 4 lines of code is not that impressive a task...

By the way, it should be quite safe to install this in the 21.3
release branch (which will certainly not see a complete color
overhaul).  If you take a look at the screen shots at
<URL:http://preview-latex.sf.net>, you will notice the disconcerting
off-color effects that the unpatched Emacs produces (the linguist
screen shots) when not working with fully saturated colors.

If Emacs is devastatingly slow on images and gets terminal palette
starvation in no time at all on paletted display, at least the static
views of non-paletted displays will look nice in screen shots.

People will be glad about the improvement they get, not knowing what
they should rather be getting...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: PNG pictures have gamma correction twice applied

[Stefan Monnier]

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

Have you checked whether this "costly operation" is actually done
in your case ?  It should only happen if the XAllocColor fails, which
should never be the case in a 16bpp (or more) display.

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

The reason for the "closest color" code is to deal with the situation
where the aren't enough color slots available.  There might very well
not be 64 slots available.
I think this part of the code is OK, especially since I believe it is only
triggered in the very rare cases where it is needed.

But I agree that the lookup&gamma&caching is a bit strangely done and
is probably not ideal for displays with more than 256 colors.  I believe
the code for lookup has a comment that says essentially the same thing.

But I also remember that some of that code was done to try and reduce the
amount of X traffic (there were many calls to XAllocColor or XLookupColor
or something like that).
I think the caching could be improved (to reduce X traffic), tho.
And bypassing this code for PNG would be a good idea since libpng should
do a good enough (better) job already.


	Stefan

Re: PNG pictures have gamma correction twice applied

[David Kastrup]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > 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.
> 
> Have you checked whether this "costly operation" is actually done
> in your case ?  It should only happen if the XAllocColor fails, which
> should never be the case in a 16bpp (or more) display.

Correction: which should not be the case when there is no palette
involved of any kind.  If there is, XAllocColor will allocate the
next free color slot.  Since the Emacs display code never deallocates
a color again, the color palette will run out of colors eventually.
Whatever colors happen to be in the palette at that time, get used
for the "closest" color.  If you have, for example, a color diagram
as an image, the red top will allocate all the colors away, and blue,
green and white will be all represented by shades of red.

For that reason it would be more prudent to allocate a fixed palette,
even if it has just 4x4x4 colors, and use that.  Just making use of
whatever happens to be present in the current palette is an emergency
measure.  And asking for the current palette again for every new
pixel is not going to be reducing the X traffic...

> The reason for the "closest color" code is to deal with the situation
> where the aren't enough color slots available.  There might very well
> not be 64 slots available.
> I think this part of the code is OK, especially since I believe it is only
> triggered in the very rare cases where it is needed.

Always when you are having a palette and using images with a large
number of colors, since Emacs does never free colors it allocates.

> But I also remember that some of that code was done to try and reduce the
> amount of X traffic (there were many calls to XAllocColor or XLookupColor
> or something like that).

Well, since the X server gets asked for the entire palette every time
a pixel color is not found in the hash, when you are having images
with just few different colors, it will significantly reduce the
traffic.  And the hash probably is not amiss where _text_ colors are
concerned, since those happen to be few, usually (even though never
freeing color slots can lead to problems there, too).  But for
_images_ it does not make sense to treat every pixel as a new
surprise, and do all the lookup including fetching the current color
palette new for every pixel.

> I think the caching could be improved (to reduce X traffic), tho.

I think that for most purposes one should rather aim to obliterate
rather than improve it.  The closest match stuff should really be
only used when Emacs does not get a chance to allocate the standard
4x4x4 palette which should only be the case when some other color
hogger on an 8bit system is actively interfering.

> And bypassing this code for PNG would be a good idea since libpng
> should do a good enough (better) job already.

libpng has nothing to do with the actual color management.  It can
cater for the gamma correction, true, but that is the smallest
problem of the current code base.

Gamma correction should probably done by table lookup, anyway, when
libpng does not already cater for it.

And the image format conversions should be done by batching them,
instead of working on every single pixel.

If the Emacs code base can't with a good conscience make use of
toolkit parts with color management (such as gdk), one might cobble
some code together from such sources in order to manage this sort of
thing more amicably.  It really sounds quite like reinvention of the
wheel.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: PNG pictures have gamma correction twice applied

[Stefan Monnier]

> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> 
> > > 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.
> > 
> > Have you checked whether this "costly operation" is actually done
> > in your case ?  It should only happen if the XAllocColor fails, which
> > should never be the case in a 16bpp (or more) display.
> 
> Correction: which should not be the case when there is no palette
> involved of any kind.  If there is, XAllocColor will allocate the
> next free color slot.  Since the Emacs display code never deallocates
> a color again, the color palette will run out of colors eventually.
> Whatever colors happen to be in the palette at that time, get used
> for the "closest" color.  If you have, for example, a color diagram
> as an image, the red top will allocate all the colors away, and blue,
> green and white will be all represented by shades of red.

IIUC, the problem is not with the closest-match thing per se, but with
the fact that Emacs doesn't deallocate colors.  And that for images,
it's probably better to pre-allocate a set of colors and stick
to them, since most images will otherwise overflow the 256-color palette.
Agreed.  The code you're looking at was really meant for text originally.

> For that reason it would be more prudent to allocate a fixed palette,
> even if it has just 4x4x4 colors, and use that.

For images, yes.  For text, I don't see the need: I hate it when an
application allocates 64colors of my small colormap only to use 10 of them;
and doesn't even get them right because it approximates
within the 64 it pre-defined rather than using the exact color.

> Just making use of whatever happens to be present in the current palette
> is an emergency measure.

For some users, it's the "normal case" (many apps gobble up most/all the
colormap).

> And asking for the current palette again for every new
> pixel is not going to be reducing the X traffic...

That's the part of the caching which could be improved.


	Stefan "who cares about 256-color displays and Emacs displaying text
		much more than about Emacs displaying images"

Re: PNG pictures have gamma correction twice applied

[David Kastrup]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> IIUC, the problem is not with the closest-match thing per se, but
> with the fact that Emacs doesn't deallocate colors.

Not only that.  We are not talking about the situation where an Emacs
uses just foreground color, background color, perhaps mouse highlight
color and nothing else.  People turn on things like font-lock, and
then we quite soon have a few dozen colors active.  Then we have a
toolbar enabled _by default_ where the colored icons will again grab
a sizable portion of colors.  It does not make much sense to draw all
of these colors from different supplies, in particular, since the
overall number of them will be limited and you won't be able to
distinguish that many text colors, anyway, as to warrant getting
exact representations for them.

> And that for images, it's probably better to pre-allocate a set of
> colors and stick to them, since most images will otherwise overflow
> the 256-color palette.  Agreed.

Please note that Emacs' default configuration already contains images
on-screen, so we'll always get a pre-allocated set.  Not such a good
idea to be allocating additional colors for the text, in particular
when there is no sane deallocation policy in sight.

> The code you're looking at was really meant for text originally.
> 
> > For that reason it would be more prudent to allocate a fixed palette,
> > even if it has just 4x4x4 colors, and use that.
> 
> For images, yes.  For text, I don't see the need: I hate it when an
> application allocates 64colors of my small colormap only to use 10
> of them; and doesn't even get them right because it approximates
> within the 64 it pre-defined rather than using the exact color.

That's the wrong view: every well-behaved application that allocates
64 colors does this using XAllocStandardColormap, and thus shares
those 64 colors (or 128 colors if you allocate a 2x3x2 cube) with any
other well-behaved application.  And even if a non-well-behaved
application gets started afterwards and hogs the palette until it is
full, it will have a reasonable set of colors to approximate to.

And if you are bothered about non-exact colors that much, using an
8bit visual in the first place is not the best idea.

> 	Stefan "who cares about 256-color displays and Emacs displaying text
> 		much more than about Emacs displaying images"

Emacs displays a toolbar right out of the box.  If you make it working
badly (color hogging in addition to a standard color map) for the
default configuration because your personal configuration will not be
hit by it, that is not being nice.  And I seriously doubt that the
slightly different shade of a text color will matter at all to you.
The only color where slight differences in color shade might be
relevant (as large areas get exposed to you in it) is the frame
background color, and one could make special allowance for that:
deallocating that color when the frame gets deleted is not much of a
bookkeeping chore.

For images, pretty much all external formats do not offer more than
8bit of color depth.  One can work this with a lookup table in the
following manner:
outcolor = offset+((gamma[r]&redmask)>>redshift) +
 ((gamma[g]&greenmask)>>greenshift) +
 ((gamma[b]&bluemask)>>blueshift);

offset, masks and shift depend on the color model and visuals.
outcolor will be stored into an 8, 16 or 32bit word, also depending
on the visual (the switch for that would probably be done outside of
the loop creating the XImage).

In case we have to deal with converting 16bit gamma values (as for
text colors), we can do this with

outcolor = offset+
  (((gammabase[r>>LINBITS]+gammamult[r>>LINBITS]*r)&redmask)>>redshift)
  ...

LINBITS is the number of lower order bits where just a linear
interpolation is done, as one would not want to build lookup tables
for the entire 16bits (which would take 128kByte for each frame).  At
least that's what I would guess: but with current memory footprints,
people might disagree with me here.

But I would guess that 8 bits of nonlinearity are quite sufficient
for even the most queasy text color proponents.  I really doubt that
many people would notice even of one first reduced the color to 8bit
and then did gamma correction (which might leave some color slots in
the screen palette unused).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum