From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 22 09:53:47 2024 Received: (at submit) by debbugs.gnu.org; 22 Nov 2024 14:53:47 +0000 Received: from localhost ([127.0.0.1]:53839 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tEV2Y-00066t-JQ for submit@debbugs.gnu.org; Fri, 22 Nov 2024 09:53:47 -0500 Received: from lists.gnu.org ([209.51.188.17]:36794) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tEV2W-00066i-Gz for submit@debbugs.gnu.org; Fri, 22 Nov 2024 09:53:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tEV2U-0002kO-22 for bug-gnu-emacs@gnu.org; Fri, 22 Nov 2024 09:53:42 -0500 Received: from ledu-giraud.fr ([51.159.28.247]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tEV2G-0002Nn-DI for bug-gnu-emacs@gnu.org; Fri, 22 Nov 2024 09:53:40 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=XqMqL2mo O/8FTZgnUNYN1ncTJ8E1Tf4PhQaJ9/trGJ0=; h=date:subject:to:from; d=ledu-giraud.fr; b=NS9zi/oZc4SVrzAFoYTtoLnp+qN7zlOiyuFQpTx6G8XFtK0LGF akyPWGUWsoaA+gqp0KRHLO//S7p56KtEeFAg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=XqMqL2moO/8FTZgn UNYN1ncTJ8E1Tf4PhQaJ9/trGJ0=; h=date:subject:to:from; d=ledu-giraud.fr; b=cS7RtNLw+7vrSKSz5CJAUoWCgdXyqVESDZd774pgSxgyEQGsSE lmk/EUxtv+WG7tM8xh3u+aEOIS41r9ijvCQp6D0AqOiK0nQZDV+9wpnSTO6poQ8rzj58xu rmeLzwwGD9yY2XRdI1A8L3Nw2WJBl6H5bI63Tu7ljmOezHetrlyoe+8x2UIOwxTZxTJtnr gKo+g9RTeZznszaCfbiPk6ZKabKImMYFKPVJ9jN0IIi5NDtI9jerVLIfRgiuHD0KEx7AjY rSD+ayaZ+7UjPzGPQBBuNQ5hcE2lwl1KarB6u/y/EsfICXpPoYPlxxbFXWk91+tyVUabq0 XV/xxbDoy+Tw== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id d820dd9f (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Fri, 22 Nov 2024 15:53:19 +0100 (CET) From: Manuel Giraud To: bug-gnu-emacs@gnu.org Subject: [PATCH] Explore JPEG loading without quantization X-Debbugs-Cc: Date: Fri, 22 Nov 2024 15:53:18 +0100 Message-ID: <871pz39v6p.fsf@ledu-giraud.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=51.159.28.247; envelope-from=manuel@ledu-giraud.fr; helo=ledu-giraud.fr X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) --=-=-= Content-Type: text/plain Tags: patch Hi, While trying to speed up "emacs as an image viewer", I found that emacs is using libjpeg with color quantization and it seems that removing this quantization could speed up JPEG loading a bit. My simple limited benchmark: - M-: (clear-image-cache) - Open an image in folder with some large enough pictures in it (4000x3000 here) - M-: (benchmark-run 10 (image-next-file 1)) Here are the results I get: without this path: (5.415405491 1 0.09232176400000025) with: (3.079911418 1 0.0751190459999993) I don't think that this patch could be applied as is (it is rather ugly). And I also think that I probably have missed some (many?) use case (where color quantization is mandatory). But I'm submitting this patch anyway as a conversation starter on the subject. Thanks, In GNU Emacs 31.0.50 (build 9, x86_64-unknown-openbsd7.6, X toolkit) of 2024-11-22 built on computer Repository revision: c66c0942ea9ac10e6d6324e472150de403a03b69 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101014 System Description: OpenBSD computer 7.6 GENERIC.MP#437 amd64 Configured using: 'configure CC=egcc CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib MAKEINFO=gmakeinfo --prefix=/home/manuel/emacs --bindir=/home/manuel/bin --with-x-toolkit=lucid --with-toolkit-scroll-bars=no --without-cairo --without-compress-install' --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0001-Explore-JPEG-loading-without-quantization.patch >From e360545b65427d6f0eec05cdeb26b8a05d8a0d61 Mon Sep 17 00:00:00 2001 From: Manuel Giraud Date: Thu, 21 Nov 2024 17:19:59 +0100 Subject: [PATCH] Explore JPEG loading without quantization --- src/image.c | 63 +++++++++++++---------------------------------------- 1 file changed, 15 insertions(+), 48 deletions(-) diff --git a/src/image.c b/src/image.c index db7f6acd171..374d2f9c454 100644 --- a/src/image.c +++ b/src/image.c @@ -8949,9 +8949,9 @@ jpeg_load_body (struct frame *f, struct image *img, FILE *fp = NULL; JSAMPARRAY buffer; int row_stride, x, y; - int width, height; - int i, ir, ig, ib; - unsigned long *colors; + int width, height, ncomp; + int i, off; + unsigned long color; Emacs_Pix_Container volatile ximg_volatile = NULL; /* Open the JPEG file. */ @@ -9049,12 +9049,11 @@ jpeg_load_body (struct frame *f, struct image *img, jpeg_read_header (&mgr->cinfo, 1); - /* Customize decompression so that color quantization will be used. - Start decompression. */ - mgr->cinfo.quantize_colors = 1; + /* Start decompression. */ jpeg_start_decompress (&mgr->cinfo); width = img->width = mgr->cinfo.output_width; height = img->height = mgr->cinfo.output_height; + ncomp = mgr->cinfo.output_components; if (!check_image_size (f, width, height)) { @@ -9073,53 +9072,22 @@ jpeg_load_body (struct frame *f, struct image *img, sys_longjmp (mgr->setjmp_buffer, 1); } - /* Allocate colors. When color quantization is used, - mgr->cinfo.actual_number_of_colors has been set with the number of - colors generated, and mgr->cinfo.colormap is a two-dimensional array - of color indices in the range 0..mgr->cinfo.actual_number_of_colors. - No more than 255 colors will be generated. */ - USE_SAFE_ALLOCA; - { - if (mgr->cinfo.out_color_components > 2) - ir = 0, ig = 1, ib = 2; - else if (mgr->cinfo.out_color_components > 1) - ir = 0, ig = 1, ib = 0; - else - ir = 0, ig = 0, ib = 0; - - /* Use the color table mechanism because it handles colors that - cannot be allocated nicely. Such colors will be replaced with - a default color, and we don't have to care about which colors - can be freed safely, and which can't. */ - init_color_table (); - SAFE_NALLOCA (colors, 1, mgr->cinfo.actual_number_of_colors); - - for (i = 0; i < mgr->cinfo.actual_number_of_colors; ++i) - { - /* Multiply RGB values with 255 because X expects RGB values - in the range 0..0xffff. */ - int r = mgr->cinfo.colormap[ir][i] << 8; - int g = mgr->cinfo.colormap[ig][i] << 8; - int b = mgr->cinfo.colormap[ib][i] << 8; - colors[i] = lookup_rgb_color (f, r, g, b); - } - -#ifdef COLOR_TABLE_SUPPORT - /* Remember those colors actually allocated. */ - img->colors = colors_in_color_table (&img->ncolors); - free_color_table (); -#endif /* COLOR_TABLE_SUPPORT */ - } - /* Read pixels. */ - row_stride = width * mgr->cinfo.output_components; + row_stride = width * ncomp; buffer = mgr->cinfo.mem->alloc_sarray ((j_common_ptr) &mgr->cinfo, JPOOL_IMAGE, row_stride, 1); for (y = 0; y < height; ++y) { jpeg_read_scanlines (&mgr->cinfo, buffer, 1); - for (x = 0; x < mgr->cinfo.output_width; ++x) - PUT_PIXEL (ximg, x, y, colors[buffer[0][x]]); + for (x = 0; x < width; ++x) + { + color = 0; + off = x * ncomp; + /* XXX I suck at bit twiddling. */ + for (i = 0; i < ncomp; ++i) + color += (buffer[0][off + i] << ((ncomp - 1 - i) * 8)); + PUT_PIXEL (ximg, x, y, color); + } } /* Clean up. */ @@ -9135,7 +9103,6 @@ jpeg_load_body (struct frame *f, struct image *img, /* Put ximg into the image. */ image_put_x_image (f, img, ximg, 0); - SAFE_FREE (); return 1; } -- 2.47.0 --=-=-= Content-Type: text/plain -- Manuel Giraud --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 05:19:35 2024 Received: (at 74476) by debbugs.gnu.org; 30 Nov 2024 10:19:35 +0000 Received: from localhost ([127.0.0.1]:45560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHKZb-000867-9E for submit@debbugs.gnu.org; Sat, 30 Nov 2024 05:19:35 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHKZZ-00085o-0t for 74476@debbugs.gnu.org; Sat, 30 Nov 2024 05:19:33 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tHKZP-00082L-Ax; Sat, 30 Nov 2024 05:19:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ETZRJId4bvobjjjMTQyc81/BGjnmiQuEJe2AkGRG944=; b=IE+gXd20cBPQ TkWXGMXFnGPtzxrtzgzFXfSTNa6D+1IV0XHia6rybQDr8daVto/75fzcYj/J4FkFYqjAF3mm1PHlD BH68SlMlKhws3bgloav5VranSGjBOQBjKlIr5906MP9atzVIJ7132xWd8w+hWOaX3Io4UJ9sJnYJ6 AJFkSuVqKCDIqrnXwx4ZbUj4u5OOIWXXGMI1tl6jNgsTe539CuBaSVRbewtP7M65xZthe16uSHTUl Lud2Y1G3N2Q4xJswJdTnFRUIadAEFi6qDgrHlbcAg40wcLhq3TIZlzrym+1W/C61FwCQw8+jhX2BK B87rdxzPNW8leYisVp9Ffg==; Date: Sat, 30 Nov 2024 12:19:16 +0200 Message-Id: <86iks581nf.fsf@gnu.org> From: Eli Zaretskii To: Manuel Giraud , Alan Third In-Reply-To: <871pz39v6p.fsf@ledu-giraud.fr> (bug-gnu-emacs@gnu.org) Subject: Re: bug#74476: [PATCH] Explore JPEG loading without quantization References: <871pz39v6p.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74476 Cc: 74476@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 22 Nov 2024 15:53:18 +0100 > From: Manuel Giraud via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > While trying to speed up "emacs as an image viewer", I found that emacs > is using libjpeg with color quantization and it seems that removing this > quantization could speed up JPEG loading a bit. > > My simple limited benchmark: > > - M-: (clear-image-cache) > - Open an image in folder with some large enough pictures in > it (4000x3000 here) > - M-: (benchmark-run 10 (image-next-file 1)) > > Here are the results I get: > > without this path: (5.415405491 1 0.09232176400000025) > with: (3.079911418 1 0.0751190459999993) > > I don't think that this patch could be applied as is (it is rather > ugly). And I also think that I probably have missed some (many?) use > case (where color quantization is mandatory). But I'm submitting this > patch anyway as a conversation starter on the subject. Alan, any comments? I know nothing about this "color quantization" aspect of JPEG images. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 06:44:40 2024 Received: (at 74476) by debbugs.gnu.org; 30 Nov 2024 11:44:40 +0000 Received: from localhost ([127.0.0.1]:45796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHLtw-0004Ao-3m for submit@debbugs.gnu.org; Sat, 30 Nov 2024 06:44:40 -0500 Received: from dane.soverin.net ([185.233.34.158]:54233) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHLtt-0004AV-Jk for 74476@debbugs.gnu.org; Sat, 30 Nov 2024 06:44:38 -0500 Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4Y0p9q3TzHzyXh; Sat, 30 Nov 2024 11:44:31 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4Y0p9p6j8JzB4; Sat, 30 Nov 2024 11:44:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1732967071; bh=6pPEzugMCT+sttn44jgVBSbPws0WhvETmG/eNGdg0uE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=d1m1CWolAonODmAr4mUGr8kGKQOvqMKGzQ2K6P8k7XDcKVh9oFTiDr8/uB31iic+8 fmBE67Mbr61x7qXn7vDsgsJWWND+ypKshDpOIvbujaEW5fK3wCMfXGUFSaFwzp6wE9 Ve6kx2X+P9dVaUKgJYRT0gCNjUtQTBxIgVq3nmm3KfQfLTE56BtQ8UTAqAKtAlcecs X3/Jf3LYKlbzNY3LxpYwjUcychIhWY/ygs8SZaHlYG/D+cJFz61a4dhj/X28Z7fXq6 V8maziG44uOMyRjE6KhJxzfVWGXEv5hvzcRykjEMoDCweLjnagsNPepZ87C98bUFzO xZuWqZYVJo7WQ== Received: from localhost (faroe.holly.idiocy.org [local]) by faroe.holly.idiocy.org (OpenSMTPD) with ESMTPA id 4faf1a16; Sat, 30 Nov 2024 11:44:29 +0000 (UTC) Date: Sat, 30 Nov 2024 11:44:29 +0000 From: Alan Third To: Eli Zaretskii Subject: Re: bug#74476: [PATCH] Explore JPEG loading without quantization Message-ID: Mail-Followup-To: Alan Third , Eli Zaretskii , Manuel Giraud , 74476@debbugs.gnu.org References: <871pz39v6p.fsf@ledu-giraud.fr> <86iks581nf.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86iks581nf.fsf@gnu.org> X-Spampanel-Class: ham X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74476 Cc: Manuel Giraud , 74476@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Nov 30, 2024 at 12:19:16PM +0200, Eli Zaretskii wrote: > > Date: Fri, 22 Nov 2024 15:53:18 +0100 > > From: Manuel Giraud via "Bug reports for GNU Emacs, > > the Swiss army knife of text editors" > > > > While trying to speed up "emacs as an image viewer", I found that emacs > > is using libjpeg with color quantization and it seems that removing this > > quantization could speed up JPEG loading a bit. > > > > My simple limited benchmark: > > > > - M-: (clear-image-cache) > > - Open an image in folder with some large enough pictures in > > it (4000x3000 here) > > - M-: (benchmark-run 10 (image-next-file 1)) > > > > Here are the results I get: > > > > without this path: (5.415405491 1 0.09232176400000025) > > with: (3.079911418 1 0.0751190459999993) > > > > I don't think that this patch could be applied as is (it is rather > > ugly). And I also think that I probably have missed some (many?) use > > case (where color quantization is mandatory). But I'm submitting this > > patch anyway as a conversation starter on the subject. > > Alan, any comments? I know nothing about this "color quantization" > aspect of JPEG images. Hi Eli, I'm not an expert on this part of the image code, but I think the jpeg colour quantization path exists for colour mapped environments. For example you can pass it an array of 256 colours and it will map all the colours in the jpeg to those colours. I don't think we need to do this. In most cases we're not in a colour mapped environment, and the existing code doesn't ask the jpeg code to map to the existing colour map anyway. AFAICT Emacs provides its own functions for colour mapping, so I think we should try turning off this quantization and rely on our own methods. That works for PNGs and others, after all. Manuel, I think you want to use lookup_rgb_color when setting the pixels in the final image buffer. This should do the right thing. You presumably also need to call init_color_table before using it, and I see calls to colors_in_color_table and free_color_table which look necessary, but I think they're already in the jpeg code. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 09:54:45 2024 Received: (at 74476) by debbugs.gnu.org; 30 Nov 2024 14:54:45 +0000 Received: from localhost ([127.0.0.1]:46053 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHOrs-0005j5-KK for submit@debbugs.gnu.org; Sat, 30 Nov 2024 09:54:44 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:20311) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHOrp-0005iw-QX for 74476@debbugs.gnu.org; Sat, 30 Nov 2024 09:54:42 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=i5yDQHpq TYEcWSqIz5tLdSRsZsN78f20qGm84Ek0dhU=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=i1uPrV3M+UGLMUM7teiry4uchVoPIt OX67ytK7vU8IfRA8rwG11DLYslLhHUfS8uHF6HFrt6edJKa7JGvzkHCg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=i5yDQHpqTYEcWSqI z5tLdSRsZsN78f20qGm84Ek0dhU=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=fwDfoRIa9gOAQBTN8Avuif2G9qnHgZxuDfEz4N yslY+R6GCDd9WQbVQi1j8zO6N61WJkgvKyftgqv03WssJ9pJu75taaHeFETwIfB0ll7moy HAKDMp4x85F2eosegRgo5eXTSsp6X4IGE2Uhr608AE2ikXqf11em23TZBQSLa/Nqcs5PpG 4BnmNNUfgt9w0JumMnlKeUqsvr5bqXmdNeoVKjqxUaI+Dbb+nThjTfaqtOclz7Qz1W5B2g LK0x4CRLQlQZjGxjXa52Qaw9x8cpaatGB8Cly5u4RC/L8lm6luQy9Hhn7zO+TKaxRNL8Hi o10IGYD9jbixl5fS5K2OvHnw== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 7b303c18 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 30 Nov 2024 15:54:41 +0100 (CET) From: Manuel Giraud To: Alan Third Subject: Re: bug#74476: [PATCH] Explore JPEG loading without quantization In-Reply-To: (Alan Third's message of "Sat, 30 Nov 2024 11:44:29 +0000") References: <871pz39v6p.fsf@ledu-giraud.fr> <86iks581nf.fsf@gnu.org> Date: Sat, 30 Nov 2024 15:54:38 +0100 Message-ID: <87y11093gx.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 74476 Cc: Eli Zaretskii , 74476@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) Alan Third writes: [...] > Manuel, I think you want to use lookup_rgb_color when setting the > pixels in the final image buffer. This should do the right thing. You > presumably also need to call init_color_table before using it, and I > see calls to colors_in_color_table and free_color_table which look > necessary, but I think they're already in the jpeg code. Hi Alan, I don't really understand: my proposed patch is getting rid of calls to lookup_rgb_color and init_color_table. -- Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 10:37:39 2024 Received: (at 74476) by debbugs.gnu.org; 30 Nov 2024 15:37:39 +0000 Received: from localhost ([127.0.0.1]:48315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHPXO-00007t-Pe for submit@debbugs.gnu.org; Sat, 30 Nov 2024 10:37:39 -0500 Received: from dane.soverin.net ([185.233.34.24]:54947) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHPXN-00007c-Lq for 74476@debbugs.gnu.org; Sat, 30 Nov 2024 10:37:38 -0500 Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4Y0vLg0nb3zyZC; Sat, 30 Nov 2024 15:37:31 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4Y0vLf4MH4zB4; Sat, 30 Nov 2024 15:37:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1732981050; bh=GGDrHynGsaZvJTqaLmskUXwl+A+OOdat5UxmpQiW5qA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jeZ/BLa1ZlnptCQTuDDEJvtmt5HkTiayOTLTQphxWhNEZGPG4aM0rzdrYP6tCW8I2 vPBLZolgtIRMrgxRYXriSnK/AaILjm7qN8w6i05lSWjcUFntVqFsgKKHPy1T9WZ3XA DitHUcgPxXnQm5fiOMqvLqN1/cR6w0bH/0IRIFjzsvDNn4sBYvvei4XC5arYyOEk0G 8EmLSuBZGdursQUwd1qpn9q+Bxl6hjL1tCmnt64KOvcY1e9tCsbXRwX6K/um9s+Em8 QJ8IVc5ajzvB0jbBv13xknDh4LyA4g1J1xVe6B8vQ4+01sFO+H/mUR8WTVfG04ul8c qya60ozZnpHiQ== Received: from localhost (faroe.holly.idiocy.org [local]) by faroe.holly.idiocy.org (OpenSMTPD) with ESMTPA id 5539fa70; Sat, 30 Nov 2024 15:37:29 +0000 (UTC) Date: Sat, 30 Nov 2024 15:37:29 +0000 From: Alan Third To: Manuel Giraud Subject: Re: bug#74476: [PATCH] Explore JPEG loading without quantization Message-ID: Mail-Followup-To: Alan Third , Manuel Giraud , Eli Zaretskii , 74476@debbugs.gnu.org References: <871pz39v6p.fsf@ledu-giraud.fr> <86iks581nf.fsf@gnu.org> <87y11093gx.fsf@ledu-giraud.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y11093gx.fsf@ledu-giraud.fr> X-Spampanel-Class: ham X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74476 Cc: Eli Zaretskii , 74476@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Nov 30, 2024 at 03:54:38PM +0100, Manuel Giraud wrote: > Alan Third writes: > > [...] > > > Manuel, I think you want to use lookup_rgb_color when setting the > > pixels in the final image buffer. This should do the right thing. You > > presumably also need to call init_color_table before using it, and I > > see calls to colors_in_color_table and free_color_table which look > > necessary, but I think they're already in the jpeg code. > > Hi Alan, > > I don't really understand: my proposed patch is getting rid of calls to > lookup_rgb_color and init_color_table. Yes, but they're internal Emacs functions, not related to libjpeg. All the other image library code uses them, so I think they are necessary to handle systems that use colour mapping (and possibly Windows too, it has a different implementation of lookup_rgb_color). For example, the PNG code looks like this: /* Fill the X image and mask from PNG data. */ init_color_table (); for (y = 0; y < height; ++y) { png_byte *p = rows[y]; for (x = 0; x < width; ++x) { int r, g, b; r = *p++ << 8; g = *p++ << 8; b = *p++ << 8; PUT_PIXEL (ximg, x, y, lookup_rgb_color (f, r, g, b)); ... -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 11:26:11 2024 Received: (at 74476) by debbugs.gnu.org; 30 Nov 2024 16:26:11 +0000 Received: from localhost ([127.0.0.1]:48401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHQIN-0002kB-AT for submit@debbugs.gnu.org; Sat, 30 Nov 2024 11:26:11 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:3334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHQIJ-0002jw-27 for 74476@debbugs.gnu.org; Sat, 30 Nov 2024 11:26:10 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=N1xZGEuu RbsDSoaBY3mGsonjL9f6vQAtQKzJW3NG6u0=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=T4m5XzJUa6CWL1cRrT+0iUqdmzRwaH PitI61M7fYoe8GIUwBcG+dXt0S4xyXHYWXQmjcJch4PUFCGjLDpk99Dw== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=N1xZGEuuRbsDSoaB Y3mGsonjL9f6vQAtQKzJW3NG6u0=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=BqgowS/9N1tkTyY/sxK5pUo2fCLmWWV/DanboD LlhSEHit5Hccx4s0O6iEPAgYJxYvg414nWjMOXYBNKjCAh0+nPSKUK7vqAUowk7U1yC9oI WrecZacwgUIQ4GGScNmhnzlAZOCXfvU12hKZFaEk6SD4tOQO6golT5zdfK4miSskJnwrrF eQWFCFhuzYj8hSrvnLF5/sGBhLo279HghxNRXkv9OZHQeEoocbLQuLzNbuG5Oq1BoTEkEP 7htZBZ9lKzl+pUTu5D84nxXXLVNsRIYk3h+h5ujkZxBzT2YIHqqiuITI3ei/TTlxipIiRX U2NugB0Ib1KE43+XrqpsFQMw== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 8590e1c0 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 30 Nov 2024 17:26:05 +0100 (CET) From: Manuel Giraud To: Alan Third Subject: Re: bug#74476: [PATCH] Explore JPEG loading without quantization In-Reply-To: (Alan Third's message of "Sat, 30 Nov 2024 15:37:29 +0000") References: <871pz39v6p.fsf@ledu-giraud.fr> <86iks581nf.fsf@gnu.org> <87y11093gx.fsf@ledu-giraud.fr> Date: Sat, 30 Nov 2024 17:26:03 +0100 Message-ID: <87r06s8z8k.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 74476 Cc: Eli Zaretskii , 74476@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) Alan Third writes: > On Sat, Nov 30, 2024 at 03:54:38PM +0100, Manuel Giraud wrote: >> Alan Third writes: >> >> [...] >> >> > Manuel, I think you want to use lookup_rgb_color when setting the >> > pixels in the final image buffer. This should do the right thing. You >> > presumably also need to call init_color_table before using it, and I >> > see calls to colors_in_color_table and free_color_table which look >> > necessary, but I think they're already in the jpeg code. >> >> Hi Alan, >> >> I don't really understand: my proposed patch is getting rid of calls to >> lookup_rgb_color and init_color_table. > > Yes, but they're internal Emacs functions, not related to libjpeg. All > the other image library code uses them, so I think they are necessary > to handle systems that use colour mapping (and possibly Windows too, > it has a different implementation of lookup_rgb_color). > > For example, the PNG code looks like this: Ok. Thanks for the clarification, I'll modify my patch. -- Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 12:25:07 2024 Received: (at 74476) by debbugs.gnu.org; 30 Nov 2024 17:25:07 +0000 Received: from localhost ([127.0.0.1]:48886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHRDO-00066q-Vy for submit@debbugs.gnu.org; Sat, 30 Nov 2024 12:25:07 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:7612) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHRDM-00064g-Pm for 74476@debbugs.gnu.org; Sat, 30 Nov 2024 12:25:06 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=bAyFug5Y biPULmKwXvU2vy9GaMPM1qU9rkDkYh6j1yI=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=psg0TFLhTc2rkZqqmzkUclXEqn6rWc E53RTqXbkdvebyfbJSUvJ6ZhdVVZFCY1A7w1nNtigEVwx8Uek8U5e1BA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=bAyFug5YbiPULmKw XvU2vy9GaMPM1qU9rkDkYh6j1yI=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=EHzQ6NWuVYWGUsp9FNkCsBxSqcrjRb249s4WrJ rAIXLbCgXpK7qOXR5+9kIkXcic0tICLH4arpGis37PtZYckcY8vEH0gn1+4KLzeRAlXDLe keKdVrevDi/OUDUweHHynf42ypFwyGeO3jeDuS0hU5NHMbDZ1e7cpAu7sPlvhml93YRgWW IeFmNRxvYY/xV4IGSP87KDHMWjlGDB84PEhEHIndZXI8epp0JWXzyuDs7cHAcHzhslxzZK 04NbKubqQ6b5rNIlzkVbrgdo8SSib4Zxpg3bzBDLPJDfLYhyEJ7QyWFVVWt2iszJaOGQrL iFHiq9K/J0JXZ4+ObZHZ2vpw== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id f1c65b05 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 30 Nov 2024 18:25:03 +0100 (CET) From: Manuel Giraud To: Alan Third Subject: Re: bug#74476: [PATCH] Explore JPEG loading without quantization In-Reply-To: (Alan Third's message of "Sat, 30 Nov 2024 15:37:29 +0000") References: <871pz39v6p.fsf@ledu-giraud.fr> <86iks581nf.fsf@gnu.org> <87y11093gx.fsf@ledu-giraud.fr> Date: Sat, 30 Nov 2024 18:25:01 +0100 Message-ID: <87h67obpn6.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74476 Cc: Eli Zaretskii , 74476@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Here is a new version with Alan suggestions. FTR, the gain is much less interesting. Here is the new timing with same benchmark (see below): (4.381739669 1 0.1034133749999997) > My simple limited benchmark: > > - M-: (clear-image-cache) > - Open an image in folder with some large enough pictures in > it (4000x3000 here) > - M-: (benchmark-run 10 (image-next-file 1)) > > Here are the results I get: > > without this path: (5.415405491 1 0.09232176400000025) > with: (3.079911418 1 0.0751190459999993) --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Explore-JPEG-loading-without-quantization.patch >From abf0a548ee1fa66db4bdf1051cd605231e29cf55 Mon Sep 17 00:00:00 2001 From: Manuel Giraud Date: Thu, 21 Nov 2024 17:19:59 +0100 Subject: [PATCH] Explore JPEG loading without quantization --- src/image.c | 66 ++++++++++++++--------------------------------------- 1 file changed, 17 insertions(+), 49 deletions(-) diff --git a/src/image.c b/src/image.c index db7f6acd171..a31c2e2658a 100644 --- a/src/image.c +++ b/src/image.c @@ -8949,9 +8949,8 @@ jpeg_load_body (struct frame *f, struct image *img, FILE *fp = NULL; JSAMPARRAY buffer; int row_stride, x, y; - int width, height; - int i, ir, ig, ib; - unsigned long *colors; + int width, height, ncomp; + int off, r, g, b; Emacs_Pix_Container volatile ximg_volatile = NULL; /* Open the JPEG file. */ @@ -9049,12 +9048,11 @@ jpeg_load_body (struct frame *f, struct image *img, jpeg_read_header (&mgr->cinfo, 1); - /* Customize decompression so that color quantization will be used. - Start decompression. */ - mgr->cinfo.quantize_colors = 1; + /* Start decompression. */ jpeg_start_decompress (&mgr->cinfo); width = img->width = mgr->cinfo.output_width; height = img->height = mgr->cinfo.output_height; + ncomp = mgr->cinfo.output_components; if (!check_image_size (f, width, height)) { @@ -9073,53 +9071,24 @@ jpeg_load_body (struct frame *f, struct image *img, sys_longjmp (mgr->setjmp_buffer, 1); } - /* Allocate colors. When color quantization is used, - mgr->cinfo.actual_number_of_colors has been set with the number of - colors generated, and mgr->cinfo.colormap is a two-dimensional array - of color indices in the range 0..mgr->cinfo.actual_number_of_colors. - No more than 255 colors will be generated. */ - USE_SAFE_ALLOCA; - { - if (mgr->cinfo.out_color_components > 2) - ir = 0, ig = 1, ib = 2; - else if (mgr->cinfo.out_color_components > 1) - ir = 0, ig = 1, ib = 0; - else - ir = 0, ig = 0, ib = 0; - - /* Use the color table mechanism because it handles colors that - cannot be allocated nicely. Such colors will be replaced with - a default color, and we don't have to care about which colors - can be freed safely, and which can't. */ - init_color_table (); - SAFE_NALLOCA (colors, 1, mgr->cinfo.actual_number_of_colors); - - for (i = 0; i < mgr->cinfo.actual_number_of_colors; ++i) - { - /* Multiply RGB values with 255 because X expects RGB values - in the range 0..0xffff. */ - int r = mgr->cinfo.colormap[ir][i] << 8; - int g = mgr->cinfo.colormap[ig][i] << 8; - int b = mgr->cinfo.colormap[ib][i] << 8; - colors[i] = lookup_rgb_color (f, r, g, b); - } - -#ifdef COLOR_TABLE_SUPPORT - /* Remember those colors actually allocated. */ - img->colors = colors_in_color_table (&img->ncolors); - free_color_table (); -#endif /* COLOR_TABLE_SUPPORT */ - } - - /* Read pixels. */ - row_stride = width * mgr->cinfo.output_components; + /* Allocate scanlines buffer and Emacs color table. */ + row_stride = width * ncomp; buffer = mgr->cinfo.mem->alloc_sarray ((j_common_ptr) &mgr->cinfo, JPOOL_IMAGE, row_stride, 1); + init_color_table (); + + /* Fill the X image from JPEG data. */ for (y = 0; y < height; ++y) { jpeg_read_scanlines (&mgr->cinfo, buffer, 1); - for (x = 0; x < mgr->cinfo.output_width; ++x) - PUT_PIXEL (ximg, x, y, colors[buffer[0][x]]); + for (x = 0; x < width; ++x) + { + off = x * ncomp; + r = buffer[0][off] << 8; + g = buffer[0][off + 1] << 8; + b = buffer[0][off + 2] << 8; + PUT_PIXEL (ximg, x, y, lookup_rgb_color (f, r, g, b)); + } } /* Clean up. */ @@ -9135,7 +9104,6 @@ jpeg_load_body (struct frame *f, struct image *img, /* Put ximg into the image. */ image_put_x_image (f, img, ximg, 0); - SAFE_FREE (); return 1; } -- 2.47.0 --=-=-= Content-Type: text/plain -- Manuel Giraud --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 13:17:20 2024 Received: (at 74476) by debbugs.gnu.org; 30 Nov 2024 18:17:20 +0000 Received: from localhost ([127.0.0.1]:48958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHS1v-0000Mx-Qo for submit@debbugs.gnu.org; Sat, 30 Nov 2024 13:17:20 -0500 Received: from dane.soverin.net ([185.233.34.35]:45507) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHS1u-0000Mc-Bm for 74476@debbugs.gnu.org; Sat, 30 Nov 2024 13:17:18 -0500 Received: from smtp.soverin.net (unknown [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4Y0ytJ3z9TzV3K; Sat, 30 Nov 2024 18:16:40 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4Y0ytJ0MxPzV0; Sat, 30 Nov 2024 18:16:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1732990600; bh=VnbXE4YnEuy3OMQKqTg6Zqjp2sDNkJrF8D80EHo2i7o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=k16F5CW8TfpgcPTvhMc/U7ypBAEjGss9FqL5JxruoaMuXsL9dcA2h8Nb7C8ofRj19 EoiIrv7FXth23pww95V6aAckjRzGKqhwEkvCJwiUGV5fIrioypZcF9VEyovDwyAO1J 5vgH7rEVZ7JQ1LUygK/lztKvgTJvxLfBzezMFOIwItRnJ7fR6R7+VwrrW3XNKFmJw0 ad6e6jeaYe6AnSnEuYTCLT8sSnxatA2s/MYMCQdb0TRxjBmHpJR8KjN16xzDV/Vfxz rQYHE/PathV/UIPhCuDX1hNmlc8rW6jW237t1MrbKAJkvehkkmB8SGBjo3GsvaCMRo PM4qiZI0zSrtA== Received: from localhost (faroe.holly.idiocy.org [local]) by faroe.holly.idiocy.org (OpenSMTPD) with ESMTPA id b6c5627e; Sat, 30 Nov 2024 18:16:39 +0000 (UTC) Date: Sat, 30 Nov 2024 18:16:39 +0000 From: Alan Third To: Manuel Giraud Subject: Re: bug#74476: [PATCH] Explore JPEG loading without quantization Message-ID: Mail-Followup-To: Alan Third , Manuel Giraud , Eli Zaretskii , 74476@debbugs.gnu.org References: <871pz39v6p.fsf@ledu-giraud.fr> <86iks581nf.fsf@gnu.org> <87y11093gx.fsf@ledu-giraud.fr> <87h67obpn6.fsf@ledu-giraud.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h67obpn6.fsf@ledu-giraud.fr> X-Spampanel-Class: ham X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 74476 Cc: Eli Zaretskii , 74476@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) On Sat, Nov 30, 2024 at 06:25:01PM +0100, Manuel Giraud wrote: > Here is a new version with Alan suggestions. > > FTR, the gain is much less interesting. Here is the new timing with > same benchmark (see below): > (4.381739669 1 0.1034133749999997) That's unfortunate, although here I see an improvement of greater than 2x. Probably I could do with finding some larger images as the whole thing completes in under a second even without your patch. I've had a quick dig into lookup_rgb_color and assuming you have a true colour display and there's no gamma calculation going on (I don't know when that happens) it shouldn't be doing a whole lot more. Perhaps it's just the extra over-head of calling a function? -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 13:32:16 2024 Received: (at 74476) by debbugs.gnu.org; 30 Nov 2024 18:32:16 +0000 Received: from localhost ([127.0.0.1]:48999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHSGO-0001Gh-3W for submit@debbugs.gnu.org; Sat, 30 Nov 2024 13:32:16 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:12550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHSGL-0001GW-4G for 74476@debbugs.gnu.org; Sat, 30 Nov 2024 13:32:14 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=i7xJmC90 78SQyB0KEHmwt2PTOHdrS/Okw84y+rlpoOs=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=YCU5AlrxKEHuZ1fp1laFHU7WGM9xaA TJAY0b2nbKzX8WI0dD06dOOpZD7GuAnziJm2Zsb/ApA5KoSqrAUTxAAA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=i7xJmC9078SQyB0K EHmwt2PTOHdrS/Okw84y+rlpoOs=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=IMTRKRy/2KTS/5o+QLHZzKDA8SkT+5nnvU3UwA dk/6UWxPCIxB21wJV7CQAEzWtCToQ3/2JADbbVdLMkWK4ydILmA9JtrN9OC+QHg/BD8r1Z RWGI/Z3hfyLHZtpcfZLYxZ02YZ+P7gdvQohzt5gCJJGZ0QJjUmao5YwMEw/z/fUb2f8b/7 yr8I3vsOM3b6G1eyBvRu8vISg75ntqy5biqVjj7kHPdNOsW/AbB6opyPjcxKe4hjlX1gdP tecjQBXr1f3wcsixxWQdRpZEwoCZXDFBt/gMH/b2TP7JuZdJBBweyK5bfOQJbu6Wen0PgA iht4i3S4nBCZA2kVr/bFPr0w== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id f946cfc2 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 30 Nov 2024 19:32:11 +0100 (CET) From: Manuel Giraud To: Alan Third Subject: Re: bug#74476: [PATCH] Explore JPEG loading without quantization In-Reply-To: (Alan Third's message of "Sat, 30 Nov 2024 18:16:39 +0000") References: <871pz39v6p.fsf@ledu-giraud.fr> <86iks581nf.fsf@gnu.org> <87y11093gx.fsf@ledu-giraud.fr> <87h67obpn6.fsf@ledu-giraud.fr> Date: Sat, 30 Nov 2024 19:32:10 +0100 Message-ID: <878qt0bmj9.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 74476 Cc: Eli Zaretskii , 74476@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) Alan Third writes: > On Sat, Nov 30, 2024 at 06:25:01PM +0100, Manuel Giraud wrote: >> Here is a new version with Alan suggestions. >> >> FTR, the gain is much less interesting. Here is the new timing with >> same benchmark (see below): >> (4.381739669 1 0.1034133749999997) > > That's unfortunate, although here I see an improvement of greater than > 2x. That's good news. > Probably I could do with finding some larger images as the whole thing > completes in under a second even without your patch. FYI, I have used images of 4000 by 3000 pixels. > I've had a quick dig into lookup_rgb_color and assuming you have a > true colour display and there's no gamma calculation going on (I don't > know when that happens) it shouldn't be doing a whole lot more. > Perhaps it's just the extra over-head of calling a function? It seems a bit much for just a function call. Or maybe it is the init_color_table call? Should it be done for each jpeg_load? -- Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 13:49:46 2024 Received: (at 74476) by debbugs.gnu.org; 30 Nov 2024 18:49:46 +0000 Received: from localhost ([127.0.0.1]:49039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHSXK-00028Z-BK for submit@debbugs.gnu.org; Sat, 30 Nov 2024 13:49:46 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:11351) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHSXH-00028M-S0 for 74476@debbugs.gnu.org; Sat, 30 Nov 2024 13:49:45 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=3d488gTw no5NzvPPLZ57nQRc5okoOPYaO7ZvLOFFt2M=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=A+CAo72xhZPySzMAn0at1G9N9UocKn 2wtgWeWnnEP5IKPqVVFWL9u8W/Z6AfAnUQpYh7q01Ga2iQzMoTdus9AQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=3d488gTwno5NzvPP LZ57nQRc5okoOPYaO7ZvLOFFt2M=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=gm44WKog6+saeTpeYz+iuu1GPrdUXzHDQIIUYf lbqCQ1Oyue184JtUCToX3AATJA30DTNwVLLmARAXDeeSBO3MFmzzeA6XDeg5x+LgSHwN0X zlNueNkbW0p9xkEGISGzxphmjS+e7R7t6/jUleNkzzDtg/o20EM9JiD8b5KAH4jUxYbEYU BnbMQfW1hqtazhsmD4Ki8O+UCLa3slfyCrTFRyH1Uqep9LtDMnn16yRtuIhzA5GLO+BLd4 9egJd5GUdy1tu+2bQbIJp59YJQFCWeW90nX6Mkv91akiuoFTFypCozqiv07b+YJF7P/ZxO VdHyXGTQmCcRQfMrH5JvKIIQ== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id ff571333 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 30 Nov 2024 19:49:42 +0100 (CET) From: Manuel Giraud To: Alan Third Subject: Re: bug#74476: [PATCH] Explore JPEG loading without quantization In-Reply-To: (Alan Third's message of "Sat, 30 Nov 2024 18:16:39 +0000") References: <871pz39v6p.fsf@ledu-giraud.fr> <86iks581nf.fsf@gnu.org> <87y11093gx.fsf@ledu-giraud.fr> <87h67obpn6.fsf@ledu-giraud.fr> Date: Sat, 30 Nov 2024 19:49:41 +0100 Message-ID: <874j3oblq2.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 74476 Cc: Eli Zaretskii , 74476@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) Alan Third writes: > On Sat, Nov 30, 2024 at 06:25:01PM +0100, Manuel Giraud wrote: >> Here is a new version with Alan suggestions. >> >> FTR, the gain is much less interesting. Here is the new timing with >> same benchmark (see below): >> (4.381739669 1 0.1034133749999997) > > That's unfortunate, although here I see an improvement of greater than > 2x. Probably I could do with finding some larger images as the whole > thing completes in under a second even without your patch. > > I've had a quick dig into lookup_rgb_color and assuming you have a > true colour display and there's no gamma calculation going on (I don't > know when that happens) it shouldn't be doing a whole lot more. > Perhaps it's just the extra over-head of calling a function? I also have a quick look at lookup_rgb_color and it seems to me that if the user has a true color display (I suspect almost everyone nowadays), we can spare the computation ct_hash_rgb and hence also spare to allocate a ct_table. WDYT? -- Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 14:55:27 2024 Received: (at 74476) by debbugs.gnu.org; 30 Nov 2024 19:55:27 +0000 Received: from localhost ([127.0.0.1]:49192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHTYt-0005la-76 for submit@debbugs.gnu.org; Sat, 30 Nov 2024 14:55:27 -0500 Received: from dane.soverin.net ([185.233.34.148]:45211) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHTYr-0005lG-SG for 74476@debbugs.gnu.org; Sat, 30 Nov 2024 14:55:26 -0500 Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4Y11472T20z2xCX; Sat, 30 Nov 2024 19:55:19 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4Y11466DdnzTq; Sat, 30 Nov 2024 19:55:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1732996519; bh=7Ftkzavbx8ejqCyMFjxnfT9efdjBMraC8esJ9ZrYdLk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Zj/JGb+vO7AW88SiDCtCaHFL4u4l/JFTzUlb6A6ILjybQbNif/324Cu8njnFiQZWL uDYWF00UZ2m2Qdoon9jFIwNumh6QU1ghEnT4f7rGubQBTAC65ciyCbC9Sx0tOQ6IGP yS/885wFYOpN7HVsklKmKcSJ3vmkhn8hC8F0tvuAG3lNPJpsC8IH+e7IsgqCuySWp0 Iuv26EiYNlKO698Gz9XACoJQfu/PwnMtUGA1npwCIMq3To8dP3xjxH39pzKhtgFUwH 0APgvS8+5cUO1XJtNSCXSPFfSZlpJm0gueV+n4TLOWzTOG2A9RqhJ/pHrQLb1H/LsU wHD/tAgosrLhA== Received: from localhost (faroe.holly.idiocy.org [local]) by faroe.holly.idiocy.org (OpenSMTPD) with ESMTPA id b3fa038c; Sat, 30 Nov 2024 19:55:17 +0000 (UTC) Date: Sat, 30 Nov 2024 19:55:17 +0000 From: Alan Third To: Manuel Giraud Subject: Re: bug#74476: [PATCH] Explore JPEG loading without quantization Message-ID: Mail-Followup-To: Alan Third , Manuel Giraud , Eli Zaretskii , 74476@debbugs.gnu.org References: <871pz39v6p.fsf@ledu-giraud.fr> <86iks581nf.fsf@gnu.org> <87y11093gx.fsf@ledu-giraud.fr> <87h67obpn6.fsf@ledu-giraud.fr> <878qt0bmj9.fsf@ledu-giraud.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878qt0bmj9.fsf@ledu-giraud.fr> X-Spampanel-Class: ham X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74476 Cc: Eli Zaretskii , 74476@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Nov 30, 2024 at 07:32:10PM +0100, Manuel Giraud wrote: > Alan Third writes: > > > Probably I could do with finding some larger images as the whole thing > > completes in under a second even without your patch. > > FYI, I have used images of 4000 by 3000 pixels. > > > I've had a quick dig into lookup_rgb_color and assuming you have a > > true colour display and there's no gamma calculation going on (I don't > > know when that happens) it shouldn't be doing a whole lot more. > > Perhaps it's just the extra over-head of calling a function? > > It seems a bit much for just a function call. Or maybe it is the > init_color_table call? Should it be done for each jpeg_load? It's 4000x3000 function calls, so it might have an effect... I think it should be done for each load. And I just noticed you need to add a free_color_table call after you're done with it. I get that it's a waste of time allocating the table on a true colour display because it's never going to be used, but it seems to make no performance difference here and it is still needed on other display types. Purely for testing purposes I tried changing the PUT_PIXEL call to this: PUT_PIXEL (ximg, x, y, x_make_truecolor_pixel (FRAME_DISPLAY_INFO(f), r, g, b)); I think it might have given an improvement, but it was so slight I can't say for sure. That obviously can't be used outside of testing, but it lets us rule out the function call, etc. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 01 06:14:01 2024 Received: (at 74476) by debbugs.gnu.org; 1 Dec 2024 11:14:01 +0000 Received: from localhost ([127.0.0.1]:50486 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHhto-0002X1-QN for submit@debbugs.gnu.org; Sun, 01 Dec 2024 06:14:01 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:5603) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHhtl-0002Ws-Se for 74476@debbugs.gnu.org; Sun, 01 Dec 2024 06:13:59 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=hcIMgPu2 kp9NKysFeD7Wleb/LESbWaG+ikrTQdi4xd4=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=Nqk3OGqhz9LFhke35cQTQyiKBIVGcI mQGs90v45yJrUPWuIX0VUH9dqhggxC9FaZr0WGcZxoAQngAleutF/sDA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=hcIMgPu2kp9NKysF eD7Wleb/LESbWaG+ikrTQdi4xd4=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=Nr4nqbGwJ16jybjYSvtDTa8c9th0wE/On0gkId RvTzFBD7FDOJazcJTni8agxlcOOemSICNF9eJ0Al0lxaoQKwzUu484PlDbbXtlJs57uGjn 4py52pbKGHpYz7/UnXBeoMzu8X6ekNGJ/15+HOQ37yu+CNp59cQqWTxbUT3FsfpeSVACL9 jcgmndfB7xzkfOj8iR5ylAJhzLvHtdsFD9GUYJDXpSYbaKtV1WXkswFeoB0KVZwgMFL9ft HHKzU0Dbb9D2aJ+a4BDcsa7X89DH44kdq/nknx7WL0avjM3+0IYYrIF7w/Fk1iv19CQYRL MlfLo+06lluJVC462Dnc7gsg== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 1b491187 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 1 Dec 2024 12:13:54 +0100 (CET) From: Manuel Giraud To: Alan Third Subject: Re: bug#74476: [PATCH] Explore JPEG loading without quantization In-Reply-To: (Alan Third's message of "Sat, 30 Nov 2024 19:55:17 +0000") References: <871pz39v6p.fsf@ledu-giraud.fr> <86iks581nf.fsf@gnu.org> <87y11093gx.fsf@ledu-giraud.fr> <87h67obpn6.fsf@ledu-giraud.fr> <878qt0bmj9.fsf@ledu-giraud.fr> Date: Sun, 01 Dec 2024 12:13:53 +0100 Message-ID: <87r06r8xla.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 74476 Cc: Eli Zaretskii , 74476@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alan Third writes: > On Sat, Nov 30, 2024 at 07:32:10PM +0100, Manuel Giraud wrote: >> Alan Third writes: >>=20 >> > Probably I could do with finding some larger images as the whole thing >> > completes in under a second even without your patch. >>=20 >> FYI, I have used images of 4000 by 3000 pixels. >>=20 >> > I've had a quick dig into lookup_rgb_color and assuming you have a >> > true colour display and there's no gamma calculation going on (I don't >> > know when that happens) it shouldn't be doing a whole lot more. >> > Perhaps it's just the extra over-head of calling a function? >>=20 >> It seems a bit much for just a function call. Or maybe it is the >> init_color_table call? Should it be done for each jpeg_load? > > It's 4000x3000 function calls, so it might have an effect... Yes, you're right. I missed this =F0=9F=98=85. > I think it should be done for each load. And I just noticed you need > to add a free_color_table call after you're done with it. Yes, I have re-add it in the attached new version of the patch. I also re-add the ir, ig and ib indices computation. WDYT? > I get that it's a waste of time allocating the table on a true colour > display because it's never going to be used, but it seems to make no > performance difference here and it is still needed on other display > types. Ok, I thought about making this allocation conditional to having a true color display or not... but if you say that there is no performance gain, it might not worth it. > Purely for testing purposes I tried changing the PUT_PIXEL call to > this: > > PUT_PIXEL (ximg, x, y, x_make_truecolor_pixel (FRAME_DISPLAY_INFO(f),= r, g, b)); > > I think it might have given an improvement, but it was so slight I > can't say for sure. That obviously can't be used outside of testing, > but it lets us rule out the function call, etc. Yes and the gamma correction part is also missing. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Do-not-use-libjpeg-quantization-bug-74476.patch >From ebb19d8eb64a8e59dd9200f24e69c92a93c723fb Mon Sep 17 00:00:00 2001 From: Manuel Giraud Date: Thu, 21 Nov 2024 17:19:59 +0100 Subject: [PATCH] Do not use libjpeg quantization (bug#74476) * src/image.c (jpeg_load_body): Remove libjpeg quantization. --- src/image.c | 80 +++++++++++++++++++++-------------------------------- 1 file changed, 31 insertions(+), 49 deletions(-) diff --git a/src/image.c b/src/image.c index db7f6acd171..b5e7bef2305 100644 --- a/src/image.c +++ b/src/image.c @@ -8949,9 +8949,8 @@ jpeg_load_body (struct frame *f, struct image *img, FILE *fp = NULL; JSAMPARRAY buffer; int row_stride, x, y; - int width, height; - int i, ir, ig, ib; - unsigned long *colors; + int width, height, ncomp; + int ir, ig, ib; Emacs_Pix_Container volatile ximg_volatile = NULL; /* Open the JPEG file. */ @@ -9049,12 +9048,17 @@ jpeg_load_body (struct frame *f, struct image *img, jpeg_read_header (&mgr->cinfo, 1); - /* Customize decompression so that color quantization will be used. - Start decompression. */ - mgr->cinfo.quantize_colors = 1; + /* Start decompression. */ jpeg_start_decompress (&mgr->cinfo); width = img->width = mgr->cinfo.output_width; height = img->height = mgr->cinfo.output_height; + ncomp = mgr->cinfo.output_components; + if (ncomp > 2) + ir = 0, ig = 1, ib = 2; + else if (ncomp > 1) + ir = 0, ig = 1, ib = 0; + else + ir = 0, ig = 0, ib = 0; if (!check_image_size (f, width, height)) { @@ -9073,55 +9077,34 @@ jpeg_load_body (struct frame *f, struct image *img, sys_longjmp (mgr->setjmp_buffer, 1); } - /* Allocate colors. When color quantization is used, - mgr->cinfo.actual_number_of_colors has been set with the number of - colors generated, and mgr->cinfo.colormap is a two-dimensional array - of color indices in the range 0..mgr->cinfo.actual_number_of_colors. - No more than 255 colors will be generated. */ - USE_SAFE_ALLOCA; - { - if (mgr->cinfo.out_color_components > 2) - ir = 0, ig = 1, ib = 2; - else if (mgr->cinfo.out_color_components > 1) - ir = 0, ig = 1, ib = 0; - else - ir = 0, ig = 0, ib = 0; - - /* Use the color table mechanism because it handles colors that - cannot be allocated nicely. Such colors will be replaced with - a default color, and we don't have to care about which colors - can be freed safely, and which can't. */ - init_color_table (); - SAFE_NALLOCA (colors, 1, mgr->cinfo.actual_number_of_colors); - - for (i = 0; i < mgr->cinfo.actual_number_of_colors; ++i) - { - /* Multiply RGB values with 255 because X expects RGB values - in the range 0..0xffff. */ - int r = mgr->cinfo.colormap[ir][i] << 8; - int g = mgr->cinfo.colormap[ig][i] << 8; - int b = mgr->cinfo.colormap[ib][i] << 8; - colors[i] = lookup_rgb_color (f, r, g, b); - } - -#ifdef COLOR_TABLE_SUPPORT - /* Remember those colors actually allocated. */ - img->colors = colors_in_color_table (&img->ncolors); - free_color_table (); -#endif /* COLOR_TABLE_SUPPORT */ - } - - /* Read pixels. */ - row_stride = width * mgr->cinfo.output_components; + /* Allocate scanlines buffer and Emacs color table. */ + row_stride = width * ncomp; buffer = mgr->cinfo.mem->alloc_sarray ((j_common_ptr) &mgr->cinfo, JPOOL_IMAGE, row_stride, 1); + init_color_table (); + + /* Fill the X image from JPEG data. */ for (y = 0; y < height; ++y) { jpeg_read_scanlines (&mgr->cinfo, buffer, 1); - for (x = 0; x < mgr->cinfo.output_width; ++x) - PUT_PIXEL (ximg, x, y, colors[buffer[0][x]]); + for (x = 0; x < width; ++x) + { + int off = x * ncomp; + /* Multiply RGB values with 255 because X expects RGB values + in the range 0..0xffff. */ + int r = buffer[0][off + ir] << 8; + int g = buffer[0][off + ig] << 8; + int b = buffer[0][off + ib] << 8; + PUT_PIXEL (ximg, x, y, lookup_rgb_color (f, r, g, b)); + } } +#ifdef COLOR_TABLE_SUPPORT + /* Remember those colors actually allocated. */ + img->colors = colors_in_color_table (&img->ncolors); + free_color_table (); +#endif /* COLOR_TABLE_SUPPORT */ + /* Clean up. */ jpeg_finish_decompress (&mgr->cinfo); jpeg_destroy_decompress (&mgr->cinfo); @@ -9135,7 +9118,6 @@ jpeg_load_body (struct frame *f, struct image *img, /* Put ximg into the image. */ image_put_x_image (f, img, ximg, 0); - SAFE_FREE (); return 1; } -- 2.47.0 --=-=-= Content-Type: text/plain -- Manuel Giraud --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 02 05:48:23 2024 Received: (at 74476-done) by debbugs.gnu.org; 2 Dec 2024 10:48:23 +0000 Received: from localhost ([127.0.0.1]:54381 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tI3yZ-0008TS-2o for submit@debbugs.gnu.org; Mon, 02 Dec 2024 05:48:23 -0500 Received: from dane.soverin.net ([185.233.34.149]:58665) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tI3yW-0008TC-Ls for 74476-done@debbugs.gnu.org; Mon, 02 Dec 2024 05:48:21 -0500 Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4Y20qN2gbxzyyW; Mon, 2 Dec 2024 10:47:44 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4Y20qM44tDz6D; Mon, 2 Dec 2024 10:47:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1733136464; bh=7Ja/ejeKo/XhNL/1qOHS8e6KwZ/3bN8HcZKGgbLrAxk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZAXEM6YkqENrFrpcp/fuHwNxI9KHe2rHKs3xZ6QbF8ttVnNillEdCBHKRsfOXoqrF 1HFByG0b7b8kn9LJo6fKwdMoelOgL7KK//R0yB4YJ2E/YjxKGanNQBbUbGos3cNbfH sk32k9aVFLK3vCYrBobCRsXcn4fyZ9BvZkNMfsHroc4/Dvaap4IhmxIVXgxpkRLRd/ k/9d1Gvp2Owj1xyHEPpnvm2PJskedBVORL5Wg/2rqQFwF9uQM8pBN5gWR3LIcMG4Kw LN8jZP7PQk7xjF7STEEV83UvfVZVPU+arQ/fyfmvYMaPiBXMHo+XVT4umPgV0N+SjB 7LdkE1KyBT5Dg== Received: from localhost (faroe.holly.idiocy.org [local]) by faroe.holly.idiocy.org (OpenSMTPD) with ESMTPA id e353ffb4; Mon, 2 Dec 2024 10:47:42 +0000 (UTC) Date: Mon, 2 Dec 2024 10:47:42 +0000 From: Alan Third To: Manuel Giraud Subject: Re: bug#74476: [PATCH] Explore JPEG loading without quantization Message-ID: Mail-Followup-To: Alan Third , Manuel Giraud , Eli Zaretskii , 74476-done@debbugs.gnu.org References: <871pz39v6p.fsf@ledu-giraud.fr> <86iks581nf.fsf@gnu.org> <87y11093gx.fsf@ledu-giraud.fr> <87h67obpn6.fsf@ledu-giraud.fr> <878qt0bmj9.fsf@ledu-giraud.fr> <87r06r8xla.fsf@ledu-giraud.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r06r8xla.fsf@ledu-giraud.fr> X-Spampanel-Class: ham X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74476-done Cc: 74476-done@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sun, Dec 01, 2024 at 12:13:53PM +0100, Manuel Giraud wrote: > Alan Third writes: > > > I think it should be done for each load. And I just noticed you need > > to add a free_color_table call after you're done with it. > > Yes, I have re-add it in the attached new version of the patch. I also > re-add the ir, ig and ib indices computation. WDYT? Looks good to me. I've pushed this to master. Thanks! -- Alan Third From unknown Tue Jun 17 20:16:48 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 30 Dec 2024 12:24:13 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator