If you look at the PNG specification you will see that sRGB,
iCCP, CHRM and gAMA are all documented in a section called "Color
space information". So not applying the color space - actually it
should say not applying color correction - means ignore all these
chunks. It is very clear in the PNG spec. that they are all
inter-related. I think all we need do is to clarify this in the
image orientation is not currently an issue I think. When formats
that can indicate the logical orientation of the image data become
available through an HTMLImage then we can consider if a further
flag is necessary. The issue we have now is arising because
apparently many PNG exporting tools do not provide sufficient
control over setting the color space information. If they did, the
obvious solution for none image data is to export it with a gAMA
chunk specifying a gamma of 1.0. I expect that tools exporting
formats with a settable image orientation will allow users to
choose the orientation so an additional flag will not be
necessary. In any changing the s & t orientations in a program
On Thu, Nov 18, 2010 at 3:39 PM, Kenneth Russell <email@example.com> wrote:
On Wed, Nov 17, 2010 at 4:50 PM, Gregg Tavares (wrk) <firstname.lastname@example.org> wrote:The wording in the spec is intentionally vague because some of the
> On Wed, Nov 17, 2010 at 4:05 PM, Mo, Zhenyao <email@example.com> wrote:
>> During the implementation of COLORSPACE_CONVERSION setting in webkit,
>> I began to think that maybe COLORSPACE is not the correct word for the
>> issue. What we want is the raw bits from the image data, ignoring all
>> the settings in the image header (meta data). Color space only covers
>> one of those settings. Others include gamma, image orientation, and
>> who knows what might be added in the future?
> I noticed this as well. The original intent was to provide a way to get
> exact binary data from lossless image formats into a WebGL into a texture.
> For PNG that means ignoring the sRGB, iCCP, cHRM, gAMA chucks.
> But the new UNPACK_COLORSPACE_CONVERSION_WEBGL pixelStore setting only
> mentions that colorspace will not be applied. It mentions nothing about
> gamma or other settings that might end up changing the values uploaded to
> the texture and it mentions nothing about only caring about lossless images.
> The implication is that colorspace settings should also be ignored in JPEGs
> as well.
> I thought the goal was to specify a way to guarantee, cross browser, that
> loading certain kinds of images into a WebGL textures would have the exact
> same binary values passed to glTexImage2D and related functions.
> Should we update the spec and/or the name of the enum to make that clearer?
> or maybe just changing the description of UNPACK_COLORSPACE_CONVERSION_WEBGL
> to cover the goals?
authors (like me) aren't well versed in all of the parameters of these
files. That having been said, while JPEGs aren't useful for uploading
data losslessly to WebGL, if we have an option for passing through PNG
files' data without applying an ICC color profile then I think it
might as well apply to JPEG files as well. At least in the WebKit
implementation, Mo has wired up the flag to both JPEGs and PNGs.
Personally I think the current wording is fine and we can supplant
this flag with another more tightly defined one in a future version of
the spec if necessary.
The reason vague is bad is because if you are uploading financial data as textures to the GPU to do some kind of GPU based statistical analysis, you need to know browser will not munge your data. The current spec does not say "don't munge the data", it's just assuming that is inferred which isn't enough IMO. Sure, uploading financial data as a texture is probably an not real example, it just highlights the issue.
The point of asking for this feature in the first place was the realization that not all texture data is based on colors (normals, heightmaps, opacity maps, etc) and there is no good path for getting that kind of data to textures except for the Image tag. If the spec does not guarantee that the data must be lossless then we might as well not even have this option and just always let the browser do whatever it feels like.
Even your interpretation above seems wrong. There is more than just the ICC profile that effects how browsers load pngs. There's also the sRGB tag. The gAMA chunk that specifies a gamma setting and the cHRM chunk which is a more flexible gamma setting. Since the spec doesn't mention those nor mention lossless, based on your comment, it sounds like you'd have implemented this only ignoring the ICC profile chunk which would not have been enough. I think that kind of proves my point that the spec is not clear enough.
begin:vcard fn:Mark Callow n:Callow;Mark org:HI Corporation;Graphics Lab, Research & Development adr:Higashiyama 1-4-4, Meguro-ku;;Meguro Higashiyama Bldg 5F;Tokyo;;153-0043;Japan email;internet:firstname.lastname@example.org title:Chief Architect tel;work:+81 3 3710 9367 x228 tel;fax:+81 3 5773 8660 x-mozilla-html:TRUE url:http://www.hicorp.co.jp, http://www.mascotcapsule.com version:2.1 end:vcard