Disclaimer: I am by no means an expert on TIFF (or anything else). This blog (series) is me sharing my recent look into TIFF errors. Please feel free to comment, point out errors, suggest better fixes, etc. At the end of the day, we’re all in this together and here to learn from each other!

You know how there are TV series that people rave about for years and you always think “yeah, when I have time I’ll go watch that”. Then someone makes you sit down to watch an episode and you’re hooked, thinking “woha, why didn’t I watch this years ago!?”.
I recently had a similar experience with TIFF. While it’s the gateway drug to file-format nerdism for many, I happily admit that I started my in-depth look rather late in life.

Having thus outed myself as a TIFF n00b I feel this is a safe space to share what I’ve learned. I’ll take it one error message at a time – talking about how the error can be validated, what I believe it means, how it can be fixed and how I judge the impact. I’m hoping for a lively discussion pointing out where I am wrong or right and what could be done differently.

Today’s error is: Tag 270 out of sequence.
While everything here works most likely for any tag-out-of-sequence error, this was the first one I encountered.

What’s the message?

Our first tool in line for reporting errors is JHOVE, from there I usually go and test further tools to crosscheck. In this case, three different tools – jhove, DPF Manager and exiftool – all agree on the file containing an error:

What’s the problem?

TIFF is a tag-based file format. In this case the error messages shown above are spot on – Tag 270 is out of sequence, aka not where it’s supposed to be. The TIFF (Revision 6.0) specification states that “the entries in an IFD must be sorted in ascending order by Tag“.

Let’s take a look at the order currently found in the IFD. Tag numbers, descriptions and values can be easily extracted with exiftool using the following command:

exiftool -D filename 

In our erroneous file, this results in the following output:

In the above output it’s fairly easy to spot that Tag 270 is indeed out of sequence, as it follows tag 305.

How can I fix it?

Again, exiftool can come to the rescue. It has a command which allows to create a copy and write all or specific tags new. If tags are written new, then they are automatically entered in the correct order. In this case, we want to just write the tag 270 Image Description new. This can be achieved via the following command:

exiftool -P -ImageDescription= -tagsfromfile @ -ImageDescription file 

This results in the old file being renamed to filename.tif_original and the creation of a new file with the same filename as the old. The -P flag prevents filesystem date/time tags, such as the Modification Date/Time, to be overwritten with the current date.

If we look at the tags of the newly created file, we can see that Tag 270 is now where it should be – in this case, between 262 and 273:

While the command only alters the tags there is, of course, always the risk of image data being corrupted during the copy process. Thankfully, there is an ImageMagick command that calculates a hash, similar to md5, but only on the image data instead of on the entire file including the metadata / tags:

 identify -quiet -format "%#" image 

Comparing the signature of the original and the new file allows us to verify whether the image data is still the same.

How do I rate the issue?

My take on rating problems / risks for file formats is a longer story which might be worth a blog in itself … to stay focused, I propose the following (potentially controversial) rating in the context of this blog:

• Critical – indicating a severe issue, data loss, unreadable files
• Middle – violations of standard / expected structure which should be fixed
• Low – issues which can be neglected / fixes postponed to later date

An out of sequence tag is clearly a violation of the TIFF specification at the most basic, i.e. structural, level. However, the few viewers I tested (IrfanView 4.42, Evince Document Viewer 2.32.0.145, ImageMagick IMDisplay v1.0, Windows Photo Viewer) managed to render the file correctly, which is due to the rather robust nature of the format’s structure. I would assume that there might be problems in viewer / tool implementations that also read out metadata from tags and rely on a sequential structuring of the tags.
As a structural problem I rate the issue as “Middle”, meaning that the file is still readable but that a fix is recommended to ensure unambiguous interpretation of the object.