From: David.Kastrup@t-online.de (David Kastrup)
Cc: emacs-devel@gnu.org
Subject: Re: PNG pictures have gamma correction twice applied
Date: Tue, 3 Dec 2002 16:21:04 +0100 [thread overview]
Message-ID: <200212031521.gB3FL4OS004357@localhost.localdomain> (raw)
In-Reply-To: E18JEVo-000649-00@fencepost.gnu.org
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
next prev parent reply other threads:[~2002-12-03 15:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200211061556.gA6FuCU6005082@localhost.localdomain>
2002-11-07 15:08 ` PNG pictures have gamma correction twice applied Richard Stallman
2002-11-09 22:40 ` David Kastrup
2002-11-11 10:20 ` Richard Stallman
2002-11-30 13:36 ` David Kastrup
2002-12-03 14:59 ` Richard Stallman
2002-12-03 15:21 ` David Kastrup [this message]
2002-12-05 15:08 ` Richard Stallman
2002-12-05 15:34 ` David Kastrup
2002-12-05 17:31 ` David Kastrup
2002-12-06 15:52 ` Richard Stallman
2002-12-06 16:01 ` David Kastrup
2002-11-11 16:58 ` Stefan Monnier
2002-11-11 17:30 ` David Kastrup
2002-11-11 17:43 ` Stefan Monnier
2002-11-18 11:31 ` David Kastrup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200212031521.gB3FL4OS004357@localhost.localdomain \
--to=david.kastrup@t-online.de \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).