tiff output - bad magic number

[toejough]

Hi,

When I try to output a tiff (either with pfsout or pfsoutimgmagick), I get a malformed file. Nothing can open it. When I run tiffdump on it, it tells me that the file has a bad "magic number."

Here's what I'm doing:

pfsin myfile.hdr | pfsout myfile.tiff

Is there something wrong with this approach? The examples in the pfsouttiff man page show the reverse being ok (.tiff -> .hdr)...

Thanks,

-joe

[toejough]

Also, the man page shows that there is a "--bit-depth" option for pfsouttiff, but when I specifiy it:

pfsinrgbe myfile.hdr | pfsouttiff myfile.tiff --bit-depth 16

I get:

pfsouttiff: unrecognized option `--bit-depth'

I'm running on a macbook pro retina (64 bit) with libraries/tools compiled for 64-bit.

thanks,

-joe

[toejough]

Nevermind about the bit-depth argument. I reconfigured and reinstalled, and the bit-depth argument is no longer an issue. However, the tiff is still bad.

A little more info:

pfsin myfile.hdr | pfsout myfile.ppm

creates a readable ppm just fine.

pfsin myfile.ppm | pfsout myfile.tiff

creates an unreadable tiff

pfsin other.tiff | pfsout copy.tiff

is also bad.

[Rafal]

Hi,

Writing TIFF files is a bit tricky. There are two ways to do it:

1) ... | pfsoutimgmagick img.tiff

This will use ImageMagic to write a LDR TIFF image. The image should be readable in most of the software. --bit-depth parameter is recognised.

2) ... | pfsouttiff img.tiff

This will use a custom HDR TIFF format, called LogLUV TIFF. Probably only PhotoSphere on Mac can read it. --bit-depth option is not available.

pfsout will use 1) if pfstools is compiled with ImageMagick, or 2) otherwise.

My guess is that pfstools is compiled without Image Magick and pfsouttiff is run instead of pfsoutimagemagic.  Make sure you compile with ImageMagic and use pfsoutimgmagick instead of pfsout.

Rafal

[toejough]

Hi Rafal, thanks for the response.

I do have imgmagick and pfsoutimgmagick installed and working, but I've had no luck with that, either.

Whether I use pfsout or pfsoutimgmagic, the tiff file that comes out the other side has a bad format. Even if I pipe in a valid tiff file (pfsin good.tiff | pfsoutimgmagick bad.tiff), this is true.

If I hexdump any readable tiff file on my computer, the first bytes are 0x49 0x49 0x2a 0x00.
If I hexdump the pfsout tiffs, the first bytes are 0x69 0x64 0x3d 0x49.

I couldn't find a specification for logluv with my initial internet searching, but the wikipedia page says it's a tiff encoding that libtiff can read.

The tiff specification states that the first two words of a tiff file have to be 0x4949 0x002a or 0x4D4D 0x002a, which the pfstiffs aren't - are the initial bytes I'm finding expected?

I'm also using libtiff's tools (tiffdump) to try to get info on/decode the pfs tiffs, but they are telling me the files are invalid (which is why I started looking at the hexdump and the file format spec in the first place).

Do you have any other tips on troubleshooting?

Is anyone else having this problem? I couldn't find anyone else with this problem except in an old fedora bug report that never got resolved. I have pfstools 1.5 and libtiff 4.03; I freshly uninstalled and reinstalled both just to be sure.

Thanks,

-joe

[toejough]

Quick update:

I downloaded some logluv tiffs from http://www.anyhere.com/gward/pixformat/tiffluvimg.html and their first two words conform to the tiff spec, and I can open them fine.

If I pipe them through pfs...they go bad:
]$hexdump -n 4 84y7.tif
0000000 4d 4d 00 2a
0000004
]$pfsin 84y7.tif | pfsout new.tif
]$hexdump -n 4 new.tif
0000000 69 64 3d 49
0000004
]$

[Rafal]

This could be a very quick fix: Try using "tif" extension instead of "tiff". ImageMagick uses the extension to decide on the file format for the output file. 

I also got invalid TIF file when the file was named "*.tiff", but it worked for me with "tif".

Rafal