Ray Gardener wrote:
> 
> It's when the channels are used in red+green encoding; certainly a
> grayscale image would work but it would only enjoy up to eight bits of
> precision, which defeats the purpose of using 16 bits. For 16-bit r+g 
> though that only gives 10 bits so r+g+b would be preferred.

Well - if you have a program generating a red channel only RGB image i 
can't help.  Note a red *and green* encoded image in 48 bit would not 
work at all (since the green values would mess it).  Apart from that 
things are clear:

Grayscale image in 48 bit RGB -> 16 bit accuracy
Grayscale image in 24 bit RGB -> 8 bit accuracy
Red+Green encoded image in 24 bit RGB -> 16 bit accuracy

and of course true grayscale images always in native accuracy.

Note you can use a red+green 48 bit RGB image in POV-Ray by manually 
combining the values in functions and thereby even achieve > 16 bit 
accuracy but this won't help for heightfields.

> Maybe the consistency should work the other way... apply GREY_SCALE3 to
> 24-bit RGB as well, and if people want elev precision beyond eight bits,
> they need to use PNG/PGM.

As said two times already this is not done for *backwards compatibility*.

> I wanted to offer a freedom of choice in terms 
> of formats because POV-Ray lists several of them when reading HF files, 
> but limiting Lev's POV export to PNG/PGM is probably more warranted -- 
> doesn't hurt the functionality and avoids potential confusion.

It also would avoid users to use a pointlessly bloated format using 1.5x 
the required space for storing the values...

Christoph

-- 
Views of the Earth: http://earth.imagico.de/
Images, include files, tutorials: http://www.imagico.de/
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message