[gwenview] [Bug 270980] Option to interpolate instead of pixellate at > 100% zoom levels

2018-04-25 Thread Huon
https://bugs.kde.org/show_bug.cgi?id=270980

Huon  changed:

   What|Removed |Added

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

--- Comment #13 from Huon  ---
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-1lib/documentview/rasterimageview.cpp

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

-- 
You are receiving this mail because:
You are watching all bug changes.

[gwenview] [Bug 270980] Option to interpolate instead of pixellate at > 100% zoom levels

2018-04-13 Thread Huon
https://bugs.kde.org/show_bug.cgi?id=270980

--- Comment #12 from Huon  ---
(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 :)

-- 
You are receiving this mail because:
You are watching all bug changes.

[gwenview] [Bug 270980] Option to interpolate instead of pixellate at > 100% zoom levels

2018-04-13 Thread Henrik Fehlauer
https://bugs.kde.org/show_bug.cgi?id=270980

Henrik Fehlauer  changed:

   What|Removed |Added

 CC||rk...@lab12.net

--- Comment #11 from 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.

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.

[gwenview] [Bug 270980] Option to interpolate instead of pixellate at > 100% zoom levels

2018-04-12 Thread Huon
https://bugs.kde.org/show_bug.cgi?id=270980

Huon  changed:

   What|Removed |Added

 CC||h...@plonq.org

--- Comment #10 from Huon  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[gwenview] [Bug 270980] Option to interpolate instead of pixellate at > 100% zoom levels

2017-11-09 Thread Nate Graham
https://bugs.kde.org/show_bug.cgi?id=270980

--- Comment #9 from Nate Graham  ---
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.

[gwenview] [Bug 270980] Option to interpolate instead of pixellate at > 100% zoom levels

2017-11-09 Thread Nate Graham
https://bugs.kde.org/show_bug.cgi?id=270980

Nate Graham  changed:

   What|Removed |Added

 CC||pointedst...@zoho.com
Summary|Zooming in gwenview is more |Option to interpolate
   |pixelated than in other |instead of pixellate at >
   |viewers |100% zoom levels

--- Comment #8 from 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.

-- 
You are receiving this mail because:
You are watching all bug changes.