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

Issue 609229 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 600867
Owner:
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Image quality loss when up-scaling an image which had been initially scaled-down with a reduced width/height.

Reported by cschu...@mocap.com, May 4 2016

Issue description

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

Example URL:
http://www.mocap.com/caps-plastic-tear-bsp.html

Steps to reproduce the problem:
1. Use an IMG with a width set less than the image's native size.
2. Use "transform: scale" to increase the size back to the native dimensions.

What is the expected behavior?
Firefox, IE Edge, Opera, (and until recently, chrome) use the original hi-res image to generate the final up-scaled image.

What went wrong?
Chrome appears to use the scaled-down image as it's data source, and then uses this reduced image to scale back up to a larger size, resulting in image data loss.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? Yes 49.0.2623.112

Does this work in other browsers? N/A 

Chrome version: 50.0.2661.94  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 21.0 r0

I see several open issues for blurry results while using transform/scale, but none for this specific issue.

In a way, the current behavior of chrome actually is the expected behavior, since it is doing exactly what has being asked of it (first scale image down, then scale it back up).  But, previous versions were smart enough to preserve the original image quality in this sort of situation, and all of the other other browser I've tested do the same as well.

Verified that this once worked in version 44.0.2403.125 and 49.0.2623.112.
Issue first noticed in 50.0.2661.94.

Example image above is actually 275x275px.
Width and height of IMG element reduced to 100x100px
Hovering image sets "transform: scale(2.50)"
 
zoom_chrome_firefox.png
100 KB View Download
Cc: kavvaru@chromium.org
Components: Blink>Image
Labels: -Pri-2 -Type-Compat hasbisect M-52 OS-Linux Pri-1 Type-Bug-Regression
Owner: amineer@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on windows 7 and Linux Ubuntu 14.04 using chrome version 50.0.2661.94 and canary 52.0.2726.0.
This is regression issue broken in M50. Please find the bisect information as below

Narrow Bisect::
Good::50.0.2661.84
Bad:: 50.0.2661.86

Providing the manual change log as the good and bad builds are branched builds
Omahaproxy Change Log::
https://chromium.googlesource.com/chromium/src/+log/50.0.2661.84..50.0.2661.86?pretty=fuller&n=10000

Possible suspect from the above CL
https://chromium.googlesource.com/chromium/src/+/bb4146c4a2bb20b9a0075a56fb7a631cdd30ad2d

amineer@ could you please look into this issue if it is related to your change,else please help us in assigning this to an appropriate owner for this issue.

Note: Issue is working fine on Mac 10.11.4 

Thanks,

Comment 2 by amin...@google.com, May 6 2016

Owner: danakj@chromium.org
That is just a revert I performed for a release, over to the author. 
Mergedinto: 600867
Status: Duplicate (was: Assigned)
Sorry :( We're trying to agree on a way to let us make things not blurry.
> Verified that this once worked in version 44.0.2403.125 and 49.0.2623.112.

I don't understand this. We did try to make things not blurry in 49, but we've had the current behaviour before 49 since.. 30something at least.

Comment 5 by cschu...@mocap.com, May 6 2016

I have an older XP machine stuck on v44, and the images do not look blurry.

My test on v49 came from a terminal client that had a slightly out-of-date copy of Chrome.  The images were not blurry on that machine either.  But, after I allowed chrome to update from v49 to v50, the images were blurry.  

But it sounds like kavvaru pinned it down to a specific update (50.0.2661.86).



Comment 6 by cschu...@mocap.com, May 6 2016

Just to mention one more small detail...

As I stated, I start with a 275px image, set it in an IMG element with a width of 100px, on hover I apply a "transform: scale(2.50)" with a *transition effect* as the scale is applied.  

I've always noticed that in Chrome the image ALWAYS appeared blurry while the transition effect was being applied. But AFTER the effect was applied, you could visually see the image magically change from the blurry image to a crisp one.   And that is what is missing now... the magic swap at the end of the process from a blurry image to a crisp one.

This effect becomes more apparent if I lengthen the transition time to 2 seconds.   On Chrome V44, the image is clearly blurry (just as on v50) until after the transition completes.  And then, presto chang-o!

Firefox stays crisp through the entire transition, but Chrome was doing something at the end of the process to improve the quality.  And now it’s not doing that.

Not sure if that's helpful, but I thought I should mention it.

Comment 7 by cschu...@mocap.com, May 6 2016

Right after posting that last message, I did some more testing.  And I found that I could make the blurriness go away if I disabled this attribute on my image's class:

    transform: perspective( 200px ) rotateY( 0deg );

To be quite honest, I'm not sure why I had this property set to begin with. It was probably just a left-over from when I was testing various 3-D transition effects.

The weird thing is that this "transform" attribute on the base class was being entirely over-ridden by the "transform" attribute of the :hover class.  So removing this attribute should make no difference, since it should get ignored anyway when the hover class is applied. Yet, its existence seems to cause some sort of issue.



In any case... Removing the "transform" attribute fixes my particular problem.  So, somebody needs to decide whether or not there is actually an issue that needs to be corrected here. 

Thanks for all your help with this!
Status: Assigned (was: Duplicate)
Thanks I'll have a look.
Cc: chrishtr@chromium.org vmp...@chromium.org enne@chromium.org
Status: Duplicate (was: Assigned)
> In any case... Removing the "transform" attribute fixes my particular problem.

Ooh ok thanks! So it was the change in 49 that you were using unawares, and the revert broke things. So I'll dupe again.

Sign in to add a comment