"SharkD" <nomail@nomail> wrote:
> "Reactor" <rea### [at] hotmailcom> wrote:
> > 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.
>
> Well, an hf_gray_24 function would require a new image format: one in which each
> channel stores 24 bits of color information, for a total of 72 bits for the
> entire image. AFAIK, povray only supports a maximum of 16 bits-per-color in a
> handful of formats (PNG is one of them).
>
> The pigment I created will generate 24 bits of heightfield data in 8
> bits-per-color images (the most common format), and 48 bits of heightfield data
> in 16 bits-per-color images.
>
> -Mike

Actually, the hf_gray_16 format doesn't use 16 bits per channel.  It uses the
existing channels. From the docs:
"The TGA and PPM file formats may be used as a storage device for 16 bit numbers
rather than an image file. These formats use the red and green bytes of each
pixel to store the high and low bytes of a height value.
....
PNG format heightfields are usually stored in the form of a grayscale image with
black corresponding to lower and white to higher parts of the height field.
Because PNG files can store up to 16 bits in grayscale images they will be as
smooth as TGA and PPM images. Since they are grayscale images you will be able
to view them with a regular image viewer."

You can use hf_gray_16 with png also, and it results in the same sort of
multicolored output, but only with 16 bits for 65536 levels.  What I meant by
hf_gray_24 wasn't for 24 bits per channel, but a 24 bit grayscale image which,
instead of using only the red and green 8-bit channels for 16 bits, would use
the red, green, and blue channels for a total of 24 bits.  No new image format
would be needed.

-Reactor

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> SharkD wrote:
> > Nicolas Alvarez <nic### [at] gmailcom> 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.
> >
> > How did you check whether it was only using 16 bits?
>
> The documentation says so.

I couldn't find anywhere in the docs where it said there was a maximum *limit*.
Rather, it merely provides an overview of the different formats, and fails to
mention any 24 bit options.

As an experiment, I created a copy of "Untitled1_hf.png", except with the blue
channel set to zero. The resulting heightfield looks subtly but noticibly
different. If it is true that povray only supports 16 bits, then 8 bits must be
being discarded *somewhere*.

-Mike

Post a reply to this message

SharkD wrote:
> As an experiment, I created a copy of "Untitled1_hf.png", except with the
> blue channel set to zero. The resulting heightfield looks subtly but
> noticibly different.
Oh really...

Post a reply to this message

"Reactor" <rea### [at] hotmailcom> wrote:
> Actually, the hf_gray_16 format doesn't use 16 bits per channel.  It uses the
> existing channels. From the docs:
> ...
> You can use hf_gray_16 with png also, and it results in the same sort of
> multicolored output, but only with 16 bits for 65536 levels.  What I meant by
> hf_gray_24 wasn't for 24 bits per channel, but a 24 bit grayscale image which,
> instead of using only the red and green 8-bit channels for 16 bits, would use
> the red, green, and blue channels for a total of 24 bits.  No new image format
> would be needed.
>
> -Reactor

OK, thanks. I tried opening up one of these PNG images in my image editor, with
weird results. Adjusting the blue and green channels had no effect, and setting
the red channel to 0% still leaves some residual coloring. Also, the program
claims the image has only 256 unique colors! Checking the levels also resulted
in wonkyness.

:)

-Mike

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> OK, here's the pigment:
> ...

I tested the pigment on a cone, and then used the output in a heightfield. It
seems to work OK if the output is rendered in as a 24 bit image, but produced
weird results when using a 48 bit image.

-Mike

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> http://imagebin.ca/view/5lUU-ge.html
>
> Source attached.
>
> "interpolate 2" in the image_map is absolutely necessary. Without
> interpolation, it like a bunch of square blocks, one for each pixel; the
> function gradient and the render times go through the roof, and it looks
> ugly. With it, the isosurface looks like a non-smoothed heightfield.

I tried a higher interpolation value, and the result is pretty cool looking, but
not useful. :)

-Mike

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> SharkD wrote:
> > As an experiment, I created a copy of "Untitled1_hf.png", except with the
> > blue channel set to zero. The resulting heightfield looks subtly but
> > noticibly different.
> Oh really...

YRLY.

-Mike

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> >     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.

Red, green and blue are "misused" to encode one single higher-precision value.

The range of 0.0 to 1.0 which I presumed is just for convenience, because that's
PoV-ray's "native" range for colors, and is a very convenient range for heights
because it can easily be scaled to any other range you may need.

In the image, the red, green & blue channels each have a precision of 8 bit, so
the smallest step a single channel can encode is 1/256 of its total range.


Now if we used only a single channel (say red) to encode the height, we could
map it like this (note that this is just a convention, not a law):

    height = red

This would give us the same precision for the height as the red channel can
provide, i.e. smallest steps being 1/256 of the total range.

If we want to increase this, we can use the other channels to help us, e.g.:

    height = red + green + blue

In this way, our smallest step is 1/256 of a *single* channel's range, but as
the height will now - as you correctly observed - be in range 0.0 to 3.0, this
is actually 1/768 of the *height's* total range. So we have tripled the
height's precision.

This is, however, not the highest precision one can get out of 3*8 = 24 bits. In
fact, it should be possible to encode steps as small as 1/(2^24) of the total
range.

In fact, we can achieve that by using the green and blue component to encode
*smaller* steps than the red component (a kind of high-precision correction
terms), e.g.:

    height = red + 0.1 * green + 0.01 * blue

So although red, green and blue have a range of 0.0 to 1.0 each, the terms now
have a range of 0.0 to 1.0, 0.0 to 0.1 and 0.00 to 0.01 respectively, with
their smallest steps being 1/256 of the *term's* range, i.e. 1/256 for the "red
term", 0.1/256 for the "green term" and 0.01/256 for the "blue term".

So the height's range would now be in the range of 0.0 to 1.11 (quite similar to
the original range), but the smallest step would be 0.01/256, i.e. we have
hundredfold the precision of a single channel.

It turns out that the ideal factors for the single terms are powers of 1/256
(the smallest step representable by a single component), giving the term I
mentioned:

    height = red + green/256 + blue/65536

Well, actually I must confess that this is not *really* the ideal formula,
unless the range for red, green and blue isn't precisely 0.0 to 1.0, but 0/256
to 255/256 and the resulting range of the height would not be 0.0 to 1.0
either, but 0/(2^24) to (2^24-1)/(2^24); for the range 0.0 to 1.0 as actually
used by PoV-ray (if I'm not mistaken), the formula should be:

    height = ( (red*255) + (green*255)/256 + (blue*255)/65536 )/255

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> Red, green and blue are "misused" to encode one single higher-precision value.
> ...
> Well, actually I must confess that this is not *really* the ideal formula,
> unless the range for red, green and blue isn't precisely 0.0 to 1.0, but 0/256
> to 255/256 and the resulting range of the height would not be 0.0 to 1.0
> either, but 0/(2^24) to (2^24-1)/(2^24); for the range 0.0 to 1.0 as actually
> used by PoV-ray (if I'm not mistaken), the formula should be:

Hehe. I already finished creating the pigment. Check one of my earlier posts.

-Mike

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> I don't think it would be easy at all. You definitely can't use
> antialiasing :) (try slightly blurring the image you have and loading it
> into your app, see what you get!)

Antialiasing doesn't seem to have harmed it in any way. See:

http://i421.photobucket.com/albums/pp292/SharkD2161/Support/hf_24_bit_pigment_overhead_hf_24.png
http://i421.photobucket.com/albums/pp292/SharkD2161/Support/hf_24_bit_pigment_overhead_hf_24_no.png

-Mike

Post a reply to this message