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: Mon, 11 Nov 2002 18:30:59 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: <200211111730.gABHUx7L010488@localhost.localdomain> References: <200211061556.gA6FuCU6005082@localhost.localdomain> <200211111658.gABGwDC16585@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1037201552 23762 80.91.224.249 (13 Nov 2002 15:32:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 13 Nov 2002 15:32:32 +0000 (UTC) Cc: rms@gnu.org, 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 18BzCg-00048A-00 for ; Wed, 13 Nov 2002 16:13:18 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18BzOc-00066k-01 for ; Wed, 13 Nov 2002 16:25: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) id 18BIh9-0003Ib-00; Mon, 11 Nov 2002 12:49:55 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18BIP1-0006US-00 for emacs-devel@gnu.org; Mon, 11 Nov 2002 12:31:11 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18BIOx-0006TZ-00 for emacs-devel@gnu.org; Mon, 11 Nov 2002 12:31:10 -0500 Original-Received: from mailout03.sul.t-online.com ([194.25.134.81]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18BIOw-0006TE-00; Mon, 11 Nov 2002 12:31:07 -0500 Original-Received: from fwd02.sul.t-online.de by mailout03.sul.t-online.com with smtp id 18BIOt-0005Ru-0A; Mon, 11 Nov 2002 18:31:03 +0100 Original-Received: from localhost.localdomain (520018396234-0001@[62.226.11.161]) by fwd02.sul.t-online.com with esmtp id 18BIOo-0gUba4C; Mon, 11 Nov 2002 18:30:58 +0100 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id gABHV24H010492; Mon, 11 Nov 2002 18:31:02 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id gABHUx7L010488; Mon, 11 Nov 2002 18:30:59 +0100 Original-To: "Stefan Monnier" 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:9378 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9378 "Stefan Monnier" 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