 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
POV 3.5 b 9.icl on PII 233 128 MB with NT 4 Sp 6
I play with tiff reading and I've problems with spherical image_map.
I've used first template of standard distribution named 'Basic scene'.
I've removed plane{} and replaced content of sphere's pigment with
image_map{ tiff "..\\test.tif" map_type 1 interpolate 2 }
I've convert test.pov from /include/ directory to tiff file in location pointed
in "..\\test.tif"
And now problems starts
First bug: "..\\" should IMO cause message with IO restrictions becouse it was
first run after start and pointed to not. But no massage. Render finished
succesfull and I changed content of pigment to
image_map{ png "..\\test.png" map_type 1 interpolate 2 }
and message about IO restrictions appeared.
Second bug and others.
Let's back to first render. I used IrfanView 3.61 (http://www.irfanview.com/) to
convert images to tiff format.
1. No conversion.
Shape of image seems ok but colors are distorted. Parts seems transparent. At
first I though it is bit/color component order problem but distortions are
different after every next render of the same compressed file.
2. LZW compression
Shape is distorted and change after next renders.
3. PackBits compression
The same as No conversion
4. JPEG compression
Parser crashed ! So no image output to comment.
5. ZIP compression
The same as No conversion
It is possible that above problems are connected with output of Irfan View but
POV shouldn't crash) so I checked output of MS Photo Editor 3.0. Output of MS
PhotoEditor is as good as output of iriginal png. So at last I found below
problems:
1. There shouldn't be crash.
2. There could be some warnings or errors when tiff file is wrong
3. Why appearance of the same tiff-file change from render to render ?
4. There should be update of documentation about tiff limitations.
5. There could be some softweare listed in documentation to validate tiff
according to pov limits.
6. Isn't IO restrictions checked for tiff reading ?
All discussed image maps after moment in povray.beta-test.binaries.
And sorry I have no time to test all this behaviours with second compile
version, other mapping types, other interpolation types and other locations.
There could be to many variants and IMO it's moment for source investigation.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>First bug: "..\\" should IMO cause message with IO restrictions becouse it was
>first run after start and pointed to not. But no massage. Render finished
>succesfull and I changed content of pigment to
>
>image_map{ png "..\\test.png" map_type 1 interpolate 2 }
>
>and message about IO restrictions appeared.
Confirmed. IO restrictions seem to be applied to PNG, GIF and JPEG image
maps, but not to TIFF image maps.
>Second bug and others.
>
>Let's back to first render. I used IrfanView 3.61 (http://www.irfanview.com/) to
>convert images to tiff format.
>
>1. No conversion.
>
>Shape of image seems ok but colors are distorted. Parts seems transparent. At
>first I though it is bit/color component order problem but distortions are
>different after every next render of the same compressed file.
Confirmed. Perhaps POV is reading off the end of the 4-bit palette into
the part of memory where it expects the 8-bit palette to reach. (All the
Irfanview TIFFs except number 4 have 4-bit palettes).
>2. LZW compression
>
>Shape is distorted and change after next renders.
Distortion confirmed. It looks the same every time on my machine.
>3. PackBits compression
>
>The same as No conversion
Confirmed.
>4. JPEG compression
>
>Parser crashed ! So no image output to comment.
This TIF file seems to be really weird. It seems to state that it uses
73646 bits per pixel.
>5. ZIP compression
>
>The same as No conversion
Confirmed.
Irfanview seems to create TIFF images with just enough bits-per-pixel
for the particular image it is processing at the time. I tested it with
an image that happens to use 130515 different colours, and it created
TIFFs with 24 bits per pixel; and with an image that happens to use 254
different colours and it created TIFFs with 8 bits per pixel.
POV handles such images correctly with all compression types none,
packbits and Zip, except that the 24-bit images are upside down.
POV fails to handle TIF images of any colour-depth created by Paint Shop
Pro. Perhaps PsP always uses LZW compression.
I happen to have 10 applications on my machine that have the ability to
read TIFF files. None of them could read types 1, 4 and 5, except
Irfanview itself.
>It is possible that above problems are connected with output of Irfan View but
>POV shouldn't crash) so I checked output of MS Photo Editor 3.0. Output of MS
>PhotoEditor is as good as output of iriginal png. So at last I found below
>problems:
>
>1. There shouldn't be crash.
>2. There could be some warnings or errors when tiff file is wrong
>3. Why appearance of the same tiff-file change from render to render ?
>4. There should be update of documentation about tiff limitations.
>5. There could be some softweare listed in documentation to validate tiff
>according to pov limits.
>6. Isn't IO restrictions checked for tiff reading ?
>
>All discussed image maps after moment in povray.beta-test.binaries.
>And sorry I have no time to test all this behaviours with second compile
>version, other mapping types, other interpolation types and other locations.
>There could be to many variants and IMO it's moment for source investigation.
I've checked map_type and interpolate. They don't affect any of the
anomalous behaviour.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Further investigations, creating TIFF files with several different
programs, reveals the following pattern of POV compatibility:-
Compression 1-bit 4-bit 8-bit 24-bit
FAX CCITT 3 Inverted - - -
FAX CCITT 4[1] Inverted - - -
Huffman Inverted - - -
LZW Bad Bad Bad Bad
LZW+Hz Predict Bad Bad Bad Bad
PackBits Inverted Bad colour Good Inverted
ZIP[1] Inverted Bad colour Good Inverted
JPEG[2] - - - *Crash*
None Inverted Bad colour[2] Good Inverted
Notes:
[1] Irfanview is the only program I have that outputs CCITT4, ZIP or
JPEG compression.
[2] The 4-bit uncompressed image from MGI Photosuite caused POV to
crash. Those from other programs just caused incorrect colours.
Overall:-
LZW compression doesn't work at all.
JPEG compression causes a crash.
4-bit images have their palettes decoded incorrectly.
1-bit and 24-bit images are upside down.
Images are not checked for compatibility, POV just goes ahead and tries
to decode them anyway.
The image data does not appear to be being checked to see if what POV
considers to be a pointer (but may not be when POV is trying to decode
stuff it doesn't understand) points off the end of the image data.
The only TIFF images that are fully supported (have 8-bit colour) and
(are compressed with Packbits or ZIP or are uncompressed).
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams <mik### [at] nospam please> wrote in
news:430### [at] econymdemoncouk:
> LZW compression doesn't work at all.
I'm surprised that Pov even tries to do anything with LZW TIFFs at all
given that the infamous Uni$y$ patent covers LZW in all forms, and that the
equally infamous polymorphic LZW usage terms now appear to require
royalties for decompression.
> Images are not checked for compatibility, POV just goes ahead and tries
> to decode them anyway.
Suggestion to developers: have you people looked at http://www.libtiff.org
yet? It might be a better option than the current POV TIFF loader.
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: tiff problems in reading (including crash, including [doc])
Date: 6 Jan 2002 15:15:27
Message: <3c38b05e@news.povray.org>
|
|
|
| |
| |
|
|
Coridon Henshaw <che### [at] sympaticoca> wrote:
: I'm surprised that Pov even tries to do anything with LZW TIFFs at all
: given that the infamous Uni$y$ patent covers LZW in all forms, and that the
: equally infamous polymorphic LZW usage terms now appear to require
: royalties for decompression.
POV-Ray supports gif reading, so it shouldn't be a big surprise.
: Suggestion to developers: have you people looked at http://www.libtiff.org
: yet? It might be a better option than the current POV TIFF loader.
POV-Ray uses libtiff version 3.5.5.
What did you think it used?
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote in news:3c38b05e@news.povray.org:
> POV-Ray uses libtiff version 3.5.5.
> What did you think it used?
I had no idea, but I didn't consider libtiff to be all that likely as Pov
chokes on extremely common TIFF subformats and even fails to read all of
libtiff's test suite.
FWIW, the current version of libtiff is 3.5.7. Quite a number of nasty
bugs that were in 3.5.5 (such as memory overruns) have been fixed in this
version.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
wrote:
> POV 3.5 b 9.icl on PII 233 128 MB with NT 4 Sp 6
>
> 1. No conversion.
> 2. LZW compression
> 3. PackBits compression
> 4. JPEG compression
> 5. ZIP compression
Non of wrong listed behaviours has changed in RC4. Crash still appear for some
cases.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
