emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PNG pictures have gamma correction twice applied


From: David Kastrup
Subject: Re: PNG pictures have gamma correction twice applied
Date: 18 Nov 2002 12:31:01 +0100

"Stefan Monnier" <monnier+gnu/address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]