Re: Down sampling guidance for raster content in SVG.

On Tue, Apr 15, 2014 at 9:54 AM, Tavmjong Bah <tav.w3c@gmail.com> wrote:
> On Tue, 2014-04-08 at 12:35 -0700, Tab Atkins Jr. wrote:
>> And the speed at which Images 4 advances is solely a function of what
>> implementors want to implement.  If there are individual features,
>> like image-rendering, which are being implemented and which people
>> would appreciate being in a higher-maturity-level draft, let me know
>> and I can kick them back to Images 3 (and do a quick LC->CR cycle) as
>> appropriate.
>
> Inkscape implements 'image-rendering' with the SVG 1.1 values 'auto',
> 'optimizeSpeed', and 'optimizeQuality'; with the 'optimizeSpeed' value
> corresponding to keeping the image blocky (using "nearest neighbor" for
> the algorithm). This was a requirement from our users who need to be
> able to control whether or not a scaled image is kept blocky or
> smoothed. This works in Opera (Presto) but not in current Firefox or
> Chrome. (We also use this property to set/unset the PDF 'interpolate'
> entry in the image dictionary which effectively does the same thing, so
> at least export to print is correct.)
>
> Being able to set scaling behavior without the above hack is ->highly<-
> desirable. Here is a test for up-scaling:

I agree, which is why Images deprecates the optimize* values; they
were used not as performance hints, but as rendering intents, and
they're named terribly for that.

> http://tavmjong.free.fr/SVG/SCALING/image_rendering.svg
>
> In Images 4, I don't understand the difference in the values:
> 'crisp-edges' and 'pixelated'. They seem to be doing similar things.

They are similar, but not identical.  'pixelated' adds specific
constraints to the scaling algorithm.  There are examples of what an
implementation could use for 'crisp-edges' in the paragraph following
that list.

> Thomas' need is for good down-scaling. Here is a test with lines:
>
> http://tavmjong.free.fr/SVG/SCALING/image_rendering3.svg
>
> There are several algorithms available for down-scaling. There was
> recently a long discussion on the Cairo mailing list as to which method
> to use in what case (speed vs. accuracy). In the case of line art, the
> fastest methods appear to not be good enough. As one zooms in and out,
> one can see lines disappear and reappear. Chrome, at least, does do a
> reasonable job in drawing the lines after the zooming stops. It would be
> good to have a value that indicates that accurate down scaling is
> required.

'image-rendering' currently doesn't address downscaling - all values
are equivalent to 'auto' int he downscaling case.  I'd be happy to
help with that by adding a second value to the property, if you can
help me figure out what the correct rendering intents are.

> As Thomas eludes to, scaling should properly done in a linear color
> space. To see why, scale the following SVG up and down in your browser
> of choice:
>
> http://tavmjong.free.fr/SVG/SCALING/scaling_test.svg
>
> If your display is calibrated to srgb, the top two squares should be the
> same color as the bottom right square. As you zoom in, the squares will
> become darker due to the averaging being done in the srgb color space
> (and not by your eye!). But this is not as important as at least showing
> the lines when down scaling and being able to maintain the sharp
> boundaries while up scaling.

Is this something that needs to be specified, or is it just a
qualty-of-implementation issue?

~TJ

Received on Tuesday, 15 April 2014 18:55:18 UTC