- From: Justin Novosad <junov@google.com>
- Date: Thu, 29 May 2014 10:45:33 -0400
- 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