Re: [whatwg] Proposal: toDataURL “image/png” compression control

On Mon, Jun 2, 2014 at 12:49 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> That's implementation cost to you :-)
>
Now we need to convince the other vendors. Do they want it, want more, want
> it in a different way?
> Then it needs to be documented. How can authors discover that this is
> supported? How can it be poly-filled?
>

Polyfill isn't really an issue, since this is just a browser hint.  We
definitely need a way to feature test option arguments, but we should start
another thread for that.

This needs a bit more guidance in the spec as far as what different numbers
mean.  A quality number of 0-1 with JPEG is fairly well-understood--you
won't always get the same result, but nobody interprets 1 as "spend 90
seconds trying as hard as you possibly can to make the image smaller".
 There's no common understanding for PNG compression levels, and there's a
wide variety of ways you can try harder to compress a PNG, with wildly
different space/time tradeoffs.  By order of cost:

- Does 0 mean "output a PNG as quickly as possible, even if it results in
zero compression"?
- What number means "be quick, but don't turn off compression entirely"?
- What number means "use a reasonable tradeoff", eg. the default today?
- What number means "prefer smaller file sizes, but I'm expecting an order
of 25% extra time cost, not a 1500%"?
- Does 1 mean "spend two minutes if you want, make the image as small as
you can"?  (pngcrush does this, and Photoshop in some versions does
this--which is incredibly annoying, by the way.)

If there's no guidance given at all, "0" might mean either of the first
two, and "1" might mean either of the last two.

My suggestion is an enum, with three values: "fast", "normal", "small",
which non-normative spec guidance suggesting that "fast" means "make the
compression faster if possible at the cost of file size, but don't go
overboard and turn compression off entirely", and "small" means "spend a
bit more time if it helps create a smaller file, but don't go overboard and
spend 15x as long".  If we want to support the other two, they can be added
later (eg. "uncompressed" and "crush").  Since this is only a hint,
implementations can choose which ones to implement; if the choice isn't
known, fall back on "default".

A normative requirement for all PNG compression is that it should always
round-trip the RGBA value for each pixel.  That means that--regardless of
this option--a UA can use paletted output only if the image color fits in a
palette, and it prohibits things like clamping pixels with a zero alpha to
#000000, which is probably one strategy for improving compression (but if
you're compressing non-image data, like helper textures for WebGL, you
don't want that).

On Mon, Jun 2, 2014 at 1:23 PM, Nils Dagsson Moskopp <
nils@dieweltistgarnichtso.net> wrote:

> As an author, I do not see why I should ever want to tell a browser
>
losslessly encoding an image any other quality argument different from
> „maximum speed“ or „minimum size“ – on a cursory look, anything else
> would probably not be interoperable. Also, is 0.5 the default value?
>

Image compression is uninteroperable from the start, in the sense that the
each UA can always come up with different output files.  This feature (and
the JPEG quality level feature) doesn't make it worse.

-- 
Glenn Maynard

Received on Monday, 2 June 2014 19:23:20 UTC