Re: [css-images][svg2] gradient rendering and the image-rendering property

Amelia,

Keep up the good work of bringing up these topics.

I would suggest to add a new property not to break old content and have  
the added benefit of being able to use different properties for different  
content. Quite often as a designer you'd like to set different behaviours  
to different objects, i.e. have vectors and bitmaps have different  
effects. Instead of having to put a pixelation filter, define that and get  
it to behave the same accross renderers, this might be a great method to  
have things behave differently. I would even go as far as to suggest  
playing around with this idea a bit further and allow authors to set  
methods of dithering. For example to generate a pixelated rendering of  
gradients that are blocks of pixels (or other units) like 1x1, 2x2, 20x20  
and maybe even floats to get specific effects. Hmm,.. how about different  
rastisations on that to simulate the good old printers (diamonds and  
stuff). I admit not to be sure how that would work out on the  
computational side of things, but it certainly would allow for interesting  
effects to be created. Granted, those are filters really, but could be  
used as basic filters to great effect on retina display quality levels and  
be portable to print at the same time. But maybe we should wait for SVG  
3.0 to come into view in the next 15 years as things are getting close to  
recommendation level?

Cheers,

Jelle Mulder



On Wed, 03 Feb 2016 11:11:03 +0800, 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
> The image or gradient should be rendered with an algorithm that balances  
> a smooth appearance with >performance.
> smooth
> The 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
> 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
> 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
>
>



-- 
Using Opera's mail client: http://www.opera.com/mail/