From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David.Kastrup@t-online.de (David Kastrup) Newsgroups: gmane.emacs.devel Subject: Re: PNG pictures have gamma correction twice applied Date: Tue, 3 Dec 2002 16:21:04 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: <200212031521.gB3FL4OS004357@localhost.localdomain> References: <200211061556.gA6FuCU6005082@localhost.localdomain> <200211301336.gAUDaEU9005748@localhost.localdomain> NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1038941908 7856 80.91.224.249 (3 Dec 2002 18:58:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 3 Dec 2002 18:58:28 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18JIEo-0001z6-00 for ; Tue, 03 Dec 2002 19:57:42 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18JIOQ-0004xw-00 for ; Tue, 03 Dec 2002 20:07:39 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18JIEC-0004o5-00; Tue, 03 Dec 2002 13:57:04 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18JIE7-0004nH-00 for emacs-devel@gnu.org; Tue, 03 Dec 2002 13:56:59 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18JIE5-0004jO-00 for emacs-devel@gnu.org; Tue, 03 Dec 2002 13:56:58 -0500 Original-Received: from mailout11.sul.t-online.com ([194.25.134.85]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18JIE3-0004fh-00; Tue, 03 Dec 2002 13:56:55 -0500 Original-Received: from fwd06.sul.t-online.de by mailout11.sul.t-online.com with smtp id 18JErX-0003Td-05; Tue, 03 Dec 2002 16:21:27 +0100 Original-Received: from localhost.localdomain (520018396234-0001@[217.80.157.168]) by fwd06.sul.t-online.com with esmtp id 18JErD-1YXXZAC; Tue, 3 Dec 2002 16:21:07 +0100 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id gB3FL5te004361; Tue, 3 Dec 2002 16:21:06 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id gB3FL4OS004357; Tue, 3 Dec 2002 16:21:04 +0100 Original-To: rms@gnu.org X-Sender: 520018396234-0001@t-dialin.net Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9841 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9841 Richard Stallman 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