Re: [Paracomp-spec] RFC : Extension EXT_datatype_float - floating point datatypes for compositing

[Randall F. <ran...@co...>]

Hello,
   I have to ask why not 16bit ints, perhaps in W space?
The 16bit float is necessary, I agree, but expensive to
implement while the int form is relatively cheap.  I know
HDR folks may not like the linear space, but for extended
blending, it works pretty well and is fast.

Thanks.

Shree Kumar wrote:
> Motivation :
> 
> Paracomp currently has support for only 8 bit unsigned color components. 
> This is not enough in many cases where better precision is needed. 
> Floating point data types are increasingly being used in rendering 
> algorithms. So it is useful to extend the API to support higher 
> precision floating point data types.
> 
> Floating point values with 16 bit & 32 bit precision are supported on 
> GPUs. 16 bit values supports a lower range of values, but are adequate 
> for a good number of applications. They take lesser bandwidth and 
> storage space, and could offer higher performance for the applications 
> which don't need the extra precision.
> 
> Rough extension description :
> 
> These new values will be supported by PC_PIXEL_FORMAT:
>    1. PC_PF_RGBA32F_EXT - 4 component RGBA, with each being a single 
> precision value (following the IEEE 754 standard)
>    2. PC_PF_RGB32F_EXT - 3 component RGB, with each being a single 
> precision value (following the IEEE 754 standard)
>    3. PC_PF_RGBA16F_EXT - 4 component RGBA, with each a half precision 
> floating point value. The floating point format is the same as for the 
> OpenGL extension ARB_half_float_pixel. This floating-point format is 
> very similar to the IEEE single-precision floating-point standard, 
> except that it has only 5 exponent bits and 10 mantissa bits.
>    4. PC_PF_RGB16F_EXT - 3 RGBA, each being a half precision floating 
> point value.
> 
> RGBA values will be valid for both DEPTH & ALPHA_SORT compositing. (It 
> will also be valid for the ADD operator, once that is included as an 
> extension)
> 
> RGB values will be valid for DEPTH compositing, but not for ALPA_SORT. 
> It may also make sense to support RGB values for the ADD operator with 
> PC_ALPHA_BEHAVIOUR set to PC_ALPHA_SEPARATE. Please refer to the 
> extension proposal for ADD operator in a separate email.
> 
> Questions/Comments are welcome. 32 bit floating point values are 
> proposed by Technical University of Budapest. The 16 bit floating point 
> values are included by me.
> 
> Note :
> 
> An implementation of these pixel formats is already available for trying 
> out at :
> 
> http://paracomp.svn.sourceforge.net/viewvc/paracomp/branches/developer/shree/feature/composite_float/
> 
> samples/intermediate/multithreaded.cpp demonstrates using these 
> datatypes on a single node.
> 
> It uses the Half class from the OpenEXR software distribution 
> (www.openexr.com) to composite 16 bit floating point values. These 
> values are not native types on the CPU, so compositing is quite slow. 
> Compositing on the GPU seems to be a better bet in this case.
> 
> For 32 bit floating point, CPU compositing is used. No optimization has 
> been done, so expect things to be slow in this case too.
> 
> Regards
> -- Shree
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Paracomp-spec mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/paracomp-spec
> 

-- 
rjf.

-------------------------------------------------------------
| Quando omni flunkus moritati                              |
| Randall Frank                  ran...@co... |
-------------------------------------------------------------