|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> clipka schrieb:
>> 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.
>
> ... and POV-Ray 3.6.2 renders both properly; I presume that this is an
> issue in the TIFF library: In the POV-Ray 3.6.2 branch, it has been
> updated to libtiff 3.8.2, while POV-Ray 3.7 still uses libtiff 3.6.1.
>
> I tried to "transplant" the libtiff 3.8.2 from POV 3.6.2 over to the
> POV-Ray 3.7 project, but with not much success yet.
POV-Ray supports only a (particular small) subset of possible
TIF-formats and IIRC there was a change between libtif 3.6 and 3.8
regarding alpha channels and the recommended way the tag
'TIFFTAG_EXTRASAMPLES' should be interpreted.
POV-Ray also ignores all colorimetric and gamma correction related tags.
And POV-Ray does not support all the 'interesting' TIF-formats like
16bps, 24bps, and 32bps floating point HDR anyway.
In fact TIFF support is 'broken' in so many ways that I would drop it
completely. I can estimate how much time is needed to write some
reliable TIF importer and I think this time would be better spend for
the more important things within POV-Ray.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive schrieb:
> POV-Ray supports only a (particular small) subset of possible
> TIF-formats and IIRC there was a change between libtif 3.6 and 3.8
> regarding alpha channels and the recommended way the tag
> 'TIFFTAG_EXTRASAMPLES' should be interpreted.
That must then be why POV-Ray 3.6.2 handles those TIFF files properly
while 3.7 does not.
> In fact TIFF support is 'broken' in so many ways that I would drop it
> completely. I can estimate how much time is needed to write some
> reliable TIF importer and I think this time would be better spend for
> the more important things within POV-Ray.
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.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive schrieb:
> It seems POV-Ray does not even support the 'most basic' TIF-files.
Well, it does /support/ them in the sense that you can use them. Whether
it supports them /well/ is a perfectly different thing.
> [... lots of chode change suggestions...]
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?
>> 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.
That may well be, but 3.8.2 is the one working successfully in POV-Ray
3.6.2 for Windows, so I figured it would be easiest to get it to compile
with 3.7 as well :-)
You're welcome of course to go for integrating 3.9.1 into POV-Ray,
including Visual Studio 8 and 9 projects and all...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|