clipka wrote:
> Well, it does /support/ them in the sense that you can use them. Whether 
> it supports them /well/ is a perfectly different thing.
> 

If you indeed see it that way so why did you bother about the alpha 
channel? You could *use* it, couldn't you even if not as you did expect 
but citing you this is a perfectly different thing.

And changing from libtif 3.6 to 3.8 (or 3.9) does not fix anything 
regarding the possible pre-multiplied data for TIF-files using an alpha 
channel, it only will make support for the other 50% of files that *did* 
previously work broken!

If somebody notes e.g. that POV-Ray does claim to support TIFF and his 
intention is to quickly visualize a 32-bit-signed-integer GEO-TIFF 
height-field all he will get from POV-Ray is an output where the 
negative values are clipped to zero and the height-field uses only 8
bit data (as delivered by the libtif-RGBA-interface currently used by 
POV) instead if at least 16bit. But POV-Ray will give him no warning 
about this and it is nowhere documented. This person will therefor 
decide that POV-Ray is just a crappy renderer and he will not know and 
care that only the POV-Ray TIFF support is *just* not very well.
And this is nothing I imagined, this is a real world example.


> You mind adding one (or separate) tasks into the bugtracking system for 
> this (http://bugs.povray.org/), so these might be followed-up as time 
> permits?

After giving it some thought, no I wont, because I do not even know 
where to begin. From my own 'simple' tiff-test-suit POV-Ray reads only
about 20% as expected and a good deal of the other 80% causes even a 
segfault. And I mean 'simple' because I have also an 'advanced' image 
set where more of the uncommon TIFF-images are collected.


-Ive

Post a reply to this message