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

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 29 May 2014 12:17:12 -0700
Message-ID: <CAGN7qDDaVwFS7+w=H1mgoHyUvkoJxy0GrD8jyNV9myXSEHywhQ@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: whatwg <whatwg@lists.whatwg.org>, Noel Gordon <noel.gordon@gmail.com>, Glenn Maynard <glenn@zewt.org>
On Thu, May 29, 2014 at 8:50 AM, Justin Novosad <junov@google.com> wrote:

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

That's right.
The values of pixels on the canvas are the same on every machine, but we
have many different types of monitors. The png's that are generated should
all be identical pixel-wise but their attached profiles might be different.


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

You are screwed either way :-)
I think authors are going to be surprised that pixels will end up
different. (Imagine taking screenshots of achievements in a game that are
put in an online gallery)
If you put the profile in and it is different from sRGB, the png will look
different from the original canvas because you now will go through an
intermediate sRGB space which will warp the color range.

As an example, I did a toDataURL of this codepen example:
http://codepen.io/Boshnik/pen/vFbgw
I then opened it up in Photoshop, attached my monitor profile and wrote a
small script that does a difference on them:
http://cabanier.github.io/BlendExamples/images.htm

If you run windows, you will see that there's content in the canvas output.
For some reason, Mac doesn't do any color conversion on any browser.
Even on my own system, there's a difference because of the sRGB conversion:
http://cabanier.github.io/BlendExamples/screenshot.png
Received on Thursday, 29 May 2014 19:17:38 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:20 UTC