Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 114 users
Status: Fixed
Owner:
Closed: Jan 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment
Add -webkit-interpolation-mode CSS for specifying scaling algorithm
Reported by patrick....@gmail.com, Sep 5 2008 Back to list
Product Version      : 0.2.149.27 (1583)
URLs (if applicable) : http://manningkrull.com/pixel_art/moatmonster.asp
Other browsers tested: Firefox, IE
Add OK or FAIL after other browsers where you have tested this issue:
    Firefox 3: FAIL
         IE 7: OK

What steps will reproduce the problem?
1. use HTML to rescale an image (e.g. pixel art) by an integral factor like 
200% or 300%

What is the expected result?
A crisp (linear) resizing.

What happens instead?
A blurry (bilinear or bicubic) resizing.

Please provide any additional information below. Attach a screenshot if 
possible.

This has been a problem with pixel artists as soon as FF 3.0 was released; 
similar bug reports exist on Bugzilla under "Firefox Zoom Blur".  There 
should be either 
1) an option to disable bilinear in favor of nearest neighbor resizing, or
2) .gif images should use nearest neighbor when being rescaled by integral 
amounts.
 
Comment 1 by Deleted ...@, Sep 6 2008
I can confirm this problem.

At the very least there should be a way to turn this off in the browser, but since 
there's no way for web developers to control this image interpolation (it's not 
uncommon to use smaller images blown up a bit as a design choice) I suggest that it 
gets disabled completely for when scaling images up. Bilinear interpolation is better 
suited for scaling images down, when scaling them up it really does nothing for the 
image quality and in fact it simply ruins the image by making it blurry.

Labels: -area-unknown Area-Misc
Comment 3 by jon@chromium.org, Jan 7 2009
Labels: -Type-Bug -Area-Misc Type-Feature Area-WebKit Mstone-X
Status: Assigned
Brett, do you think we should change how we do this?
Labels: -Pri-2 Pri-3
Status: Unconfirmed
Summary: Consider using nearest neighbor for even factors of magnification (was: NULL)
This definitely does not warrant a global browser option.

I don't think this is a "feature" of IE. They use nearest neighbor (the filer said 
"linear" which he doesn't mean) for all resampling. It could well be considered a 
bug, since sometimes (like photos) you will want better sampling than nearest 
neighbor.

This is not something that's guaranteed in any browser. If you're making designs that 
depend on it, your designs will be broken. I don't think that is a valid reason to 
request this change. If you want the ability to specify this via a web page, you 
should bring it up with a standards body.

This may still be something we want to consider (that is, nearest neighbor for even 
multiples of magnification). I'm interested in it in the context of full page zoom. 
It may be the best looking (and certainly best performing) option for zoom factors of 
200 or 300%.
Comment 5 by jon@chromium.org, Jan 16 2009
Status: Untriaged
Came across this today, apparently Microsoft does have a CSS tag for forcing nearest 
neighbor vs. bicubic. Here's a link:
http://msdn.microsoft.com/en-us/library/ms530822(VS.85).aspx

On a side note, apparently IE does use nearest neighbor by default when scaling up by 
an integer amount (200%, for example).
Comment 7 by jon@chromium.org, Apr 3 2009
Labels: Size-Medium
Status: Available
Summary: Support -ms-interpolation-mode CSS for specifying scaling algorithm (was: NULL)
Comment 8 by omat...@gmail.com, Apr 3 2009
You shouldn't use different behavior for integer amounts because what if someone is 
using some JS or something to do a zoom animation - we can't have it using one 
algorithm at 199%, another at 200%, and the first again at 201%.
Out of curiosity, why not? Does it bog down the computer to switch between alogrithms, 
or are you against the algorithm swaps for visual reasons?
Comment 10 by omat...@gmail.com, Apr 6 2009
It would be very hard for a web developer to make a smooth zoom animation in 
javascript if certain zoom levels used a different algorithm with no control given to 
the web developer to override the browsers choice.

You could consider it to one frame of a video being rendered in black and white when 
all other frames are color - the overall effect would be an annoying flicker when 
watching the film.
Good point. However, I think the suggestion posted here has changed to allowing a CSS 
option for which algorithm a host wants for certain images, with default being bicubic 
for non-integral scales and nearest neighbor otherwise. If this were the case, a 
developer with code for animated image resize could simply force bicubic in all 
instances.
Summary: Add -webkit-interpolation-mode CSS for specifying scaling algorithm (was: NULL)
This would really be a WebKit feature and not a Chromium one. As such, it should 
really be filed at bugs.webkit.org, and implemented there.

Also note that WebKit would not support "-ms" CSS options. It would need a new one 
starting with "-webkit". 
Has anything happened with this request? Firefox 3.6 will have a CSS option for 
specifying the algorithm, what about chrome?
Comment 14 by lolla...@gmail.com, Nov 17 2009
I agree, something has to be done now...
This is implemented in Firefox 3.6.3 and it is Internet Explorer:

Example:
image-rendering: -moz-crisp-edges; 
-ms-interpolation-mode: nearest-neighbor;

Webkit (Safari & Chrome) needs to include an option for this.

Something like this:
image-rendering: -webkit-crisp-edges; 
-webkit-interpolation-mode: nearest-neighbor;

Sites that need it and will use it are: 

http://www.wayofthepixel.net/pixelation/
http://www.pixeljoint.com/


Comment 16 by Deleted ...@, Jun 21 2010
Yes, this is needed!
Comment 17 by ftp...@gmail.com, Jun 22 2010
Just letting know that this issue has been posted on the webkit bug report:
https://bugs.webkit.org/show_bug.cgi?id=40881
Comment 18 by Deleted ...@, Jun 27 2010
This is in all honestly my biggest issue with Firefox right now, and has been ever since version 3 released. Please fix it. I don't like using IE.
The latest version of Firefox has this already. 

Only mainstream browsers that don't have this are Chrome, Safari, and possibly Opera. 
Comment 20 by Deleted ...@, Sep 23 2010
It'd be lovely to have the option to specify nearest neighbour interpolation. Main use would be for the display of pixel art, for example from the following game consoles: amiga, c64, nes, nes, neo geo, gbc, gba, and so on. Scaled nearest neighbour is really the only way to view this kind of art with the intended effect.
I have made a rather big web based Photoshop-like image editor. The biggest problem I am facing is that when zooming in, the pixels are blurred. The Gecko CSS extension "image-rendering: -moz-crisp-edges" is perfect way to solve that problem. However, in Google Chrome, there is no way to create an image editor with a zoom feature.
It indeed is a problem for PixelArt images, artists and theyr galleries.
I understand that for "standard user" this is a feature, but why there isn't a way to switch this off ?!
Comment 24 by erdav...@gmail.com, Mar 29 2011
I can't believe this has not been fixed since 2008! This feature is very important to me, I might stop using chrome if it doesn't get implemented soon.
It's not just for pixel-art, there are other uses for it for example a visualization site I'm working on fails on this because it displays 3D data as a grid with the value encoded as a color. This grid is generated serverside as a small PNG then upscaled in the browser, which of course looks horrible when you can't turn off the interpolation!

It could be upscaled in the server as well of course, but the server is the CPU bottleneck so that's not a very good sustainable solution..

Same option as firefox or IE would be perfect.

Comment 26 by tran...@gmail.com, Apr 7 2011
Argh.  It's been years!  Come, on.  Why can't we use CSS to specify a nearest neighbor rendering of images that are resized?!!!  This is so stupid.
This is also desperately needed for HTML5/Canvas games. Many games are deliberately low-res, but scaled up to be playable on normal screen resolutions. E.g. http://playbiolab.com/ is scaled up 2x. 

I had to implemented a nearest neighbor scaling algorithm in JavaScript that goes through every image pixel by pixel and scales it up on game load. It needs extra CPU time on game load and 4x the amount of RAM to store the upscaled images - all just to have a low-res look. This can't be in the interest of a browser that calls itself "fast".
Comment 28 by noel@chromium.org, Apr 19 2011
Cc: mikelawther@chromium.org
Status: ExternalDependency
https://bugs.webkit.org/show_bug.cgi?id=56627
Comment 29 by cms...@gmail.com, Sep 30 2011
As per comment 27, I need this for a game too.
Comment 30 by cms...@gmail.com, Sep 30 2011
Will the fix be automatically be pulled in from Webkit?

Is there any timescale for this?

Thanks,

Chris.
Labels: nomedia
Comment 32 by Deleted ...@, Dec 19 2011
I think google is more focused on the canvas element at the moment, perhaps they feel the img tag is old hat and will only be used for general purpose "pictures." For more advanced/modern control try implementing the canvas object.

 I have the same issue as you guys, I want to rapidly swap out images to "scroll" through 3D data... the high quality scaling slows things way down on tablets. When I get to my optimization stage, I will implement canvas tag.
I understood that this bug thread is about canvas as well. After all css rules are more general, and not img tag specific.
The 'image-rendering' property has been punted from Level 3 of CSS Image Values and Replaced Content Module to Level 4. It was most recently in this draft: http://www.w3.org/TR/2011/WD-css3-images-20110712/#image-rendering.

This property is intended to apply to both img and canvas.
@32 In my website (blaggart.com) I have to manually pixelate my images in chrome by converting them into a canvas object. Doing this processing in Javascript is much slower than it takes the browser to interpolate the image with their optimised code.
Owner: mikelawther@chromium.org
Status: Fixed
Fixed in https://bugs.webkit.org/show_bug.cgi?id=56627
Project Member Comment 37 by bugdroid1@chromium.org, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 38 by bugdroid1@chromium.org, Mar 11 2013
Labels: -Area-WebKit Cr-Content
Project Member Comment 39 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Sign in to add a comment