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

In article <408d3322$1@news.povray.org>,
 Nicolas Calimet <pov### [at] freefr> wrote:

> > It is portable.
> 
> 	Indeed, and this is why I answered to myself that I was wrong.

Oh, I see it now... "Yes, most likely."
I just mentally set it aside to figure out what you were talking about 
later, and it never "clicked". Sorry.


> It's just that I'm so used to softwares writing raw floating-point data
> by people who don't even know what is endianness that I was immediatly
> suspicious of using floating point in PNG... until I re-read your
> message and the bit distribution you proposed.

Understandable. Most people take the easy way out, either through 
ignorance or laziness. It'd probably be different if the C library 
included functions for converting to some cross-platform standardized 
format.


> 	As Christoph suggests, that would be quite nice to make it in
> the official PNG format, instead of making it a derivative.  That could
> go in e.g. libpng-1.3 -- the only drawback is: when would it appear ?
> (png and zlib developpers are not particularly fast at releasing new
> versions, and I don't know their policies in accepting contributions).

Well, I'll find out when I get around to emailing them about 
it...probably not until after finals.

-- 
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