   Float packing
  Most of my data are in the [-2, 2] range, such as pixel 154 109 -0.007666 -0.002736 0.032422 0.508851pixel 154 110 0.060688 -0.113596 0.179429 0.849869pixel 154 111 -0.138292 -0.330974 0.462604 1.451673...So it's convenient to renormalize the data to [0,1] and store in RGBA texture.But I can't do that because about 10% of the data have large signed values in at least one channel:pixel 164 119 2846.726463 -0.197024 0.378962 0.904985pixel 96 103  -0.112487 128469.656514 -212368.296140 1.364759I estimate the bounds are [-250000, 250000], though other sets of data may change.I am willing to devote four bytes instead of one to represent each float, hence creating more textures.I thought of using integer math. But to accommodate for the large signed values, the float part will have small precision.Also there is that convert to base 256 method. Not sure how that copes with large values.Any ideas? Must I use hdr format?   
  You can store the floats in any number of formats. It depends on your needs: what you are using it for? Storing normals? Colors?How much of that range [-250000, 250000] is actually covered. How many components do you need to store? one, two, three, or four? Your best bet is to get to work :P Start testing different formats and see the results.   ;Quote:Original post by smasherprogYou can store the floats in any number of formats. It depends on your needs: what you are using it for? Storing normals? Colors?How much of that range [-250000, 250000] is actually covered. How many components do you need to store? one, two, three, or four? Your best bet is to get to work :P Start testing different formats and see the results.Those are test function parameters to brdfs, so I must store all of them.90% are within [-2,2]. So anything above that would appear as outliers if the data is graphed.Maybe I should try RGBE, though for the pixels where there is much dynamic range in between the channels, the accuracy would tank I assume? And in pixel shaders, especially for old cards, is pow() or exp() very expensive as part of decoding process?   ;  get the max of the 3 channelsmaxVal=max(abs(c.r),max(abs(c.g),abs(c.b)));normalize them by this valuec=c/maxVal;encode those 3  as bytesout.rgb=c*0.5f+0.5f;store the power of two exponent of maxval in alphaout.a = log(maxVal)/log(2.f);reconstruction should bec = (in.rgb*2.f-1.f)*pow(2.f,in.a);just an idea, didn't validate it (and there is quite some room for optimization).;  Half-precision floats only have a range of +/-65K, but they are otherwise exactly what you want.  Here are a couple of 32->16->32 bit converters:http://stackoverflow.com/questions/1659440/32-bit-to-16-bit-floating-point-conversion/3542975#3542975http://cellperformance.beyond3d.com/articles/2006/07/update-19-july-06-added.html   