Re: Image transformation filter for upscaled images

[Evgeny Zajcev <lg.zevlg@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

пн, 8 мар. 2021 г. в 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 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 text
> > 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

-- 
lg

[-- Attachment #2: Type: text/html, Size: 2278 bytes --]