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.

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.


Ray Gardener
Daylon Graphics Ltd.

Post a reply to this message

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' 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.

> 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).

-- Christoph

Post a reply to this message

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

Ray Gardener schrieb:
> 
> 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.

Huh?

If you have a grayscale image stored in an RGB format (so R, G and B 
identical for each pixel) i don't see how this handling reduces the data 
to 31 levels.

> 
> 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).

As said the red+green interpretation is an old hack that only exists for 
backwards compatibility.  And as also said there is absolutely no 
practical use in having the same hack used for 48 bit images as well.

> Heightfields today have explicit file formats -- why not support some of 
> them? [...]

POV-Ray supports PGM and PNG 16 bit grayscale images perfectly.  If you 
like to implement support for additional formats you are welcome but a 
bloated, proprietary or rarely used format will most likely not make it 
into POV-Ray.

> 
> 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.

If you like to implement a broader Tiff support for POV-Ray using basic 
libtiff functions you are welcome.  This is not a matter of a 'quick 
patch' though.

-- Christoph

Post a reply to this message

Ray Gardener wrote:
> 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.

Well, when TIFF support was added, the assumption was that libtiff would
provide all the support needed. But as TIFF is a pretty messy file format,
and libtiff does a rather poor job hiding all that TIFF complexity, support
in POV-Ray is a minimal set of features. This means grayscale isn't
supported currently.

I haven't checked 3.7 source, but maybe Chris Cason fixed that bit when
porting the old reading code. You may want to check the beta and see if it
does work. If not, and assuming it is correct that we can fix it with a
one-liner in the current 3.6 code, I am sure it can be added in 3.7 - just
file a bug report for the 3.7 beta then (and refer to this thread, too).

Either way, I cannot recommend using TIFF images unless you absolutely have
to. I would recommend PNG images, which are much better supported in POV-Ray
 due to libpng being usable on a favorable level of abstraction that doesn't
force us to worry about format oddities too much :-)

	Thorsten

Post a reply to this message

Christoph Hormann wrote:
> Ray Gardener schrieb:
>> 
>> 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.
> 
> Huh?
> 
> If you have a grayscale image stored in an RGB format (so R, G and B
>  identical for each pixel) i don't see how this handling reduces the
> data to 31 levels.

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.

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. 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.

Ray

Post a reply to this message

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