This is not a libtiff bug, and the fact that the tiff file is multipage is not relevant. The problem is with the tiff file headers and with the applications' interpretations of those headers. I believe eog and evince are both misinterpreting the orientation header. To rule out the multipage nature of the image as a source of the problem, you run tiffsplit on the attached image to get separate images for each of the eight pages, called xaaa.tif through xaah.tif. You can display any of those pages with evince or eog and see the same thing, indicating that this doesn't have anything to do with the image being a multipage image. We can observe that the orientation of these tiff files is unusual. To do this, create a "normal" tiff file using "import" from ImageMagick. Run import /tmp/a.tif and click on any window. Then run tiffinfo /tmp/a.tiff | grep Orientation You will see Orientation: row 0 top, col 0 lhs This means that the first row of the image is the visual top, and the first column is the visual left. If you run tiffinfo on the attached image file and grep for Orientation, you see the following: Orientation: row 0 rhs, col 0 top Orientation: row 0 rhs, col 0 top Orientation: row 0 rhs, col 0 top Orientation: row 0 rhs, col 0 top Orientation: row 0 rhs, col 0 top Orientation: row 0 rhs, col 0 top Orientation: row 0 rhs, col 0 top Orientation: row 0 rhs, col 0 top All subimages have row 0 rhs, col 0 top, meaning that the first row is the visual right and the first column is the visual top. This is the same as having the image rotated 90 degrees to the right. It seems that both eog and evince are flipping the image horizontally instead of rotating it, and "display" from ImageMagick is ignoring the orientation field entirely. The only application I've been able to find that actually handles this orientation value is gthumb, which at least the way I have it configured (I know I set some option to obey image orientation because my Canon digital camera uses the jpeg orientation field), does actually show the image rotated 90 degrees to the right. Even gimp doesn't handle this properly. If you run gimp on one of the pages, you get the warning ** (tiff-load:27322): WARNING **: Orientation 6 not handled yet! If you run tiffcp on the file to copy it to another file using the tiff library: % tiffcp AK-LV104e.tif a.tif AK-LV104e.tif: Warning, using top-left orientation. AK-LV104e.tif: Warning, using top-left orientation. AK-LV104e.tif: Warning, using top-left orientation. AK-LV104e.tif: Warning, using top-left orientation. AK-LV104e.tif: Warning, using top-left orientation. AK-LV104e.tif: Warning, using top-left orientation. AK-LV104e.tif: Warning, using top-left orientation. AK-LV104e.tif: Warning, using top-left orientation. you can observe that libtiff overrides the orientation. The resulting file displays properly with evince and eog and all the other viewers I can find. I'm not sure whether eog and evince, both gnome applications, might be using the same underlying code between the application and libtiff to render the images. In that case, the bug is really against that library, not libtiff. It's also possible that they both interpret the orientation fields in the same way in their own code. More investigation would be required to figure out where the bugs really live. As an interesting experiment, you can determine how different applications interpret orientation by resetting the orientation field in the header using tiffset. The orientation field has tag number 274, which you can tell from the output of tiffdump. To set the orientation of one of the pages to normal "1" orientation, you can run tiffset -s 274 1 xaaa.tif Then you will observe that xaaa.tif displays properly in all viewers. Here are the meanings of the orientation values from the TIFF spec: 1 = row 0 top, col 0 left 2 = row 0 top, col 0 right 3 = row 0 bottom, col 0 right 4 = row 0 bottom, col 0 left 5 = row 0 left, col 0 top 6 = row 0 right, col 0 top 7 = row 0 right, col 0 bottom 8 = row 0 left, col 0 bottom