[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] UNPACK_COLORSPACE_CONVERSION_WEBGL added
- To: "Gregg Tavares (wrk)" <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] UNPACK_COLORSPACE_CONVERSION_WEBGL added
- From: Kenneth Russell <email@example.com>
- Date: Wed, 6 Oct 2010 13:56:29 -0700
- Cc: firstname.lastname@example.org
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1286399053; bh=fLZJLnN9hukcv/iSP21jNrWd2Vs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=jrI5ynE2R6d4iy62/6j722F849Ee1CDcLaxnQ+omIozU98S+5G15ONKkwg+pDzvKD 3MuvsMAqiDyc6Og1+Rb1w==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4zCqBtpmLdp1IFwhYc3e77uJXTaq/S1ooxy2RSUIMJQ=; b=vDQJiaGOMmBoDDMIB+7vI8Gl6auw8KrTbjQE/lDum+aKvA2XC1o/edgQmeXS6tuNpG 4uZlfbrpv7csUHzZY+rQ==
- Domainkey-signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RuRIuAEHmVjqkt503OhIwlYDt9J60PJE6BiI3cfcNZsPOoSCc+qT3TDHjt+6SDFAuv 98o4cSSU+q3gYxcyT3ZQ==
- In-reply-to: <AANLkTin3jp8sfzaA8APJJyRbgqSFJx8_U_KRxPGcLe_email@example.com>
- References: <AANLkTikQsx4p0pXpLumrgkS1atU5t4h_zT+pB0J-=PgM@mail.gmail.com> <AANLkTin3jp8sfzaA8APJJyRbgqSFJx8_U_KRxPGcLe_firstname.lastname@example.org>
- Sender: email@example.com
The thinking of the working group (correct me if my recollection is
wrong) was that the majority of web developers will upload images as
WebGL textures and, with no lighting applied, expect the rendered
output to look the same as the img tag. The scenario where the
developer requires the pixel data to be completely unmodified, because
they are uploading normal maps or other non-color data, seems to be
the minority use case.
On Tue, Oct 5, 2010 at 10:30 PM, Gregg Tavares (wrk) <firstname.lastname@example.org> wrote:
> I'm sure this discussion already happened so it would be nice to know the
> thoughts that lead to it to default to BROWSER_DEFAULT_WEBGL but without
> knowing that discussion it seems like it should default to NONE.
> The reason is, most developers coming from OpenGL will not even bother to
> look at the docs. So, they'll write their app without setting this flag, it
> will appear to work on a particular browser because that browser happens to
> be doing what they expect (no conversion). Only later will they find out
> that it's not working in other browsers.
> If it defaults to NONE, the worst that will happen is the colors will be off
> if compared to the same image displayed in an img tag but their app will
> still work. They can then look it up and find out how to get their colors
> correct but at least in the meantime their app works everywhere.
> That would seem to match many of the other decisions to prevent apps from
> breaking across implementations.
> On Tue, Oct 5, 2010 at 11:15 AM, Kenneth Russell <email@example.com> wrote:
>> At the recent Khronos F2F the WebGL working group resolved to add a
>> new pixel storage parameter UNPACK_COLORSPACE_CONVERSION_WEBGL,
>> applying to texImage2D and texSubImage2D uploads. The default value is
>> BROWSER_DEFAULT_WEBGL, and it can be set to NONE to disable all
>> colorspace conversion by the browser (if applicable to the file type
>> being uploaded -- in particular, PNG).
>> The rationale is that there are certain situations in which the four
>> channels of RGBA textures may contain non-color information, and an
>> upload path preserving the original values in the texture is needed.
>> The WebGL spec and IDL have been updated with this change, and a bug
>> has been filed with the OpenGL registry to add the two new enums.
>> Please post any comments to the list.
>> You are currently subscribed to firstname.lastname@example.org.
>> To unsubscribe, send an email to email@example.com with
>> the following command in the body of your email:
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: