[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Moving float color buffer proposals to draft (was Re: Fixing the OES_texture_float mess)






On Thu, Nov 15, 2012 at 2:30 PM, Mark Callow <callow.mark@artspark.co.jp> wrote:

I have updated EXT_color_buffer_half_float and WEBGL_color_buffer_float  to clarify that FLOAT reads are supported and to make the latter extension depend on the former for all language except the type tokens. I would like to move these to drafts so implementations can be done. If you have any objections, please raise them.

I propose to change the sentence in OES_texture{_half,}_float beginning "The WebGL implementation may optionally accept ..." to

The WebGL implementation my optionally accept a texture with pixel type {FLOAT, HALF_FLOAT_OES}. In such implementations, enabling this extension must implicitly enable the {EXT,WEBGL}_color_buffer{_half,}_float extension and the {float,half-float} rendering support must comply with that specification.

I am undecided whether make this change when the color buffer extensions become draft or when there is at least one implementation. Opinions?

I just noticed the following in OES_texture{_half,}_float ...

The texImage2D and texSubImage2D entry points taking ImageData, HTMLImageElement, HTMLCanvasElement and HTMLVideoElement are extended to accept the pixel type FLOAT

What is this supposed to do? The type parameter is used to tell the implementation what type of data is being passed in.


The type parameter tells WebGL what format to convert the ImageData/HTMLImageElement/HTMLCanvasElement/HTMLVideoElement into before calling texImage2D. Allowing GL_FLOAT there means you can upload images into float textures. (maybe you'd like to edit them with floating point precision)
 

I do not know any way to get float, never mind half-float, data in any of the listed HTML elements so this statement seems completely pointless. It should be deleted.


WebGL's intent is supposed to be a lossless upload when the source image is the same format as the format being requested. The spec currently only requires that for 8bit textures.

Safari actually supports loading FLOAT TIFF files in image tags so arguably it should allow uploading those directly into FLOAT textuires without loss of data. Maybe you should add that language to the spec like the main spec has for 8bit lossless formats. I'm happy to add add a test. 

If the intention is for the implementation to convert the incoming data to {half-,}float then what is needed is for the internalformat parameter to accept one of the tokens from the new extensions: RGBA16F, RGBA32F etc.


Why? ES 2.0 doesn't specify stuff that way. It's broken but it infers the internal format from the combination of format/type.

So in WebGL, 
   
     texImage2D(...., GL_RGBA, GL_RGBA, GL_FLOAT, image)  

Says: Take the data in 'image'. Convert to RGBA32F then create an RGBA32F texture. There are tests for this

Yes, internal_format/format/type in ES 2.0 is busted. I believe this has been fixed in ES 3.0 but I'm not sure it's backward compatible. (haven't looked)


Regards

    -Mark

--
注意:この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.

NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.