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

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

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

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
ones.

Received on Thursday, 29 May 2014 15:21:37 UTC