I understand that POV uses double precision floating point numbers
internally, it then clips them to 0..1 and scales appropiately to save to a
24-bit bitmap.  If this is correct, is there any way to output the raw
double float values for each rendered pixel to a file?  Has anyone written a
patch to do this? It doesn't seem like it will be that hard.

I would like to use the raw full-precision values in a program I am writing,
so the format doesn't matter really.

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

scott wrote:
> I understand that POV uses double precision floating point numbers
> internally, it then clips them to 0..1 and scales appropiately to save to a
> 24-bit bitmap.  If this is correct, is there any way to output the raw
> double float values for each rendered pixel to a file?  Has anyone written a
> patch to do this? It doesn't seem like it will be that hard.
> 
> I would like to use the raw full-precision values in a program I am writing,
> so the format doesn't matter really.
> 
> 
> 
Mega pov 1.1...

http://megapov.inetart.net/manual-1.1/global_settings.html#post_processing

Using the RAW format (+FR switch)... but it was dropped from latest
official. I do not know if Megapov kept it.

Notice: PNG is not limited to 8 bits per channels. You can boost it up
to 16 bits per channel if you want. (yep, that's 48 RGB bits!)

PS: printf usually as an issue with double precision, do not expect all
the digits!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCS/5is/YJ43cSjHIRAoASAJ9tifGrCf3IRBUA8l67Cg42njA5nACgi3aX
fCqrCZkkA3jP96ZnW8fvKDg=
=YoB9
-----END PGP SIGNATURE-----

Post a reply to this message

Le Forgeron <jgr### [at] freefr> wrote:
> PS: printf usually as an issue with double precision, do not expect all
> the digits!

  printf has no issues with double precision. It's just a question of
specifying the proper parameters.

    double d = 1.234567890123456789;
    printf("%.15f\n", d);

prints:

1.234567890123457

  And by the way, color values are calculated using single precision
floating points in povray.

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

Warp wrote:
> Le Forgeron <jgr### [at] freefr> wrote:
>> PS: printf usually as an issue with double precision, do not expect
>> all the digits!
>
>   printf has no issues with double precision. It's just a question of
> specifying the proper parameters.
>
>     double d = 1.234567890123456789;
>     printf("%.15f\n", d);
>
> prints:
>
> 1.234567890123457
>
>   And by the way, color values are calculated using single precision
> floating points in povray.

I would probably just write the binary to a file, rather than use printf.

So in theory I can patch the source code to output these 32-bit floats for
each colour for each pixel rendered?

I found the following code in pvbmp.cpp:

 for (i = 0 ; i < width ; i++)
  {
    out << (unsigned char) floor (line_data [i] [pBLUE] * 255.0) ;
    out << (unsigned char) floor (line_data [i] [pGREEN] * 255.0) ;
    out << (unsigned char) floor (line_data [i] [pRED] * 255.0) ;
  }

So this line_data[i][pBLUE] is a single float value that I can just write
directly to a file rather than using *255.0 and floor()...

Post a reply to this message

jgr### [at] freefr news:424bfe63$1@news.povray.org

> Using the RAW format (+FR switch)... but it was dropped from latest
> official. I do not know if Megapov kept it.

I few times suggested such extension as usable, and when finaly they added 
it, then it was droped :( why in the gods name?

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

Post a reply to this message

Xns962B2D575F64Eraf256com@203.29.75.35...
> jgr### [at] freefr news:424bfe63$1@news.povray.org
>
>> Using the RAW format (+FR switch)... but it was dropped from latest
>> official. I do not know if Megapov kept it.
>
> I few times suggested such extension as usable, and when finaly they added
> it, then it was droped :( why in the gods name?

The RAW format that was supported from POV-Ray 1.0 to 3.0 and dropped in 
3.1. was just a regular 3 byte per pixel, 24 color data, and NOT a double 
precision format. It was dropped because it was considered useless.

From the old raw.c code in POV-Ray 2.0:
*  (header:)
*    wwww hhhh       - Width, Height (16 bits, LSB first)
*  (each scanline:)
*    llll            - Line number (16 bits, LSB first)
*    rr rr rr ...    - Red data for line (8 bits per pixel,
*                       left to right, 0-255 (255=bright, 0=dark))
*    gg gg gg ...    - Green data for line (8 bits per pixel,
*                       left to right, 0-255 (255=bright, 0=dark))
*    bb bb bb ...    - Blue data for line (8 bits per pixel,
*                       left to right, 0-255 (255=bright, 0=dark))

G.

-- 
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters


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

Post a reply to this message

"scott" <sco### [at] spamcom> schrieb im Newsbeitrag
news:424c0a27@news.povray.org...

> So this line_data[i][pBLUE] is a single float value that I can just write
> directly to a file rather than using *255.0 and floor()...
>
If you compile a Win version with this, I'd be quite interested in it too...

Micha

Post a reply to this message

On 31 Mar 2005 21:33:22 -0500, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> I few times suggested such extension as usable, and when finaly they added 
> it, then it was droped :(

+FR was added after your suggestion? 1st April joke?

> why in the gods name?

Find your posts and reread threads to get answers :-)

ABX

Post a reply to this message

scott schrieb:
> 
> >   And by the way, color values are calculated using single precision
> > floating points in povray.
> 
> I would probably just write the binary to a file, rather than use printf.
> 
> So in theory I can patch the source code to output these 32-bit floats for
> each colour for each pixel rendered?

Note such a patch will never make it into official POV or MegaPOV (the
reason has been explained multiple times in the past so i won't do it
again).  This does not mean there will not be any floating point format
output but certainly not in the way you describe it (which will not even
be portable between PC and Mac).

Also note in MegaPOV you can write those raw color values to a text file
using the camera_view pigment in a pigment function and evaluating it in
a loop.  Not exactly highly efficient but usable.

-- Christoph

Post a reply to this message

Michael Zier wrote:
> "scott" <sco### [at] spamcom> schrieb im Newsbeitrag
> news:424c0a27@news.povray.org...
>
>> So this line_data[i][pBLUE] is a single float value that I can just
>> write directly to a file rather than using *255.0 and floor()...
>>
> If you compile a Win version with this, I'd be quite interested in it
> too...

OK, well all I did was to modify the pvbmp.cpp file to output floats instead
of bytes.  It's all a bit of a hack but I rarely use bmp output anyway.  It
does what I want (which will probably be explained around here somewhere at
some point...) but isn't very clean:

This is the updated BMP_Image::Write_Line function below, if you can't
compile it then drop me an email and I'll send you the windows .exe (i'm
scottgboham at hotmail.com).  Note that the file size is much bigger than
the BMP header suggests due to this...

void BMP_Image::Write_Line (COLOUR *line_data)
{
  int pad = (4 - ((width * 3) % 4)) & 0x03 ;
  int i;
  OStream& out = *out_file ;

  if (!out.seekg (14 + 40 + (height - 1 - line_number) * (12 * width )))
    Error ("Error seeking in BMP image.") ;

  unsigned long *t;
  float tmp;
  float *t2;

  t2 = &tmp;
  t  = (unsigned long *) &tmp;

  for (i = 0 ; i < width ; i++)
  {
    tmp = (float) line_data [i] [pBLUE];   out << ( *t ) ;
    tmp = (float) line_data [i] [pGREEN];  out << ( *t ) ;
    tmp = (float) line_data [i] [pRED];    out << ( *t ) ;


  }

  if (!out)
    Error ("Error writing to BMP image.") ;

  line_number++;

  out.flush () ;
}

Post a reply to this message