- From: Rick <graham.rick@gmail.com>
- Date: Wed, 3 Feb 2016 10:50:26 -0500
- To: Jonathan Wilkes <jancsika@yahoo.com>
- Cc: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, "www-style@w3.org list" <www-style@w3.org>, www-svg <www-svg@w3.org>
- Message-ID: <CAGDjS3dXeOzzE3k_gr43HPrk6-0zNwOBG-Q5F9fjn81=RQsbsg@mail.gmail.com>
When I read it, pixelated was nearest neighbour with zero smoothing and crisp edges were anti-aliased. On Wed, Feb 3, 2016 at 2:15 AM, Jonathan Wilkes <jancsika@yahoo.com> wrote: > What is the difference between "pixelated" and "crisp-edges"? > > -Jonathan > > > > > On Tuesday, February 2, 2016 10:13 PM, Amelia Bellamy-Royds < > amelia.bellamy.royds@gmail.com> wrote: > > > A discussion at the joint SVG/CSS face-to-face meeting centered on > gradient quality, and whether features such as dithering could be supported > (or required) to address banding in gradients. > > I brought up that there are already cross-browser inconsistencies in > whether colors are anti-aliased when gradients have sharp transitions > (color stops at the same offset value to create stripes), and pointed out > that anti-aliasing looks better on diagonal stripes but can look fuzzy on > horizontal/vertical stripes. Someone suggested I write up a proposal. I > initially avoided an action, but after discussion moved on I realized that > this is essentially the same issue as the image-rendering properties: > sometimes you want smooth interpolation, and sometimes you want crisp edges. > > So, the basic proposal is as follows: make the image-rendering property > apply to gradient images, including CSS and SVG gradients for an element. > Add the proposed "smooth" value to distinguish from "auto", and make the > definitions for each value as follows: > > auto <https://drafts.csswg.org/css-images-3/#valdef-image-rendering-auto>The > image or gradient should be rendered with an algorithm that balances a > smooth appearance with performance.smoothThe image or gradient should be > rendered in such a way that pixilation effects are minimized. In > particular, image scaling should smoothly interpolate color transitions, > such as by using bilinear interpolation. This is intended for images such > as photos. Gradient rendering should use anti-aliasing on sharp color > transitions and may use dithering or similar effects to minimize banding > when the color depth of the display cannot create an even color transition. > crisp-edges > <https://drafts.csswg.org/css-images-3/#valdef-image-rendering-crisp-edges>The > image or gradient should be rendered in a way that preserves contrast and > edges in the image. Images should be scaled with algorithms that do not > smooth colors or introduce blur to the image in the process. This is > intended for images such as pixel art. Gradient rendering may (or should?) > nonetheless use anti-aliasing to create clean diagonal lines.pixelated > <https://drafts.csswg.org/css-images-3/#valdef-image-rendering-pixelated>Images > must be scaled with the "nearest neighbor" or similar algorithm, to > preserve a "pixelated" look as the image changes in size. Gradients should > not use anti-aliasing or dithering. > > Some additional complications: > > - For SVG paint servers, should the value in effect on the paint > server element be used, or the value in effect on the painted shape? I > think consistency with other *-rendering properties (e.g. for color) is to > use the value on the gradient element itself. Alternatively, the "auto" > behavior on a shape could be to use the behavior on the gradient, but a > different value on the shape could override it. > - Should you be able to set different rendering hints on different > layers of CSS backgrounds (e.g. to have a smooth gradient overtop of a > crisp-edges stripe)? E.g., with a background-image-rendering property that > takes a list of values? If so, probably also want to introduce equivalent > properties for layered SVG fill and stroke paint. > > - For existing SVG content, there may be backwards compatibility > issues. E.g., if image-rendering is set on the <svg> element itself with > the expectation that it would only affect <image> elements, but now it also > affects gradients. Not sure if this would break anything badly. > > If people are worried about backwards compatibility, an alternative would > be to create a distinct `gradient-rendering` property. If so, I would want > `gradient-rendering` to use the same values as `image-rendering` as > described above, so authors would only have to memorize one set of keywords. > > ~Amelia Bellamy-Royds > > > > > -- Soap and education are not as sudden as a massacre, but they are more deadly in the long run. -- Mark Twain
Received on Wednesday, 3 February 2016 15:51:04 UTC