Discussion:
[Bug 270980] New: Zooming in gwenview is more pixelated than in other viewers
Thomas Damgaard
2011-04-14 18:16:03 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=270980

Summary: Zooming in gwenview is more pixelated than in other
viewers
Product: gwenview
Version: 2.6
Platform: Ubuntu Packages
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
AssignedTo: agateau-***@public.gmane.org
ReportedBy: thomasdn-***@public.gmane.org


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:
Loading Image...

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.
--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
Christoph Feck
2011-04-19 20:06:00 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=270980





--- Comment #1 from Christoph Feck <christoph maxiom de> 2011-04-19 22:05:58 ---
Post by Thomas Damgaard
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 :)
--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
Thomas Damgaard
2011-04-28 12:43:58 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=270980





--- Comment #2 from Thomas Damgaard <thomasdn gmail com> 2011-04-28 14:43:57 ---
Post by Christoph Feck
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.
Post by Christoph Feck
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.
Post by Christoph Feck
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%.
Post by Christoph Feck
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.
--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
Mark S.
2011-12-28 02:09:50 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=270980


Mark S. <hamboy95-***@public.gmane.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |hamboy95-***@public.gmane.org,
| |myriam-***@public.gmane.org




--- Comment #3 from Mark S. <hamboy95 live com> 2011-12-28 02:09:49 ---
This might want to be listed as a wishlist item as Christopher stated that the
pixelation is by design, not by accident.
--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
Myriam Schweingruber
2012-01-02 18:32:37 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=270980


Myriam Schweingruber <myriam-***@public.gmane.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |wishlist




--- Comment #4 from Myriam Schweingruber <myriam kde org> 2012-01-02 18:32:36 ---
Moving to wishlist.
--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
Benni Hill
2013-04-09 21:17:25 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=270980

Benni Hill <benni-***@public.gmane.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |kde-2011.08-+lSI1PGSVck6GGFevw1D/***@public.gmane.org

--- Comment #5 from Benni Hill <benni-***@public.gmane.org> ---
*** Bug 193886 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are watching all bug changes.
Benni Hill
2013-04-09 21:21:18 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=270980

Benni Hill <benni-***@public.gmane.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |vms796-***@public.gmane.org

--- Comment #6 from Benni Hill <benni-***@public.gmane.org> ---
*** Bug 171377 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are watching all bug changes.
Ulrich Lukas
2014-09-23 23:04:51 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=270980

Ulrich Lukas <stellplatz-nr.13b-7vBoImwI/***@public.gmane.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |stellplatz-***@datenpark
| |platz.de

--- Comment #7 from Ulrich Lukas <stellplatz-nr.13b-7vBoImwI/***@public.gmane.org> ---
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.)
--
You are receiving this mail because:
You are watching all bug changes.
Ulrich Lukas
2014-09-23 23:04:51 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=270980

Ulrich Lukas <stellplatz-***@datenparkplatz.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |stellplatz-***@datenpark
| |platz.de

--- Comment #7 from Ulrich Lukas <stellplatz-***@datenparkplatz.de> ---
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.)
--
You are receiving this mail because:
You are watching all bug changes.
Arthur Țițeică
2014-11-02 10:34:35 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=270980

Arthur Țițeică <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com
--
You are receiving this mail because:
You are watching all bug changes.
Nate Graham
2017-11-09 16:26:39 UTC
Permalink
Dette indlæg kan være upassende. Klik for at få det vist.
Nate Graham
2017-11-09 17:20:00 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=270980

--- Comment #9 from Nate Graham <***@zoho.com> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
Huon
2018-04-13 04:21:15 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=270980

Huon <***@plonq.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@plonq.org

--- Comment #10 from Huon <***@plonq.org> ---
(In reply to Nate Graham from comment #8)
Post by Nate Graham
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.
--
You are receiving this mail because:
You are watching all bug changes.
Henrik Fehlauer
2018-04-13 11:18:44 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=270980

Henrik Fehlauer <***@lab12.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
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 ;)
--
You are receiving this mail because:
You are watching all bug changes.
Huon
2018-04-13 22:39:02 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=270980

--- Comment #12 from Huon <***@plonq.org> ---
(In reply to Henrik Fehlauer from comment #11)
Post by Henrik Fehlauer
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.
Post by Henrik Fehlauer
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.
Post by Henrik Fehlauer
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 :)
--
You are receiving this mail because:
You are watching all bug changes.
Huon
2018-04-25 06:51:28 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=270980

Huon <***@plonq.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
Latest Commit| |https://commits.kde.org/gwe
| |nview/f88db58a516bcd76e8ea1
| |4d28881e5f2ea1d9d61

--- Comment #13 from Huon <***@plonq.org> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
Loading...