Christoph Hormann wrote:
> Ray Gardener schrieb:
>> 1. Why is GREY_SCALE3 interpretation being used on 16-bit color data 
>> when it isn't on 24-bit data? (source/image.cpp, near line 540). This 
>> winds up getting only effective five out of fifteen bits of elevation 
>> precision.
> 
> I don't know how you come to the 'five out of fifteen bits' 

Elev encoding uses the red channel as the most signficant, but 
GREY_SCALE3 only gives red a third of the "volume", so 16/3 ~= 5 bits. 
The resulting renders in POV-Ray bear that out; the HF winds up terraced 
to about 31 levels.


> but the 
> special handling if 24 bit RGB images as 16 bit encoded in red and green 
> (see docs for how this works) was an ugly and inefficient hack 
> introduced when generic 16 bit formats where not yet common.  This hack 
> was not translated to 48 bit RGB - also since it would be rather 
> pointless since height values are stored with only 16 bit accuracy 
> internally anyway.

I don't personally have any issue with red+green interpretation, I'm 
only saying, if that's how colors get converted to elevations, why not 
do that consistently regardless of bit depth (except for 8 bits, where 
it makes more sense to use palette indices).

Heightfields today have explicit file formats -- why not support some of 
them? Then we could skip hacking altogether since images shouldn't be 
coerced into persisting elevation data anyway. PNG and PNM already have 
explicit 16-bit gray, as well as TIFF, and BT and USGS DEM are both 
stable and public domain. I would just drop the whole color interp hack 
altogether and insist on 8-bit gray, 16-bit gray, or true elev data. 
There'd be a lot less confusion that way.


>> 2. When reading 16-bit grayscale TIFFs, shouldn't the 
>> Image->Image_Type field be set to IS16GRAYIMAGE? GeoTIFF elev data 
>> can't be used as heightfields correctly without this.
> 
> POV-Ray's support for Tiff images is limited to a very small subset due 
> to the design of libtiff that only provides higher level functions for 
> reading the most basic tiff formats.  I have implemented use of GDAL for 
> image reading some time ago (which would offer support for most Tiffs) 
> but it is unlikely to make it into an official release version due to 
> the optional support of closed formats in GDAL and resulting licensing 
> and support issues.  You have to convert such files into a format 
> supported by POV-Ray using external tools (Imagemagick, gdal_translate).

I can see that in some cases. I believe, though, libtiff is good about 
providing the photometric interpretation value of a TIFF image being 
read; if you want I can attempt a quick patch here and share the code. 
You don't need to use libgeotiff or GDAL to read GeoTIFF in POV's case 
-- libtiff itself will do -- since you're not reading any georef data.

Ray

Post a reply to this message