From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Evgeny Zajcev Newsgroups: gmane.emacs.devel Subject: Re: Image transformation filter for upscaled images Date: Mon, 8 Mar 2021 23:05:29 +0300 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000004a5b7505bd0bf58c" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25222"; mail-complaints-to="usenet@ciao.gmane.io" To: Alan Third , Stefan Kangas , Evgeny Zajcev , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 08 21:06:48 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lJM9O-0006QT-AF for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 21:06:46 +0100 Original-Received: from localhost ([::1]:38762 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJM9N-0003nE-C6 for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 15:06:45 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58004) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJM8V-00032x-SP for emacs-devel@gnu.org; Mon, 08 Mar 2021 15:05:51 -0500 Original-Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]:41694) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJM8N-0005XL-De for emacs-devel@gnu.org; Mon, 08 Mar 2021 15:05:51 -0500 Original-Received: by mail-lf1-x134.google.com with SMTP id q25so23023674lfc.8 for ; Mon, 08 Mar 2021 12:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=cVlMlVGw2IB4wREUdqynskJQsVG8WQVDx6UciAfvg6c=; b=cWRXK7Nxf0bl1IxC8Rl0vIdncCGndWPHhn7j+JxY/UoBxXlWXCWafBu7ijZz7IB3LW PlJL5aZIm2Br3JEvNlqcjIylMsvuVJmTGnS1yvQs4H7/Yd24uQIxA8qfxz+hwPtXJ51B YrqC5gocADUIgfkqp/0ttaEBCp+jRb+g++n8SApF1BGetNY2A8TIzTqhZQjb3ojRRcUj WqxxUMyiYtQorsiotmIeHsqUtFJZNh62zgmHslx8/wFuoFPNxPXTjt00gfCNtlJSVGLv sozKzspgo04gmiw44yKtg7uv/0vGO14GLbVbYJ+n1FFsiDseRF6oJl5Hx+iLQQ921lS6 yjmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=cVlMlVGw2IB4wREUdqynskJQsVG8WQVDx6UciAfvg6c=; b=rA89wtsr7cjveuU9zPHO0rtYuGaR50YTxqIm11aLm5kDxBpo3MBY7mM81d7jADiuiK PRuCpMZ3V/ae0l1g0W7xMLzmWeBqhWfqURFyEFTETVb1lckwt71a5jGSHVK87rvL/yDR gWQ/YVUf3l/a0p1WR38bVBCLe/EwxlzYJwcOmzLruEHXR5Fafww1Hfs3m6n5GOL4H7ku gueRk/bA1zvhtIZ2dEwjkAiXWcxomiCVrCkVEVR6Vbqg4A+ScGWWvbN0UIJ9tH8CCWGp RXVgZck8Ro8p2kdBkVPLBrvLZ+FWgrTUGddxERujJ62Mnc7khSkoQwE5V2nG/r085E0b quMA== X-Gm-Message-State: AOAM533KQzxSpN5VhcwV3pByZmoYccmdsyGClMtSUbkZfeQBpen/nLOv 15wXbUUk5iFll2JJHJbWEuoRjJhNj3OAGe2Fy+Y= X-Google-Smtp-Source: ABdhPJy4CKoAX1OT+UKgQYsVTT44zcu8lzVhuJOZywrTGHvNtecP3yYSNB3FDqAEEUR7AWTS81noA3llbJKL8A6/oAk= X-Received: by 2002:ac2:4254:: with SMTP id m20mr5285250lfl.474.1615233941133; Mon, 08 Mar 2021 12:05:41 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::134; envelope-from=lg.zevlg@gmail.com; helo=mail-lf1-x134.google.com 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:266221 Archived-At: --0000000000004a5b7505bd0bf58c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D0=BF=D0=BD, 8 =D0=BC=D0=B0=D1=80. 2021 =D0=B3. =D0=B2 21:58, Alan Third <= alan@idiocy.org>: > On Sun, Mar 07, 2021 at 05:27:44PM -0600, Stefan Kangas wrote: > > Evgeny Zajcev writes: > > > > >> The reason nearest was chosen was because scaled up pixel art (emoji= s, > > >> mostly, like etc/images/smilies/wry.xpm) looked abominable > > > > Doesn't it seem like a bad trade-off to improve rendering of smileys at > > the cost of rendering PDF:s worse? I rarely if ever use doc-view, but > > testing it now seems to produce less than stellar results (i.e. the tex= t > > is barely readable). > > This is the first I've heard of any complaints about the rendering of > PDFs, and I don't view them in Emacs. Certainly nobody brought it up > when the change was implemented, so the trade-off wasn't considered. > > I don't feel strongly about this. Can someone try the "best" filter > and see if good is an improvement over it? We use best for scaling > down, so if we're happy with best for scaling up then we can just > remove the code that sets it completely. Or go with good across the > board, but best is, y'know, better. ;) > BEST looks even better then good - http://lgarc.narod.ru/pics/upscaled-best.png comparing to http://lgarc.narod.ru/pics/upscaled-good.png and http://lgarc.narod.ru/pics/upscaled-nearest.png Is it possible to access image type at the filter application time? in that case we can apply NEAREST for small xpm files and BEST otherwise --=20 lg --0000000000004a5b7505bd0bf58c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
=D0=BF=D0=BD, 8 =D0=BC=D0=B0=D1=80. 2= 021 =D0=B3. =D0=B2 21:58, Alan Third <alan@idiocy.org>:
On Sun, Mar 07, 2021 at 05:27:44PM -0600, Stefan Kangas wrote: > Evgeny Zajcev <lg.zevlg@gmail.com> writes:
>
> >> The reason nearest was chosen was because scaled up pixel art= (emojis,
> >> mostly, like etc/images/smilies/wry.xpm) looked abominable >
> Doesn't it seem like a bad trade-off to improve rendering of smile= ys at
> the cost of rendering PDF:s worse?=C2=A0 I rarely if ever use doc-view= , but
> testing it now seems to produce less than stellar results (i.e. the te= xt
> is barely readable).

This is the first I've heard of any complaints about the rendering of PDFs, and I don't view them in Emacs. Certainly nobody brought it up when the change was implemented, so the trade-off wasn't considered.
I don't feel strongly about this. Can someone try the "best" = filter
and see if good is an improvement over it? We use best for scaling
down, so if we're happy with best for scaling up then we can just
remove the code that sets it completely. Or go with good across the
board, but best is, y'know, better. ;)

<= div>BEST looks even better then good - http://lgarc.narod.ru/pics/upscaled-best.png
=


Is it possible= to access image type at the filter application time? in that case we can a= pply NEAREST for small xpm files and BEST otherwise

-- =
lg
--0000000000004a5b7505bd0bf58c--