Re: [whatwg] Bicubic filtering on context.drawImage
On Wed, Mar 26, 2014 at 10:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 26, 2014, at 9:22 PM, Rik Cabanier caban...@gmail.com wrote: On Wed, Mar 26, 2014 at 8:59 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 24, 2014, at 8:25 AM, Justin Novosad ju...@google.com wrote: On Sat, Mar 22, 2014 at 1:47 AM, K. Gadd k...@luminance.org wrote: A list of resampling methods defined by the spec would be a great overengineered (not in a bad way) solution, but I think you really only need to worry about breaking existing apps - so providing an escape valve to demand bilinear (this is pretty straightforward, everything can do bilinear) instead of the 'best' filtering being offered is probably enough for future-proofing. It might be better to default to bilinear and instead require canvas users to opt into better filtering, in which case a list of available filters would probably be preferred, since that lets the developer do feature detection. I think we missed an opportunity to make filtering future-proof when it got spec'ed as a boolean. Should have been an enum IMHO :-( Anyways, if we add another image smoothing attribute to select the algorithm let's at least make that one an enum. I'm not sure the spec should impose specific filter implementations, or perhaps only bi-linear absolutely needs to be supported, and all other modes can have fallbacks. For example. We could have an attribute named imageSmoothingQuality. possibles value could be 'best' and 'fast'. Perhaps 'fast' would mean bi-linear. Not sure which mode should be the default. We could also have interpolateEndpointsCleanly flag that forces bilinear or an equivalent algorithm that ensures endpoints do not get affected by inner contents. Is that to clamp the sampling to the source rect? http://jsfiddle.net/6vh5q/9/ shows that Safari samples when smoothing is turned off which is a bit strange. In general, it's better to define semantic based flags and options so that UAs could optimize it in the future. Mandating a particular scaling algorithm in the spec. would limit such optimizations in the future. e.g. there could be a hardware that natively support Lanczos sampling but not Bicubic sampling. If it was an enum/string, an author could set the desired sampling method and if the UA doesn't support it, the attribute would not change. The point I was trying to make isn't so much about some UA not supporting a particular sampling algorithm. It's more about that the right/most-effective sampling algorithm depending on platform/hardware. In general, UA is in a much better position to determine what sampling algorithm works best given the constraints such as smoothness and interpolating endpoints cleanly on a given hardware. Yes, figuring out the various aliasing options will be difficult to figure out. Katalyn's use case is with controlling the sampling outside the source rect in drawImage which we can treat as a separate, more trivial issue.
Re: [whatwg] Bicubic filtering on context.drawImage
On Mar 24, 2014, at 8:25 AM, Justin Novosad ju...@google.com wrote: On Sat, Mar 22, 2014 at 1:47 AM, K. Gadd k...@luminance.org wrote: A list of resampling methods defined by the spec would be a great overengineered (not in a bad way) solution, but I think you really only need to worry about breaking existing apps - so providing an escape valve to demand bilinear (this is pretty straightforward, everything can do bilinear) instead of the 'best' filtering being offered is probably enough for future-proofing. It might be better to default to bilinear and instead require canvas users to opt into better filtering, in which case a list of available filters would probably be preferred, since that lets the developer do feature detection. I think we missed an opportunity to make filtering future-proof when it got spec'ed as a boolean. Should have been an enum IMHO :-( Anyways, if we add another image smoothing attribute to select the algorithm let's at least make that one an enum. I'm not sure the spec should impose specific filter implementations, or perhaps only bi-linear absolutely needs to be supported, and all other modes can have fallbacks. For example. We could have an attribute named imageSmoothingQuality. possibles value could be 'best' and 'fast'. Perhaps 'fast' would mean bi-linear. Not sure which mode should be the default. We could also have interpolateEndpointsCleanly flag that forces bilinear or an equivalent algorithm that ensures endpoints do not get affected by inner contents. In general, it's better to define semantic based flags and options so that UAs could optimize it in the future. Mandating a particular scaling algorithm in the spec. would limit such optimizations in the future. e.g. there could be a hardware that natively support Lanczos sampling but not Bicubic sampling. - R. Niwa
Re: [whatwg] Bicubic filtering on context.drawImage
On Wed, Mar 26, 2014 at 8:59 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 24, 2014, at 8:25 AM, Justin Novosad ju...@google.com wrote: On Sat, Mar 22, 2014 at 1:47 AM, K. Gadd k...@luminance.org wrote: A list of resampling methods defined by the spec would be a great overengineered (not in a bad way) solution, but I think you really only need to worry about breaking existing apps - so providing an escape valve to demand bilinear (this is pretty straightforward, everything can do bilinear) instead of the 'best' filtering being offered is probably enough for future-proofing. It might be better to default to bilinear and instead require canvas users to opt into better filtering, in which case a list of available filters would probably be preferred, since that lets the developer do feature detection. I think we missed an opportunity to make filtering future-proof when it got spec'ed as a boolean. Should have been an enum IMHO :-( Anyways, if we add another image smoothing attribute to select the algorithm let's at least make that one an enum. I'm not sure the spec should impose specific filter implementations, or perhaps only bi-linear absolutely needs to be supported, and all other modes can have fallbacks. For example. We could have an attribute named imageSmoothingQuality. possibles value could be 'best' and 'fast'. Perhaps 'fast' would mean bi-linear. Not sure which mode should be the default. We could also have interpolateEndpointsCleanly flag that forces bilinear or an equivalent algorithm that ensures endpoints do not get affected by inner contents. Is that to clamp the sampling to the source rect? http://jsfiddle.net/6vh5q/9/ shows that Safari samples when smoothing is turned off which is a bit strange. In general, it's better to define semantic based flags and options so that UAs could optimize it in the future. Mandating a particular scaling algorithm in the spec. would limit such optimizations in the future. e.g. there could be a hardware that natively support Lanczos sampling but not Bicubic sampling. If it was an enum/string, an author could set the desired sampling method and if the UA doesn't support it, the attribute would not change.
Re: [whatwg] Bicubic filtering on context.drawImage
As I mentioned to Ryosuke off-list, I think the interpolateEndpointsCleanly attribute is a (relatively) simple solution to the problem I have with the current spec, and it doesn't overcomplicate things or make it hard to improve filtering in the future. It's also trivial to feature-detect, which means I can use it when available and fallback to a temporary canvas otherwise. I think providing this option would also make it easier to solve situations where applications rely on the getImageData output after rendering a scaled bitmap. I'd probably call it something (to me) clearer about semantics, though, like 'sampleInsideRectangle' On Wed, Mar 26, 2014 at 9:22 PM, Rik Cabanier caban...@gmail.com wrote: On Wed, Mar 26, 2014 at 8:59 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 24, 2014, at 8:25 AM, Justin Novosad ju...@google.com wrote: On Sat, Mar 22, 2014 at 1:47 AM, K. Gadd k...@luminance.org wrote: A list of resampling methods defined by the spec would be a great overengineered (not in a bad way) solution, but I think you really only need to worry about breaking existing apps - so providing an escape valve to demand bilinear (this is pretty straightforward, everything can do bilinear) instead of the 'best' filtering being offered is probably enough for future-proofing. It might be better to default to bilinear and instead require canvas users to opt into better filtering, in which case a list of available filters would probably be preferred, since that lets the developer do feature detection. I think we missed an opportunity to make filtering future-proof when it got spec'ed as a boolean. Should have been an enum IMHO :-( Anyways, if we add another image smoothing attribute to select the algorithm let's at least make that one an enum. I'm not sure the spec should impose specific filter implementations, or perhaps only bi-linear absolutely needs to be supported, and all other modes can have fallbacks. For example. We could have an attribute named imageSmoothingQuality. possibles value could be 'best' and 'fast'. Perhaps 'fast' would mean bi-linear. Not sure which mode should be the default. We could also have interpolateEndpointsCleanly flag that forces bilinear or an equivalent algorithm that ensures endpoints do not get affected by inner contents. Is that to clamp the sampling to the source rect? http://jsfiddle.net/6vh5q/9/ shows that Safari samples when smoothing is turned off which is a bit strange. In general, it's better to define semantic based flags and options so that UAs could optimize it in the future. Mandating a particular scaling algorithm in the spec. would limit such optimizations in the future. e.g. there could be a hardware that natively support Lanczos sampling but not Bicubic sampling. If it was an enum/string, an author could set the desired sampling method and if the UA doesn't support it, the attribute would not change.
Re: [whatwg] Bicubic filtering on context.drawImage
On Mar 26, 2014, at 9:22 PM, Rik Cabanier caban...@gmail.com wrote: On Wed, Mar 26, 2014 at 8:59 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 24, 2014, at 8:25 AM, Justin Novosad ju...@google.com wrote: On Sat, Mar 22, 2014 at 1:47 AM, K. Gadd k...@luminance.org wrote: A list of resampling methods defined by the spec would be a great overengineered (not in a bad way) solution, but I think you really only need to worry about breaking existing apps - so providing an escape valve to demand bilinear (this is pretty straightforward, everything can do bilinear) instead of the 'best' filtering being offered is probably enough for future-proofing. It might be better to default to bilinear and instead require canvas users to opt into better filtering, in which case a list of available filters would probably be preferred, since that lets the developer do feature detection. I think we missed an opportunity to make filtering future-proof when it got spec'ed as a boolean. Should have been an enum IMHO :-( Anyways, if we add another image smoothing attribute to select the algorithm let's at least make that one an enum. I'm not sure the spec should impose specific filter implementations, or perhaps only bi-linear absolutely needs to be supported, and all other modes can have fallbacks. For example. We could have an attribute named imageSmoothingQuality. possibles value could be 'best' and 'fast'. Perhaps 'fast' would mean bi-linear. Not sure which mode should be the default. We could also have interpolateEndpointsCleanly flag that forces bilinear or an equivalent algorithm that ensures endpoints do not get affected by inner contents. Is that to clamp the sampling to the source rect? http://jsfiddle.net/6vh5q/9/ shows that Safari samples when smoothing is turned off which is a bit strange. In general, it's better to define semantic based flags and options so that UAs could optimize it in the future. Mandating a particular scaling algorithm in the spec. would limit such optimizations in the future. e.g. there could be a hardware that natively support Lanczos sampling but not Bicubic sampling. If it was an enum/string, an author could set the desired sampling method and if the UA doesn't support it, the attribute would not change. The point I was trying to make isn't so much about some UA not supporting a particular sampling algorithm. It's more about that the right/most-effective sampling algorithm depending on platform/hardware. In general, UA is in a much better position to determine what sampling algorithm works best given the constraints such as smoothness and interpolating endpoints cleanly on a given hardware. - R. Niwa
Re: [whatwg] Bicubic filtering on context.drawImage
On Sat, Mar 22, 2014 at 1:47 AM, K. Gadd k...@luminance.org wrote: A list of resampling methods defined by the spec would be a great overengineered (not in a bad way) solution, but I think you really only need to worry about breaking existing apps - so providing an escape valve to demand bilinear (this is pretty straightforward, everything can do bilinear) instead of the 'best' filtering being offered is probably enough for future-proofing. It might be better to default to bilinear and instead require canvas users to opt into better filtering, in which case a list of available filters would probably be preferred, since that lets the developer do feature detection. I think we missed an opportunity to make filtering future-proof when it got spec'ed as a boolean. Should have been an enum IMHO :-( Anyways, if we add another image smoothing attribute to select the algorithm let's at least make that one an enum. I'm not sure the spec should impose specific filter implementations, or perhaps only bi-linear absolutely needs to be supported, and all other modes can have fallbacks. For example. We could have an attribute named imageSmoothingQuality. possibles value could be 'best' and 'fast'. Perhaps 'fast' would mean bi-linear. Not sure which mode should be the default. -Justin
Re: [whatwg] Bicubic filtering on context.drawImage
Hi Katelyn, would this solved by creating a list of resampling methods that are clearly defined in the spec? Do you have a list in mind? On Sat, Mar 15, 2014 at 4:14 AM, K. Gadd k...@luminance.org wrote: In game scenarios it is sometimes necessary to have explicit control over the filtering mechanism used, too. My HTML5 ports of old games all have severe rendering issues in every modern browser because of changes they made to canvas semantics - using filtering when not requested by the game, sampling outside of texture rectangles as a result of filtering Can you give an example of when that sampling happens? , etc - imageSmoothingEnabled doesn't go far enough here, and I am sure there are applications that would break if bilinear was suddenly replaced with bicubic, or bicubic was replaced with lanczos, or whatever. This matters since some applications may be using getImageData to sample the result of a scaled drawImage and changing the scaling algorithm can change the data they get. One example I can think of is that many games bilinear scale a tiny (2-16 pixel wide) image to get a large, detailed gradient (since bilinear cleanly interpolates the endpoints). If you swap to another algorithm the gradient may end up no longer being linear, and the results would change dramatically. On Fri, Mar 14, 2014 at 1:45 PM, Simon Sarris sar...@acm.org wrote: On Fri, Mar 14, 2014 at 2:40 PM, Justin Novosad ju...@google.com wrote: Yes, and if we fixed it to make it prettier, people would complain about a performance regression. It is impossible to make everyone happy right now. Would be nice to have some kind of speed versus quality hint. As a canvas/web author (not vendor) I agree with Justin. Quality is very important for some canvas apps (image viewers/editors), performance is very important for others (games). Canvas fills a lot of roles, and leaving a decision like that up to browsers where they are forced to pick one or the other in a utility dichotomy. I don't think it's a good thing to leave debatable choices up to browser vendors. It ought to be something solved at the spec level. Either that or end users/programmers need to get really lucky and hope all the browsers pick a similar method, because the alternative is a (admittedly soft) version of This site/webapp best viewed in Netscape Navigator. Simon Sarris
Re: [whatwg] Bicubic filtering on context.drawImage
Hi, the attached screenshots and test case in
https://bugzilla.mozilla.org/show_bug.cgi?id=782054 demonstrate how
the issue affects 2D games that perform scaling/rotation of bitmaps.
There are other scenarios I probably haven't considered as well. As
far as I can tell the mechanism used to render these quads is
rendering quads that are slightly too large (probably for coverage
purposes or to handle subpixel coordinates?) which results in
effectively drawing a rectangle larger than the input rectangle, so
you sample a bit outside of it and get noise when texture atlases are
in use.
Interestingly, I raised this on the list previously and it was pointed
out that Chrome's previous ('correct' for that test case) behavior was
actually incorrect, so it was changed. If I remember correctly there
are good reasons for this behavior when bilinear filtering is enabled,
but it's quite unexpected to basically get 'antialiasing'
on the edges of your bitmaps when filtering is explicitly disabled.
Getting opted into a different filter than the filter you expect could
probably be similarly problematic but I don't know of any direct
examples other than the gradient fill one.
A list of resampling methods defined by the spec would be a great
overengineered (not in a bad way) solution, but I think you really
only need to worry about breaking existing apps - so providing an
escape valve to demand bilinear (this is pretty straightforward,
everything can do bilinear) instead of the 'best' filtering being
offered is probably enough for future-proofing. It might be better to
default to bilinear and instead require canvas users to opt into
better filtering, in which case a list of available filters would
probably be preferred, since that lets the developer do feature
detection.
-kg
On Fri, Mar 21, 2014 at 9:38 PM, Rik Cabanier caban...@gmail.com wrote:
Hi Katelyn,
would this solved by creating a list of resampling methods that are clearly
defined in the spec?
Do you have a list in mind?
On Sat, Mar 15, 2014 at 4:14 AM, K. Gadd k...@luminance.org wrote:
In game scenarios it is sometimes necessary to have explicit control
over the filtering mechanism used, too. My HTML5 ports of old games
all have severe rendering issues in every modern browser because of
changes they made to canvas semantics - using filtering when not
requested by the game, sampling outside of texture rectangles as a
result of filtering
Can you give an example of when that sampling happens?
, etc - imageSmoothingEnabled doesn't go far enough
here, and I am sure there are applications that would break if
bilinear was suddenly replaced with bicubic, or bicubic was replaced
with lanczos, or whatever. This matters since some applications may be
using getImageData to sample the result of a scaled drawImage and
changing the scaling algorithm can change the data they get.
One example I can think of is that many games bilinear scale a tiny
(2-16 pixel wide) image to get a large, detailed gradient (since
bilinear cleanly interpolates the endpoints). If you swap to another
algorithm the gradient may end up no longer being linear, and the
results would change dramatically.
On Fri, Mar 14, 2014 at 1:45 PM, Simon Sarris sar...@acm.org wrote:
On Fri, Mar 14, 2014 at 2:40 PM, Justin Novosad ju...@google.com
wrote:
Yes, and if we fixed it to make it prettier, people would complain
about a
performance regression. It is impossible to make everyone happy right
now.
Would be nice to have some kind of speed versus quality hint.
As a canvas/web author (not vendor) I agree with Justin. Quality is very
important for some canvas apps (image viewers/editors), performance is
very
important for others (games).
Canvas fills a lot of roles, and leaving a decision like that up to
browsers where they are forced to pick one or the other in a utility
dichotomy. I don't think it's a good thing to leave debatable choices
up
to browser vendors. It ought to be something solved at the spec level.
Either that or end users/programmers need to get really lucky and hope
all
the browsers pick a similar method, because the alternative is a
(admittedly soft) version of This site/webapp best viewed in Netscape
Navigator.
Simon Sarris
Re: [whatwg] Bicubic filtering on context.drawImage
On Mon, 9 Dec 2013, Tingan Ho wrote: I'm a web developer in need of bicubic filtering on context.drawImage. I use to crop and scale images on the web using canvas. And I noticed that quality when you scale down very much is very bad on canvas. Do you need bicubic filtering specifically, or would any high quality resizing algorithm work for you? I scale down images using context.drawImage. There is no way for me to opt in for which filter method to use. I thought it was a bug first, because I thought context.webkitImageSmoothingEnabled did the job. But it didn't. So I filed a bug for chrome. But they suggested me to email you guys. https://code.google.com/p/chromium/issues/detail?id=326640 If the bug is that Chrome resamples the image in an ugly way, then that's a bug with Chrome. As the bug says, browsers are allowed to pick whatever algorithm they want -- it's a quality-of-implementation issue. But if the result is ugly, that's a low quality implementation. On Mon, 9 Dec 2013, Tingan Ho wrote: [...] it kind of make sense if you set imageSmothingEnabled to true in the context object, that all down-scaling should use bicubic resampling(I haven't tried yet, but I think the scale use bicubic sampling). I think it is is a miss in the specification that the method drawImage doesn't use bicubic resampling. It is a method of the context objext on des down-scaling. Well, when scaling down, nearest-neighbor interpolation doesn't make sense. So the false value doesn't really make sense when scaling down. So browsers have to pick an algorithm. Which they pick (and how it's implemented, etc) decides the quality of their implementation. On Mon, 9 Dec 2013, Oliver Hunt wrote: I’m not sure why you have a bias towards bicubic filtering as there are many different scaling filters that can be used. Lanczos is better than bicubic in many (most?) cases. Spline scaling can also do a good job, as can fractal interpolation. There are even specific scaling systems like Sal which are designed for upscaling sprites, and do a better job at the specific task than anything else (IIRC this is frequently used by the various old console emulators) This is why the spec currently doesn't specify an algorithm. On Mon, 9 Dec 2013, Tingan Ho wrote: That would be even better. At least if I can opt-in for the one I want. But I think most developers also don't want to dive into this algorithms, so it would be good to have default values that perform well. right now I don't know exactly what all browser vendors are using, maybe bilinear? But it result in very poor image quality. That's a quality-of-implementation bug with the browsers, not a spec bug. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Bicubic filtering on context.drawImage
On Fri, Mar 14, 2014 at 2:29 PM, Ian Hickson i...@hixie.ch wrote: I scale down images using context.drawImage. There is no way for me to opt in for which filter method to use. I thought it was a bug first, because I thought context.webkitImageSmoothingEnabled did the job. But it didn't. So I filed a bug for chrome. But they suggested me to email you guys. https://code.google.com/p/chromium/issues/detail?id=326640 If the bug is that Chrome resamples the image in an ugly way, then that's a bug with Chrome. As the bug says, browsers are allowed to pick whatever algorithm they want -- it's a quality-of-implementation issue. But if the result is ugly, that's a low quality implementation. Yes, and if we fixed it to make it prettier, people would complain about a performance regression. It is impossible to make everyone happy right now. Would be nice to have some kind of speed versus quality hint.
Re: [whatwg] Bicubic filtering on context.drawImage
On Fri, Mar 14, 2014 at 2:40 PM, Justin Novosad ju...@google.com wrote: Yes, and if we fixed it to make it prettier, people would complain about a performance regression. It is impossible to make everyone happy right now. Would be nice to have some kind of speed versus quality hint. As a canvas/web author (not vendor) I agree with Justin. Quality is very important for some canvas apps (image viewers/editors), performance is very important for others (games). Canvas fills a lot of roles, and leaving a decision like that up to browsers where they are forced to pick one or the other in a utility dichotomy. I don't think it's a good thing to leave debatable choices up to browser vendors. It ought to be something solved at the spec level. Either that or end users/programmers need to get really lucky and hope all the browsers pick a similar method, because the alternative is a (admittedly soft) version of This site/webapp best viewed in Netscape Navigator. Simon Sarris
Re: [whatwg] Bicubic filtering on context.drawImage
--- Original Message --- From: Tab Atkins Jr. jackalm...@gmail.com Sent: December 9, 2013 2:22 AM To: Tingan Ho tin...@p1.cn Cc: WHATWG whatwg@lists.whatwg.org Subject: Re: [whatwg] Bicubic filtering on context.drawImage On Mon, Dec 9, 2013 at 5:29 PM, Tingan Ho tin...@p1.cn wrote: Hi Whatwg, I'm a web developer in need of bicubic filtering on context.drawImage. I use to crop and scale images on the web using canvas. And I noticed that quality when you scale down very much is very bad on canvas. I scale down images using context.drawImage. There is no way for me to opt in for which filter method to use. I thought it was a bug first, because I thought context.webkitImageSmoothingEnabled did the job. But it didn't. So I filed a bug for chrome. But they suggested me to email you guys. https://code.google.com/p/chromium/issues/detail?id=326640 Hm, I wonder if image-interpolation on the canvas should affect this? It's defined to only have an effect when you scale the canvas element itself, but I think it probably makes sense that whatever scaling intent you specify for the element should probably apply to images you draw into it with a scale. ~TJ
Re: [whatwg] Bicubic filtering on context.drawImage
On Mon, Dec 9, 2013 at 1:21 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Hm, I wonder if image-interpolation on the canvas should affect this? It's defined to only have an effect when you scale the canvas element itself, but I think it probably makes sense that whatever scaling intent you specify for the element should probably apply to images you draw into it with a scale. What is image-interpolation? It looks like a CSS property, but Google doesn't distinguish between image-interpolation and image interpolation, so it's impossible to search for. If it is, having CSS state affect drawing of 2d canvas seems wrong. Aside from the bad layering, it would lead to different rendering if you draw to a Canvas before stylesheets finish loading (equivalent to not waiting for images, but much easier to get wrong without noticing), and if you offscreen render a Canvas before actually putting it in a document. -- Glenn Maynard
Re: [whatwg] Bicubic filtering on context.drawImage
On Mon, Dec 9, 2013 at 4:06 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Dec 9, 2013 at 1:21 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Hm, I wonder if image-interpolation on the canvas should affect this? It's defined to only have an effect when you scale the canvas element itself, but I think it probably makes sense that whatever scaling intent you specify for the element should probably apply to images you draw into it with a scale. [...] If it is, having CSS state affect drawing of 2d canvas seems wrong. Aside from the bad layering, it would lead to different rendering if you draw to a Canvas before stylesheets finish loading (equivalent to not waiting for images, but much easier to get wrong without noticing), and if you offscreen render a Canvas before actually putting it in a document. Well, doesn't this already happen with remote web fonts and fillText/strokeText? -- Glenn Maynard -- kangax
Re: [whatwg] Bicubic filtering on context.drawImage
On Mon, Dec 9, 2013 at 9:42 AM, Juriy Zaytsev kan...@gmail.com wrote: Well, doesn't this already happen with remote web fonts and fillText/strokeText? I'm not familiar with that, but at least if a font size is incorrect it's a lot more noticable than if a resampling filter is sometimes in bilinear when you wanted bicubic. -- Glenn Maynard
Re: [whatwg] Bicubic filtering on context.drawImage
On Mon, Dec 9, 2013 at 7:06 AM, Glenn Maynard gl...@zewt.org wrote: On Mon, Dec 9, 2013 at 1:21 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Hm, I wonder if image-interpolation on the canvas should affect this? It's defined to only have an effect when you scale the canvas element itself, but I think it probably makes sense that whatever scaling intent you specify for the element should probably apply to images you draw into it with a scale. What is image-interpolation? It looks like a CSS property, but Google doesn't distinguish between image-interpolation and image interpolation, so it's impossible to search for. If it is, having CSS state affect drawing of 2d canvas seems wrong. Aside from the bad layering, it would lead to different rendering if you draw to a Canvas before stylesheets finish loading (equivalent to not waiting for images, but much easier to get wrong without noticing), and if you offscreen render a Canvas before actually putting it in a document. Yes, CSS properties should not affect 'drawImage'. The spec currently doesn't enforce what resampling algorithm to use; it just allows you to turn it off. Tingan, would it be acceptable for you to do the resampling in JavaScript?
Re: [whatwg] Bicubic filtering on context.drawImage
Tingan, would it be acceptable for you to do the resampling in JavaScript? First, writing it in Javascript is less performant. Since natively you can have access to the GPU. Second, it is abstract a layer for JS developers, since they don't need to care about bicubic resampling algoritmen. Third, it kind of make sense if you set imageSmothingEnabled to true in the context object, that all down-scaling should use bicubic resampling(I haven't tried yet, but I think the scale use bicubic sampling). I think it is is a miss in the specification that the method drawImage doesn't use bicubic resampling. It is a method of the context objext on des down-scaling. On Mon, Dec 9, 2013 at 7:22 PM, Rik Cabanier caban...@gmail.com wrote: On Mon, Dec 9, 2013 at 7:06 AM, Glenn Maynard gl...@zewt.org wrote: On Mon, Dec 9, 2013 at 1:21 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Hm, I wonder if image-interpolation on the canvas should affect this? It's defined to only have an effect when you scale the canvas element itself, but I think it probably makes sense that whatever scaling intent you specify for the element should probably apply to images you draw into it with a scale. What is image-interpolation? It looks like a CSS property, but Google doesn't distinguish between image-interpolation and image interpolation, so it's impossible to search for. If it is, having CSS state affect drawing of 2d canvas seems wrong. Aside from the bad layering, it would lead to different rendering if you draw to a Canvas before stylesheets finish loading (equivalent to not waiting for images, but much easier to get wrong without noticing), and if you offscreen render a Canvas before actually putting it in a document. Yes, CSS properties should not affect 'drawImage'. The spec currently doesn't enforce what resampling algorithm to use; it just allows you to turn it off. Tingan, would it be acceptable for you to do the resampling in JavaScript? -- Sincerely, Tingan Ho tin...@p1.cn
Re: [whatwg] Bicubic filtering on context.drawImage
On Dec 9, 2013, at 2:29 PM, Tingan Ho tin...@p1.cn wrote: Tingan, would it be acceptable for you to do the resampling in JavaScript? First, writing it in Javascript is less performant. Since natively you can have access to the GPU. Second, it is abstract a layer for JS developers, since they don't need to care about bicubic resampling algoritmen. Third, it kind of make sense if you set imageSmothingEnabled to true in the context object, that all down-scaling should use bicubic resampling(I haven't tried yet, but I think the scale use bicubic sampling). I think it is is a miss in the specification that the method drawImage doesn't use bicubic resampling. It is a method of the context objext on des down-scaling. GPUs don’t do bicubic resampling natively. You may also find that javascript can give enough performance to be usable: http://people.mozilla.org/~jmuizelaar/image-scaling/scale.html -Jeff
Re: [whatwg] Bicubic filtering on context.drawImage
On Dec 9, 2013, at 2:29 PM, Tingan Ho tin...@p1.cn wrote: Tingan, would it be acceptable for you to do the resampling in JavaScript? First, writing it in Javascript is less performant. Since natively you can have access to the GPU. Second, it is abstract a layer for JS developers, since they don't need to care about bicubic resampling algoritmen. Third, it kind of make sense if you set imageSmothingEnabled to true in the context object, that all down-scaling should use bicubic resampling(I haven't tried yet, but I think the scale use bicubic sampling). I’m not sure why you have a bias towards bicubic filtering as there are many different scaling filters that can be used. Lanczos is better than bicubic in many (most?) cases. Spline scaling can also do a good job, as can fractal interpolation. There are even specific scaling systems like Sal which are designed for upscaling sprites, and do a better job at the specific task than anything else (IIRC this is frequently used by the various old console emulators) —Oliver
Re: [whatwg] Bicubic filtering on context.drawImage
I’m not sure why you have a bias towards bicubic filtering as there are many different scaling filters that can be used. Lanczos is better than bicubic in many (most?) cases. Spline scaling can also do a good job, as can fractal interpolation. That would be even better. At least if I can opt-in for the one I want. But I think most developers also don't want to dive into this algorithms, so it would be good to have default values that perform well. right now I don't know exactly what all browser vendors are using, maybe bilinear? But it result in very poor image quality. I think it also breaks consistency that drawImage doesn't behave the same way as you would scale up and down an ordinary HTML Image object. On Mon, Dec 9, 2013 at 10:15 PM, Oliver Hunt oli...@apple.com wrote: On Dec 9, 2013, at 2:29 PM, Tingan Ho tin...@p1.cn wrote: Tingan, would it be acceptable for you to do the resampling in JavaScript? First, writing it in Javascript is less performant. Since natively you can have access to the GPU. Second, it is abstract a layer for JS developers, since they don't need to care about bicubic resampling algoritmen. Third, it kind of make sense if you set imageSmothingEnabled to true in the context object, that all down-scaling should use bicubic resampling(I haven't tried yet, but I think the scale use bicubic sampling). I’m not sure why you have a bias towards bicubic filtering as there are many different scaling filters that can be used. Lanczos is better than bicubic in many (most?) cases. Spline scaling can also do a good job, as can fractal interpolation. There are even specific scaling systems like Sal which are designed for upscaling sprites, and do a better job at the specific task than anything else (IIRC this is frequently used by the various old console emulators) —Oliver -- Sincerely, Tingan Ho tin...@p1.cn
[whatwg] Bicubic filtering on context.drawImage
Hi Whatwg, I'm a web developer in need of bicubic filtering on context.drawImage. I use to crop and scale images on the web using canvas. And I noticed that quality when you scale down very much is very bad on canvas. I scale down images using context.drawImage. There is no way for me to opt in for which filter method to use. I thought it was a bug first, because I thought context.webkitImageSmoothingEnabled did the job. But it didn't. So I filed a bug for chrome. But they suggested me to email you guys. https://code.google.com/p/chromium/issues/detail?id=326640 -- Sincerely, Tingan Ho tin...@p1.cn
Re: [whatwg] Bicubic filtering on context.drawImage
On Mon, Dec 9, 2013 at 5:29 PM, Tingan Ho tin...@p1.cn wrote: Hi Whatwg, I'm a web developer in need of bicubic filtering on context.drawImage. I use to crop and scale images on the web using canvas. And I noticed that quality when you scale down very much is very bad on canvas. I scale down images using context.drawImage. There is no way for me to opt in for which filter method to use. I thought it was a bug first, because I thought context.webkitImageSmoothingEnabled did the job. But it didn't. So I filed a bug for chrome. But they suggested me to email you guys. https://code.google.com/p/chromium/issues/detail?id=326640 Hm, I wonder if image-interpolation on the canvas should affect this? It's defined to only have an effect when you scale the canvas element itself, but I think it probably makes sense that whatever scaling intent you specify for the element should probably apply to images you draw into it with a scale. ~TJ
