W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

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

From: Justin Novosad <junov@google.com>
Date: Thu, 29 May 2014 10:45:33 -0400
Message-ID: <CABpaAqTe0MmyoVykDwZPBTXzEqYNexBv95w0VkNgbOCknuKwQg@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: whatwg <whatwg@lists.whatwg.org>, Noel Gordon <noel.gordon@gmail.com>, Rik Cabanier <cabanier@gmail.com>
On Thu, May 29, 2014 at 9:59 AM, Glenn Maynard <glenn@zewt.org> wrote:

> On Thu, May 29, 2014 at 1:32 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>
> > This has been requested before. ie
> >
> http://lists.whatwg.org/pipermail/help-whatwg.org/2013-May/001209.html
> > The conclusion was that this can be accomplished using JavaScript. There
> > are JS libraries that can compress images and performance is very good
> > these days.
> >
>
> This is a nonsensical conclusion.  People shouldn't have to pull in a PNG
> compressor and deflate code when a PNG compression API already exists on
> the platform.  This is an argument against adding toDataURL at all, which
> is a decision that's already been made.
>
> +1
I would add that the fact that such libraries even exist despite the fact
that the platform provides a competing API proves that the API is not what
it should be.

Also, an encoder written in JavaScript cannot produce color-managed results
because we do not have any APIs that expose color profiles. I am guessing
that png encoders written in JS probably assume that data returned by
getImageData is in sRGB, which is often not the case.  toDataURL, on the
other hand, has the possibility of encoding into the png, a color profile
that expresses the canvas backing store's color space. I know current
implementations of toDataURL don't do that, but we could and should.

   -Justin


> --
> Glenn Maynard
>
Received on Thursday, 29 May 2014 14:46:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:28 UTC