 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A few months ago I posted an idea for creating 24 bit heightfields using
existing image formats. The idea is that each channel is used to encode
height data at different levels of precision. I was wondering if this
could be implemented as an export format in POV-Ray? I think the
Leveller program also uses this format, and the images it outputs seem
to already work OK when used in POV-Ray.
Here's some sample code:
//BEGIN
camera
{
orthographic
location -z * 10
direction +z
up +y * 2
right +x * 2 * image_width/image_height
rotate +x * 90
}
#local hf_pigment_function_pow = function {y * pow(256,3)}
#local hf_pigment_function_b = function
{mod(hf_pigment_function_pow(x,y,z), pow(256,1))}
#local hf_pigment_function_g = function
{mod(hf_pigment_function_pow(x,y,z) - hf_pigment_function_b(x,y,z),
pow(256,2))}
#local hf_pigment_function_r = function
{mod(hf_pigment_function_pow(x,y,z) - hf_pigment_function_b(x,y,z) -
hf_pigment_function_g(x,y,z), pow(256,3))}
#local hf_pigment_b = pigment
{
function {hf_pigment_function_b(x,y,z) / pow(256,1)}
color_map {[0 rgb 0][1 rgb z * 3]}
}
#local hf_pigment_g = pigment
{
function {hf_pigment_function_g(x,y,z) / pow(256,2)}
color_map {[0 rgb 0][1 rgb y * 3]}
}
#local hf_pigment_r = pigment
{
function {hf_pigment_function_r(x,y,z) / pow(256,3)}
color_map {[0 rgb 0][1 rgb x * 3]}
}
// This is the one you want
#local hf_pigment_rgb = pigment
{
average
pigment_map {[hf_pigment_b][hf_pigment_g][hf_pigment_r]}
}
cone
{
0, 1, y, 0
texture
{
pigment {hf_pigment_rgb}
finish {ambient 1}
}
}
//END
The technique could also be extended to 32 bits. For example:
//BEGIN
camera
{
orthographic
location -z * 10
direction +z
up +y * 2
right +x * 2 * image_width/image_height
rotate +x * 90
}
#local hf_pigment_function_pow = function {y * pow(256,4)}
#local hf_pigment_function_t = function
{mod(hf_pigment_function_pow(x,y,z), pow(256,1))}
#local hf_pigment_function_b = function
{mod(hf_pigment_function_pow(x,y,z) - hf_pigment_function_t(x,y,z),
pow(256,2))}
#local hf_pigment_function_g = function
{mod(hf_pigment_function_pow(x,y,z) - hf_pigment_function_t(x,y,z) -
hf_pigment_function_b(x,y,z), pow(256,3))}
#local hf_pigment_function_r = function
{mod(hf_pigment_function_pow(x,y,z) - hf_pigment_function_t(x,y,z) -
hf_pigment_function_b(x,y,z) - hf_pigment_function_g(x,y,z), pow(256,4))}
#local hf_pigment_t = pigment
{
function {hf_pigment_function_t(x,y,z) / pow(256,1)}
color_map {[0 rgbt 0][1 rgbt <0,0,0,4,>]}
}
#local hf_pigment_b = pigment
{
function {hf_pigment_function_b(x,y,z) / pow(256,2)}
color_map {[0 rgbt 0][1 rgbt <0,0,4,0,>]}
}
#local hf_pigment_g = pigment
{
function {hf_pigment_function_g(x,y,z) / pow(256,3)}
color_map {[0 rgbt 0][1 rgbt <0,4,0,0,>]}
}
#local hf_pigment_r = pigment
{
function {hf_pigment_function_r(x,y,z) / pow(256,4)}
color_map {[0 rgbt 0][1 rgbt <4,0,0,0,>]}
}
// This is the one you want
#local hf_pigment_rgbt = pigment
{
average
pigment_map {[hf_pigment_t][hf_pigment_b][hf_pigment_g][hf_pigment_r]}
}
cone
{
0, 1, y, 0
open
texture
{
pigment {hf_pigment_rgbt}
finish {ambient 1}
}
}
//END
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/19/2009 12:36 PM, SharkD wrote:
> A few months ago I posted an idea for creating 24 bit heightfields using
> existing image formats. The idea is that each channel is used to encode
> height data at different levels of precision. I was wondering if this
> could be implemented as an export format in POV-Ray? I think the
> Leveller program also uses this format, and the images it outputs seem
> to already work OK when used in POV-Ray.
I write in more detail about this here:
http://isometricland.com/povray/povray_high_precision_heightfields.php
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SharkD wrote:
> I write in more detail about this here:
>
> http://isometricland.com/povray/povray_high_precision_heightfields.php
It's rather specialized. I think it would only make sense
to implement this in POV-Ray if the height_field object would
then also support the higher resolution.
Also, instead of again using a hacked format like it was done
with 16-bit TGA, it might be preferrable to use a 32-bit TIFF.
Possibly the hdr file format could be of interest as well? Of
course, most software likely won't read that either ;) I think
someone was already looking into improving TIFF support for 3.7,
maybe this would become practicable as a side effect.
PS: Your keyboard chart generator looks nice.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/20/2009 1:26 PM, Christian Froeschlin wrote:
> Also, instead of again using a hacked format like it was done
> with 16-bit TGA, it might be preferrable to use a 32-bit TIFF.
Is TIFF better in some way than PNG?
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it SharkD who wrote:
>On 10/20/2009 1:26 PM, Christian Froeschlin wrote:
>> Also, instead of again using a hacked format like it was done
>> with 16-bit TGA, it might be preferrable to use a 32-bit TIFF.
>
>Is TIFF better in some way than PNG?
The TIFF specs allow you to directly specify 24 or 32 bit greyscale.
Other programs that handle TIFF files will know that it is a greyscale
image (some may not necessarily be able to render it). It might even be
possible to find a graphics application that does support that format
and be able to do useful things like blur the image, thus smoothing the
heightfield.
The PNG specs only allow 8 or 16 bit greyscale. You can hack the format
by setting the parameters to say that the image is a normal full colour
PNG with transparency, and get 8 bits for each of the R, G, B and A
channels, then use the red channel as the high order 8 bits, etc. Other
programs that handle PNG files will render it as full colour with
transparency. It will not be possible to find graphics applications that
would be able to manipulate the image as if it were greyscale.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/28/2009 11:01 PM, Mike Williams wrote:
> It will not be possible to find graphics applications that
> would be able to manipulate the image as if it were greyscale.
What can you do in grayscale that you can't do in RGB?
Let's say that instead of 8 bits per channel, each channel instead only
held 10 values, from 0 through 9. You could then represent the three
channels as a decimal value between 0.000 and 0.999 with each channel
corresponding to a decimal place.
If you had two "colors" (color is actually meaningless here), 0.345 and
0.765, "blurring" them would result in the average, or 0.555, which is a
valid result.
Granted, creating heightfields from a gradient would require more work
than a simple grayscale image. But if your paint application supported
working on channels independently, then you'd still only need to apply a
different gradient to each channel.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it SharkD who wrote:
>On 10/28/2009 11:01 PM, Mike Williams wrote:
>> It will not be possible to find graphics applications that
>> would be able to manipulate the image as if it were greyscale.
>
>What can you do in grayscale that you can't do in RGB?
One thing that would go wrong is that bits wouldn't be carried between
channels.
Consider the border of regions with these 32-bit greyscale values
00000001-00000000-00000000-00000000
00000000-00000000-00000000-00000000
What we'd like is for a three-pixel-radius blur to output values like
00000001-00000000-00000000-00000000
00000000-11000000-00000000-00000000
00000000-10000000-00000000-00000000
00000000-01000000-00000000-00000000
00000000-00000000-00000000-00000000
as we approach and cross the boundary, but if the channels are blurred
independently that can't happen.
An application that treats the image as RGBA won't produce bright blue
by blurring together what it sees as dark red and black.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams schrieb:
> The PNG specs only allow 8 or 16 bit greyscale. You can hack the format
> by setting the parameters to say that the image is a normal full colour
> PNG with transparency, and get 8 bits for each of the R, G, B and A
> channels, then use the red channel as the high order 8 bits, etc. Other
> programs that handle PNG files will render it as full colour with
> transparency. It will not be possible to find graphics applications that
> would be able to manipulate the image as if it were greyscale.
The old hacked formats were invented because (a) formats with the same
capabilities didn't exist, or could be processed only by very few
applications, while converters were difficult to find, and (b) they were
necessary.
Now again, formats supporting 32-bit greyscale are few, and the programs
supporting them are even fewer. What's different, however, is that they
are not needed.
16-bit depth greyscale formats were required to eliminate terracing with
height fields, which would be a common effect with 8-bit depth images.
Even with a uniform slope, terracing would occur at resolutions as low
as 256x256.
With 16 bit depth, however, you can represent...
... the entire earth's topology (including ocean floors) to a vertical
resolution of ca. 30 cm, or 1'0".
... the entire earth's continental topology (i.e. above ocean level) to
a vertical resolition of about 15 cm, or 6".
... a section of the Grand Canyon to a vertical resolution of about 2,5
cm, or 1".
If you really /need/ such a high vertical resolution (and can't get away
with a 16-bit floating-point based format for instance, placing the
range of highest precision around the camera elevation), chances are
you're doin' it wrong, and that nobody will really bother to implement
input/output routines for some exotic file format in POV-Ray just to
help you out, unless he's at it anyway and implementing it would be just
a few lines extra.
The good news is that I think nobody will bother to hack some other file
format to serve that purpose either - at least as far as official
POV-Ray is concerned.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SharkD schrieb:
> On 10/28/2009 11:01 PM, Mike Williams wrote:
>> It will not be possible to find graphics applications that
>> would be able to manipulate the image as if it were greyscale.
>
> What can you do in grayscale that you can't do in RGB?
>
> Let's say that instead of 8 bits per channel, each channel instead only
> held 10 values, from 0 through 9. You could then represent the three
> channels as a decimal value between 0.000 and 0.999 with each channel
> corresponding to a decimal place.
>
> If you had two "colors" (color is actually meaningless here), 0.345 and
> 0.765, "blurring" them would result in the average, or 0.555, which is a
> valid result.
Not so for, say, 0.500 and 0.600: Obviously the proper result should be
0.550, but averaging on a per-digit base would yield 0.500 or 0.600,
depending on your rounding mode.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/29/2009 8:30 AM, clipka wrote:
> Not so for, say, 0.500 and 0.600: Obviously the proper result should be
> 0.550, but averaging on a per-digit base would yield 0.500 or 0.600,
> depending on your rounding mode.
Ah, OK. I was mistaken.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
