New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 49 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Regression

Blocked on:
issue skia:7541


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment
link

Issue 562162: Background images are blurred when scaled down since 46

Reported by kojii@chromium.org, Nov 26 2015 Project Member

Issue description

Split image issue from  bug 545643 .

UserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36

Example URL:
http://apple.com/iphone

Steps to reproduce the problem:
The issue with the scaled down images ("retina display ready"):
1. Open both Chromium and any other major browser
2. Examine any retina display image (e.g: an image scaled down to 50% on desktop)
3. Examine the result, it's way too blurred compared to any other browser.

Results of the tests I've made:
http://i.imgur.com/d0mjaLt.png
http://i.imgur.com/TuIwmEv.png

What partially fixed this was setting the CSS rule: image-rendering:-webkit-optimize-contrast; to the body tag as I have described in the original topic at: https://productforums.google.com/forum/#!topic/chrome/VezviJoWRsI

<-- fonts part removed from the original description -->

All these things were not present prior to Chrome 46.

The tests were done on over 20 different PCs located around the world using Chrome 46, 47 beta and Canary. In addition I have also run the same tests on BrowserStack which runs Chrome on virtual machine and the results were exactly the same.

I have tried various settings in chrome://flags including enabling/disabling: GPU Rasterization and DirectWrite. I have also "Reset all to default" with no improvement whatsoever.

What is the expected behavior?
The expected results should be similar to the images I've presented (see Firefox output).

What went wrong?
All the scaled down images appear way too blurry.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes Chrome 45 and lower

Does this work in other browsers? Yes 

Chrome version: 46.0.2490.71  Channel: stable
OS Version: 6.3
Flash Version: Shockwave Flash 19.0 r0
 

Comment 1 by kojii@chromium.org, Nov 26 2015

Another reproducible case is the logo image on the left top of:
https://www.google.com/settings/chrome/manage

Extracted a minimized test case and screen shot on Mac (non-Retina) attached; Chrome on left and Firefox on right.
blurred-images-545643.html
282 bytes View Download
blurred-image-562162.png
14.3 KB View Download

Comment 2 by markusheintz@chromium.org, Nov 26 2015

Cc: markusheintz@chromium.org

Comment 3 by tkent@chromium.org, Nov 27 2015

Labels: Needs-Bisect Cr-Blink-Paint

Comment 4 by wtstats....@gmail.com, Nov 28 2015

@kojii: your example shows the exact issue I've reported. Also it should be pointed out that it wouldn't matter if the width would be 50% of the original image with, it would still be way too blurred compared to ANY other browsers. This was not the case in previous Chrome versions.

Comment 5 by olivier....@gmail.com, Nov 29 2015

I am not sure if this is related, but i just noticed that on my retina laptop (Pixel), x1 images appear too soft in 46, and x2 images appear fine. 

Version 46.0.2490.82 (64-bit)

Comment 6 by wtstats....@gmail.com, Nov 29 2015

@olivier: if by soft you mean more blurred, then yes - that's the case. That does not happen only on retina displays but also on normal displays.

Comment 7 by olivier....@gmail.com, Nov 29 2015

@wtstats: what i meant is that interestingly enough it seems to work the other way around on my retina display; normal 100% / 1x zoom images are displayed kind of fuzzy/soft/blurry, while 50% scaled down x2 (retina-) images are razor sharp in Chrome 46.

Comment 8 Deleted

Comment 9 by tkonch...@chromium.org, Nov 30 2015

Tried the same with the html file given in comment #1 on win8.1, MacBook Pro (Retina, 15-inch, Mid 2014) and Linux 14.04 could not observe the blurred image compared to firefox browser.

Please find the screenshot( leftmost chrome canary, Chrome stable, rightmost Firefox browser)

Could you please let us know if i am missing something here.
Screen Shot 2015-11-30 at 1.25.36 PM.png
41.4 KB View Download

Comment 10 by kojii@chromium.org, Nov 30 2015

Results vary by the combination of scale factors and screen resolutions. The repro file in #1 can best viewed in non-retina Mac. Can you try on non-Retina Mac?

I don't have a minimized case for retina, maybe wkstats.com or someone else can provide?

Comment 11 by wtstats....@gmail.com, Nov 30 2015

I have tried it on Windows 8.1, Windows 10, Linux 14.04, OSX 10.11 using Chrome 46, Chrome 47 beta and Canary on about 20 different systems, and the difference was obvious between the two [none were retina].

Comment 12 by olivier....@gmail.com, Nov 30 2015

Here is another interesting effect of this behaviour on Retina (Pixel - Chrome OS 46 Stable). The same image viewed in a fullscreen Chrome Remote Desktop session and then the RDP session is windowed. The fullscreen version is sharp, as soon as it is windowed it turns blurry (sharp edges are softened). 

Pictures taken with a phone cam, but i don't think it shows any motion blur compared to what i see on screen.
chrome remote desktop windowed.jpg
1.6 MB View Download
chrome remote desktop fullscreen.jpg
2.2 MB View Download

Comment 13 by wtstats....@gmail.com, Nov 30 2015

@tkonch: I missed the image you posted, but there are obvious differences in the screenshot you've attached. The first two images are blurred while the 3rd one (Firefox) is sharp.

Comment 14 by wtstats....@gmail.com, Dec 1 2015

Chrome 47.0.2526.73 has been released, the issue is still there.

Comment 15 by pdr@chromium.org, Dec 1 2015

Labels: -Needs-Feedback M-48

Comment 16 by ajha@chromium.org, Dec 2 2015

Cc: ajha@chromium.org
Labels: -Type-Bug -Pri-2 -M-48 -Needs-Bisect Type-Bug-Regression Pri-1 M-49
Owner: est...@chromium.org
Status: Assigned
This looks same as  Issue 526671 , assigning to estade@ to have a look at this. Tested this on Windows-7.

Last good build:46.0.2489.0
First bad build:46.0.2490.0

Change log:
============
https://chromium.googlesource.com/chromium/src/+log/46.0.2489.0..46.0.2490.0?pretty=fuller&n=10000

Suspected change:https://chromium.googlesource.com/chromium/src/+/5731f9f9e7a29e3bf0f321209fa180def9acc9c5


Note: This is a split issue from   bug 545643  and is about image blurriness.

Comment 17 by sergiu@chromium.org, Dec 2 2015

Labels: Needs-Bisect
This bug affects pages rendered by Chrome. The Chrome icon is resource loaded by the operating system, the issues are unrelated. I assume the bisect range was from  issue 526671 .

Comment 18 by chrishtr@chromium.org, Dec 2 2015

Owner: fmalita@chromium.org
https://codereview.chromium.org/1294673006 could be related and is in the bisect range. Florin any ideas?

Comment 19 by chrishtr@chromium.org, Dec 2 2015

Comment 20 by est...@chromium.org, Dec 2 2015

this is not the same as  bug 526671 . This is a blink bug. I haven't touched anything that would affect rendering of http://apple.com/iphone

as noted in #17 it doesn't look like the bisect above was actually performed for this bug, but was copied from a different unrelated issue.

Comment 21 by fmalita@chromium.org, Dec 2 2015

Cc: reed@google.com chrishtr@chromium.org
Labels: -Needs-Bisect
Images scaled down 50% and then scaled up 2x (via DSF/retina) should draw 1:1 and not involve any resampling.  If there is any fuzzyness on retina devices, it's most likely a result of post-scale filtering bugs (the compositor layer is not pixel aligned, etc -  http://crbug.com/406529  for example).

Now to the non-retina case.

The c#0 Chrome-vs-Firefox diff bisects (unsurprisingly) to https://chromium.googlesource.com/chromium/src/+/21294f2df129ceb3f57c27e877d45ea71c0be4b0 - that's when we switched from Lanczos to Mitchell for the HQ resampler.

Mitchell produces softer results - but it avoids the nasty Lanczos edge ringing artifacts ( http://crbug.com/421914 ).  There is no one-size-fits-all, and perceived downsampling quality depends on the image type: high-density/photography style vs. sharp edges/logo style.

Note that edge contrast may be improved by using plain bilerp resampling (kLow_SkFilterQuality) - which is exactly what "image-rendering: -webkit-optimize-contrast;" does.  I'm open to ideas, but giving authors control via image-rendering hints seems to be the best option at the moment.

(attachment rendered with -webkit-optimize-contrast - Chrome's results are indistinguishable from FF).
webkit-optimize-contrast.png
18.5 KB View Download

Comment 22 by chrishtr@chromium.org, Dec 2 2015

What about a 2x image scaled down 50% on non-retina? The example in #1 is almost that (change width to 123px). That seems like a common scenario to do better for by default. Is there something useful to do in that case?

Comment 23 by olivier....@gmail.com, Dec 2 2015

@fmalita: for retina, non-scaled images at 100% size appear fuzzy, scaled down x2 images appear sharp.  The Chrome logos in webkit-optimize-contrast.png are fuzzy (soft/feathered) on my Pixel screen, but they are sharp in a fullscreen Chrome RDP session on the same laptop. Windowing RDP makes them fuzzy again. Is this a different bug?

Comment 24 Deleted

Comment 25 by wtstats....@gmail.com, Dec 3 2015

@fmalita: Using image-rendering: -webkit-optimize-contrast; does NOT give you any control, it actually creates very BAD results on small image sizes (see the attached image).

@olivier: the bug is not about images on retina displays, but on standard displays. The retina displays the image just fine. However on normal screens, the images appears softer/blurred. This was not the case in previous Chrome versions builds.

Something very important that it seems I have to re-mention again. This bug affects ALL images that are being scaled up/down, that includes any images on any website that does not use the exact image size.

Comment 26 by fmalita@chromium.org, Dec 3 2015

Cc: vmp...@chromium.org
@chrishtr I don't think there's anything special to do for 2x -> x.  "Better" depends on the image type (high contrast vs. photo).


@olivier.keun you might be seeing the same issue on retina:

  effective_scale = css_scale * device_scale_factor

For retina, I believe DSF == 2.

So a css_scale of 1.0 will yield an effective_scale == 2.0 => we're upscaling => Mitchell produces softer edges.
A css_scale of 0.5 yields an effective_scale of 1.0 => we're drawing 1:1 w/ no resampling.


@wtstats.com not sure I follow: the Chrome result does have higher-contrast edges, which is exactly what you're asking for with -webkit-optimize-contrast (which is ignored by FF - so you're comparing Chrome's contrast-optimized resampler with FF's photo-optimized resampler).  If your point is that the old Chrome high-quality resampler (Lanczos) hit a sweet-spot for certain icon-type/sharp-edge images, and was usable in cases where high-contrast was important, then you're correct - Mitchell is better suited for photo resampling (and avoids some nasty artifacts present in Lanczos).  So it's a trade-off, the sweet-spot has moved.

(+vmpstr@, who may be interested in this)

Ideally, I think authors should have two orthogonal scaling knobs: high-quality vs. low-quality AND high-contrast vs. photo/low-contrast.  A potential Skia resampler mapping would look like


      LC           HC

LQ    bilerp       nearest-neighbor
HQ    Mitchell     Lanczos


We could presumably try to expose both Lanczos and Mitchell, but since the spec (image-rendering) doesn't provide a way to distinguish between HC/HQ and HC/LQ, we'd end up using Lanczos for both.  Then I'm sure there are some cases where the current -webkit-optimize-contrast bilerp produces better results => we've just moved the sweet-spot again.


The difference in your screenshot is interesting for another reason though: per (possibly outdated) Mozilla documentation, FF's photo-quality resampler *is* bilinear - which should match Chrome's low-quality/
-webkit-optimize-contrast behavior (https://developer.mozilla.org/en-US/docs/Web/CSS/image-rendering).  This is why the images in my prev attachment look the same.  So I'd like to understand why the results diverge for your example.  Do you mind uploading the original/unscaled image?  @reed, do we devolve to nearest-neighbor if the size gets low-enough?

Comment 27 by wtstats....@gmail.com, Dec 3 2015

@fmalita, I do know what -webkit-optimize-constrast- does, but you claimed that we have "control" with that option to get a proper rendering when clearly that's not the case [you said that Lanczos was better with sharp contrasted images and that -webkit-optimize-contrast would achieve that].

Now, from my understanding, you're saying that the old Lanczos resampler was better on high contrast images (such as logos) while Mitchell does much better on photos. I could not find a single image to this point that looks better on Chrome than on Firefox.

Let's take the attached attached photos example, 2 photos with two people (I've checked over 20 different photo renderings, ranging from 100px by 100px to 800px by 800px), why does Chrome render the image so blurred/softened while Firefox shows the image so clear? In both images Firefox wins over Chrome. This was the case with all the images I could find, that includes all images from Facebook, Twitter, and other social networks.

As an end user I couldn't care less about what filters Chrome is using, what I do care is how the end result looks, and the truth is that Chrome looks very bad.
ss.png
81.4 KB View Download

Comment 28 by bugdroid1@chromium.org, Feb 11 2016

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0c7e2f7bcee59d0f26ed86a0d87dce4e0800f2f2

commit 0c7e2f7bcee59d0f26ed86a0d87dce4e0800f2f2
Author: fmalita <fmalita@chromium.org>
Date: Wed Feb 10 19:42:26 2016

Remove SK_SUPPORT_LEGACY_HQ_DOWNSAMPLING

Switches Skia's software HQ downscaling algorithm from Mitchell to
mipmaps.

This is a good idea because

1) it aligns the results with Ganesh (which already uses
  mipmaps for downscaling)

2) mipmaps are cheaper/more efficient (to produce and to cache)

3) yields (arguably) sharper results, particularly when scaling to
  half size - which appears to be a common technique used for
  Retina-ready pages.

BUG= 583478 ,562162
R=reed@google.com,senorblanco@chromium.org

Review URL: https://codereview.chromium.org/1511113004

Cr-Commit-Position: refs/heads/master@{#374703}

[modify] http://crrev.com/0c7e2f7bcee59d0f26ed86a0d87dce4e0800f2f2/chrome/test/data/plugin_power_saver/poster_tests_expected.png
[modify] http://crrev.com/0c7e2f7bcee59d0f26ed86a0d87dce4e0800f2f2/chrome/test/data/plugin_power_saver/smaller_than_play_icon_expected.png
[modify] http://crrev.com/0c7e2f7bcee59d0f26ed86a0d87dce4e0800f2f2/skia/config/SkUserConfig.h
[modify] http://crrev.com/0c7e2f7bcee59d0f26ed86a0d87dce4e0800f2f2/third_party/WebKit/LayoutTests/TestExpectations
[delete] http://crrev.com/62c38d412f4501d5bf8411bf87ee1b81a3975cb8/third_party/WebKit/LayoutTests/css3/masking/mask-repeat-round-content-expected.html
[modify] http://crrev.com/0c7e2f7bcee59d0f26ed86a0d87dce4e0800f2f2/third_party/WebKit/LayoutTests/fast/canvas/canvas-imageSmoothingQuality.html

Comment 29 by chrishtr@chromium.org, Mar 2 2016

Labels: -Pri-1 Pri-2

Comment 30 by wtstats....@gmail.com, May 13 2016

Hello guys. I'm back again with the exact same issue appearing again on latest two Chrome 50 Stable releases.

The images appear again to be blurred when being downscaled (see the attached image, Left-Chrome - Right-Firefox). Firefox and Edge deliver far sharper results compared to Chrome.

The original images have a 90px by 90px size while on the document they are being displayed at 42px by 42px. If I display them exactly at 45px by 45px (50% which is retina display common practice), they appear sharp, similar to Firefox and Edge.

Important: The very first Chrome 50 Stable release has fixed this, even when being downscaled from 90px to 42px.
chrome_vs_firefox_image_rendering.png
21.1 KB View Download

Comment 31 by quasimod...@gmail.com, Aug 2 2016

I've noticed this myself in Chrome, specifically when there is whitespace in a PNG image.

Testing a transparent icon with 1px of surrounding whitespace (ie: a canvas size larger than the actual graphic) then scaling it to 50% of the original produces a blurry rendering in Chrome. However after removing the whitespace in an image editor it produces a crisp rendering.

While I'd love a fix for this issue the above may be a useful interim workaround for web devs who need raster sprites.

Comment 32 by chrishtr@chromium.org, Aug 2 2016

Hi Florin, what's the status of this bug?

Comment 33 by 2slow2ha...@gmail.com, Sep 26 2016

I've just updated chromium from 47 to 55 and it's freaking horrible. Some weird artifacts with CSS-downscaled images.

https://jsfiddle.net/pc1vL4u1/
47.jpg
27.6 KB View Download
55.jpg
30.0 KB View Download
ff_vs_chromium.png
243 KB View Download

Comment 34 by chrishtr@chromium.org, Sep 26 2016

vmpstr: is this in effect a duplicate of  issue 649046 ?

Comment 35 by vmp...@chromium.org, Sep 26 2016

This looks to be a different issue (it's not impacted by my change -- before and after looks the same)

Comment 36 by vmp...@chromium.org, Sep 26 2016

Note that disabling cc image controller and image hijack canvas altogether also produces similar results, so this is probably something in Skia.

Comment 37 by schenney@chromium.org, Sep 28 2016

Components: -Blink>Image -Blink>Paint Internals>Skia

Comment 38 by wtstats....@gmail.com, Oct 12 2016

This was fixed for a short period on Chrome 50 (the very first stable release), it was later reversed again to post 47 and current version. I gave up and got used to the shitty image rendering quality on Chrome. Sadly.

Comment 39 by chrishtr@chromium.org, Nov 2 2016

Florin, any idea on this bug? Is it actionable?

Comment 40 by oyv...@nymedia.no, Jan 25 2017

I'm working with a client trying to optimize the image quality for their website and I didn't realize until now that so much of the problem actually stems from Chrome or webkit itself. We've been optimizing our workflows in Drupal and Photoshop, but now when I'm comparing a scaled image in Chrome to a scaled image in Firefox the difference is night and day.

What can I do to help speed up the process for fixing this? Surely there are no pros with how Chrome/webkit is rendering scaled images at the moment? I've tested with dozens of images and they all look much blurrier and much worse than they do in Firefox.

This seems to affect Opera, Safari and Chrome on OSX and Safari and Chrome on iOS, those are the browsers I've tested so far, and as far as I know they all use webkit. Firefox on OSX looks razor sharp by comparison.

We're working with a responsive website, same as probably everyone else these days, so trying to avoid image scaling in the browser is impossible.

Comment 41 by oyv...@nymedia.no, Jan 25 2017

And because I'm a bit unsure what this issue is for I will add some examples of the problem I'm experiencing. The original post in this thread talks about retina and 50% scaling etc., but for me this problem is something that happens even if you just scale an image by 1px in Chrome, it goes completely blurry, while in Firefox it does not.

Attached are the images. There are 2 sets of 2 images and I haven't labeled which one is from Chrome and which one is from Firefox, but it should be very apparent to anyone that one image in each set looks a lot crisper than the other.

I saved them as png to avoid any extra compression so they are a bit large.

For all four images the source image is 800x450 pixels and then the browser scaled the largest ones down to 788x443 and the smallest one down to 374x210. In Chrome and any webkit browser this makes the images look so bad that it basically looks like they've been scaled up rather than down, but in Firefox the images look about as sharp as the source.
image-1a.png
617 KB View Download
image-1b.png
559 KB View Download
image-2a.png
101 KB View Download
image-2b.png
116 KB View Download

Comment 42 by reed@chromium.org, Jan 25 2017

Cc: brianosman@chromium.org

Comment 43 by wtstats....@gmail.com, Feb 3 2017

You're fighting with windmills. I've been trying to convince them that the current way the Chrome render images lowers the quality of the photo when being resized drastically. It's been 14 months since I've reported this, it was temporarily fixed for 2/3 weeks, and then reverted back. The images you've posted are similar to what I've posted in my previous messages.

Since you haven't labeled them, it's obvious that 1b and 2a are the results of the Chrome poor render engine, 1a and 2b are from Firefox.

You should just move on at this point and get used to the idea, like I did (you should see how bad the retina optimized images look on Chrome compared to Edge/Firefox).

Comment 44 by oyv...@nymedia.no, Feb 4 2017

Thanks for the information. It sort of doesn't matter that much for me knowing it's Chrome/Webkit's fault and not my own so it's unavoidable in a way, but it would of course be nice to see it fixed because Chrome is my main browser and the main browser of nearly everyone these days.

And obviously when clients complain about the image quality it became something I felt I needed to investigate.

Comment 45 by jorandir...@gmail.com, Feb 20 2017

Re: "Florin, any idea on this bug? Is it actionable?"

It looks like there has been no response on this since Nov 2? It should be actionable, it worked in the past and this is a quality issue.

Comment 46 by julix1...@gmail.com, Feb 24 2017

I found something interesting: when it first renders the page it's sharp, and then gets replaced with unsharp within a split second. - the delay was big enough that I managed to catch a screen shot of the sharp version. 

Noticed that while I was playing with the size, i.e. when I was re-sizing it would be sharp for a moment, then blurred. - Please fix!

This is an image at 50 % resolution, that should not have to be this blurry!
error.png
21.6 KB View Download

Comment 47 by chrishtr@chromium.org, Mar 16 2017

Owner: schenney@chromium.org
Hi Stephen, sending to you for analysis of next steps, per our discussion.

Comment 48 by dtristra...@gmail.com, Mar 23 2017

we're using chrome as embedded framework (CEF) to show tutorial content with a combination of images and text captions.  rendered images are visibly blurry on retina display compared with native app UI elements.  high frequency images when up sampled for presentation on retina display are over-blurred.

Comment 49 by felixh...@gmail.com, Jun 12 2017

Hi, I'am using the prototyping tool framer (https://framer.com) which heavily relies on image transformation (especially scaling) and the results look terrible in Chrome compared to other browsers on a non-retina display.

See the attached screenshots. Please note that all text on the prototype is rendered from .png files and is not rendered by browser.

Here is the link to the website: https://share.framerjs.com/iaj37n9c5uzp/

--
Chrome: 59.0.3071.86 (Official Build) (64-bit)
OS: MacOS 10.12.5
framer_chrome.png
641 KB View Download
framer_safari.png
812 KB View Download

Comment 50 by sdy@chromium.org, Sep 12 2017

FWIW, the results seem to be exceptionally bad when only scaling one axis. See attachments.
Screen Shot 2017-09-12 at 4.38.44 PM.png
16.9 KB View Download
Screen Shot 2017-09-12 at 4.38.53 PM.png
14.3 KB View Download
crbug_562162_scale_width.html
13.4 KB View Download

Comment 51 by julix1...@gmail.com, Sep 12 2017

Is anyone currently working on this? Seems so strange that it starts out sharp and then *becomes* blurry...

Comment 52 by chrishtr@chromium.org, Sep 12 2017

I can't reproduce the result from comment 50. How did you get to the second
screenshot?

Comment 53 by julix1...@gmail.com, Sep 12 2017

I agree with Comment 52, just opening the html provided shows me a clean square. However, if I change the width it becomes unclean.
distort.png
38.7 KB View Download

Comment 54 by chrishtr@chromium.org, Sep 12 2017

Ah - I can reproduce comment 50's result on Retina Mac.

Comment 55 by vmp...@chromium.org, Sep 12 2017

Cc: ericrk@chromium.org

Comment 56 by chrishtr@chromium.org, Sep 12 2017

THe different result in #50 is due to GPU raster. Looking into it.

Comment 57 by ericrk@chromium.org, Sep 13 2017

The issue in comment #50 is a more extreme case of  bug 472864 . I'm guessing that 
this is a different issue from the other image issues being discussed in this bug.

Comment 58 by oyv...@nymedia.no, Sep 13 2017

Since there were some replies to this thread I just wanted to add that in the latest Chrome v. 61.0.3163.79 the image quality for scaled images is still inferior to that of the latest Firefox v. 55.0.3. See the attached images for examples of the problem. The images are screenshots of the same page taken from one of my client's websites. The original images are 800x450, but are in these examples displayed at 788x443 due to the responsive nature of the site.

The scaling algorithm used by Chrome is clearly inferior to the one used by Firefox.
1_firefox.png
641 KB View Download
1_chrome.png
588 KB View Download
2_firefox.png
651 KB View Download
2_chrome.png
615 KB View Download

Comment 59 by greenrea...@gmail.com, Sep 27 2017

I run an art site where we dynamically resize art down from its maximum resolution (i.e. set width: to screen width) and I've just had to throw on image-rendering: -webkit-optimize-contrast; because Chrome otherwise adds an unacceptable level of blurriness on what should be excellent-quality images.

This is better than Chrome's default scale on most images, but I still consider it a stopgap, because it results in noticeable aliasing with high-frequency elements (moreso than Firefox), e.g. bright lines at certain angles.

I appreciate that the standard only offers one option for image-rendering, and it isn't specific about what is "high-quality", but that doesn't seem like a great excuse for the current situation, especially since what is "high quality" may differ depending on the operation.

I think you need to reconsider the decision to internally just use one algorithm for everything. There's a reason Paint Shop Pro advises bicubic for upscaling, bilinear for downscaling - for the former, you tend to want to avoid artifacts, while in the latter case preserving perceived detail can be more important. Mitchell and other bicubic splines tend to work better for upscaling. Lanczos often works better for downscaling - and failing that, bilinear (bilerp) may be better than Mitchell.

This page demonstrates how bicubics can blur fine detail on downscaling (see "How does using it affect the output?"):
https://gis.stackexchange.com/questions/10931/what-is-lanczos-resampling-useful-for-in-a-spatial-context/14361#14361

One option would be to use Mitchell for increasing the size and either Lanczos (preferable) or bilerp for downscaling. Most of the time it's one or the other. If you're doing both on one image then you'll need to make a choice (Mitchell if width x height > oldwidth x oldheight?).

Alternatively, try tweaking the free parameter of the cubic function (assuming that is possible in this case) depending on whether you're doing upscaling or downscaling. Or use Lanczos rather than bilrep for the high-contrast option.

You might also image-rendering into a multi-choice with generic and specific options, like font-face, offering users more specific choice of algorithms with fallbacks. That way if your graphic designers want to complain about how their images are being resized, you can tell them to set a CSS style, rather than using a different default (thus leading to different output) to everyone else.

Comment 60 by schenney@chromium.org, Nov 13 2017

Owner: ----
Status: untriaged (was: Assigned)
Looking over all of this there seem to be two active issues. The GPU resizing bluriness is tracked in https://bugs.chromium.org/p/chromium/issues/detail?id=472864. The choice of filer method for rescaling images is still tracked here.

At the end of the day this comes down to compositor and Skia decisions on filtering techniques. Based on fmalita@ comments way back in comment #26, it seems this still lives in Skia land, so I am passing it over to there for re-triage to someone who can drive the choices.

Comment 61 by fabian.w...@gmail.com, Nov 16 2017

Same issue here I am very surpised. I have an highres bg image downscaled to 50% via css background-size.
Looks still great on FF 57, but Chrome 62 washes it out extremely. Like upscaling something to 400%

Comment 62 by reed@chromium.org, Nov 16 2017

I wonder if we are choosing the wrong pow-2 when the image is "prescaled". That could explain the fuzzy nature, since we would then upscale (w/ bilerp) to get back to the desired size.

Comment 63 by mgiuca@chromium.org, Jan 25 2018

Ping. Looks like this is still an issue. (Seen in a thread: https://www.resetera.com/threads/blurry-resetera-avatars-caused-by-google-chrome.18734/)

Interesting comment in that thread: "Interestingly enough, Opera -- which is based off of Chromium -- doesn't have blurry avatars."

Having said that, the avatars on that thread look fine to me under close inspection in Chrome 63.0.3239.132.

Can someone on the Skia team take ownership of this?

Comment 64 by mgiuca@chromium.org, Jan 25 2018

Follow-up: I can't repro this on Chrome for Linux 63. Perhaps this only affects Windows or some other combination of platforms?

See attached picture of an avatar from https://www.resetera.com/threads/blurry-resetera-avatars-caused-by-google-chrome.18734/. A user posted screenshots of this picture in Chrome and Firefox in Comment 6.

- Left: My screenshot from Chrome 63 for Linux.
- Center: "Chrome screenshot" from Comment 6.
- Right: "Firefox screenshot" from Comment 6.

You can see that Left and Right look very sharp, while Center looks dull/blurry. The image is scaled from a natural 192x192 to 100x100.
scaling.png
61.6 KB View Download

Comment 65 by r.brusko...@sp.design, Jan 25 2018

I can confirm the blur with Chrome Version 64.0.3282.119 on macOS Sierra 10.12.6
MacBook Pro Retina display: No issues
Non-Retina Apple Thunderbolt display: Scaled images look dull and blurry

With Opera, results seem to be better in some specific cases only.

My interest in this originates from being a user of Framer app. Framer's prototypes look very blurry in Chrome and sharp in Safari (on the Non-Retina display). Not sure if thats related, though.

Screenshots:
- Left: Chrome 64 / macOS / Thunderbolt
- Center: Opera 50 / macOS / Thunderbolt
- Right: Safari 11.0.2 / macOS / Thunderbolt
Bildschirmfoto 2018-01-25 um 10.22.30.png
38.9 KB View Download
Bildschirmfoto 2018-01-25 um 10.22.45.png
68.8 KB View Download
Bildschirmfoto 2018-01-25 um 10.23.00.png
35.6 KB View Download

Comment 66 by oyv...@nymedia.no, Jan 25 2018

I checked again in the latest versions of Chrome, Safari, Opera and Firefox on the latest version of OS X and everything looks similar to what I reported in January and September last year.

I didn't compare Opera and Safari back then, but looking at them now I can say that Opera looks identical to Chrome, equally blurry, and Safari looks almost as sharp as Firefox, but not quite. Safari doesn't look bad though, it's hard to even see the difference without directly comparing it with Firefox. Chrome and Opera on the other hand definitely look bad, unacceptably bad in my opinion, even though the images are downscaled they look like they're upscaled in Chrome and Opera.

As an experiment I tried downscaling the same images I've been testing with in the latest version of Photoshop and it does look better than the browsers, but Firefox is almost up there, and Safari is close.

Comment 67 by hcm@chromium.org, Jan 25 2018

Cc: hcm@chromium.org
Owner: fmalita@chromium.org
Thanks for the updated test results, we've had mixed reviews on repro by platform, retina/non-retina, but it seems there is still an issue for many. fmalita, do you have thoughts here?

Comment 68 by greenrea...@gmail.com, Jan 26 2018

Retina-level devices are less likely to show this issue, since the scaling factor will be less. It'd be most visible on low-end devices (like entry-level Chromebooks). Such displays are the default - on our site, 50% of visits report 1920×1080, 360×640 (mobile, probably 720×1280 in reality) or 1366×768; perhaps 10% are above Full HD.

I noticed Skia is creating each mip-map level from the previous one:
https://github.com/google/skia/blob/master/src/core/SkMipMap.cpp#L666

Doesn't that end up propagating accumulated error, as compared to generating each one from the original? Maybe less so if you're using a triangle filter, but that may be part of the problem.

I also stumbled across Issue 618324, which seems to be this bug from a Canvas perspective; it highlights the filtering algorithm used to generate (and possibly render) the mipmaps; as junov says there, "would be nice to use a lanczos filter for mipmap generation."

As for performance: ideally, scaled images would look perfect, instantly. But failing that, we should be able to say "go slower and get this one right". By all means, add it to PageSpeed; but let us decide based on our quality requirements, not just yours. Otherwise we have to say "best viewed in Firefox", because it really is. :-)

[In the Resetera example linked above, the first avatar is, for me, 192×308 scaled down to 75×120 (so ~2.5x). That just looks a little blurry; they all clean up with the image-rendering trick above. 4000-5000px wide images scaled to 720px don't work so well; it doesn't seem to sample enough pixels when creating (or rendering?) at lower resolution, resulting in severe blurring or - with -webkit-optimize-contrast - aliasing.

Given the range of devices, scaling high-resolution images should be an easy way to improve quality for those at the high end (like many web designers and developers), while maintaining quality for others. Everything else aside, it's incredibly non-intuitive to give a browser a better image and end up with a worse result.]

Comment 69 by fmalita@chromium.org, Jan 26 2018

Cc: cblume@chromium.org robertphillips@chromium.org
(there are several issues on this thread, some obsolete; I'll focus on the recent resetera samples for now)

Most of the image scaling heuristics have been externalized and now live in Chrome's compositor (CC), which handles image decoding/scaling/caching.  IIRC, at this point Skia only receives kNone (nearest-neighbor), kLow (bilerp) and kMedium (mip-map) requests from Chrome.

Looking at the resetera.com examples, I can repro on Linux/ToT -- but only with GPU rasterization enabled.  See https://codepen.io/fmalita/pen/BJXwXq.

r.bruskowski@sp.design would you mind trying Chrome with --disable-gpu-rasterization to verify that the avatars get sharper?

This kinda smells like  issue 472864  mentioned by schenney@ -- but that bug is focused on anisotropic upscaling, while here we're dealing with isotropic downscaling ([192,192]->[100,100]).  One difference I'm aware of is the GPU impl uses trilinear filtering between mip-levels while the sw impl does a bilerp from the higher mip level.  Not sure if that's enough to explain the blurriness though, I'll see if I can isolate in Skia.
cpu.png
11.3 KB View Download
gpu.png
10.9 KB View Download

Comment 70 by fmalita@chromium.org, Jan 26 2018

Blockedon: skia:7541

Comment 71 by r.brusko...@sp.design, Jan 26 2018

fmalita@chromium.org

I can confirm that most avatars do get sharper with --disable-gpu-rasterization on macOS (Non Retina Thunderbolt Display). detuned_radios doesn't, though. The latter is 192 x 241 px and Grey Scale.

By the way: All the images are apparently served as *.jpg, at least Chrome saves them with this extension. Although at least some of them are actually PNG files with transparency.
blurriness-issue.png
214 KB View Download
blurriness-issue-200percent.png
234 KB View Download

Comment 72 by gtcr...@gmail.com, Jan 27 2018

Can also confirm this issue on Chrome 63 and 64. It's especially noticable on images with text on them. Example below.
comparison.png
1.8 MB View Download

Comment 73 by bugdroid1@chromium.org, Feb 13 2018

Project Member
The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/8a83ca4e9afc9e3c08b4e8c33a74392f9b3154d7

commit 8a83ca4e9afc9e3c08b4e8c33a74392f9b3154d7
Author: Brian Osman <brianosman@google.com>
Date: Tue Feb 13 16:30:20 2018

Add "sharpen" option to SkSL, to LOD bias all textures

This adds a fixed bias (-0.5) to the computed LOD of all
mip-mapped texture fetches. (Technically, to all texture
fetches, but that only matters for mip-mapped ones).

Clients can opt-in with a new GrContextOption.

Bug: skia:7541
Bug: chromium:562162
Change-Id: Ie3cd0679c4ab66f62d2dc32e7e68e5c99355115e
Reviewed-on: https://skia-review.googlesource.com/106322
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>

[modify] https://crrev.com/8a83ca4e9afc9e3c08b4e8c33a74392f9b3154d7/src/gpu/gl/builders/GrGLProgramBuilder.cpp
[modify] https://crrev.com/8a83ca4e9afc9e3c08b4e8c33a74392f9b3154d7/src/gpu/vk/GrVkPipelineStateBuilder.cpp
[modify] https://crrev.com/8a83ca4e9afc9e3c08b4e8c33a74392f9b3154d7/tests/SkSLGLSLTest.cpp
[modify] https://crrev.com/8a83ca4e9afc9e3c08b4e8c33a74392f9b3154d7/include/gpu/GrContext.h
[modify] https://crrev.com/8a83ca4e9afc9e3c08b4e8c33a74392f9b3154d7/src/sksl/SkSLSPIRVCodeGenerator.cpp
[modify] https://crrev.com/8a83ca4e9afc9e3c08b4e8c33a74392f9b3154d7/src/gpu/GrContextPriv.h
[modify] https://crrev.com/8a83ca4e9afc9e3c08b4e8c33a74392f9b3154d7/src/gpu/GrContext.cpp
[modify] https://crrev.com/8a83ca4e9afc9e3c08b4e8c33a74392f9b3154d7/src/sksl/ir/SkSLProgram.h
[modify] https://crrev.com/8a83ca4e9afc9e3c08b4e8c33a74392f9b3154d7/include/gpu/GrContextOptions.h
[modify] https://crrev.com/8a83ca4e9afc9e3c08b4e8c33a74392f9b3154d7/src/sksl/SkSLGLSLCodeGenerator.cpp

Comment 74 by bugdroid1@chromium.org, Feb 22 2018

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dbefb45d16d8544042eb143a831da738618be61b

commit dbefb45d16d8544042eb143a831da738618be61b
Author: Brian Osman <brianosman@google.com>
Date: Thu Feb 22 15:42:04 2018

Enable fSharpenMipmappedTextures in Skia

This enables a Skia option to bias LOD selection for mipmapped
textures by 1/2 level. That sharpens any downscaled images,
and effectively switches to linear blending for scale factors
above 1/sqrt(2).

On the linked bug, this dramatically improves the quality of
the small avatar images from resetera.com (#63 - #71).

Other cases in the bug are not addressed, particularly the
framer.com issues from #49. (Those issues appear even without
GPU rasterization, so the cause may be outside Skia).

Bug: chromium:562162
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I0b1ab4e55ef93f8312065a48f938ae1d5ae3aa00
Reviewed-on: https://chromium-review.googlesource.com/916557
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@chromium.org>
Reviewed-by: Victor Miura <vmiura@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Cr-Commit-Position: refs/heads/master@{#538442}
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/gpu/skia_bindings/grcontext_for_gles2_interface.cc
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/linux/virtual/gpu-rasterization/images/color-profile-image-filter-all-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/linux/virtual/gpu-rasterization/images/color-profile-svg-fill-text-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/color-profile-background-image-cover-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/color-profile-background-image-repeat-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/color-profile-background-image-space-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/color-profile-border-radius-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/color-profile-filter-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/color-profile-image-canvas-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/color-profile-image-canvas-pattern-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/color-profile-image-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/color-profile-image-filter-all-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/color-profile-image-profile-match-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/color-profile-mask-image-svg-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/color-profile-object-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/color-profile-svg-fill-text-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/exif-orientation-height-image-document-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/jpeg-yuv-progressive-image-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/rgb-png-with-cmyk-color-profile-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/sprite-no-bleed-expected.png
[modify] https://crrev.com/dbefb45d16d8544042eb143a831da738618be61b/third_party/WebKit/LayoutTests/platform/win/virtual/gpu-rasterization/images/ycbcr-with-cmyk-color-profile-expected.png

Comment 75 by greenrea...@gmail.com, Mar 27 2018

This landed in 66 (currently in Beta). To provide end-user feedback: there's a very noticeable improvement in our use-case (high-ratio downscaling) when I test with Dev 67 vs. Release 65.

To my eye, Firefox still has an edge in perceptual sharpness; but the new version is acceptably similar, where the previous one was not. As a result, we should soon be able to remove our CSS workaround. Thanks for listening!

Comment 76 by benhenry@chromium.org, Aug 3

Status: Assigned (was: Untriaged)
This bug has an owner, thus, it's been triaged. Changing status to "assigned".

Comment 77 by weiliangc@chromium.org, Sep 14

Cc: bsalo...@google.com vmi...@chromium.org
 Issue 472864  has been merged into this issue.

Sign in to add a comment