Re: Down sampling guidance for raster content in SVG.

On Tue, 2014-04-08 at 12:35 -0700, Tab Atkins Jr. wrote:
> On Tue, Apr 8, 2014 at 9:00 AM, Tavmjong Bah <tav.w3c@gmail.com> wrote:
> > On Fri, 2014-04-04 at 20:28 +0000, Smailus, Thomas O wrote:
> >> Good idea.  Just tested it and that made no difference.
> >>
> >> I suspect there isn’t even the functionality internally available to
> >> better handle subsampling raster inside of SVG content; just for PNG.
> >> That code base would need to be called to produce the subsampled SVG
> >> raster content before it is painted.
> >>
> >> The bitonal PNG still looks super, and the same image embedded as RGB
> >> color space raster in an SVG looks horrible with a good percentage of
> >> the line-art pixels now whitespace.
> >
> > 'image-rendering' is just a hint to the renderer. I attempted to get
> > more useful values for this property into SVG but ran up against the
> > property having been co-opted by CSS in a spec that won't be finished
> > for a long time.
> >
> >   http://dev.w3.org/csswg/css-images-4/#the-image-rendering
> 
> I'm sorry, I don't recall this occurring.  Can you point me back to
> your suggestions?

I don't remember when I suggested it... and it may have only been in
front of the SVG WG (which didn't want to touch it as it was now in
css-images-4).

> 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:

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.

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.

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.


> Never let concerns over spec levels dictate what you want to do.  We
> can work around anything.

Good to know.

Tav

Received on Tuesday, 15 April 2014 16:55:01 UTC