Bug 270980 - Option to interpolate instead of pixellate at > 100% zoom levels
Summary: Option to interpolate instead of pixellate at > 100% zoom levels
Status: RESOLVED FIXED
Alias: None
Product: gwenview
Classification: Applications
Component: general (show other bugs)
Version: 2.6
Platform: Ubuntu Linux
: NOR wishlist with 30 votes (vote)
Target Milestone: ---
Assignee: Gwenview Bugs
URL:
Keywords:
: 171377 193886 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-04-14 20:16 UTC by Thomas Damgaard
Modified: 2018-04-25 06:51 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Damgaard 2011-04-14 20:16:02 UTC
Version:           2.6 (using KDE 4.6.2) 
OS:                Linux

When zooming in on a picture in gwenview the picture quickly becomes pixelated. This is not the case for other viewers such as gqview, okular, several Mac and Windows viewers.


Screenshot illustrating the difference between gqview and gwenview: http://i.imgur.com/JE7rH.png

I know that gwenview's "naive" zooming is closer to the original, however, it should be possible to configure this. If you are viewing photos, you probably just want to see what is most aesthetical, however, if you are a graphics designer  working on an image, you probably want to see the exact image.


Reproducible: Always

Steps to Reproduce:
Open an image and zoom in.


Actual Results:  
Pixelated image.

Expected Results:  
Smooth image.
Comment 1 Christoph Feck 2011-04-19 22:05:58 UTC
> exact image

Right, not interpolating pixels is more exact than trying to compute information that isn't there.

Gwenview, as an image viewer, is designed to favor speed over image quality. Photos generally are not smaller than screen resolution, so if you zoom in that far, you likely do it because you want to see the pixels. I cannot think of any other reason to zoom in beyond the native resolution. But maybe you can enlighten me :)
Comment 2 Thomas Damgaard 2011-04-28 14:43:57 UTC
> Gwenview, as an image viewer, is designed to favor speed over image quality.

Really? I cannot find any mention of this on the Gwenview website. Is this a stated goal of Gwenview?  If so, does KDE have an image viewer designed with  viewing quality in mind?

Also, I cannot see why the two are mutually exclusive. It seems that most other image viewers I have found as well as KDE apps that shows images supports smoothing out pixels when zooming in. But even then, they do not seem slow at all.



> Photos generally are not smaller than screen resolution, 

Really? 12 of 16 images in my ~/Pictures folders are smaller than my current screen resolution (1920x1200). Resolutions of the images are here: http://paste.adora.dk/P2027.txt (found by running identify ~/Pictures/*.jpg |cut -d ' ' -f 3)

Many users download images from websites such as Flickr and the like. Often, these photos are not available in full scale. Often just in 800x600 or 1024x768 or the like. 


> so if you zoom in that
> far, 

You do not *have* to zoom in that far to see the pixels. I did that the illustrate the point more easily. Often, it can be seen when zooming just 200%.


> you likely do it because you want to see the pixels. I cannot think of any
> other reason to zoom in beyond the native resolution. But maybe you can
enlighten me :)

Well, as I wrote above, there are several use cases. One obvious one being to view downloaded images that have smaller resolution that the screen. I can see the need to zoom in a lot to see the individual pixels, thus it should be possible to check a box in the Settings to enable/disable the smoothing/exact zooming. However, I would think that if you need to view the individual pixels on an image you would probably rather use and image *editor* like Gimp or the like instead of an image viewer like Gwenview.
Comment 3 Mark S. 2011-12-28 02:09:49 UTC
This might want to be listed as a wishlist item as Christopher stated that the pixelation is by design, not by accident.
Comment 4 Myriam Schweingruber 2012-01-02 18:32:36 UTC
Moving to wishlist.
Comment 5 Benni Hill 2013-04-09 21:17:25 UTC
*** Bug 193886 has been marked as a duplicate of this bug. ***
Comment 6 Benni Hill 2013-04-09 21:21:18 UTC
*** Bug 171377 has been marked as a duplicate of this bug. ***
Comment 7 Ulrich Lukas 2014-09-23 23:04:51 UTC
I'd like to add that anti-aliasing pictures when upscaling becomes a real issue with screens that have more than the traditional 96 dpi physical resolution.

E.g. "retina"-display devices, UHD-resolution screens and many professional graphics-mode LCDs (2560x1440 pixels on 22, 24 or 27 inches is a useful mode for electronic circuit design CAD etc.)
Comment 8 Nate Graham 2017-11-09 16:26:39 UTC
As a point of comparison, macOS preview interpolates at zoom levels between 101% and 300%; beyond 300%, it switches to displaying exact pixels.

We could do something like that, or else we could add a user-facing control to determine interpolation vs pixelation behavior.
Comment 9 Nate Graham 2017-11-09 17:20:00 UTC
Actually it looks like Preview is even smarter: it automatically pixellates at > 100% zoom levels for certain graphic-design-related image formats like .tga. Intriguing.
Comment 10 Huon 2018-04-13 04:21:15 UTC
(In reply to Nate Graham from comment #8)
> As a point of comparison, macOS preview interpolates at zoom levels between
> 101% and 300%; beyond 300%, it switches to displaying exact pixels.
> 
> We could do something like that, or else we could add a user-facing control
> to determine interpolation vs pixelation behavior.

We already do that, but at >= 200% instead of 300%.

I think the problems lies in the fact small images quickly get to 2-3x zoom, perhaps even before they get bigger than the screen. Conversely, very large images would take a lot of zooming before you see pixels.
So what if we based this decision on percentage of image visible? E.g., if less than let's say one third of the image is visible (AND zoom factor is > 1x), switch to pixels. This is then independent of the image size.

It might get confusing though, since the transition would happen at different zoom factors for different images sizes (and dimensions).
Alternatively we could bump it up to 300% like Preview.

If we wanted to add a config option, I think we'd want to keep the current 'smart' behaviour, therefore ending up with three options: Smart, smooth, fast/pixel. But there the question is whether it's important enough to put in the configuration dialog.
Comment 11 null 2018-04-13 11:18:44 UTC
> large images would take a lot of zooming before you see pixels
Are you sure about that? If I'm not mistaken, the zoom levels are split in two groups: Below 100% (let's ignore that for now, because it is not relevant for interpolation), and above 100%. In the latter case, zooming a tiny PNG icon and a huge JPG camera image to 1600% both result in the same on-screen size of an individual pixel, i.e. the image dimensions don't affect the zoom levels available.

IMO the decision to pixelate should be based the on-screen size of an individual pixel, which for Gwenview directly correlates with the zoom level. If we want to get fancy, we could also account for the user's DPI settings or default font size, but let's not get into that for now.

I'd say what should be done here is some tweaking of the threshold. https://phabricator.kde.org/D7972 reworked the zoom levels a bit, maybe we also need to adapt the threshold accordingly? Hm, I should probably just play around a bit and see what threshold I like…

> ending up with three options
I'm afraid then we'd also end up with an image viewer which is not simple anymore ;)
Comment 12 Huon 2018-04-13 22:39:02 UTC
(In reply to Henrik Fehlauer from comment #11)
> > large images would take a lot of zooming before you see pixels
> Are you sure about that? If I'm not mistaken, the zoom levels are split in
> two groups: Below 100% (let's ignore that for now, because it is not
> relevant for interpolation), and above 100%. In the latter case, zooming a
> tiny PNG icon and a huge JPG camera image to 1600% both result in the same
> on-screen size of an individual pixel, i.e. the image dimensions don't
> affect the zoom levels available.

What I meant was, a large image may start at 14% zoom, meaning it's more zooming (from a user's perspective) to get to max 1600% zoom.

> 
> IMO the decision to pixelate should be based the on-screen size of an
> individual pixel, which for Gwenview directly correlates with the zoom
> level. If we want to get fancy, we could also account for the user's DPI
> settings or default font size, but let's not get into that for now.
> 
> I'd say what should be done here is some tweaking of the threshold.
> https://phabricator.kde.org/D7972 reworked the zoom levels a bit, maybe we
> also need to adapt the threshold accordingly? Hm, I should probably just
> play around a bit and see what threshold I like…

This should be the first thing we try, since it's so easy. It might be enough by itself.

> 
> > ending up with three options
> I'm afraid then we'd also end up with an image viewer which is not simple
> anymore ;)

True that :)
Comment 13 Huon 2018-04-25 06:51:28 UTC
Git commit f88db58a516bcd76e8ea14d28881e5f2ea1d9d61 by Huon Imberger.
Committed on 25/04/2018 at 06:51.
Pushed by huoni into branch 'master'.

Change smooth zoom threshold from 200% to 400%

Summary:
At zoom levels >= 200%, scaling changed from smooth to fast, i.e.
actual pixels started showing.
This patch changes it to 400%.

Test Plan:
Open different sized raster images.
Zoom to at least 400%.
Image should only look pixellated at 400% and higher zooms.

Reviewers: #gwenview, rkflx

Reviewed By: #gwenview, rkflx

Subscribers: ngraham, rkflx

Tags: #gwenview

Differential Revision: https://phabricator.kde.org/D12483

M  +1    -1    lib/documentview/rasterimageview.cpp

https://commits.kde.org/gwenview/f88db58a516bcd76e8ea14d28881e5f2ea1d9d61