5

When trying to view tif image files in feh, the following pair of error messages is printed to stderr:

TIFFReadDirectory: Warning, Unknown field with tag 37553 (0x92b1) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 37554 (0x92b2) encountered.

TIFFReadDirectory is a C library, and the error message is self-explanatory (manpage). Unfortunately, I can't find much information about the relevant tag numbers (37553, 37554). What do these tags specify? Can I build support for them into TIFFReadDirectory? The problem is that they prevent functionality when viewing the files in the feh image viewer, specifically the ability to lock viewport settings from one image to another.

user001
  • 3,598
  • 5
  • 39
  • 54
  • Can you strip the unknown tags from the images? Or can you convert the images to a different format? – Volker Siegel Sep 09 '14 at 04:09
  • Do you have an indication where the IMAGES came from. We used our own extension tags in the early 90s as it was proved (too) difficult to get a range assigned from Aldus. However software can (and should) skip container elements with tags it doesn't know, so `feh`'s functionality should not be blocked by this – Anthon Sep 09 '14 at 04:09
  • @VolkerSiegel: That's a good idea. I will have to look into tag stripping. – user001 Sep 09 '14 at 15:14
  • @Anthon: The images come from a Spot digital camera. Do you think that the `feh`-related problem I described might be unrelated to the errors about the unrecognized tag? – user001 Sep 09 '14 at 15:16
  • If the steps in my answer do not help, please post (a link to) the `tiffinfo` output for one of these files. – Anthon Sep 09 '14 at 16:30

2 Answers2

5

Background
The TIFF files format is a container format, with items in the container with a specific length and identifying TAG. How to interpret these items is depending on the TAG, a whole list of them was specified in the Aldus documentation, and there are vendor specific extensions, some of which are in the list that @slm pointed to, but this list is not exhaustive.

feh, should be able to ignore items with an unknown TAG¹. The TIFF specification is at version 6.0 and that is from 1992, so that aspect of reading the file format should be easy.

feh is more likely to have problems with data in some of the normal TAGs, e.g. with trying to access compressed data in random access mode, or no support for (compressed) tiled image data. These kind of problems have been reported on the internet before although this seem to have been related to files having the unknown tags as well. TIFF 6.0 already had support for LZW compression of image data, which not all reading programs supported. It is normally possible to convert from compressed TIFF to non-compressed TIFF (and back). We used to have our own converter because none of the available programs supported the compressed tiled format we needed for optimising our ray-tracing program.

How to proceed
You should try to use gimp to read the files and write them non-compressed. AFAIK gimp uses libtiff (you might have to install support for the format as a plug-in). And feh uses libim2.
Use tiffinfo on the file before and after the "expansion" through gimp to check if anything else was deleted.

Another thing to do is check is whether the camera supports settings for saving to differing TIFF file formats (compressed/non-compressed etc), experimenting with that might help you find that the unknown tags stay, but that the files become usable. Of course that doesn't help you with these problematic files.

¹ I have created TIFF files with non-registered tags, that only our own software could interpret. Other software we used had no problem ignoring this, and that was 21 years ago.
² This was not because of technical difficulties, but because of copyright restrictions, in the same way that it could be problematic to support GIF files in an application
.

Anthon
  • 78,313
  • 42
  • 165
  • 222
  • Thanks for your explanation. I think the problem might relate to the fact that TIFF container consists of two images, one is 2048x2048 and contains the full-resolution image; the other is, I suppose for thumbnail display by file browsers, and consists of a 62x62 low-resolution version of the same image. I believe the layers have different compressions, layer 1 being uncompressed and layer 2 being compressed with JPEG. This is shown by running the following command (the output of which is shown in the succeeding comment). `$identify -verbose temp.tif | grep -i compression` [output follows] – user001 Sep 09 '14 at 20:54
  • [output from preceding command; `\n` denotes a newline] STDOUT: `Compression: None` \n `Compression: JPEG` \n STDERR: `identify.im6: Unknown field with tag 37553 (0x92b1) encountered. 'TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/768.` \n `identify.im6: Unknown field with tag 37554 (0x92b2) encountered. 'TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/768.` \n – user001 Sep 09 '14 at 20:54
  • @user001 Is there any chance of sharing that TIFF file? Or otherwise the output of a `tiffdump`, so that there is more information about the internals of the file? – Anthon Sep 11 '14 at 14:19
3

I found this page that describes some of the tags.

It describes the tags as follows:

Extension TIFF tags are those tags listed as part of TIFF features that may not be supported by all TIFF readers, according to the TIFF specification.

It goes on to show a table of tag values below. Neither of those 2 tags are included, which is likely the issue to begin with, some image application generated the TIFF files you're attempting to view with tags that are unique to only that tool, and are not part of the TIFF specification.

    ss#1

If you poke around that website you'll notice that you can also search for specific tags. Neither of the ones you mentioned were listed. The FAQ is worth browsing through too. It covers how TIFF works and specifically this question might be helpful:

slm
  • 363,520
  • 117
  • 767
  • 871
  • Thanks. So it sounds like `TIFFReader` might only be able to interpret official tiff tags, and throws an error whenever it encounters private or custom tags. I wonder why this causes dysfunctionality with the viewer (`feh`) that depends on the `TIFFReader` library. – user001 Sep 09 '14 at 15:14