W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2016

Re: [whatwg] Reviving ImageBitmap options: Intend to spec and implement

From: Justin Novosad <junov@google.com>
Date: Wed, 10 Feb 2016 14:01:47 -0500
Message-ID: <CABpaAqTr2+MtUH=FFHqY0sg-Z5M-BgXOEs_5w=d5tr5FsWifsQ@mail.gmail.com>
To: Gregg Tavares <gman@chromium.org>
Cc: WHAT Working Group <whatwg@whatwg.org>
On Wed, Feb 10, 2016 at 1:29 PM, Gregg Tavares <gman@chromium.org> wrote:

> Is there a reason in the proposal many of the options default to
> "implementation specific behavior"?
>

Yes. It is because different browsers have implemented their graphics
pipelines in different ways. For example, decoded images may or may not be
cached in a form that has the display device's color profile baked-in.  The
defaults are designed to avoid coercing implementation into a specific
graphics pipeline design. This follows what was done in WebGL with pixel
storage parameters. See UNPACK_COLORSPACE_CONVERSION_WEBGL :
https://www.khronos.org/registry/webgl/specs/latest/1.0/#PIXEL_STORAGE_PARAMETERS

Similarly, implementation may or may not be designed in a way where storing
images in alpha pre-multiplied form is optimal.


>
> If the point of ImageBitmap is to get the data (use Image if you don't
> care), then it seems like having any "implementation defined" options,
> especially as the default, is just asking for lurking bugs in websites.
>

Debatable. In blink, for example, images get the display color profile
applied at image decode time and the WebGL render buffer goes straight to
display with out any color space conversion. Other implementations may use
an sRGB or other intermediate color space and apply a color correction
downstream when bringing the render buffer to the display. Blink might do
this in the future too, who knows. There are pros and cons to both
approaches which we do not need to debate here, but the fact is that there
are a lot of differences between implementations, which we have to live
with. And it is not all bad that the spec allows for this flexibility,
which allows implementors to chose certain compromises. So using the
browser default color space conversion should be the right thing when
passing color values straight through WebGL (or 2D canvas). And forcing no
color correction, should be the right thing for image data that is not
color values (like bump maps).  Right now we are missing a solution for
device-independent (or implementation-independent) shading, but that is a
WebGL problem.
Received on Wednesday, 10 February 2016 19:02:17 UTC

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