GNOME Bugzilla – Bug 439994
TIFF loader does not handle all types of orientation equally
Last modified: 2018-05-22 13:05:19 UTC
This is a follow-up to bug 428725, where the ability to add tiff and jpeg/exif orientation tags was added to the pixbuf loaders. Libtiff does not perform rotations [1] (because that requires swapping the height and width of the image). To compensate for the partial transformations, an orientation option is attached to the resulting pixbuf. The application needs to take care of this option to display the image with the correct orientation. I think we should use either the orientation option or the automatic rotation, but not a mixture of both. Because with the current situation, depending on the orientation value of the image, you can end up with three different situations: no transformation, a partial transformation or a full transformation. [1] http://bugzilla.remotesensing.org/show_bug.cgi?id=1548
Jef, I think that the "correct" way to produce consistent behavior would be to add a new function to libtiff that does not perform the partial transforms, and then modify the gtk tiff loader to use that function (bumping the libtiff version requirement, again). The partial transforms in libtiff are currently mandatory; it is only the "starting position" that can be adjusted (which is a little odd). That way, gdk_pixbuf_new_from_file would always provide un-rotated images, and gdk_pixbuf_transform_orientation_auto would always be needed for proper loading. Neither library would have bizarre hacks that way. It's not the highest priority issue, though... Most applications should be patched to use gdk_pixbuf_transform_orientation_auto, which will resolve the issue from an end-user perspective, even if the underlying code is hackish. - Mike
The original bug on remotesensing.org isn't available any more. Do you have example of files that we don't handle properly, and a way to see how they're supposed to look?
Bastien, I don't have sample files anymore, but the issue is fairly well documented in gdk-pixbuf/io-tiff.c:tiff_image_parse. libtiff does the right thing for orientations 1-4. It does not implement the rotations required for orientation 5-8, but it implements the required flips, which is weird. As a result, their is some hackish code in tiff_image_parse to report a "compensated" orientation code which will result in the correct display IF the code calls gdk_pixbuf_apply_embedded_orientation after loading the initial "raw" pixbuf. I think most (?) gnomish apps call gdk_pixbuf_apply_embedded_orientation now. Personally, I think the tiff and jpeg loaders should call gdk_pixbuf_apply_embedded_orientation automatically. This wouldn't break any existing code, because the orientation pixbuf-option-tag gets reset, so calling gdk_pixbuf_apply_embedded_orientation multiple times won't break anything. I'm not familiar enough any more with the loaders to make this happen.
Oh, I remember something else: I think gdk_pixbuf_apply_embedded_orientation was tacked on as a utility function, because it was hard to handle the progressive loaders properly - major code surgery would be needed to make the progressive loaders handle the orientation right from the start.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/11.