clipka wrote:

> I think retaining support for the most basic TIFF files won't hurt, and 
> in that case it would appear rather odd for POV-Ray 3.7 to support less 
> variants of TIFF than 3.6.2.

It seems POV-Ray does not even support the 'most basic' TIF-files.

POV-Ray uses the so called RGBA-libtif interface and this interface 
returns *always* 8 bit/sample 32 bit/pixel data. A simple uncompressed 
16bps grayscale image (e.g. for hight fields) will be used by POV-Ray 
reduced to 8bps but stored as RGB+A. So in this case we have a loss of 
information (16 -> 8 bit) together with a waste of memory.

POV-Ray throws a warning about this 16bit->8bit conversion, but only if 
the input *is* exactly 16bit but other bit-depth are quite common within 
TIFF. Therefor at least the line


if (BitsPerSample == 16)
{
BytesPerSample = 2;
options.warnings.push_back
("Warning: reading 16 bits/sample TIFF file; components crunched to 8");
}


within tiff.cpp should be changed to


if (BitsPerSample > 8)
{
[...]


But even then e.g. Greg Ward's LogLuv HDR TIFF files will be *silently* 
converted and used by POV-Ray as simple LDR 8bps data. No warning, no 
message and no documentation about this behavior. This is definitely not 
the way image import should be handled.

Also the input for 'simple' color palette TIFF is broken as it does 
ignore the possibility of tiles instead of strips within TIFF. And this 
causes even a segfault!


To avoid the possible crash the line

if (PhotometricInterpretation == PHOTOMETRIC_PALETTE)
{
[...]


should be changed to

if ((PhotometricInterpretation == PHOTOMETRIC_PALETTE) && 
(TIFFIsTiled(tif) == 0))
{
[...]



> Anyway, I got the libtiff 3.8.2 running with POV-Ray 3.7 now, and will 
> submit the changes to the repository any minute.

The latest libtif release is 3.9.1 and fixes numerous bugs (including 
some fixes provided by me ;) compared to 3.8.2.

-Ive

Post a reply to this message