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

["Dr. Michael J. Chudobiak" <mjc avtechpulse com>]

> 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
I don't think it is wrong :-)


> this has the effect of not applying some transformations or applying
> them twice.
That would definitely be a bug. Can you document a reproducible example 
where a transformation leads to an incorrectly displayed image?

> If I can suggest a general policy to handle the Orientation tag:
Roughly speaking, the orientation tag is compensated for when loading an 
image into a pixbuf.
pixbuf data is always ordered the same way, so saving the pixbuf always 
results in top-left encoded data (whether the top-left orientation tag 
is there, or omitted entirely.) So a top-left tag is generally enforced 
at save-time.
Lossless rotation is a little different because it doesn't work on 
pixbufs. It works directly on files. But the basic idea is the same: 
compensate for orientation on the input, use a standard orientation on 
the output.
gThumb does try to keep things simple. Saving with top-left orientation 
is one of those simplicities. I don't see any advantage to changing 
that, personally.
2.10.x had the option to rotate by changing the orientation tag only. I 
think that's gone in 2.11.x. I don't think anyone will miss it.

> I know it's a topic you already discuss, I still have some pictures
> rotated by gthumb 2.10.x with invalid exit information inside :-)
I think 2.10.x generally did the correct thing (certainly the later 
versions did). Earlier versions did the wrong thing. See 
https://bugzilla.gnome.org/show_bug.cgi?id=343867 for some of the (long) 
history.

- Mike