POV-Ray : Newsgroups : povray.general : 24 bit heightfields Server Time
30 Jul 2024 22:27:39 EDT (-0400)
  24 bit heightfields (Message 6 to 15 of 35)  
<<< Previous 5 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: SharkD
Subject: Re: 24 bit heightfields
Date: 11 Dec 2008 16:45:01
Message: <web.494188b3869f689feb2e5c3e0@news.povray.org>
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> You want POV-Ray to output an image like this, for another application to
> use?

No, I want to reuse the images in POV.

-Mike


Post a reply to this message

From: SharkD
Subject: Re: 24 bit heightfields
Date: 11 Dec 2008 16:45:01
Message: <web.4941894e869f689feb2e5c3e0@news.povray.org>
"clipka" <nomail@nomail> wrote:
> it's not very easy to tell, given the low resolution - but it is quite obvious
> that the red channel is most significant. So I'd guess that the height is coded
> as:
>
>     height = red + (green/256.0) + (blue/65536.0)
>
> with red, green, blue and height all ranging from 0.0 to 1.0.

I don't quite understand your math. If red, green and blue all range from 0 to
1, then the maximum possible height is 3. The maximum height of heightfields is
1.

-Mike


Post a reply to this message

From: Reactor
Subject: Re: 24 bit heightfields
Date: 11 Dec 2008 16:55:00
Message: <web.49418be0869f689f353f48a70@news.povray.org>
"SharkD" <nomail@nomail> wrote:
> I generated the following heightfield in some program or other. It uses all 24
> bits for elevation information. My question is, how are the colors/height data
> organized? I would like to create a pigment that produces similar maps.
>
> http://i421.photobucket.com/albums/pp292/SharkD2161/Support/Untitled1_hf.png
>
> -Mike

I am intrigued by this idea.  I have been using hf_gray_16 in the past, and it
usually creates enough levels, but an hf_gray_24 might be pretty cool too.

From the documentation:
"When  hf_gray_16 is on, the output file will be in the form of a heightfield,
with the height at any point being dependent on the brightness of the pixel.
The brightness of a pixel is calculated in the same way that color images are
converted to grayscale images: height = 0.3 * red + 0.59 * green + 0.11 *
blue."

It'll take a bit of testing, but if it is that easy...

-Reactor


Post a reply to this message

From: SharkD
Subject: Re: 24 bit heightfields
Date: 11 Dec 2008 16:55:01
Message: <web.49418c0e869f689f1c3f45200@news.povray.org>
"SharkD" <nomail@nomail> wrote:
> "clipka" <nomail@nomail> wrote:
> > it's not very easy to tell, given the low resolution - but it is quite obvious
> > that the red channel is most significant. So I'd guess that the height is coded
> > as:
> >
> >     height = red + (green/256.0) + (blue/65536.0)
> >
> > with red, green, blue and height all ranging from 0.0 to 1.0.
>
> I don't quite understand your math. If red, green and blue all range from 0 to
> 1, then the maximum possible height is 3. The maximum height of heightfields is
> 1.
>
> -Mike

Errr... I meant, "the maximum possible height is greater than 1", not 3.

-Mike


Post a reply to this message

From: Nicolas Alvarez
Subject: Re: 24 bit heightfields
Date: 11 Dec 2008 17:23:27
Message: <494192df@news.povray.org>
SharkD wrote:
> "clipka" <nomail@nomail> wrote:
>> it's not very easy to tell, given the low resolution - but it is quite
>> obvious that the red channel is most significant. So I'd guess that the
>> height is coded as:
>>
>>     height = red + (green/256.0) + (blue/65536.0)
>>
>> with red, green, blue and height all ranging from 0.0 to 1.0.
> 
> I don't quite understand your math. If red, green and blue all range from
> 0 to 1, then the maximum possible height is 3. The maximum height of
> heightfields is 1.

Those maths assume red, green and blue go from 0 to 255, and height would be
from 0 to 16777216.


Post a reply to this message

From: SharkD
Subject: Re: 24 bit heightfields
Date: 11 Dec 2008 17:55:00
Message: <web.49419947869f689fe63ea9550@news.povray.org>
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> SharkD wrote:
> > "clipka" <nomail@nomail> wrote:
> >> it's not very easy to tell, given the low resolution - but it is quite
> >> obvious that the red channel is most significant. So I'd guess that the
> >> height is coded as:
> >>
> >>     height = red + (green/256.0) + (blue/65536.0)
> >>
> >> with red, green, blue and height all ranging from 0.0 to 1.0.
> >
> > I don't quite understand your math. If red, green and blue all range from
> > 0 to 1, then the maximum possible height is 3. The maximum height of
> > heightfields is 1.
>
> Those maths assume red, green and blue go from 0 to 255, and height would be
> from 0 to 16777216.

OK, but 255 + 255/256 + 255/65536 still don't add up to 16777216!

-Mike


Post a reply to this message

From: Nicolas Alvarez
Subject: Re: 24 bit heightfields
Date: 11 Dec 2008 17:55:12
Message: <49419a50@news.povray.org>
SharkD wrote:
> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>> You want POV-Ray to output an image like this, for another application to
>> use?
> 
> No, I want to reuse the images in POV.

I put the image directly into a heightfield, and I think I got the correct
height, but only at 16 bits. I can't see any way (without hacking the code)
to get 24 bits of precision in a heightfield.

The only way to put data in a heightfield without passing a filename is
using bitmap functions (function 200,200 { ... }), and those also support
only 16-bit.


Post a reply to this message

From: Dan Connelly
Subject: Re: 24 bit heightfields
Date: 11 Dec 2008 18:44:56
Message: <4941a5f8$1@news.povray.org>
SharkD wrote:
> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>> SharkD wrote:
>>> "clipka" <nomail@nomail> wrote:
>>>> it's not very easy to tell, given the low resolution - but it is quite
>>>> obvious that the red channel is most significant. So I'd guess that the
>>>> height is coded as:
>>>>
>>>>     height = red + (green/256.0) + (blue/65536.0)
>>>>
>>>> with red, green, blue and height all ranging from 0.0 to 1.0.
>>> I don't quite understand your math. If red, green and blue all range from
>>> 0 to 1, then the maximum possible height is 3. The maximum height of
>>> heightfields is 1.
>> Those maths assume red, green and blue go from 0 to 255, and height would be
>> from 0 to 16777216.
> 
> OK, but 255 + 255/256 + 255/65536 still don't add up to 16777216!
> 

No -- the values go from 0 to 255, so the sum can go from 0 to (256 - 1 / 256^2)

Dan


Post a reply to this message

From: SharkD
Subject: Re: 24 bit heightfields
Date: 11 Dec 2008 19:00:00
Message: <web.4941a917869f689fe70991d60@news.povray.org>
Dan Connelly <djc### [at] yahoocom> wrote:
> No -- the values go from 0 to 255, so the sum can go from 0 to (256 - 1 / 256^2)
>
> Dan

Ah, I see now! Thanks.

-Mike


Post a reply to this message

From: Nicolas Alvarez
Subject: Re: 24 bit heightfields
Date: 11 Dec 2008 19:25:20
Message: <4941af6f@news.povray.org>
Nicolas Alvarez wrote:
> I put the image directly into a heightfield, and I think I got the correct
> height, but only at 16 bits. I can't see any way (without hacking the
> code) to get 24 bits of precision in a heightfield.
> 
> The only way to put data in a heightfield without passing a filename is
> using bitmap functions (function 200,200 { ... }), and those also support
> only 16-bit.

But using some creative coding, I can get an isosurface out of a
heightfield. I lose almost all interpolation though; it looks like a
heightfield without the "smooth" parameter.

Isosurface function:

function(x,y,z) {
  y -
  Map(x,y,z).red +
  Map(x,y,z).green / 256.0 +
  Map(x,y,z).blue / 65536.0
}


Post a reply to this message

<<< Previous 5 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.