I use an external program to create png files that contain height data. 
The difference between adjacent points is generally very little but as 
povray renders the height fields it shows very large jumps in height.

is it

height of pixel = (R x 256 x 256) + (G * 256) + B?
-- 
Cheers
Ger

Post a reply to this message

Ger wrote:

> I use an external program to create png files that contain height data. 
> The difference between adjacent points is generally very little but as 
> povray renders the height fields it shows very large jumps in height.
 >
> is it
> 
> height of pixel = (R x 256 x 256) + (G * 256) + B?

I *think* POV-Ray only supports 16 bit data, and that the color hack
is not for higher bit depth but for 16 bit support back when no native
16-bit formats where suported. For 16-bit you can use a single channel
(gray) 16-bit PNG file if supported by the software.

Also, I'm not aware that this color-coding is in any way standardized,
so I wonder what kind of tool creates color HF data (unless intended for
POV, but then it should have worked).

Post a reply to this message

Maybe this will help.

http://wiki.povray.org/content/Knowledgebase:High_precision_heightfields

I'm not sure I ever got it to work 100%.



Mike


Ger <ger### [at] NoSpamthankyou> wrote:
> I use an external program to create png files that contain height data.
> The difference between adjacent points is generally very little but as
> povray renders the height fields it shows very large jumps in height.
>
> is it
>
> height of pixel = (R x 256 x 256) + (G * 256) + B?
> --
> Cheers
> Ger

Post a reply to this message

Never mind. I misunderstood your question.


Mike



"posfan12" <nomail@nomail> wrote:
> Maybe this will help.
>
> http://wiki.povray.org/content/Knowledgebase:High_precision_heightfields
>
> I'm not sure I ever got it to work 100%.
>
>
>
> Mike
>
>
> Ger <ger### [at] NoSpamthankyou> wrote:
> > I use an external program to create png files that contain height data.
> > The difference between adjacent points is generally very little but as
> > povray renders the height fields it shows very large jumps in height.
> >
> > is it
> >
> > height of pixel = (R x 256 x 256) + (G * 256) + B?
> > --
> > Cheers
> > Ger

Post a reply to this message

Le 07/09/2013 00:30, Ger nous fit lire :
> I use an external program to create png files that contain height data.
> The difference between adjacent points is generally very little but as
> povray renders the height fields it shows very large jumps in height.
> 
> is it
> 
> height of pixel = (R x 256 x 256) + (G * 256) + B?

See:
> http://wiki.povray.org/content/Reference:Height_Field

If the png is a colour-one (instead of grey), it is used as it is done
for tga and ppm: red and green bytes of each pixel are used to store 16
bits number: Most Significant Byte (MSB) is red, Least Significant Byte
is green (and blue is irrelevant, as long as there is only up to 8 bits
per channel): (255.0*Red + Green)*255.0
(with Red the value between 0 and 1.0 (so, it's your R/255))
In term of bits-operation, it it is ((R<<8)|G) (with R & G in 0..255),
or Rx256+G (max value of height field is 65535)

If the png is a grey one, the grey value is used as the height.
(remember that png can have more than 8 bits per channel, you can have a
16 bits grey png without any problem)

If the png is a coloured one with more than 8 bits per channel, the
grey-equivalent is used :
 0.297*Red + 0.589*Green + 0.114*Blue

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> If the png is a grey one, the grey value is used as the height.
> (remember that png can have more than 8 bits per channel, you can have a
> 16 bits grey png without any problem)

A 16-bit grayscale PNG is indeed the most optimal format for heightfields.

-- 
                                                          - Warp

Post a reply to this message