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: Thu, 5 Dec 2002 16:34:31 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: <200212051534.gB5FYVip008794@localhost.localdomain> References: <200211061556.gA6FuCU6005082@localhost.localdomain> <200211301336.gAUDaEU9005748@localhost.localdomain> <200212031521.gB3FL4OS004357@localhost.localdomain> NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1039103225 21077 80.91.224.249 (5 Dec 2002 15:47:05 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 5 Dec 2002 15:47:05 +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 18JyDP-0005Tn-00 for ; Thu, 05 Dec 2002 16:47:03 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18JyLc-0003oO-00 for ; Thu, 05 Dec 2002 16:55:32 +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 18Jy2D-00060d-00; Thu, 05 Dec 2002 10:35:29 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18Jy1h-0005mW-00 for emacs-devel@gnu.org; Thu, 05 Dec 2002 10:34:57 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18Jy1e-0005kt-00 for emacs-devel@gnu.org; Thu, 05 Dec 2002 10:34:56 -0500 Original-Received: from mailout09.sul.t-online.com ([194.25.134.84]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18Jy1c-0005kF-00; Thu, 05 Dec 2002 10:34:52 -0500 Original-Received: from fwd09.sul.t-online.de by mailout09.sul.t-online.com with smtp id 18Jy1b-0006cM-08; Thu, 05 Dec 2002 16:34:51 +0100 Original-Received: from localhost.localdomain (520018396234-0001@[217.80.157.151]) by fwd09.sul.t-online.com with esmtp id 18Jy1K-10a05AC; Thu, 5 Dec 2002 16:34:34 +0100 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id gB5FYWTK008798; Thu, 5 Dec 2002 16:34:33 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id gB5FYVip008794; Thu, 5 Dec 2002 16:34:31 +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:9889 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9889 Richard Stallman 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