GNOME Bugzilla – Bug 335959
Multilayer TIFFs only show one layer.
Last modified: 2014-10-21 15:28:48 UTC
The attached TIFF was generated as a multilayer composite with Hugin. When loaded with Gimp, it displays properly, but gthumb only displays the top layer, cropped to its dimensions--the image should be around 500 pixels wide, but it displays as only the width of a single layer. I do not know if multipage TIFFs are stored as multiple layers; if they are, it would be inappropriate to display them as one big image. However, if the layers are all painted on the same canvas, as these are, they should be displayed as one large image. I am using gthumb 2.7.1-0ubuntu1 on Ubuntu Breezy.
Created attachment 61981 [details] Image exhibiting the bug A multilayer TIFF, as generated by Hugin. ImageMagick recognizes it as such: $ identify small-test.tif small-test.tif[1] TIFF 107x165 DirectClass 390kb small-test.tif[2] TIFF 114x165 DirectClass 390kb small-test.tif[3] TIFF 104x165 DirectClass 390kb small-test.tif[4] TIFF 114x165 DirectClass 390kb small-test.tif[5] TIFF 114x165 DirectClass 390kb small-test.tif[6] TIFF 114x155 DirectClass 390kb small-test.tif[7] TIFF 83x165 DirectClass 390kb
Created attachment 61982 [details] Image triggering the bug A multilayer TIFF, as generated by Hugin. ImageMagick recognizes it as such: $ identify small-test.tif small-test.tif[1] TIFF 107x165 DirectClass 390kb small-test.tif[2] TIFF 114x165 DirectClass 390kb small-test.tif[3] TIFF 104x165 DirectClass 390kb small-test.tif[4] TIFF 114x165 DirectClass 390kb small-test.tif[5] TIFF 114x165 DirectClass 390kb small-test.tif[6] TIFF 114x155 DirectClass 390kb small-test.tif[7] TIFF 83x165 DirectClass 390kb
gThumb uses gdk-pixbuf to load tiff files. So... re-assigning to gdk-pixbuf. - Mike
Well, there is a "slight" difference in level of functionality between GIMP and gdk-pixbuf. I really doubt it's proper for gdk-pixbuf itself to start handling multi-layered images, especially for the case of a format like TIFF which by definition (the "tagged" part of the name) can be extended by anyone with new tags that can mean anything. Of course, gdk-pixbuf is extensible, you are free to write a gdk-pixbuf loader that does what you want.
I have recently had a problem with a novice user (on ubuntu hardy) which received a tif via email. The tif was a 5 page scan. One file, but 5 pages of images. Sending side (using windows, of course) just scanned the files and this file was created. Receiving side just viewed the tif, but has seen only the first page. On one hand, the gtk-pixbuf is not supposed to handle it. Gtk-pixbuf primary purpose is to work with a single image. On the other hand EOG completely trusts gtk-pixbuf in displaying multi page image. This creates a big surprise for the user. There is a question: should this problem should be fixed? It emerged while using "non-standard" extension of some image format. This is probably for Mike to answer. Then there are 2 choices. Either implement multiple page feature in gtk-pixbuff together with an interface for paging OR use another tool to split the tiff into multiple images before loaded into gtk-pixbuf. Any of these solutions, is a perfect example of creep feature. Tough choice ...
It wouldn't be hard to modify the tiff loader to set option strings indicating the number of pages and/or layers in the image. It already sets an orientation string for the orientation tag. The application (gthumb, eog) could then use gdk_pixbuf_get_option to determine whether or not gdk_pixbuf was actually suitable for the image, and use a different loading strategy for multi-page/multi-layer images. Or at least issue a warning. Or offer to open the file in evince, which is designed to handle multi-page documents like faxes. - Mike
Yes, I had exactly this problem today. I almost got into a fight with the person sending me a 5-page tif-file because I claimed it was just one page! Then I opened it with evince and I saw it has 5 pages! So it is a pretty nasty bug.
Created attachment 161941 [details] [review] flag multi-page tiff files This (untested) patch should flag multi-page tiff files, allowing the client app (gthumb, for example) to warn the user. - Mike
[evolution] Bug 653247 - Don't show TIFF documents inline https://mail.gnome.org/archives/commits-list/2011-June/msg10179.html depends upon this bug being fixed. At present, Evolution is unable to render TIFF images because gdk-pixbuf unconditionally renders the first page only. I am receiving emails from a user of an Apple device that is converting images to TIFF, even if they are imported as JPEG, so the problem is starting to hurt. Is there any chance of getting this bug progressed? -Doug
I've committed this: commit 09b3fc03284ac4f9a4f466ba908f9cd7309b2ced Author: Michael Chudobiak <mjc@avtechpulse.com> Date: Tue May 25 13:15:00 2010 +0000 tiff: Flag multi-page TIFF files Add the "multipage" option to TIFF files with multiple pages. This will allow applications that use gdk-pixbuf to display images to detect them, and offer to open them in more capable readers (such as GIMP, or Evince). https://bugzilla.gnome.org/show_bug.cgi?id=335959 And I've added this fix to shared-mime-info: commit f3fea91ce8b7b5ca1c6e1776882268e8b2e217fa Author: Bastien Nocera <hadess@hadess.net> Date: Tue Oct 21 17:21:56 2014 +0200 Add image/x-tiff-multipage mime-type It's a fake mime-type that can be used by applications using a simple image loader (such as gdk-pixbuf) to find other applications capable of opening multi-page TIFF images. See https://bugzilla.gnome.org/show_bug.cgi?id=335959 Please file bugs against applications that should handle multi-page tiffs to get them to add this new mime-type (Evince, GIMP, etc.) and bugs against applications that should defer to those more capable ones to handle multi-page TIFFs (from the bug reports, evolution and gthumb).