The Persistence of Vision Raytracer (POV-Ray).
This is the Bug Tracking System for the POV-Ray project. Before opening a new task, please read How to make a Bug Report
Please do not issue bugs reports against versions earlier than 3.6.
FS#57 - Compressed TIFF image_map renders all transparent
Opened by Christoph Lipka (clipka) - Wednesday, 09 September 2009, 20:29 GMT
Last edited by Christoph Lipka (clipka) - Saturday, 07 November 2009, 16:30 GMT
|
DetailsThe attached TIFF file was created with IC using compression. When used in an image_map, POV-Ray 3.7.0.beta.34 on Windows XP x64 renders the image all transparent, while POV-Ray 3.6.2 renders the file fine. The same effect can be seen with LZW-compressed TIFF files created with Adobe Photoshop 6.0. Uncompressed TIFF files created with either IC or Photoshop render fine in both versions of POV-Ray. Stepping through the code of POV-Ray 3.7.0 shows that the same code path is taken regardless of compression, but the libtiff library returns different alpha channel values, indicating a problem in that library. POV-Ray 3.7 still uses libtiff 3.6.1, whereas the POV-Ray 3.6 branch has been updated to libtiff 3.8.2, which according to the change history includes a few alpha-related changes. 
test_image.tif
(62.1 KiB)
|
Updated from libtiff 3.6.1 to 3.8.2 with change #4887.
Can someone please check whether the Visual Studio 2008 “tiff” project compiles properly with the updates?
The build fails with an error where it attempts to overrwite tiffconf.h with tiffconf.h.vc. This is because tiffconf.h is by default read-only since it's checked in to perforce. I am unsure why this wasn't an issue earlier since it's not a new file, however I'm guessing that perhaps the build system didn't detect that it needed to be overwritten. If we can confirm that it's auto-created on other platforms as well then it might be appropriate to delete tiffconf.h from perforce.
Apart from that, all seems to be OK.
tiffconf.h was previously not auto-generated during the build process, hence the issue. I'm surprised though that this did not surface as a problem with 3.6.2, as the file is auto-generated there as well despite still being in the repository. From all I see, it should be safe to delete the file from perforce for both 3.6 and 3.7.
As the file apparently contains platform-specific settings, it should *not* be shared among platforms anyway. At worst, a copy should be placed in platform-specific subdirectories and pulled in during the build process.
For the records, the problem was allegedly just due to LZW decoding not being enabled in the libtiff configuration. I don't see a point to roll back to the older libtiff version though.