On Thu, May 29, 2014 at 7:45 AM, Justin Novosad <ju...@google.com> wrote:

> On Thu, May 29, 2014 at 9:59 AM, Glenn Maynard <gl...@zewt.org> wrote:
>> On Thu, May 29, 2014 at 1:32 AM, Rik Cabanier <caban...@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.

I'm not sure if we want to bake in the device's color profile into the
output bitmap by default because on re-import it will then go through color
management and its pixels will look different from the unmanaged canvas

Reply via email to