clipka wrote:
> 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.
> 

There is nothing highly sophisticated within a 16bit grayscale tiff, for 
instance.


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

As said there are a lot of problems within all versions of libtif. 
Mostly because Adobe 'owns' the tiff specification but did not update it 
since 1996! Sometimes they publish a tech-note about TIFF enhancements
but usually they do so *after* having implemented them into Photoshop.
Adobe itself does not use libtif.
And I would never rule out that IC is buggy, by the way. Sure it is,even 
if I'm not aware of any within the current version.


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

Ah, well, ok. This message (together with the radiosity and spline 
warning) appears, let me guess, since 10 years? More? So I have learned 
to completely ignore and forget about it. But you are right, it is 
there, so I'll take back my 'No Warning' grumbling.


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

You do get me wrong here. POV-Ray uses the libtif-RGBA-interface. This 
interface is the only high level interface provided by libtif, but it 
only delivers 8bit/sample data no matter what the input color resolution 
might be. It is meant to be used for a quick preview or thumbnail 
generation but is in no way suitable for the way a rendered uses images.
It does not support most of the 'newer' data formats as written e.g. by 
Photoshop and finally it even causes segfaults for some input formats. 
As long as this interface is used there is simply no way of fixing 
anything for POV-Ray's TIFF import.
Dropping the usage of this interface and usage of the libtif low level 
functionality means *a lot* of work. My guess: about 40 man-hours for a 
person who is already very familiar with the TIF format specification 
and the inner working of libtif. Otherwise multiply the required time at 
least by 3.
And I'm not talking about support for exotic flavors of TIF-files here 
  only support for 8 and 16bps gray/rgb images and maybe the 'newer' HDR 
formats. All other formats (especially color separations) should be 
rejected on input and the user should be informed that this particular
TIF-format is not supported by POV-Ray.
I am indeed considering doing this by myself but as I have also already 
pointed out: after such an long lasting 'experimental' phase I think 
simply dropping the TIFF support would in fact also be a valid solution 
as there *is* currently no benefit for POV-Ray in using TIF-files as 
they are always stored as 8bps rgb images and those are supported by all 
the other image file formats POV-Ray does use as well.
The point I do disagree with you is this 'better a poor support than 
nothing'. Hey, it's the 21st century and I simply expect from any render 
software to make use of higher bit-depth if the image file format 
supports this.

-Ive

Post a reply to this message

Ive schrieb:
> I am indeed considering doing this by myself

... which would be good news, because I guess it would be in good hands...

 > but as I have also already
> pointed out: after such an long lasting 'experimental' phase I think 
> simply dropping the TIFF support would in fact also be a valid solution 
> as there *is* currently no benefit for POV-Ray in using TIF-files as 
> they are always stored as 8bps rgb images and those are supported by all 
> the other image file formats POV-Ray does use as well.

That is indeed a valid point. And it's not like image file formats are 
any difficult to convert nowadays.

> The point I do disagree with you is this 'better a poor support than 
> nothing'. Hey, it's the 21st century and I simply expect from any render 
> software to make use of higher bit-depth if the image file format 
> supports this.

Well, my point was actually "better a merely inferior support than one 
that doesn't even work for the most brain-dead basic file variant", and 
"retaining an existing albeit inferior support doesn't hurt" (at least 
not too much).

Though I do concede that dropping TIFF support altogether might not hurt 
too much either. And after all, it has been marked experimental all the 
while anyway.

What I do disagree with is the "changing from libtiff 3.6.1 to libtiff 
3.8.2 makes things even worse" that your postings appeared to imply.

Post a reply to this message

clipka wrote:
> What I do disagree with is the "changing from libtiff 3.6.1 to libtiff 
> 3.8.2 makes things even worse" that your postings appeared to imply.

Sorry, it was not meant this way. Of course it is a good idea to change 
to a more resent libtif version and I appreciate the work you put into it.
My point was that between 3.6 and 3.8 the libtif developers changed 
libtif's interpretation of one tag regarding the handling of alpha 
channels. This change was made for better compatibility to tif-files as 
e.g. written by Adobe software but did at the same time break the 
correct handling for other files, including the ones written by older 
versions of libtif itself. So it is not a *fix* but a paradigm change.

-Ive

Post a reply to this message

clipka wrote:
> clipka schrieb:
>> clipka schrieb:
>>> It appears to me that TIFF file input is broken, leading to a 
>>> transparent texture when used in an image_map; can someone confirm?
>>
>> I should have mentioned that this is about 3.7 (beta.34 to be exact).
> 
> Apparently, the behavior is different for compressed and uncompressed 
> files.

Finally a funny observation: the problem had nothing to do with the 
changed handling of alpha channels or the libtif version. It just 
happened that the LZW support within the libtif configuration is 
disabled for the 3.7 beta 34 due to the (meanwhile obsolete) LZW patent 
issue I assume.
And as tiff warning and error messages are disabled by the POV-Ray 
importer it just returned an empty image.

-Ive

Post a reply to this message