war### [at] tagpovrayorg news:412b8fb2@news.povray.org

>   The IEEE 32-bit floating point format is very well specified and
> there should not be problems in making any program to read that (even
> if the target architecture does not support IEEE floats, it should not
> be a problem to convert from the IEEE format to whatever format the
> architecture in question uses).
>   32 bits per color component makes the (uncompressed) image file 4 times
> bigger than a regular full-color image file, but that's not unacceptable.

Btw, how about in addition a text file? Like:

width_pixels height_pixels
maximum_value_of_RGB_component
pixel_y0_x0 pixel_y0_x1 pixel_y0_x2 pixel_y0_x3
pixel_y1_x0 pixel_y1_x1 pixel_y1_x2 pixel_y1_x3

and each pixel is:red green blue where each R,G,B is either a float or a 
integer ranged from 0 .. maximum_value_of_RGB_component (usualy 0 - 255 or 
0.0 - 1.0)

So for example:

640 480
1.0
1.0 0.0 0.0 0.5 0.5 0.0 (...)
0.9987 0.0 0.0 0.499 0.499 0.0 (...)

is an 640x480 image with red pixel, then yellow, in first line, etc.

As addition to IEEE floats format - it would be very easy to read form user 
program and still it will have very heavy quality

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message