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



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]