After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 725582 - gdk_pixbuf_apply_embedded_orientation is not working for attached image
gdk_pixbuf_apply_embedded_orientation is not working for attached image
Status: RESOLVED FIXED
Product: gdk-pixbuf
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gdk-pixbuf-maint
gdk-pixbuf-maint
Depends on:
Blocks:
 
 
Reported: 2014-03-03 14:57 UTC by Jussi Pakkanen
Modified: 2015-04-21 11:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jussi Pakkanen 2014-03-03 14:57:41 UTC
Attached is an image that is stored wide but has orientation metadata specifying that it should be displayed vertically. Note that the image's "visually correct orientation" is vertical, that is, when viewed in the orientation specified by the metadata it is displayed the wrong way visually. This does not affect the bug here, though.

Open the image with Gimp. It will ask "do you want to rotate this image to its correct orientation". If you select yes, it will rotate it.

Then try to reorient the image with the following piece of code:

-------

#include<gdk-pixbuf/gdk-pixbuf.h>

int main(int argc, char **argv) {
  if(argc != 3) {
    printf("%s input_file output_file.\n", argv[0]);
    return 1;
  }
  GdkPixbuf *img = gdk_pixbuf_new_from_file(argv[1], NULL);
  GdkPixbuf *rot = gdk_pixbuf_apply_embedded_orientation(img);
  gdk_pixbuf_save(rot, argv[2], "png", NULL, NULL);
  g_object_unref(G_OBJECT(img));
  g_object_unref(G_OBJECT(rot));
  return 0;
}

------

The resulting image will not be reoriented. Opening it in the Gimp will display it in the uncorrected orientation.

gdk_pixbuf_apply_embedded_orientation should rotate the image into its correct orientation, but it does not seem to be doing that.
Comment 1 Jussi Pakkanen 2014-03-03 15:02:52 UTC
The image file was too large for bugzilla, so here's a link:

https://dl.dropboxusercontent.com/u/37517477/test.jpg
Comment 2 James Henstridge 2014-03-11 09:38:05 UTC
From a quick test of the image, it seems that the problem is not in apply_embedded_orientation(), but rather the JPEG loader not reading the orientation correctly:

    >>> from gi.repository import GdkPixbuf
    >>> pb = GdkPixbuf.Pixbuf.new_from_file('test.jpg')
    >>> print(pb.get_option('orientation'))
    None

With no orientation data to work with, apply_embedded_orientation() is a no-op.
Comment 3 James Henstridge 2014-03-11 09:55:50 UTC
The problem seems to be that the JPEG loader assumes that the orientation will be encoded as a short (type 3):

https://git.gnome.org/browse/gdk-pixbuf/tree/gdk-pixbuf/io-jpeg.c#n479

While the camera that produced the problem image encoded it as a signed long (type 9).  Even if this violates the spec, presumably there are a fair number of cameras in the wild that exhibit this behaviour.
Comment 4 Bastien Nocera 2014-10-22 17:33:15 UTC
Test file is not available anymore.
Comment 5 Michi Henning 2015-04-21 03:45:38 UTC
Test file is available here:

https://www.dropbox.com/s/h6wv9kt5nl8nevl/testrotate.jpg?dl=0
Comment 6 Bastien Nocera 2015-04-21 10:42:08 UTC
What's weird is that nautilus shows it properly. I've uploaded the file to:
https://people.gnome.org/~hadess/bug725582-testrotate.jpg
Comment 7 Bastien Nocera 2015-04-21 11:15:00 UTC
Huh. GIMP is asking me whether to apply the rotation. The image is already horizontal, and applying the orientation shifts it to vertical.

Michi, are you sure that Dropbox isn't mangling this image?
Comment 8 Michi Henning 2015-04-21 11:24:21 UTC
Yes, I'm pretty sure. This is a test file from our codebase. The idea is that the original image is horizontal and looks correct. The thumbnail inside it also is horizontal, so the image looks right. However, the orientation data for the thumbnail says to rotate it 90 degrees clockwise. So, if the thumbnail is extracted correctly (with the orientation info applied), what you should see is the image in portrait mode so it looks "wrong".

Gimp does exactly the right thing with this image. It asks whether to apply the EXIF orientation and, if you do, you will see the image "wrong" (on its side).

My understanding of this bug is that gdk_pixbuf_apply_embedded_orientation() should result in the same "wrong" image that Gimp shows. But, apparently, that's not what's happening.
Comment 9 Michi Henning 2015-04-21 11:31:49 UTC
(In reply to Bastien Nocera from comment #6)
> What's weird is that nautilus shows it properly. I've uploaded the file to:
> https://people.gnome.org/~hadess/bug725582-testrotate.jpg

That's interesting. I just tried with Nautilus, and it shows the image rotated correctly (that is, "wrong", with portrait orientation, such that the image is on its side). In other words, Nautilus appears to apply the orientation correctly.
Comment 10 Bastien Nocera 2015-04-21 11:34:22 UTC
(In reply to Michi Henning from comment #8)
> Yes, I'm pretty sure. This is a test file from our codebase. The idea is
> that the original image is horizontal and looks correct. The thumbnail
> inside it also is horizontal, so the image looks right. However, the
> orientation data for the thumbnail says to rotate it 90 degrees clockwise.
> So, if the thumbnail is extracted correctly (with the orientation info
> applied), what you should see is the image in portrait mode so it looks
> "wrong".

Grmmpf. I expected a real photo, not something cooked up for testing, which is why I wondered why this photo appeared wrong.

Then my code looks fine.
Comment 11 Bastien Nocera 2015-04-21 11:37:30 UTC
Fixed in master, thanks for the test image.
Comment 12 Michi Henning 2015-04-21 11:49:26 UTC
> Grmmpf. I expected a real photo, not something cooked up for testing, which
> is why I wondered why this photo appeared wrong.

My apologies. I came to this issue late. The image wasn't mine originally and chimed up mainly because I happened to know where it was. My apologies for the confusion.

Thanks for fixing this so promptly!