In article <c6j8q1$6rh$1@chho.imagico.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> And actually the same would be possible for 32bit floating point values, 
> you just would need to have a convention for the distribution of bits 
> for mantissa/exponent and a file format storing 32bit values (which png 
> IIRC does not). 

It would be trivial to add storage for 32 bit values...it probably would 
only consist of modifying the error checking code to allow additional 
values for depth and color type.


> And of course reading such files would be slower than 
> reading the native binary format of that particular platform.

But not hugely so, considering that you get it as an array of bytes read 
from a compressed file. The additional overhead of decoding the float 
values would be quite small in comparison.

And of course, the image will most likely be processed with native data 
types, which may not match the stored data type...that's just 
unavoidable, unless you want to emulate math on the stored data type, 
which would be much slower. I'm pretty sure all implementations of 
single-precision floats will exactly represent all possible values of 
these half-floats, but it may affect processing of single-float images.

BTW, I'm especially interested in 32 bit float grayscale images, for 
depth maps. Tri-channel images would also be useful for normal and point 
maps. The post-processing filters of MegaPOV 0.7 showed some of the 
possibilities of post processing when this data is available.

32 bit grayscale could be hacked over RGBA images. 32 bit RGB could be 
done easily as double-width 16 bit per component RGB images. But again, 
these are hacks, it'd be far better to add new depths and color types, 
which should be quite easy.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message