W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Re: [css3-images] image-rendering property for contrast-preserving image upscaling

From: Lech <unattended@gmail.com>
Date: Sat, 5 Feb 2011 10:37:46 -0600
Message-ID: <AANLkTimH-Qu6+bjN=f83jSJOrbtRmHntszGRT5xjaEzX@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:37 GMT