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

On Thu, May 29, 2014 at 11:21 AM, Rik Cabanier <cabanier@gmail.com> wrote:

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

I think you meant "encode" rather than "bake in" that above sentence.
Correct?  Currently, the non-color managed output of toDataURL has the
display profile baked in.

Take the following code:

var image = newImage()
image.src = canvas.toDataURL('image/png');
image.onload = function() { canvas.drawImage(image, 0, 0); }

Under a non color managed implementation, the above code will not modify
the content of the canvas in any way because there are no color space
conversions since the png is not color managed... All is good.  If
toDataURL encoded a color profile, the behavior would remain unchanged
because the color correction applied during the image decode would do
nothing (converting to and from the same color space). Again, all is good.

However, if the data URL was to be sent over the network to be decoded on a
different machine, then you are screwed with a non-color managed png,
because the sender's display's color profile is baked-in to the image but
there is no color profile meta data to allow the receiver to bring the
image into a known color space.

   -Justin

Received on Thursday, 29 May 2014 15:50:38 UTC