 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've checked the documentation and don't see an easy way of doing this. What
I want to do is generate high precision data, such as 32-bit floating point
values per color. Is there a way to do this with vanilla POV-Ray?
Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 24 Aug 2004 10:47:18 EDT, "" <nomail@nomail> wrote:
> I've checked the documentation and don't see an easy way of doing this. What
> I want to do is generate high precision data, such as 32-bit floating point
> values per color.
clipped ot not ?
> Is there a way to do this with vanilla POV-Ray?
IIRC PNG supports more than 8 bits per color.
ABX
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: Outputing floating point or 32-bits per color frame data
Date: 24 Aug 2004 12:04:32
Message: <412b6710@news.povray.org>
|
|
|
| |
| |
|
|
nomail@nomail wrote:
> I've checked the documentation and don't see an easy way of doing this. What
> I want to do is generate high precision data, such as 32-bit floating point
> values per color.
I think you mean "per color component", not "per color"?
> Is there a way to do this with vanilla POV-Ray?
Nope. It would require modifications to the source code of POV-Ray.
I think there are some unofficial patches which support something
similar to what you want to do, but I don't remember any details.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: Outputing floating point or 32-bits per color frame data
Date: 24 Aug 2004 12:13:39
Message: <412b6933$1@news.povray.org>
|
|
|
| |
| |
|
|
nomail@nomail wrote:
> I've checked the documentation and don't see an easy way of doing this. What
> I want to do is generate high precision data, such as 32-bit floating point
> values per color. Is there a way to do this with vanilla POV-Ray?
POV-Ray supports 16 bit output in various formats for a long time and
MegaPOV 1.1 supports high dynamic range output in Radiance RGBE format.
32bit floating point output would only be completely portable in form of
an ASCII file format and that would not be useful for most purposes
(because extremely large).
--
Christoph Hormann
http://www.tu-bs.de/~y0013390/
Post a reply to this message
|
|
| |
| |
|
|
From: Nicolas Calimet
Subject: Re: Outputing floating point or 32-bits per color frame data
Date: 24 Aug 2004 14:32:19
Message: <412b89b3@news.povray.org>
|
|
|
| |
| |
|
|
> 32bit floating point output would only be completely portable in form of
> an ASCII file format
There are binary, portable alternatives. E.g. netCDF
http://my.unidata.ucar.edu/content/software/netcdf/index.html
- NC
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: Outputing floating point or 32-bits per color frame data
Date: 24 Aug 2004 14:57:54
Message: <412b8fb2@news.povray.org>
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmx de> wrote:
> 32bit floating point output would only be completely portable in form of
> an ASCII file format and that would not be useful for most purposes
> (because extremely large).
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.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: Outputing floating point or 32-bits per color frame data
Date: 24 Aug 2004 16:19:57
Message: <412ba2ed@news.povray.org>
|
|
|
| |
| |
|
|
Warp wrote:
>
> 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.
>
If you have a portable code for reading and writing 32-bit IEEE floating
point numbers i would be happy to see.
--
Christoph Hormann
http://www.tu-bs.de/~y0013390/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If you have a portable code for reading and writing 32-bit IEEE
> floating point numbers i would be happy to see.
I'd be happy to show you some as long as you don't mind it being written
in Java :->
There may be plenty of reasons to dislike it but it has its moments.
Daniel
--
A most peculiar man With the windows closed And Mrs Reardon says
He died last Saturday So he'd never wake up He has a brother somewhere
He turned on the gas To his silent world Who should be notified soon
And he went to sleep And his tiny room .oO( http://sad.istic.org/ )
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: Outputing floating point or 32-bits per color frame data
Date: 24 Aug 2004 17:28:14
Message: <412bb2ed@news.povray.org>
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> If you have a portable code for reading and writing 32-bit IEEE floating
> point numbers i would be happy to see.
You mean there are formats which are impossible to read and interpret
correctly with C++? I find that hard to believe.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
