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 168231 - want EXIF rotation information via gdk_pixbuf_new_from_file
want EXIF rotation information via gdk_pixbuf_new_from_file
Status: RESOLVED DUPLICATE of bug 428725
Product: gdk-pixbuf
Classification: Platform
Component: general
git master
Other All
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
: 158538 (view as bug list)
Depends on:
Blocks: 335053
 
 
Reported: 2005-02-23 06:09 UTC by Jamie Zawinski
Modified: 2010-07-10 04:04 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Jamie Zawinski 2005-02-23 06:09:33 UTC
I load image data into my program by calling gdk_pixbuf_new_from_file().
When the file that is loaded happens to be a JPEG file from a camera,
I might need to rotate the image in order to display it properly,
depending on what the EXIF data says.

Currently, I think the only way to accomplish that is to parse the file
twice: once in a format-agnostic way (via gdk_pixbuf_new_from_file) and
then again in a JPEG-specific way (using libjpeg or something.)

I would like either:

    1)  A way to tell gdk_pixbuf_new_from_file() to auto-rotate images
        before giving them to me; or

    2)  A way to interrogate the GdkPixbuf object and ask it whether
        it requires rotation (i.e., whether it started its life as a
        JPEG whose EXIF data said so.)
Comment 1 Matthias Clasen 2005-02-23 23:50:49 UTC
Would have to link the jpeg loader against libexif for this. I think we
wontfixed a request+patch for that in the past, but we may reconsider. First
step would probably be to dig out the old bug report and update the patch.
Comment 2 Jamie Zawinski 2005-02-24 05:20:36 UTC
libexif.so is 78K.  That doesn't seem like a hardship to me...
Comment 3 Matthias Clasen 2005-02-24 13:33:20 UTC
It is also adding new code paths to the image loaders which are the only
security sensitive part of gtk...
Comment 4 Manish Singh 2005-02-24 17:46:58 UTC
Well, some minimal exif handling code could be put in the loader itself, instead
of relying on libexif (which is fairly ugly code, and trivial to crash with all
but the most recent versions).
Comment 5 Matthias Clasen 2005-06-18 14:47:17 UTC
*** Bug 158538 has been marked as a duplicate of this bug. ***
Comment 6 Christian Neumair 2006-06-16 17:02:48 UTC
The JPEG loader doesn't seem to call gdk_pixbuf_set_option with the EXIF data, which would allow the client applications to use simple flip/rotation operations according to http://jpegclub.org/exif_orientation.html.
Comment 7 Christian Neumair 2006-09-28 20:48:30 UTC
http://fresh.t-systems-sfr.com/linux/src/jpeginfo-1.6.0.tar.gz:a/jpeginfo-1.6.0/jpeginfo.c
has some interesting sample code. I wonder whether it is a good idea to evaluate jpeglib's marker_list for all attributes. I fear that auto-collecting all metadata will lead to huge mallocs. Maybe we have to introduce new helpers to determine whether a pixbuf loader should load metadata, and maybe define a filter function?
Comment 8 Michael Chudobiak 2007-04-16 12:14:36 UTC
We're taking a look at this at: http://bugzilla.gnome.org/show_bug.cgi?id=428725#c17

Please take a look...

- Mike
Comment 9 Michael Chudobiak 2007-04-22 19:07:33 UTC
Matthias, 

A patch is available at http://bugzilla.gnome.org/show_bug.cgi?id=428725#c43.

Could you/someone review the patch to see if we're on the right track?

- Mike
Comment 10 Michael Chudobiak 2007-04-23 16:53:32 UTC

*** This bug has been marked as a duplicate of 428725 ***