|
 |
Ive schrieb:
> 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.
Well, I think there is a difference here: What I was talking about was
loss of quality. What you're referring to is inability to see the image
at all. Which is a much more "WTF"-ish situation than distorted colors:
Where's my object? Did I break the geometry? Do I have scaled up the
scene too much? I guess broken input file handling is the thing that
comes to mind last in such a situation. Whereas if the colors look
crappy, it's easier to notice that something might be wrong with the
image file.
> 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!
I know not much about that; if you know a better solution to get even
the most dumb-ass photoshopped TIFF files to show, you're welcome to
join the ranks and get your hands dirty on the code. But since POV-Ray
3.6.2 has gone that road for libtiff 3.8.2, and has done so with some
success (after all, it does properly read the very vanilla
8-bit-per-color non-transparent TIFFs a most-stupid-of-all-users is most
likely to produce, which POV-Ray 3.7 using lbtiff 3.6.1 failed at), it's
also a matter of consistency to pull 3.7 in that direction as well.
Besides, if a user is proficient enough to use highly sophisticated
variants of TIFF, chances are he knows a bit more about the pitfalls and
typical incompatibilities associated with their use than a dumb-ass
photoshopping noob.
Ah, and did I mention that one of the TIFFs POV-Ray 3.7, using libtiff
3.6.1, failed to load was created by IC with the very default settings?
So if the problem wasn't in libtiff but in TIFF files not conforming to
specifications, wouldn't that mean that IC is buggy?
> 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.
"Parse Warning: This rendering uses the following experimental
feature(s): TIFF image support. The design and implementation of these
features is likely to change in future versions of POV-Ray. Full
backward compatibility with the current implementation is NOT guaranteed."
Even though it doesn't *explicitly* say that support is far from
perfect, I think it should be clear enough. "Experimental" is the
keyword here.
>> 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.
Well, in that case I consider it a bit moot to complain. The problems
will not solve themselves, nor will anyone of the dev team or the other
code contributors solve them unless they know about them in the first place.
Post a reply to this message
|
|
