- From: Lech <unattended@gmail.com>
- Date: Sat, 5 Feb 2011 10:37:46 -0600
- To: www-style@w3.org
Sorry for resurrecting a topic like this, but if it's not yet set in stone I may have a constructive solution for this: As many authors are indeed asking for 'nearest-neighbor' scaling explicitly for pixel art/editors and anything which requires pixel precision at zoom. Instead of abstracting away the name of the given method for image scaling or filtering, why not allow authors the option to specify the method value explicitly as suggested? To add what Robert was suggesting, calling the as it's named, for example "image-rendering: nearest-neighbor;" as a minimum, explicitly named base requirement and leaving it up to vendors (collectively) to also make available any other scaling or filter methods which are available (Bilinear seems wide-spread) to the authors along with any new methods that come along in the future (Bicubic/Lanczos/Other) to use as they please. Bilinear and Bicubic scaling are becoming fairly common now that I suspect in the it will be uncommon not to find these filtering and scaling methods available in the future. I'd also wager that most authors asking for these values explicitly will know what to expect based on what they're asking for. Currently I read "auto | optimizeSpeed | optimizeQuality | inherit" as the values under http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty, adding another value to specify the scaling or filtering method explicitly would help in many ways by giving options to over-ride the UA. I suspect that optimizeSpeed and Quality are targeted toward mobile devices which are slowly gaining on desktop systems so I can guess that if and by the time this becomes final AND fully supported across the board it may already be out-dated. In any case, having these options would certainly be a bonus. My two cents, -L >On Thu, Dec 2, 2010 at 6:34 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > >> On Fri, Dec 3, 2010 at 3:13 PM, Gregg Tavares (wrk) <gman@google.com>wrote: >> >>> On Thu, Dec 2, 2010 at 5:59 PM, Robert O'Callahan <robert@ocallahan.org>wrote: >>> >>>> On Thu, Dec 2, 2010 at 3:04 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote: >>>> >>>>> Gimme a name for the new value and I'll add it to Image Values. >>>>> >>>> >>>> I think sometimes authors explicitly want nearest-neighbour (e.g. to >>>> expose the pixel data of an image, perhaps in an editor), so we might want >>>> to provide 'nearest-neighbor' explicitly. >>>> >>>> For what James described as "optimize-contrast", maybe >>>> "optimize-contrast" is the best name. Or maybe "preserve-contrast". >>> >>> >>> I agree. I don't understand "optimize-contrast" >>> >>> Does that mean If I have 5 pixels black,red,blue,green,white and I scale >>> to 10 pixels I'll get >>> >>> black,black,red,redish-purple,bluish-purple,blue,blueish-green,green,white,white >>> since by some definitions there is no contrast between red,green,blue so >>> those would be blended >>> >>> Why not just say "nearest-neighbor" if that's the effect people are asking >>> for? >>> >> >> For some use-cases, e.g. emulators, we want to allow scaling algorithms >> more elaborate than nearest-neighbor, like the ones Tab linked to earlier. >> > > I understand that but suspect the user or the developer would want to choose > the algorithm, not leave it up to the browser. If the browser chooses the > wrong one the results will not be pleasant. Different algos work better with > different content. The UA has no way of knowing which is best for a given > piece of content or page. > > >> >> But one option is to tell those authors to implement their own scaling >> algorithms in WebGL. >> >> Rob >> -- >
Received on Sunday, 6 February 2011 22:16:18 UTC