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 01:35:50 +0300 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000250afb05bcf9f1a7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30869"; mail-complaints-to="usenet@ciao.gmane.io" To: Alan Third , Evgeny Zajcev , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 07 23:36:56 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 1lJ219-0007va-SL for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Mar 2021 23:36:55 +0100 Original-Received: from localhost ([::1]:47600 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJ218-0006Rm-Rn for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Mar 2021 17:36:54 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47074) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJ20M-0005rN-JS for emacs-devel@gnu.org; Sun, 07 Mar 2021 17:36:06 -0500 Original-Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]:41356) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJ20K-00011n-9e for emacs-devel@gnu.org; Sun, 07 Mar 2021 17:36:06 -0500 Original-Received: by mail-lj1-x22a.google.com with SMTP id t9so12696271ljt.8 for ; Sun, 07 Mar 2021 14:36:03 -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=ktPHo70voc3HtBdPkyQbx1XjAAZtVR3CJqX/ZJ9dkAA=; b=P0SRUdFGZjbdZy0EGZRRB/YfHBRXVLDfNvNVThbuKOFBsHOiHxPRlSD6DXuFm6iLXA aYG1/GUvVKv8rVNGg/IJz6eFaWic+RHioG2LhqHXONKejdS0088NltVE0l9RXp/6kLNV 3hH1vkYw91w14CNFU09ZJZ+JACcTEJy0FczyMyN9fqh5Fc631GsFCnFYmGJweFIjq0fJ HTPm2OaJcoCDP4we2bCuUzdd1HEXMjvC0EJtM/bdQXQZ2MEYx1CGo9TYoChOodKIc5TN /nhkIOMMWVjE3x7Xol3Uyu3HfIhhKXAGRsNBLgcxWN4XSh926tMym0Qo6C5fA1VNzOeX jQ7g== 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=ktPHo70voc3HtBdPkyQbx1XjAAZtVR3CJqX/ZJ9dkAA=; b=PaDtrtDef0vzvwZgwYRrWDVY7EAYRY45Yr2yMfZULorRo71R7owRNXoYZzwJPsFLsI g6z24yF0RLgUb73DmvZXcZrNvhblsDMuTSC10rN4PdhHZjNt95vb1aarnIEQj5W49shV mH8uoPON/2ZVMDncbExxFRP/EeAcCv9bMP4fI5ElW7qvS56k/pciVSAyBFDmiIa28z41 rC9izSh0Csjq2B+ikeizwt5dEoEx8OIpeteCTP0pJ2g767gGeX7rL80EXN3c9EC3Lh4r DGhkdCp9L5C3ubHBWcjtQghEd3+pDD3B+79cMdnnFbxJ6I1Au/myL8ws6rt358LE40nP 8dGA== X-Gm-Message-State: AOAM532JaYB/6Jwli5pR3GipiA/2EJ7JswLUa1hyGTP3jXlXi2aQDtTP BqTx2YbM0pF4Mwq9SPo/wac7j15sr89VjesOn50= X-Google-Smtp-Source: ABdhPJywRmd+fdXp86DYsLnXS8oeTpB+DKogf0G1DkESwWREbRi+U95Hw5CoGfVDSy7vQm03Ydozxh12HuwBPQLIoSA= X-Received: by 2002:a2e:9c12:: with SMTP id s18mr11861319lji.383.1615156562167; Sun, 07 Mar 2021 14:36:02 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::22a; envelope-from=lg.zevlg@gmail.com; helo=mail-lj1-x22a.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:266150 Archived-At: --000000000000250afb05bcf9f1a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D0=B2=D1=81, 7 =D0=BC=D0=B0=D1=80. 2021 =D0=B3. =D0=B2 23:46, Alan Third <= alan@idiocy.org>: > On Sun, Mar 07, 2021 at 10:12:43PM +0300, Evgeny Zajcev wrote: > > Currently, image transformation for upscaled images uses NEAREST filter= , > > which is fast, but renders very bad results for images with text inside= . > > > > Maybe change it to GOOD, which is also fast, but renders more decent > results > > > > Here is I've got two screenshots showing the difference: > > > > NEAREST (currently hardcoded in Emacs) - > > http://lgarc.narod.ru/pics/upscaled-nearest.png > > > > GOOD (my proposal) - http://lgarc.narod.ru/pics/upscaled-good.png > > > > What do you think? > > See also bug#38394. > > The reason nearest was chosen was because scaled up pixel art (emojis, > mostly, like etc/images/smilies/wry.xpm) looked abominable In 2k21 any xpm with any filter will look abominable :) when using > the "best" filter, > but most other types of images look OK when using > nearest. We (telega.el project) see many images of different kind daily, and only some of them looks OK when nearest filter is applied. Most of the time, especially if some contrast diagonals are involved (including character glyphs) upscaling results are no ok. Also, doc-view suffers from this, most pdf files viewed inside Emacs looks no ok. On the other hand the bug report complains that scaled up > pixel art looks abominable with nearest, so clearly there's a > difference of opinion. > Just get rid of any xpm :) Emacs has nice support for SVG after all, we can write xpm to svg converter to keep pixel art precision. I don't know whether "good" is a better compromise, I suspect it looks > quite like "best". > I don't know what the best option is, I suspect there's no clear > one-size-fits-all winning strategy. > Or maybe we can make the transformation filter configurable, so it could be changed from elisp side? --=20 lg --000000000000250afb05bcf9f1a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=D0=B2=D1=81, 7 =D0=BC=D0=B0=D1=80. 2021 = =D0=B3. =D0=B2 23:46, Alan Third <ala= n@idiocy.org>:
On Sun, Mar 07, 2021 at 10:12:43PM +0300, = Evgeny Zajcev wrote:
> Currently, image transformation for upscaled images uses NEAREST filte= r,
> which is fast, but renders very bad results for images with text insid= e.
>
> Maybe change it to GOOD, which is also fast, but renders more decent r= esults
>
> Here is I've got two screenshots showing the difference:
>
> NEAREST (currently hardcoded in Emacs) -
> http://lgarc.narod.ru/pics/upscaled-nearest.png<= /a>
>
> GOOD (my proposal) - http://lgarc.narod.ru/pics/ups= caled-good.png
>
> What do you think?

See also bug#38394.

The reason nearest was chosen was because scaled up pixel art (emojis,
mostly, like etc/images/smilies/wry.xpm) looked abominable

In 2k21 any xpm with any filter will look abominable :)

when u= sing
the "best" filter,
=C2=A0
but most other types of images look OK wh= en using
nearest.

We (telega.el project) see many im= ages of different kind daily, and only some of them looks OK when nearest f= ilter is applied. Most of the time, especially if some contrast diagonals a= re involved (including character glyphs) upscaling results are no ok.=C2=A0= Also, doc-view suffers from this, most pdf files viewed inside Emacs looks= no ok.

On the other hand the bug report complains that scaled up
pixel art looks abominable with nearest, so clearly there's a
difference of opinion.

Just get rid of = any xpm :) Emacs has nice support for SVG after all, we can write xpm to sv= g converter to keep pixel art precision.

I don't know whether "good" is a better compromise, I suspect= it looks
quite like "best".
I don't know what the best option is, I suspect there's no clear one-size-fits-all winning strategy.

Or maybe we can make the transformation fi= lter configurable, so it could be changed from elisp side?
<= br>--
lg
--000000000000250afb05bcf9f1a7--