Re: [gthumb-list] The Exif Orientation tag, again

[Jef Driesen <jefdriesen hotmail com>]

On 20/06/10 23:31, Stefano Pettini wrote:
> This is how I see the tag: it's merely an hint to the viewing software
> on how to display the picture. It has nothing to do with the X and Y
> resolution of the picture, the X and Y Exif dimensions, or any other
> kind of metadata that describes properties with a kind of horizontal
> or vertical concept. I see it as an extra hint to take into account
> one second before showing up a picture. All the image data and
> metadata should always be valid, with or without the Orientation tag.
> With this I mean that every Exif tag should always match how the JPEG
> is physically encoded, not how it's meant to be displayed. Exif
> dimension and X/Y resolution and so on should always match real
> parameters.

I agree with you that the metadata should match the physical data. If 
gthumb gets that wrong somewhere, that's definitely a bug.

But that's also what makes a physical transform difficult to implement 
correctly. Every single piece of metadata that is related to the 
dimensions needs to be adjusted too. And it's very easy to forget one, 
because there are many types of metadata (exif, iptc, xmp, tiff, etc) 
and even proprietary extensions like exif makernotes.

That's why I personally prefer transforms using only the exif 
orientation tag. Only a single byte needs to be changed, and all the 
other metadata remains correct at all times.

> Looking at the code and behavior of the latest gthumb, we reset the
> Exif orientation tag during lossless rotations. I think it's wrong and
> this has the effect of not applying some transformations or applying
> them twice.

It's the correct behavior, and I'll illustrate with a simple example why.

Assume you have an image with an orientation tag that says "rotate 90° 
clockwise", most likely because you had your camera rotated while taking 
the photo. If you have a modern exif aware viewer like gthumb, it will 
show your photo rotated correctly. If it doesn't take into account the 
exif orientation is will show up without the rotation, which is of 
course wrong.

Now, if you physically rotate the image data (lossless or not doesn't 
matter here) but don't reset the orientation tag, your image will show 
up correctly only if your viewer doesn't take into account the exif 
orientation. But the exif orientation still says "rotate 90° clockwise", 
so any exif aware viewer will apply an extra rotation, and you end up 
with a double rotation.

So you only have two correct options:

1. Rotate physically AND reset the orientation tag to top-left (which is 
equivalent to no orientation tag).

2. Rotate by updating the orientation tag, and leaving the image data 
untouched.

The reason why earlier gthumb versions created images with invalid exif 
orientation is because it *didn't* reset the orientation tag. The same 
problem happens if you rotate an image with a non exif aware 
application. If it doesn't know about the tag, it won't reset it either. 
That's why gthumb 2.10.x had a reset orientation tool to fix those images.