Rotation and exif orientation observation

jnash
jnash's picture

Joined: 2004-08-02
Posts: 814
Posted: Wed, 2013-04-17 14:26

I'm wondering if anyone else has encountered this:

When Gallery rotates an image based on the exif orientation flag, the image is physically rotated and saved. However, the exif orientation flag is not updated to reflect this rotation.

When viewing the images on a viewer that honors to the exif orientation tag (PS3, iPhone/iPad(mobile safari) then the image is rotated and distorted automatically by the viewer. (IE: the height/width are right, but the image is rotated into this dimension)

I've been working around the 'issue' by running a script that resets the exif orientation flag on all images (thumbs/resizes/full) to '1' or "Top-Left" as this reflect the image appropriately once it is physically rotated.

I'll see if I can post up an example later.

I'm sure this is a bug in jpegtran, not the gallery itself. I'm probably using an older jpegtran that's not updating the exif flag when it rotates.

EDIT:
I see that this has been discussed before: http://galleryproject.org/node/109418
 
jnash
jnash's picture

Joined: 2004-08-02
Posts: 814
Posted: Wed, 2013-04-17 14:35

Bingo:

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1

Description of problem:
When you run "jpegtran -rot 90 -copy all x.jpg > y.jpg", the EXIF information isnt' re-written to contain the correct "Image Data/Orientation" field as it should be.

EXIF-aware applications will display the image incorrectly if this field is not correctly modified to reflect the true encoded orientation.


Version-Release number of selected component (if applicable):
libjpeg-6b-33

How reproducible:
Always

Steps to Reproduce:
1. Find a JPEG image that contains EXIF orientation data.
2. In nautilus, right click it, and view the EXIF data. Note the "Image Data/Orientation" field.
3. run "jpegtran -rot 90 -copy all x.jpg > y.jpg"
4. In nautilus, right click the new y.jpg file, view the EXIF data again, and not that the "Image Data/Orientation" field has not been updated.
 
jnash
jnash's picture

Joined: 2004-08-02
Posts: 814
Posted: Wed, 2013-04-17 14:37

and more:

jpegtran does not change the Orientation Tag when performing lossless transformations. The reason is that it cannot rely on the validity of the stated information, and it could potentially confuse other applications if it would mistakenly rely on the information and change it appropriately.

Furthermore, if you want automatic correction, then you must examine the field first to decide whether to call jpegtran at all and if yes with which transformation option.

Therefore, it has been found that the best solution to the problem would be to handle the examination and manipulation of the Exif Orientation field by separate utilities, not jpegtran.

To solve the task of automatic image orientation correction, we therefore provide two utility programs.

The first utility program is called jpegexiforient and is written in simple C. It only can read or write the Orientation Tag. It writes it out as ASCII character to stdout when called from the commandline.
 
jnash
jnash's picture

Joined: 2004-08-02
Posts: 814
Posted: Wed, 2013-04-17 14:44

Just posted for informational purposes... In case anyone experiences the issue.

(I was alerted by an iPad user that some of my images looked 'funny' [rotated and squished])

However, I'm thinking of patching the rotation code to update the exif tag as well. (at least for my use)

1) This will work for images rotated within gallery
2) This will still be broke as I use gallery_remote to upload pictures and I rotate within gallery_remote (also using jpegtran) prior to uploading
2a) Maybe I shouldn't rotate in gallery_remote and then turn on the autorotate module in gallery - which should then update the flag base on my patch...
3) hmmm