in reply to How to flip little-endian TIFF to big-endian?

According to my /usr/share/magic, the headers differ for the two, "II\x2A\x00" for little-endian (Intel), and "MM\x00\x2A" for big-endian (Motorola).

Update: You have more against you than the header. TIFF files are tagged data, and part of the tag should not be reordered. Will follow up with specifics.

Update: The TIFF header looks like this C struct,

typedef struct { uint16 numbertype; uint16 version; uint32 offset; } TIFFHEAD;
'offset' is the offset to the first tagged image library in the file. The tag is a structure like this:
typedef struct { uint16 tag; uint16 type; uint32 length; uint32 offset; } TIFFTAG;
Tags can nest. The data they contain is a mixture of types. A straightforward 32-bit conversion like you propose will clearly scramble the file. You need to get information about TIFF tag types and recursively unpack the files according to each tag's content.

After Compline,
Zaxo

Replies are listed 'Best First'.
Re: Re: How to flip little-endian TIFF to big-endian?
by Anonymous Monk on Dec 20, 2003 at 00:30 UTC
    Zaxo,

    Thanks alot for the help. It turns out that flipping the TIFF file is not necessarily the problem I'm hitting here. In fact, I found this piece of text:

    Programmers working with bitmap files need to be concerned about byte order, because many popular formats such as Macintosh Paint (MacPaint), Interchange File Format (IFF or AmigaPaint), and SunRaster image files are always read and written in big-endian byte order. The TIFF file format is unique, however, in that any TIFF file can be written in either format, and any TIFF reader must be able to read either byte order correctly regardless of the system on which the code is executing.

    So, I'm going to pushback on the user. This is being generated from a very very very old piece of Windoze 3.1 software. I suspect it's generating dubious files. In fact, stuff like the GIMP, ImageMagick, etc can't properly identify the file.

    Thanks for all your help.