Issue metadata
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 descriptionUserAgent: 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)"
,
May 6 2016
That is just a revert I performed for a release, over to the author.
,
May 6 2016
Sorry :( We're trying to agree on a way to let us make things not blurry.
,
May 6 2016
> 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.
,
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).
,
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.
,
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!
,
May 6 2016
Thanks I'll have a look.
,
May 6 2016
,
May 6 2016
> 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 |
|||||||||||||||||||||||||
Comment 1 by kavvaru@chromium.org
, May 6 2016Components: 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)