Christian Froeschlin wrote:
> stbenge wrote:
> 
>> I'm developing a set of macros to load and manipulate 16-bit height 
>> field data. With them, you can import red/green 16-bit grayscale
>> images and manipulate them as you would any other pigment.
> 
> I'm not sure I understand what these do. As far as I know,
> Povray 3.6 already supports 16 bit png as input format both
> for height fields and image_map pigments. Wouldn't that be
> simpler to use than red/green tga?

World Machine and TerraBrush use 16-bit tgas. In the version of WM I 
have, the option for png output is not supported yet. My attempts to 
convert a 16-bit tga to a png have not been successful; the data is 
still encoded with red and green colors, thus resulting in a high 
frequency mess. This probably wouldn't be true if I converted it using 
POV, but it's faster to use IrfanView :)

Regarding pngs, if a person were to supply a well-supported 16-bit png 
to some versions of my functions, then it should work out all right.

>> There are functions for finding edges (via a proximity pattern),
>> finding angles for special effects
> 
> I can see these would be useful. Do they work on pigments which
> encapsulate height information both in red and green channel or
> do you linearize the data into a gray pigment?

The macros will return straight grayscale data, be it 8 or 16-bit data. 
Some will load images (converting them to a grayscale pigment), and some 
will work directly with whatever pigment you provide for it, including 
pre-declared, processed images. All will return grayscale information 
which can then be encoded into a red/green height map if one wishes to 
do so.

>The latter case would be more flexible as your processing functions will then
>be independed of the height field image format.

My goal is to make the edge and angle functions work with any pigment, 
exporting to a few 16-bit pigments.

>> POV-Ray's handling of image_maps produces strange edge artifacts
> 
> What kind of edge artifacts do you mean?

It only appears at certain times, under certain conditions, when I 
convert images to functions. It's a single line of incorrect image info 
residing between units. I can try to reproduce the artifact. It happens 
with my luminous bloom code if I comment out the fixes I made.

Post a reply to this message