Warp wrote:
> 
>   I don't think that the current behaviour is that problematic. I think that
> the biggest problem is that this behaviour is not clearly documented. I have
> read the heightfield documentation countless times during these years, and I
> never realized this behaviour.

Well, I have. But I also read the Fractint documentation,
who also used "16 out of 24 bits" formats, so I easily
understood what POV was doing.

I am not sure that if you convert 24-bit to greyscale
you will get 16-bit precision : I would say 8-bit, but I'm
not at all into this field, so I'm not sure at all.
Something inbetween perhaps.

> I think that the documentation
> lacks a clear and unambiguous description of the exact algorithm used for
> the pixel to height conversion with true color images (what happens with
> indexed images is a lot better documented).

Indexed color : the number of the color in the index
 is used to determine the height. 8-bit and 16-bit indexes
 are accepted and used by POV. 16-bit indexes are mostly/only?
 supported by PNG file format.

True color : the red and green components are combined to
 form a 16-bit value. This dates back from days where no
 file format supported 16-bit palettes or 16-bit B&W.
 Fractint introduced this hack, and it has been kept. Of
 course, it is almost impossible to draw them by hand (or
 you do a B&W picture, but only get 8-bit precision), you
 should use a special program for that. afaik, hflab can
 output such format.

>   On the other hand, I wouldn't mind that the b/w conversion would be used
> to create the heightfield from the image. Note that this way you get *more*
> than 256 heights, which makes the heightfield more accurate even with 24-bit
> images.

I'm a bit confused about the issue of B&W conversion. Are you
sure you will have more than 8-bit precision in that case?

-- 
Adrien Beau   adr### [at] freefr   http://adrien.beau.free.fr/

Post a reply to this message