* Image transformation filter for upscaled images @ 2021-03-07 19:12 Evgeny Zajcev 2021-03-07 20:45 ` Alan Third 0 siblings, 1 reply; 42+ messages in thread From: Evgeny Zajcev @ 2021-03-07 19:12 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 475 bytes --] 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? Thanks -- lg [-- Attachment #2: Type: text/html, Size: 882 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-07 19:12 Image transformation filter for upscaled images Evgeny Zajcev @ 2021-03-07 20:45 ` Alan Third 2021-03-07 22:35 ` Evgeny Zajcev 2021-03-07 23:12 ` Stefan Monnier 0 siblings, 2 replies; 42+ messages in thread From: Alan Third @ 2021-03-07 20:45 UTC (permalink / raw) To: Evgeny Zajcev; +Cc: emacs-devel 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 when using the "best" filter, but most other types of images look OK when using nearest. 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. 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. -- Alan Third ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-07 20:45 ` Alan Third @ 2021-03-07 22:35 ` Evgeny Zajcev 2021-03-07 23:27 ` Stefan Kangas 2021-03-08 13:27 ` Eli Zaretskii 2021-03-07 23:12 ` Stefan Monnier 1 sibling, 2 replies; 42+ messages in thread From: Evgeny Zajcev @ 2021-03-07 22:35 UTC (permalink / raw) To: Alan Third, Evgeny Zajcev, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1949 bytes --] вс, 7 мар. 2021 г. в 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? -- lg [-- Attachment #2: Type: text/html, Size: 3373 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-07 22:35 ` Evgeny Zajcev @ 2021-03-07 23:27 ` Stefan Kangas 2021-03-08 0:42 ` Evgeny Zajcev ` (2 more replies) 2021-03-08 13:27 ` Eli Zaretskii 1 sibling, 3 replies; 42+ messages in thread From: Stefan Kangas @ 2021-03-07 23:27 UTC (permalink / raw) To: Evgeny Zajcev, Alan Third, emacs-devel 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). > 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. Is there a way to convert from XPM automatically, or are you saying you volunteer to make the SVG:s? Another option would perhaps be to just replace the XPM:s we have with some set of emojis licensed under Creative Commons. The first one I found when searching online was this one: https://openmoji.org/ https://github.com/hfg-gmuend/openmoji/blob/master/FAQ.md Its license is Creative Commons Share Alike License 4.0 (CC BY-SA 4.0). That is okay for distributing with Emacs, I think? Or we could use some other set, I don't exactly care which one it is. If there is more than one candidate perhaps we could distribute more than one and add an option to choose between them. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-07 23:27 ` Stefan Kangas @ 2021-03-08 0:42 ` Evgeny Zajcev 2021-03-08 2:31 ` Stefan Kangas 2021-03-08 13:31 ` Eli Zaretskii 2021-03-08 18:58 ` Alan Third 2 siblings, 1 reply; 42+ messages in thread From: Evgeny Zajcev @ 2021-03-08 0:42 UTC (permalink / raw) To: Stefan Kangas; +Cc: Alan Third, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1889 bytes --] пн, 8 мар. 2021 г. в 02:27, Stefan Kangas <stefankangas@gmail.com>: > 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). > > > 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. > > Is there a way to convert from XPM automatically, or are you saying you > volunteer to make the SVG:s? > I can write the converter of course, however, there are already fonts with colored emojis with "SIL Open Font License" that might be used to get SVG emojis. Is that license suitable? Or keeping pixel art for old xpm's is crucial? Nowadays having emojis is easy as evaluating (set-fontset-font t 'symbol (font-spec :family "<font family with emojis>")) sexp, probably old packages (that uses emoji xpms) could be updated to use unicode emojis instead? > Another option would perhaps be to just replace the XPM:s we have with > some set of emojis licensed under Creative Commons. The first one I > found when searching online was this one: > > https://openmoji.org/ > https://github.com/hfg-gmuend/openmoji/blob/master/FAQ.md > > Its license is Creative Commons Share Alike License 4.0 (CC BY-SA 4.0). > That is okay for distributing with Emacs, I think? > > Or we could use some other set, I don't exactly care which one it is. > If there is more than one candidate perhaps we could distribute more > than one and add an option to choose between them. > -- lg [-- Attachment #2: Type: text/html, Size: 2808 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-08 0:42 ` Evgeny Zajcev @ 2021-03-08 2:31 ` Stefan Kangas 2021-03-08 13:34 ` Eli Zaretskii 0 siblings, 1 reply; 42+ messages in thread From: Stefan Kangas @ 2021-03-08 2:31 UTC (permalink / raw) To: Evgeny Zajcev; +Cc: Alan Third, emacs-devel Evgeny Zajcev <lg.zevlg@gmail.com> writes: >> Is there a way to convert from XPM automatically, or are you saying you >> volunteer to make the SVG:s? > > I can write the converter of course, however, there are already fonts with > colored emojis with "SIL Open Font License" that might be used to get SVG > emojis. Is that license suitable? Or keeping pixel art for old xpm's is > crucial? Why not both? IOW, why not begin by converting the XPM files to SVG, and then look into if we could use fonts instead? I think the SVG conversion would be useful in any case. IIUC, there should be no issue distributing fonts with Emacs for free operating systems but there might be some problems on some proprietary ones. If this is an insurmountable obstacle, those operating systems could just continue using the SVG, I suppose. And even if we can't distribute fonts with Emacs, perhaps we could detect when these fonts are installed and prefer them when they are? The SIL Open Font License 1.1 is fine: https://www.gnu.org/licenses/license-list.html#SILOFL ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-08 2:31 ` Stefan Kangas @ 2021-03-08 13:34 ` Eli Zaretskii 0 siblings, 0 replies; 42+ messages in thread From: Eli Zaretskii @ 2021-03-08 13:34 UTC (permalink / raw) To: Stefan Kangas; +Cc: alan, lg.zevlg, emacs-devel > From: Stefan Kangas <stefankangas@gmail.com> > Date: Sun, 7 Mar 2021 20:31:40 -0600 > Cc: Alan Third <alan@idiocy.org>, emacs-devel <emacs-devel@gnu.org> > > IIUC, there should be no issue distributing fonts with Emacs for free > operating systems but there might be some problems on some proprietary > ones. There's no technical problem with this, but installing a private font is not trivial on all systems, as you need to perform supporting steps, like update the font caches etc. I'd rather we avoided that. Also see my other message about the disadvantages of using emoji. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-07 23:27 ` Stefan Kangas 2021-03-08 0:42 ` Evgeny Zajcev @ 2021-03-08 13:31 ` Eli Zaretskii 2021-03-08 18:58 ` Alan Third 2 siblings, 0 replies; 42+ messages in thread From: Eli Zaretskii @ 2021-03-08 13:31 UTC (permalink / raw) To: Stefan Kangas; +Cc: alan, lg.zevlg, emacs-devel > From: Stefan Kangas <stefankangas@gmail.com> > Date: Sun, 7 Mar 2021 17:27:44 -0600 > > Another option would perhaps be to just replace the XPM:s we have with > some set of emojis licensed under Creative Commons. The disadvantage of using emoji is that you cannot have an icon for which there's no character in the Unicode database. I don't think it's wise for us to assume any icon we could ever want to show will always be available as an emoticon character. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-07 23:27 ` Stefan Kangas 2021-03-08 0:42 ` Evgeny Zajcev 2021-03-08 13:31 ` Eli Zaretskii @ 2021-03-08 18:58 ` Alan Third 2021-03-08 19:18 ` Lars Ingebrigtsen 2021-03-08 20:05 ` Evgeny Zajcev 2 siblings, 2 replies; 42+ messages in thread From: Alan Third @ 2021-03-08 18:58 UTC (permalink / raw) To: Stefan Kangas; +Cc: Evgeny Zajcev, emacs-devel 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. ;) Remove the ternary operator in this line (image.c:2372), and probably the one just below on line 2378 as well: XRenderSetPictureFilter (FRAME_X_DISPLAY (f), img->mask_picture, scale_down ? FilterBest : FilterNearest, 0, 0); > > 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. > > Is there a way to convert from XPM automatically, or are you saying you > volunteer to make the SVG:s? There are only 12 emoji XPMs, so trying to copy them directly into SVG would probably not take too much effort... They might not look very good, though. ;) -- Alan Third ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-08 18:58 ` Alan Third @ 2021-03-08 19:18 ` Lars Ingebrigtsen 2021-03-08 21:27 ` Alan Third 2021-03-08 20:05 ` Evgeny Zajcev 1 sibling, 1 reply; 42+ messages in thread From: Lars Ingebrigtsen @ 2021-03-08 19:18 UTC (permalink / raw) To: Alan Third; +Cc: Evgeny Zajcev, Stefan Kangas, emacs-devel Alan Third <alan@idiocy.org> writes: > 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. ;) The problem is that icons that are scaled up look like fuzzy messes when scaled up with "best", I think? But scaling up text does indeed look kinda bad when using the current method. Text images are usually large, while icons are usually small, so we could use some heuristic for switching between the methods. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-08 19:18 ` Lars Ingebrigtsen @ 2021-03-08 21:27 ` Alan Third 2021-03-08 21:31 ` Lars Ingebrigtsen 0 siblings, 1 reply; 42+ messages in thread From: Alan Third @ 2021-03-08 21:27 UTC (permalink / raw) To: Lars Ingebrigtsen, g; +Cc: Evgeny Zajcev, Stefan Kangas, emacs-devel On Mon, Mar 08, 2021 at 08:18:21PM +0100, Lars Ingebrigtsen wrote: > Alan Third <alan@idiocy.org> writes: > > > 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. ;) > > The problem is that icons that are scaled up look like fuzzy messes when > scaled up with "best", I think? But scaling up text does indeed look > kinda bad when using the current method. Indeed, and I doubt they look much better using good, either. > Text images are usually large, while icons are usually small, so we > could use some heuristic for switching between the methods. I don't know, I'd be inclined to go with adding an image option, like ":filter smooth" or ":filter nearest" and letting mode authors choose what they think is best. Although I can see that that won't help with the likes of eww where you just don't know what type of image you're loading. (Also, I think :filter may be taken, so perhaps just ":smooth t/nil" or something...) -- Alan Third ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-08 21:27 ` Alan Third @ 2021-03-08 21:31 ` Lars Ingebrigtsen 2021-03-08 21:59 ` Alan Third 0 siblings, 1 reply; 42+ messages in thread From: Lars Ingebrigtsen @ 2021-03-08 21:31 UTC (permalink / raw) To: Alan Third; +Cc: Evgeny Zajcev, Stefan Kangas, g, emacs-devel Alan Third <alan@idiocy.org> writes: > I don't know, I'd be inclined to go with adding an image option, like > ":filter smooth" or ":filter nearest" and letting mode authors choose > what they think is best. Yes, that's an excellent idea. > Although I can see that that won't help with the likes of eww where > you just don't know what type of image you're loading. Well, it'd be up to the application to add heuristics (if any). > (Also, I think :filter may be taken, so perhaps just ":smooth t/nil" > or something...) Sure. Or... :scaling-algorithm... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-08 21:31 ` Lars Ingebrigtsen @ 2021-03-08 21:59 ` Alan Third 2021-03-09 8:34 ` Evgeny Zajcev 0 siblings, 1 reply; 42+ messages in thread From: Alan Third @ 2021-03-08 21:59 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Evgeny Zajcev, Stefan Kangas, emacs-devel On Mon, Mar 08, 2021 at 10:31:16PM +0100, Lars Ingebrigtsen wrote: > Alan Third <alan@idiocy.org> writes: > > > I don't know, I'd be inclined to go with adding an image option, like > > ":filter smooth" or ":filter nearest" and letting mode authors choose > > what they think is best. > > Yes, that's an excellent idea. Not my idea, but certainly a good one. :) > > (Also, I think :filter may be taken, so perhaps just ":smooth t/nil" > > or something...) > > Sure. Or... :scaling-algorithm... I was wrong, :filter is available, I'll have a bit more of a think about what we want to call it. As for default behaviour, I'm inclined to stick with what we have where scaling down uses best and scaling up uses nearest neighbour but any use of :filter (or whatever) over-rides the default. Anyone have an opinion? Do we just want to use best everywhere by default? -- Alan Third ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-08 21:59 ` Alan Third @ 2021-03-09 8:34 ` Evgeny Zajcev 2021-03-09 9:28 ` Alan Third ` (2 more replies) 0 siblings, 3 replies; 42+ messages in thread From: Evgeny Zajcev @ 2021-03-09 8:34 UTC (permalink / raw) To: Alan Third, Lars Ingebrigtsen, Evgeny Zajcev, Stefan Kangas, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1091 bytes --] вт, 9 мар. 2021 г. в 00:59, Alan Third <alan@idiocy.org>: > On Mon, Mar 08, 2021 at 10:31:16PM +0100, Lars Ingebrigtsen wrote: > > Alan Third <alan@idiocy.org> writes: > > > > > I don't know, I'd be inclined to go with adding an image option, like > > > ":filter smooth" or ":filter nearest" and letting mode authors choose > > > what they think is best. > > > > Yes, that's an excellent idea. > > Not my idea, but certainly a good one. :) > > > > (Also, I think :filter may be taken, so perhaps just ":smooth t/nil" > > > or something...) > > > > Sure. Or... :scaling-algorithm... > > I was wrong, :filter is available, I'll have a bit more of a think > about what we want to call it. > > As for default behaviour, I'm inclined to stick with what we have > where scaling down uses best and scaling up uses nearest neighbour but > any use of :filter (or whatever) over-rides the default. Anyone have > an opinion? Do we just want to use best everywhere by default? > I vote for "best" everywhere by default, making doc-view shine out-of-box -- lg [-- Attachment #2: Type: text/html, Size: 1693 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 8:34 ` Evgeny Zajcev @ 2021-03-09 9:28 ` Alan Third 2021-03-09 9:46 ` Evgeny Zajcev 2021-03-09 14:16 ` Stefan Monnier 2021-03-09 13:09 ` Eli Zaretskii 2021-03-09 13:16 ` Lars Ingebrigtsen 2 siblings, 2 replies; 42+ messages in thread From: Alan Third @ 2021-03-09 9:28 UTC (permalink / raw) To: Evgeny Zajcev; +Cc: Lars Ingebrigtsen, Stefan Kangas, emacs-devel On Tue, Mar 09, 2021 at 11:34:28AM +0300, Evgeny Zajcev wrote: > вт, 9 мар. 2021 г. в 00:59, Alan Third <alan@idiocy.org>: > > > As for default behaviour, I'm inclined to stick with what we have > > where scaling down uses best and scaling up uses nearest neighbour but > > any use of :filter (or whatever) over-rides the default. Anyone have > > an opinion? Do we just want to use best everywhere by default? > > > > I vote for "best" everywhere by default, making doc-view shine out-of-box This might be a stupid question, but would it not make more sense to teach doc-view to generate images that are the correct resolution already? That would make it look much better than any scaling option. -- Alan Third ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 9:28 ` Alan Third @ 2021-03-09 9:46 ` Evgeny Zajcev 2021-03-09 14:16 ` Stefan Monnier 1 sibling, 0 replies; 42+ messages in thread From: Evgeny Zajcev @ 2021-03-09 9:46 UTC (permalink / raw) To: Alan Third, Evgeny Zajcev, Lars Ingebrigtsen, Stefan Kangas, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1151 bytes --] вт, 9 мар. 2021 г. в 12:28, Alan Third <alan@idiocy.org>: > On Tue, Mar 09, 2021 at 11:34:28AM +0300, Evgeny Zajcev wrote: > > вт, 9 мар. 2021 г. в 00:59, Alan Third <alan@idiocy.org>: > > > > > As for default behaviour, I'm inclined to stick with what we have > > > where scaling down uses best and scaling up uses nearest neighbour but > > > any use of :filter (or whatever) over-rides the default. Anyone have > > > an opinion? Do we just want to use best everywhere by default? > > > > > > > I vote for "best" everywhere by default, making doc-view shine out-of-box > > This might be a stupid question, but would it not make more sense to > teach doc-view to generate images that are the correct resolution > already? That would make it look much better than any scaling option. > This will involve many tricks to be added, doc-view uses image-mode to view the image, and user can change (enlarge) window size at any moment, so doc-view must add some handlings for that to regenerate/redisplay images. Also using larger images makes things slower, then just applying scale filter at display time. -- lg [-- Attachment #2: Type: text/html, Size: 1670 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 9:28 ` Alan Third 2021-03-09 9:46 ` Evgeny Zajcev @ 2021-03-09 14:16 ` Stefan Monnier 1 sibling, 0 replies; 42+ messages in thread From: Stefan Monnier @ 2021-03-09 14:16 UTC (permalink / raw) To: Alan Third; +Cc: Lars Ingebrigtsen, Evgeny Zajcev, Stefan Kangas, emacs-devel > This might be a stupid question, but would it not make more sense to > teach doc-view to generate images that are the correct resolution > already? That would make it look much better than any scaling option. It does already, in most circumstances. There are cases where we use scaling, tho [ can't remember when or why, sorry. ] Stefan ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 8:34 ` Evgeny Zajcev 2021-03-09 9:28 ` Alan Third @ 2021-03-09 13:09 ` Eli Zaretskii 2021-03-09 13:48 ` Evgeny Zajcev 2021-03-09 13:59 ` Lars Ingebrigtsen 2021-03-09 13:16 ` Lars Ingebrigtsen 2 siblings, 2 replies; 42+ messages in thread From: Eli Zaretskii @ 2021-03-09 13:09 UTC (permalink / raw) To: Evgeny Zajcev; +Cc: alan, emacs-devel, lg.zevlg, larsi, stefankangas > From: Evgeny Zajcev <lg.zevlg@gmail.com> > Date: Tue, 9 Mar 2021 11:34:28 +0300 > > I vote for "best" everywhere by default, making doc-view shine out-of-box IME, doing this will make sure we will have this discussion again in the near future, when someone will report that "best" is not really the best in some use case dear to them. I don't understand why we are still arguing instead of adding a variable or an attribute to control this? From where I stand, it's a no-brainer. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 13:09 ` Eli Zaretskii @ 2021-03-09 13:48 ` Evgeny Zajcev 2021-03-09 13:59 ` Lars Ingebrigtsen 1 sibling, 0 replies; 42+ messages in thread From: Evgeny Zajcev @ 2021-03-09 13:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, emacs-devel, Lars Ingebrigtsen, Stefan Kangas [-- Attachment #1: Type: text/plain, Size: 678 bytes --] вт, 9 мар. 2021 г. в 16:09, Eli Zaretskii <eliz@gnu.org>: > > From: Evgeny Zajcev <lg.zevlg@gmail.com> > > Date: Tue, 9 Mar 2021 11:34:28 +0300 > > > > I vote for "best" everywhere by default, making doc-view shine out-of-box > > IME, doing this will make sure we will have this discussion again in > the near future, when someone will report that "best" is not really > the best in some use case dear to them. > > I don't understand why we are still arguing instead of adding a > variable or an attribute to control this? From where I stand, it's a > no-brainer. > Yeah, any default value is ok if we have control over the scaling filter. -- lg [-- Attachment #2: Type: text/html, Size: 1175 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 13:09 ` Eli Zaretskii 2021-03-09 13:48 ` Evgeny Zajcev @ 2021-03-09 13:59 ` Lars Ingebrigtsen 2021-03-09 16:37 ` Eli Zaretskii 1 sibling, 1 reply; 42+ messages in thread From: Lars Ingebrigtsen @ 2021-03-09 13:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alan, Evgeny Zajcev, stefankangas, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > I don't understand why we are still arguing instead of adding a > variable or an attribute to control this? From where I stand, it's a > no-brainer. There's no single value that will give good results in all cases. Adding a variable to control the default is all well and good, but it's not sufficient. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 13:59 ` Lars Ingebrigtsen @ 2021-03-09 16:37 ` Eli Zaretskii 2021-03-09 17:04 ` Lars Ingebrigtsen 0 siblings, 1 reply; 42+ messages in thread From: Eli Zaretskii @ 2021-03-09 16:37 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: alan, lg.zevlg, stefankangas, emacs-devel > From: Lars Ingebrigtsen <larsi@gnus.org> > Date: Tue, 09 Mar 2021 14:59:04 +0100 > Cc: alan@idiocy.org, Evgeny Zajcev <lg.zevlg@gmail.com>, stefankangas@gmail.com, > emacs-devel@gnu.org > > Eli Zaretskii <eliz@gnu.org> writes: > > > I don't understand why we are still arguing instead of adding a > > variable or an attribute to control this? From where I stand, it's a > > no-brainer. > > There's no single value that will give good results in all cases. > Adding a variable to control the default is all well and good, but it's > not sufficient. Neither a variable nor an image attribute? (I suggested both.) Then what would you suggest to do to resolve this? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 16:37 ` Eli Zaretskii @ 2021-03-09 17:04 ` Lars Ingebrigtsen 2021-03-09 18:01 ` Eli Zaretskii 2021-03-10 4:23 ` Yuri Khan 0 siblings, 2 replies; 42+ messages in thread From: Lars Ingebrigtsen @ 2021-03-09 17:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alan, lg.zevlg, stefankangas, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> There's no single value that will give good results in all cases. >> Adding a variable to control the default is all well and good, but it's >> not sufficient. > > Neither a variable nor an image attribute? (I suggested both.) Then > what would you suggest to do to resolve this? Sorry; missed that you also mentioned an image attribute, which would be fine. Thinking a bit more about this, I wonder whether a general solution is kinda-sorta possible anyway. That is, having a function that returns what algorithm to use. We normally want shrinking the image to always use `best', and enlarging an image slightly to use `good' or `best' (that's the issue with doc-view, I think? we're rendering at one size and then enlarging it on HiDPI screens? I haven't actually debugged it), and enlarging more than (say) 3x in size to use nearest neighbour... Having a variable (that can be a function that returns the algo to use, or be one of the symbols) would allow us to experiment with this more easily and see whether we can come up with something that works for most people out of the box. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 17:04 ` Lars Ingebrigtsen @ 2021-03-09 18:01 ` Eli Zaretskii 2021-03-10 4:23 ` Yuri Khan 1 sibling, 0 replies; 42+ messages in thread From: Eli Zaretskii @ 2021-03-09 18:01 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: alan, lg.zevlg, stefankangas, emacs-devel > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: alan@idiocy.org, lg.zevlg@gmail.com, stefankangas@gmail.com, > emacs-devel@gnu.org > Date: Tue, 09 Mar 2021 18:04:59 +0100 > > Thinking a bit more about this, I wonder whether a general solution is > kinda-sorta possible anyway. That is, having a function that returns > what algorithm to use. We normally want shrinking the image to always > use `best', and enlarging an image slightly to use `good' or `best' > (that's the issue with doc-view, I think? we're rendering at one size > and then enlarging it on HiDPI screens? I haven't actually debugged > it), and enlarging more than (say) 3x in size to use nearest > neighbour... > > Having a variable (that can be a function that returns the algo to > use, or be one of the symbols) would allow us to experiment with this > more easily and see whether we can come up with something that works for > most people out of the box. If we can DTRT in most cases by default, we should, of course. I was under the impression that the "best" choice depended on what people did with images most of the time and on personal preferences. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 17:04 ` Lars Ingebrigtsen 2021-03-09 18:01 ` Eli Zaretskii @ 2021-03-10 4:23 ` Yuri Khan 2021-03-10 14:44 ` Lars Ingebrigtsen 1 sibling, 1 reply; 42+ messages in thread From: Yuri Khan @ 2021-03-10 4:23 UTC (permalink / raw) To: Lars Ingebrigtsen Cc: Eli Zaretskii, Emacs developers, lg.zevlg, Alan Third, Stefan Kangas On Wed, 10 Mar 2021 at 02:32, Lars Ingebrigtsen <larsi@gnus.org> wrote: > Thinking a bit more about this, I wonder whether a general solution is > kinda-sorta possible anyway. That is, having a function that returns > what algorithm to use. We normally want shrinking the image to always > use `best', and enlarging an image slightly to use `good' or `best' > (that's the issue with doc-view, I think? we're rendering at one size > and then enlarging it on HiDPI screens? I haven't actually debugged > it), and enlarging more than (say) 3x in size to use nearest > neighbour... Nearest-neighbor scaling when enlarging by exactly 2x feels very good, too. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-10 4:23 ` Yuri Khan @ 2021-03-10 14:44 ` Lars Ingebrigtsen 0 siblings, 0 replies; 42+ messages in thread From: Lars Ingebrigtsen @ 2021-03-10 14:44 UTC (permalink / raw) To: Yuri Khan Cc: Eli Zaretskii, Emacs developers, lg.zevlg, Alan Third, Stefan Kangas Yuri Khan <yuri.v.khan@gmail.com> writes: > Nearest-neighbor scaling when enlarging by exactly 2x feels very good, too. Yup. I guess all integer scaling might be better without blurring, even if some things may look a bit odd. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 8:34 ` Evgeny Zajcev 2021-03-09 9:28 ` Alan Third 2021-03-09 13:09 ` Eli Zaretskii @ 2021-03-09 13:16 ` Lars Ingebrigtsen 2021-03-09 13:50 ` Dov Grobgeld 2021-03-09 18:12 ` Alan Third 2 siblings, 2 replies; 42+ messages in thread From: Lars Ingebrigtsen @ 2021-03-09 13:16 UTC (permalink / raw) To: Evgeny Zajcev; +Cc: Alan Third, Stefan Kangas, emacs-devel Evgeny Zajcev <lg.zevlg@gmail.com> writes: > I vote for "best" everywhere by default, making doc-view shine out-of-box doc-view can call create-image with :filter 'best, so what's best for doc-view is pretty much irrelevant as to what the default should be. The current default works pretty well for most images (just not on text), so I think it makes sense to not change the default. (And, as Alan pointed out, doc-view really should be smarter about this stuff, and render the PDF in the size it's going to be displayed at.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 13:16 ` Lars Ingebrigtsen @ 2021-03-09 13:50 ` Dov Grobgeld 2021-03-09 18:16 ` Alan Third 2021-03-09 18:12 ` Alan Third 1 sibling, 1 reply; 42+ messages in thread From: Dov Grobgeld @ 2021-03-09 13:50 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Alan Third, Evgeny Zajcev, Stefan Kangas, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1070 bytes --] Note that there are various smart algorithms for bitmap to contour (svg) tracing. E.g. http://potrace.sourceforge.net/ But there are others. One idea would be to use potrace for "small" images and pixel interpolation (or nearest neighbor) for large images. The specification for small and large should be settable by the user. On Tue, Mar 9, 2021 at 3:30 PM Lars Ingebrigtsen <larsi@gnus.org> wrote: > Evgeny Zajcev <lg.zevlg@gmail.com> writes: > > > I vote for "best" everywhere by default, making doc-view shine out-of-box > > doc-view can call create-image with :filter 'best, so what's best for > doc-view is pretty much irrelevant as to what the default should be. > > The current default works pretty well for most images (just not on > text), so I think it makes sense to not change the default. > > (And, as Alan pointed out, doc-view really should be smarter about this > stuff, and render the PDF in the size it's going to be displayed at.) > > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no > > [-- Attachment #2: Type: text/html, Size: 2107 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 13:50 ` Dov Grobgeld @ 2021-03-09 18:16 ` Alan Third 0 siblings, 0 replies; 42+ messages in thread From: Alan Third @ 2021-03-09 18:16 UTC (permalink / raw) To: Dov Grobgeld; +Cc: Lars Ingebrigtsen, Evgeny Zajcev, Stefan Kangas, emacs-devel On Tue, Mar 09, 2021 at 03:50:08PM +0200, Dov Grobgeld wrote: > Note that there are various smart algorithms for bitmap to contour (svg) > tracing. E.g. > > http://potrace.sourceforge.net/ > > But there are others. One idea would be to use potrace for "small" images > and pixel interpolation (or nearest neighbor) for large images. The > specification for small and large should be settable by the user. Unfortunately this is when using the (hopefully) hardware accelerated image transforms, so we're stuck with what the system gives us. -- Alan Third ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 13:16 ` Lars Ingebrigtsen 2021-03-09 13:50 ` Dov Grobgeld @ 2021-03-09 18:12 ` Alan Third 2021-03-09 22:31 ` Basil L. Contovounesios 2021-03-10 14:49 ` Lars Ingebrigtsen 1 sibling, 2 replies; 42+ messages in thread From: Alan Third @ 2021-03-09 18:12 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Evgeny Zajcev, Stefan Kangas, emacs-devel [-- Attachment #1: Type: text/plain, Size: 887 bytes --] On Tue, Mar 09, 2021 at 02:16:43PM +0100, Lars Ingebrigtsen wrote: > Evgeny Zajcev <lg.zevlg@gmail.com> writes: > > > I vote for "best" everywhere by default, making doc-view shine out-of-box > > doc-view can call create-image with :filter 'best, so what's best for > doc-view is pretty much irrelevant as to what the default should be. > > The current default works pretty well for most images (just not on > text), so I think it makes sense to not change the default. Attached is a patch that should allow us to set smoothing using ":transform-smoothing t", or nil to disable it and use nearest neighbour. Also sm in image mode lets you set it directly, and doc-view will always use it. I'm not sure about the term "smoothing", but it seemed better than filter or similar. I dunno. Anyway, it needs a news entry and documentation written, but I'll do that later. -- Alan Third [-- Attachment #2: 0001-Enable-selectable-image-smoothing-bug-38394.patch --] [-- Type: text/plain, Size: 6800 bytes --] From 62e13bfaa703bb1b19a3c170ca13a7cfe544c97b Mon Sep 17 00:00:00 2001 From: Alan Third <alan@idiocy.org> Date: Tue, 9 Mar 2021 18:05:10 +0000 Subject: [PATCH] Enable selectable image smoothing (bug#38394) * lisp/doc-view.el (doc-view-insert-image): Always use smoothing in docview. * lisp/image-mode.el (image-transform-smoothing): New variable. (image-mode-map): Add smoothing binding. (image-transform-properties): Apply smoothing when requested. (image-transform-set-smoothing): New function. (image-transform-reset): Reset smoothing. * src/image.c (image_set_transform): Use new :transform-smoothing attribute. (syms_of_image): Add :transform-smoothing attribute. --- lisp/doc-view.el | 2 ++ lisp/image-mode.el | 20 ++++++++++++++++++-- src/image.c | 16 +++++++++++----- 3 files changed, 31 insertions(+), 7 deletions(-) diff --git a/lisp/doc-view.el b/lisp/doc-view.el index f6fcfae453..cef09009d9 100644 --- a/lisp/doc-view.el +++ b/lisp/doc-view.el @@ -1439,6 +1439,8 @@ doc-view-insert-image (apply #'create-image file doc-view--image-type nil args) (unless (member :width args) (setq args `(,@args :width ,doc-view-image-width))) + (unless (member :transform-smoothing args) + (setq args `(,@args :transform-smoothing t))) (apply #'create-image file doc-view--image-type nil args)))) (slice (doc-view-current-slice)) (img-width (and image (car (image-size image)))) diff --git a/lisp/image-mode.el b/lisp/image-mode.el index 7384abf3b2..ba3f104f1e 100644 --- a/lisp/image-mode.el +++ b/lisp/image-mode.el @@ -95,6 +95,9 @@ image-transform-scale (defvar-local image-transform-rotation 0.0 "Rotation angle for the image in the current Image mode buffer.") +(defvar-local image-transform-smoothing nil + "Whether to use transform smoothing.") + (defvar image-transform-right-angle-fudge 0.0001 "Snap distance to a multiple of a right angle. There's no deep theory behind the default value, it should just @@ -457,6 +460,7 @@ image-mode-map (define-key map "sb" 'image-transform-fit-both) (define-key map "ss" 'image-transform-set-scale) (define-key map "sr" 'image-transform-set-rotation) + (define-key map "sm" 'image-transform-set-smoothing) (define-key map "so" 'image-transform-original) (define-key map "s0" 'image-transform-reset) @@ -523,6 +527,8 @@ image-mode-map :help "Rotate the image"] ["Set Rotation..." image-transform-set-rotation :help "Set rotation angle of the image"] + ["Set Smoothing..." image-transform-set-smoothing + :help "Toggle smoothing"] ["Original Size" image-transform-original :help "Reset image to actual size"] ["Reset to Default Size" image-transform-reset @@ -1474,7 +1480,10 @@ image-transform-properties ,@(when (cdr resized) (list :height (cdr resized))) ,@(unless (= 0.0 image-transform-rotation) - (list :rotation image-transform-rotation)))))) + (list :rotation image-transform-rotation)) + ,@(when image-transform-smoothing + (list :transform-smoothing + (string= image-transform-smoothing "smooth"))))))) (defun image-transform-set-scale (scale) "Prompt for a number, and resize the current image by that amount." @@ -1507,6 +1516,12 @@ image-transform-set-rotation (setq image-transform-rotation (float (mod rotation 360))) (image-toggle-display-image)) +(defun image-transform-set-smoothing (smoothing) + (interactive (list (completing-read "Smoothing: " + '(none smooth) nil t))) + (setq image-transform-smoothing smoothing) + (image-toggle-display-image)) + (defun image-transform-original () "Display the current image with the original (actual) size and rotation." (interactive) @@ -1519,7 +1534,8 @@ image-transform-reset (interactive) (setq image-transform-resize image-auto-resize image-transform-rotation 0.0 - image-transform-scale 1) + image-transform-scale 1 + image-transform-smoothing nil) (image-toggle-display-image)) (provide 'image-mode) diff --git a/src/image.c b/src/image.c index 8137dbea8d..95ae573354 100644 --- a/src/image.c +++ b/src/image.c @@ -2230,7 +2230,12 @@ image_set_transform (struct frame *f, struct image *img) operations to use a blended filter, to avoid aliasing and the like. TODO: implement for Windows. */ - bool scale_down = (width < img->width) || (height < img->height); + bool smoothing; + Lisp_Object s = image_spec_value (img->spec, QCtransform_smoothing, NULL); + if (!s) + smoothing = (width < img->width) || (height < img->height); + else + smoothing = !NILP (s); # endif /* Perform scale transformation. */ @@ -2344,13 +2349,13 @@ image_set_transform (struct frame *f, struct image *img) /* Under NS the transform is applied to the drawing surface at drawing time, so store it for later. */ ns_image_set_transform (img->pixmap, matrix); - ns_image_set_smoothing (img->pixmap, scale_down); + ns_image_set_smoothing (img->pixmap, smoothing); # elif defined USE_CAIRO cairo_matrix_t cr_matrix = {matrix[0][0], matrix[0][1], matrix[1][0], matrix[1][1], matrix[2][0], matrix[2][1]}; cairo_pattern_t *pattern = cairo_pattern_create_rgb (0, 0, 0); cairo_pattern_set_matrix (pattern, &cr_matrix); - cairo_pattern_set_filter (pattern, scale_down + cairo_pattern_set_filter (pattern, smoothing ? CAIRO_FILTER_BEST : CAIRO_FILTER_NEAREST); /* Dummy solid color pattern just to record pattern matrix. */ img->cr_data = pattern; @@ -2369,13 +2374,13 @@ image_set_transform (struct frame *f, struct image *img) XDoubleToFixed (matrix[2][2])}}}; XRenderSetPictureFilter (FRAME_X_DISPLAY (f), img->picture, - scale_down ? FilterBest : FilterNearest, 0, 0); + smoothing ? FilterBest : FilterNearest, 0, 0); XRenderSetPictureTransform (FRAME_X_DISPLAY (f), img->picture, &tmat); if (img->mask_picture) { XRenderSetPictureFilter (FRAME_X_DISPLAY (f), img->mask_picture, - scale_down ? FilterBest : FilterNearest, 0, 0); + smoothing ? FilterBest : FilterNearest, 0, 0); XRenderSetPictureTransform (FRAME_X_DISPLAY (f), img->mask_picture, &tmat); } @@ -10693,6 +10698,7 @@ syms_of_image (void) DEFSYM (QCrotation, ":rotation"); DEFSYM (QCmatrix, ":matrix"); DEFSYM (QCscale, ":scale"); + DEFSYM (QCtransform_smoothing, ":transform-smoothing"); DEFSYM (QCcolor_adjustment, ":color-adjustment"); DEFSYM (QCmask, ":mask"); -- 2.29.2 ^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 18:12 ` Alan Third @ 2021-03-09 22:31 ` Basil L. Contovounesios 2021-03-09 23:59 ` Stefan Monnier 2021-03-10 13:37 ` Alan Third 2021-03-10 14:49 ` Lars Ingebrigtsen 1 sibling, 2 replies; 42+ messages in thread From: Basil L. Contovounesios @ 2021-03-09 22:31 UTC (permalink / raw) To: Alan Third; +Cc: Lars Ingebrigtsen, Evgeny Zajcev, Stefan Kangas, emacs-devel Alan Third <alan@idiocy.org> writes: > Attached is a patch that should allow us to set smoothing using > ":transform-smoothing t", or nil to disable it and use nearest > neighbour. Also sm in image mode lets you set it directly, and > doc-view will always use it. Thanks, just one nit/question from me: > +(defun image-transform-set-smoothing (smoothing) > + (interactive (list (completing-read "Smoothing: " > + '(none smooth) nil t))) I know that completing-read can handle a list of symbols, but its documentation says only list of strings. Who's right? Do we care? -- Basil ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 22:31 ` Basil L. Contovounesios @ 2021-03-09 23:59 ` Stefan Monnier 2021-03-10 13:37 ` Alan Third 1 sibling, 0 replies; 42+ messages in thread From: Stefan Monnier @ 2021-03-09 23:59 UTC (permalink / raw) To: Basil L. Contovounesios Cc: Alan Third, emacs-devel, Evgeny Zajcev, Lars Ingebrigtsen, Stefan Kangas > I know that completing-read can handle a list of symbols, but its > documentation says only list of strings. Who's right? Do we care? IIRC what it officially supports are lists of strings and alists whose keys are strings or symbols. The way the code is implemented, it mostly works with lists of symbols as well, tho expect breakage if your first symbol happens to be `lambda` or `closure`. Stefan ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 22:31 ` Basil L. Contovounesios 2021-03-09 23:59 ` Stefan Monnier @ 2021-03-10 13:37 ` Alan Third 1 sibling, 0 replies; 42+ messages in thread From: Alan Third @ 2021-03-10 13:37 UTC (permalink / raw) To: Basil L. Contovounesios Cc: Lars Ingebrigtsen, Evgeny Zajcev, Stefan Kangas, emacs-devel On Tue, Mar 09, 2021 at 10:31:29PM +0000, Basil L. Contovounesios wrote: > Alan Third <alan@idiocy.org> writes: > > > +(defun image-transform-set-smoothing (smoothing) > > + (interactive (list (completing-read "Smoothing: " > > + '(none smooth) nil t))) > > I know that completing-read can handle a list of symbols, but its > documentation says only list of strings. Who's right? Do we care? I've changed them to strings. Thanks. -- Alan Third ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-09 18:12 ` Alan Third 2021-03-09 22:31 ` Basil L. Contovounesios @ 2021-03-10 14:49 ` Lars Ingebrigtsen 2021-03-10 21:45 ` Alan Third 1 sibling, 1 reply; 42+ messages in thread From: Lars Ingebrigtsen @ 2021-03-10 14:49 UTC (permalink / raw) To: Alan Third; +Cc: Evgeny Zajcev, Stefan Kangas, emacs-devel Alan Third <alan@idiocy.org> writes: > Attached is a patch that should allow us to set smoothing using > ":transform-smoothing t", or nil to disable it and use nearest > neighbour. Also sm in image mode lets you set it directly, and > doc-view will always use it. > > I'm not sure about the term "smoothing", but it seemed better than > filter or similar. I dunno. Sounds good to me, and the patch looks good to me, too. We should probably introduce something like the defcustom I described elsewhere in this thread, and use it in `create-image' by default, so that downscaling images will still use smoothing. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-10 14:49 ` Lars Ingebrigtsen @ 2021-03-10 21:45 ` Alan Third 2021-03-11 16:53 ` Lars Ingebrigtsen 2021-03-12 1:38 ` Lars Ingebrigtsen 0 siblings, 2 replies; 42+ messages in thread From: Alan Third @ 2021-03-10 21:45 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Evgeny Zajcev, Stefan Kangas, emacs-devel On Wed, Mar 10, 2021 at 03:49:49PM +0100, Lars Ingebrigtsen wrote: > Alan Third <alan@idiocy.org> writes: > > > Attached is a patch that should allow us to set smoothing using > > ":transform-smoothing t", or nil to disable it and use nearest > > neighbour. Also sm in image mode lets you set it directly, and > > doc-view will always use it. > > > > I'm not sure about the term "smoothing", but it seemed better than > > filter or similar. I dunno. > > Sounds good to me, and the patch looks good to me, too. I've pushed it to master as c93447eac6f801d7ff97ed6dad368dc49d55cc46. > We should probably introduce something like the defcustom I described > elsewhere in this thread, and use it in `create-image' by default, so > that downscaling images will still use smoothing. I like this idea, but I felt somewhat out of my depth trying to implement it. -- Alan Third ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-10 21:45 ` Alan Third @ 2021-03-11 16:53 ` Lars Ingebrigtsen 2021-03-12 1:38 ` Lars Ingebrigtsen 1 sibling, 0 replies; 42+ messages in thread From: Lars Ingebrigtsen @ 2021-03-11 16:53 UTC (permalink / raw) To: Alan Third; +Cc: Evgeny Zajcev, Stefan Kangas, emacs-devel Alan Third <alan@idiocy.org> writes: >> We should probably introduce something like the defcustom I described >> elsewhere in this thread, and use it in `create-image' by default, so >> that downscaling images will still use smoothing. > > I like this idea, but I felt somewhat out of my depth trying to > implement it. OK; I'll take a stab at it. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-10 21:45 ` Alan Third 2021-03-11 16:53 ` Lars Ingebrigtsen @ 2021-03-12 1:38 ` Lars Ingebrigtsen 2021-03-12 2:01 ` Evgeny Zajcev 2021-03-12 18:32 ` Alan Third 1 sibling, 2 replies; 42+ messages in thread From: Lars Ingebrigtsen @ 2021-03-12 1:38 UTC (permalink / raw) To: Alan Third; +Cc: Evgeny Zajcev, Stefan Kangas, emacs-devel Alan Third <alan@idiocy.org> writes: > I like this idea, but I felt somewhat out of my depth trying to > implement it. Now pushed to Emacs 28. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-12 1:38 ` Lars Ingebrigtsen @ 2021-03-12 2:01 ` Evgeny Zajcev 2021-03-12 18:32 ` Alan Third 1 sibling, 0 replies; 42+ messages in thread From: Evgeny Zajcev @ 2021-03-12 2:01 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Alan Third, Stefan Kangas, emacs-devel [-- Attachment #1: Type: text/plain, Size: 338 bytes --] пт, 12 мар. 2021 г. в 04:38, Lars Ingebrigtsen <larsi@gnus.org>: > Alan Third <alan@idiocy.org> writes: > > > I like this idea, but I felt somewhat out of my depth trying to > > implement it. > > Now pushed to Emacs 28. > Thanks, works like a charm! Very useful feature, thanks all you guys for the work! -- lg [-- Attachment #2: Type: text/html, Size: 784 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-12 1:38 ` Lars Ingebrigtsen 2021-03-12 2:01 ` Evgeny Zajcev @ 2021-03-12 18:32 ` Alan Third 1 sibling, 0 replies; 42+ messages in thread From: Alan Third @ 2021-03-12 18:32 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Evgeny Zajcev, Stefan Kangas, emacs-devel On Fri, Mar 12, 2021 at 02:38:33AM +0100, Lars Ingebrigtsen wrote: > Alan Third <alan@idiocy.org> writes: > > > I like this idea, but I felt somewhat out of my depth trying to > > implement it. > > Now pushed to Emacs 28. Excellent. Thanks, Lars. -- Alan Third ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-08 18:58 ` Alan Third 2021-03-08 19:18 ` Lars Ingebrigtsen @ 2021-03-08 20:05 ` Evgeny Zajcev 2021-03-08 21:29 ` Alan Third 1 sibling, 1 reply; 42+ messages in thread From: Evgeny Zajcev @ 2021-03-08 20:05 UTC (permalink / raw) To: Alan Third, Stefan Kangas, Evgeny Zajcev, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-08 20:05 ` Evgeny Zajcev @ 2021-03-08 21:29 ` Alan Third 0 siblings, 0 replies; 42+ messages in thread From: Alan Third @ 2021-03-08 21:29 UTC (permalink / raw) To: Evgeny Zajcev; +Cc: Stefan Kangas, emacs-devel On Mon, Mar 08, 2021 at 11:05:29PM +0300, Evgeny Zajcev wrote: > > BEST looks even better then good - > http://lgarc.narod.ru/pics/upscaled-best.png I suppose we shouldn't really be surprised. ;) Good to know though. Thanks for checking. > 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 I think we'd need to do it for pbms and pngs as well. The list may grow endlessly. I prefer the other idea of providing an option to whoever is loading the image. -- Alan Third ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-07 22:35 ` Evgeny Zajcev 2021-03-07 23:27 ` Stefan Kangas @ 2021-03-08 13:27 ` Eli Zaretskii 1 sibling, 0 replies; 42+ messages in thread From: Eli Zaretskii @ 2021-03-08 13:27 UTC (permalink / raw) To: Evgeny Zajcev; +Cc: alan, lg.zevlg, emacs-devel > From: Evgeny Zajcev <lg.zevlg@gmail.com> > Date: Mon, 8 Mar 2021 01:35:50 +0300 > > Or maybe we can make the transformation filter configurable, so it could be changed from elisp side? That is probably the best way out of this conundrum. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Image transformation filter for upscaled images 2021-03-07 20:45 ` Alan Third 2021-03-07 22:35 ` Evgeny Zajcev @ 2021-03-07 23:12 ` Stefan Monnier 1 sibling, 0 replies; 42+ messages in thread From: Stefan Monnier @ 2021-03-07 23:12 UTC (permalink / raw) To: Alan Third; +Cc: Evgeny Zajcev, emacs-devel > 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 when using > the "best" filter, but most other types of images look OK when using > nearest. 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. > > 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. FWIW, I think there is no perfect solution, and I'm not sure it's worth the trouble to give much control to the end user. So I'd go for the solution which minimizes the frequency of terrible results. I'd vote for "good" (my experience is mostly with doc-view where I've found the current "nearest" to be rather poor), but it's not a strong vote. Stefan ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2021-03-12 18:32 UTC | newest] Thread overview: 42+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-03-07 19:12 Image transformation filter for upscaled images Evgeny Zajcev 2021-03-07 20:45 ` Alan Third 2021-03-07 22:35 ` Evgeny Zajcev 2021-03-07 23:27 ` Stefan Kangas 2021-03-08 0:42 ` Evgeny Zajcev 2021-03-08 2:31 ` Stefan Kangas 2021-03-08 13:34 ` Eli Zaretskii 2021-03-08 13:31 ` Eli Zaretskii 2021-03-08 18:58 ` Alan Third 2021-03-08 19:18 ` Lars Ingebrigtsen 2021-03-08 21:27 ` Alan Third 2021-03-08 21:31 ` Lars Ingebrigtsen 2021-03-08 21:59 ` Alan Third 2021-03-09 8:34 ` Evgeny Zajcev 2021-03-09 9:28 ` Alan Third 2021-03-09 9:46 ` Evgeny Zajcev 2021-03-09 14:16 ` Stefan Monnier 2021-03-09 13:09 ` Eli Zaretskii 2021-03-09 13:48 ` Evgeny Zajcev 2021-03-09 13:59 ` Lars Ingebrigtsen 2021-03-09 16:37 ` Eli Zaretskii 2021-03-09 17:04 ` Lars Ingebrigtsen 2021-03-09 18:01 ` Eli Zaretskii 2021-03-10 4:23 ` Yuri Khan 2021-03-10 14:44 ` Lars Ingebrigtsen 2021-03-09 13:16 ` Lars Ingebrigtsen 2021-03-09 13:50 ` Dov Grobgeld 2021-03-09 18:16 ` Alan Third 2021-03-09 18:12 ` Alan Third 2021-03-09 22:31 ` Basil L. Contovounesios 2021-03-09 23:59 ` Stefan Monnier 2021-03-10 13:37 ` Alan Third 2021-03-10 14:49 ` Lars Ingebrigtsen 2021-03-10 21:45 ` Alan Third 2021-03-11 16:53 ` Lars Ingebrigtsen 2021-03-12 1:38 ` Lars Ingebrigtsen 2021-03-12 2:01 ` Evgeny Zajcev 2021-03-12 18:32 ` Alan Third 2021-03-08 20:05 ` Evgeny Zajcev 2021-03-08 21:29 ` Alan Third 2021-03-08 13:27 ` Eli Zaretskii 2021-03-07 23:12 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).